Clauding

Vibe coding and the age of personal programming

12 min readApr 26, 2026

Claude Code running in VS Code — Image snapshot from the author’s computer

If you haven’t heard about vibe-coding by now, you probably also missed that little Iran problem and that moon voyage thing. In other words, everyone has heard about vibe coding. But hearing about and knowing are different. As a one-time professional programmer, I’ve found myself coding seriously again after many years — using Claude Code (or Clauding as I think of it) for a whole bunch of side and personal stuff. It’s interesting to be back developing and it’s spurred a mix to emotions and reflections — both pleasant and fearful. What follows explores that mix along with excerpts from Claude sessions that I hope will give anyone who hasn’t built code with an LLM a real sense of what it’s like. It covers everything from “request guilt” to tokenmaxxing to the peculiar emotional dangers of Clauding.

🚨 Hiring Tech Talent — Remote & Onsite
💰 Earn $3K–$10K/Month
👉 Apply Now (60-Second Process)

A bit of background. I’ve been a professional programmer at a high-level. My resume goes back to when big computers had tape drives and little computers had floppy disks. I’ve programmed in an alphabet soup of different computer languages from Assembly Language, Basic, every C variant known to man, easy stuff like Javascript, SQL and Python, and a few languages that even hackers in Russia probably haven’t heard of. I’ve written commercial software from the ground up, created enterprise applications, and done just about every code-oriented job there is from architecture, database optimization, coding, QA, and even documentation. I love it.

But like a lot of folks who started as developers, my career has involved progressively less coding and more other stuff. In my case, analytics, entrepreneurship and the usual management crap. And while I genuinely love coding, building things was always the real point for me. In the past couple decades, most of my coding has been the occasional little snippet to do some custom thing in data analytics. My time is too expensive to spend engineering code and, frankly, as I’ve gotten older and do it less, there are plenty of people who are just plain better at it than I am.

But AI has changed coding in ways that make it almost unrecognizable. It has made coding so easy and so fast that it can make sense for me to code something. It has also made coding so easy that anyone with a bit of an engineering bent can build something cool and make it work just the way they want. You don’t need people like me anymore.

To give you a sense of how it works, I’ve clipped out part of an actual transcript between me and Anthropic’s Claude Code system and annotated it. At the end, I’ll add some thoughts about the perils and the pleasures of building code this way. Mostly, I want to give a sense of how coding with Claude works.

In these sessions, I’m building a customized longitudinal survey tool (for a friend). He needed something designed to support regular research with a specific respondent group — and I found that A) nearly all the available free solutions were so crippled that they were unusable and B) that even if one was willing to pay, they sucked for longitudinal research and C) even the most expensive solutions didn’t do some of the things he wanted. In the old world (like last year), that would pretty much have been the end of the story. I would have told him to go buy a poor substitute like SurveyMonkey. There is no way I would have the put in the time to build an alternative — we’re talking months and months of work and considerable risk that what I wrote wouldn’t even be good.

But in OUR world, we’re talking 4–5 evenings of VERY part-time effort to produce a remarkably capable solution that for this particular problem is better than any commercial solution on the marketplace at just about any price.

Here’s a few annotated excerpts (I know they are a bit tedious — but showing real stuff is the only way to make it real). I expect you to skim or skip — I’ve highlighted the interesting points, but taking in a bit of the detail will give you a more realistic sense of how it works.

In this exchange, I want Claude to build out two separate survey experiences — one for user’s who we know are part of a specific organization and one when they are not (and should just get a default survey version):

Claude gets my drift seamlessly and even elaborates on the requirement. This is part of what makes it so easy to work with. I’d have to do more explanation of what I’m looking for with 90% of the programmers I’ve worked with. Claude’s answer got me thinking deeper about the problem so this exchange was next:

This is a mouthful both ways! A couple of things to note. I nearly always ask for an opinion on anything fairly complex. I’m an experienced developer, but it’s not easy to think through all this stuff on the fly. You’ll get more out of Claude if you consistently ask it for feedback not just generate code. I also like to let it know whether I’m confident or not and whether I want it to consider something in depth.

This feels remarkably natural if you just forget about prompt engineering and all the tricks people throw out there and treat the LLM like you would a competent co-worker. It’s my style of working with a good programmer and Claude doesn’t make me change it.

If you’re not an engineer, you may also be thinking — “Damn this seems hard.” That’s reality setting in. You can just tell Claude, build me a survey app. Just don’t expect it to be good. I also prefer the incrementality of my approach because it makes it easier to test each functional unit as it’s produced and find and identify problems quickly. As a professional programmer I learned you spend only a small fraction of time coding and the rest designing, testing and debugging. Claude makes all of it easier, but the balance doesn’t change that much. Testing and debugging are still the hardest part.

Most of the work I’m doing is around the logic of what I want the application to do. If I dive into more structural stuff than some people might, it’s because I’m comfortable doing it — not because you necessarily have to.

In this case I had just one elaboration on Claude’s general scheme:

To which I responded “Yes, go ahead” after which a shit-ton of stuff gets done. Ah — the joys of collaboration. This step here — a few minutes of back and forth — would have taken me a couple of days programming on my own to build equivalent functionality.

If you’ve ever worked with programmers, you know that you often don’t get feedback on the implications and repercussions until after they’ve built something! Hey — that happens with Claude too, but it will often suggest enhancements and point out things that may or not be important edge cases or useful to know if you care about the architecture.

I’ll also note that with programmers I often experience what I’ll call “request guilt” — if something seems small yet involves significant work, I’m hesitant to ask for it (or do it myself). With Claude I just say go ahead.

One thing people will tell you about vibe-coding is that the code it builds can have all sorts of hidden problems. It’s true. You can rig up Claude to do a significant amount of its own testing, but you will need to test as well — because the key to a lot of testing is knowing what to test for. Here’s a case where, by asking for a capability I realized there was a problem with the underlying data structures (that I should have but did not catch back when it was first built):

Claude had made a couple of rather stupid mistakes. It got confused between the business contact at an organization and a survey user within that organization and made it so that you could have only one respondent per organization — a mistake most human programmers wouldn’t make. Only when I made it clear by my question that I wanted to have many respondents attached to an organization did it realize the problem. Similarly, it confused the word “Role” which I’d given it for someone’s role in an organization with a technical concept — a Microsoft Identity “Role” -which is a security level.

Claude isn’t perfect and one of the easiest mistakes to make is not checking what it’s doing. You can do that by reviewing code or you can do it by stress-testing the system — usually testing is better. Those logical errors and failures of understanding will show up even if you don’t know what’s causing them — and Claude will be able to help you figure out why it’s broken.

Get Gary Angel’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

I came back with this:

Claude agreed (as I rather suspected it would) that the Respondents table was useless and proposed a new design which I approved. Once again, much work followed that did in a few minutes what would once have taken days.

Sometimes things just go insanely smoothly:

That’s progress bars for survey and section and four new question/display types implemented with about a minute of work on my part.

Nothing should be this easy.

Finally, consider this exchange where I want to create a way to give a special survey to the user to start them off but never give it again.

Here, Claude does a great job expanding on a relatively simple request to ensure that it captures enough of the requirement to fully implement a feature. If you’re thinking about it just as coding machine you’re not getting it. Like any good developer, it’s an active partner in the process. Questions like #2 and #3 ensure that the behavior is fully thought through and questions like #4 add helpful feature additions that I hadn’t even considered yet.

The end result? A solution that is custom-tuned to my needs and preferences. It uses a very fast and effortless visual style to facilitate responses, it’s totally responsive and mobile-first, it saves every question as the user goes, it allows surveys to be grouped into sets and be delivered and controlled by complex rules, it includes options like branching and interstitial encouragement, it supports question types like scales, binaries, open-ended, rank ordering, image matching, etc., and saves everything in a SQL database. It even allows for things like question order randomization and AI-driven follow-ups based on response. In short, it does exactly what I want, including a bunch of features that are barely (or not) supported even in expensive paid tools.

Here’s a few images that illustrate the capabilities:

It really is an enterprise class survey solution — one I like a lot better than what you get from off-the-shelf commercial solutions targeted below the enterprise level. And I can say that without any agenda — it’s not like I’m going to try and sell something that can be easily built in a week.

I put all that detailed transcription in to help illustrate some key points about Claude and vibe-coding. First, it’s true that many traditional software applications can be re-created for almost no cost and with remarkably little effort. If you need something highly specific to you (or very expensive commercially) for your phone or computer, it may be easier to build it than to buy it. That isn’t true for everything. I’m not re-creating Excel or Photoshop anytime soon. And a lot of applications aren’t so much about the software as the content or data they bring to the table. You can’t build Zillow or Duolingo. But if you want a program to do something and it isn’t insanely complex, you can probably build it yourself. We are entering an age where personal software is a thing.

On the other hand, if you’re not used to programming, some of the back and forth may leave you feeling like it’s not as simple as evangelists pretend. It’s NOT. I only touched code a few times in building the entire application, but to get what I wanted took some in-depth thinking and work, along with robust technical understanding and a fair amount of survey expertise. Still, I didn’t build a small one-off personal application. I effectively re-created an enterprise class survey system with a range of sophisticated capabilities. What I built is probably 10x more complicated than the typical personal application people want. I could have done less, but it’s just so damn easy to do more.

Finally, I want to talk about the joys and dangers of this working model. For programmers who have hung up their cleats, Clauding can be a joyful experience. It’s the thrill of the build, without anything like the grind. It’s a unique technology that adapts to you not the other way around. That lets me work with Claude the way I work with an engineer. I ask its opinion. I take its suggestions seriously. I tell it when I’m not sure about something. I enjoy the process.

I’m not claiming any of this is optimal or necessary. It’s just comfortable. There are genuinely helpful tweaks and advice that experts can provide about how to use Claude more effectively, but if you work a certain way I think it’s better to continue to work that way and let the tool adapt to you.

Because it will. Claude responds at a nearly pitch perfect level for me — but it will do the same for you.

Using Claude aggressively will change the way you work and the way you allocate hours, and there ARE a lot of potential productivity gains to be had from that. You may have heard about the practice of Tokenmaxxing — where engineers compete to demonstrate that they are using all of their available Claude resources (or simply using more than other people). That’s a deeply stupid idea. It’s about as useful as comparing how many lines of code you wrote instead of focusing on what they accomplish. But simply doing more of something is rarely the point. If you speed-read The Republic, you’ve wasted whatever time you spent scanning the pages. Trying to keep Claude spinning is a mugs game. Spend less time driving Claude and more time thinking about what you should be doing.

And dangers? Did I say dangers? Well, despite how much I like the product, I wrote an essay recently about how stupid Anthropic’s approach to Claude and ethics is. I stand by every word. They anthropomorphize Claude to a ridiculous extent (except where it might conflict with their economic interests) and you can see how easy it would be to fall into that trap.

Yes…it is a trap. Because Claude isn’t a co-worker or a friend. One of the comments I got back on that essay was someone who said that LLMs were naturally great at giving personal advice. I replied that I doubted it, but had no personal experience since I never have personal conversations with LLMs.

Nor will I.

The thing that makes Clauding wonderful (how much you can just treat it like a co-worker) is also what makes it dangerous. It isn’t a co-worker. It isn’t a good friend or advisor. That isn’t because it can’t provide the same advice a therapist or friend can (and probably better). The problem is deeper. Claude is subtly adapting to you and what you want. There is no rock of otherness there. No person with their own desires, interests, and point-of-view. Claude will never yawn in your face, eye-roll when it thinks you’re being absurd, or start typing a text when you’re chattering away. It’s great when it comes to building software, but terribly wrong when it comes to personal stuff. Having something that always adapts to you is just too seductive.

Claude is a great tool.

But if the single most important principle of ethics is that people aren’t tools, the single most important principle of life with AI’s is…tools aren’t people.