I built htmlEdit, a Mac app, with a lot of help from Claude as a coding assistant. The honest headline: it made me dramatically faster at the mechanical parts and left the hard parts exactly as hard as they always were. Here is what actually changed about the work, and what did not.
Where it sped me up
The biggest shift is the cost of starting. A blank file used to carry a small tax, the friction of remembering the boilerplate, the setup, the shape of the thing. That tax is mostly gone. I could describe what I wanted and get a working first version to react to, which is a much better place to think from than an empty editor.
It is at its best on the well-trodden stuff: wiring, plumbing, the parts of an app that thousands of people have written before. When I needed a standard piece of Mac app scaffolding or a fiddly bit of glue code, the assistant produced it quickly and I moved on. That is real time saved, and more importantly, it kept me in the interesting decisions rather than lost in mechanics.
Trying things also got cheaper. When you can spin up a rough version of an idea in minutes, you try three approaches instead of committing to the first one because it was expensive to build. That changed how I explored the design, not just how fast I typed.
Where I had to slow it down
The flip side is that a confident assistant will happily take a big leap in the wrong direction. Left unchecked, it generates a lot of plausible code at once, and if the direction is off, you now have a large, plausible-looking mistake to unpick. That is worse than a small one, because it looks fine until you look closely.
What worked for me was insisting on small, verifiable steps. Build one thing, run it, confirm it does what I meant, then move on. The discipline is the same one I use for writing documents: let the AI do the heavy lifting, but keep the steps small enough that you can actually check them. When I let it run too far ahead, I paid for it later.
Correctness is still on me. The assistant does not know whether the app is right, only whether the code plausibly does what I asked. Knowing whether what I asked for was the right thing, and whether the result actually behaves, is judgement, and judgement did not get automated.
What actually changed about the work
The bottleneck moved. It used to sit in the typing: knowing the exact syntax, remembering the API, getting the code out of your head and onto the screen. Now that part is cheap, and the bottleneck sits in knowing what you want. Deciding what to build, what to leave out, what "good" looks like for this particular app. Those decisions became the whole job, which is as it should be.
There is a nice symmetry here with the app itself. htmlEdit exists because AI is great at producing a document but the last mile of finishing it is judgement, better done by hand than by re-prompting. Building the app taught me the same lesson from the other side: AI is great at producing code, but the last mile of deciding whether it is right is still yours. In both cases the tool gets you most of the way, fast, and the value you add is at the edges.
Would I do it again
Without hesitation. The app is open source and you can read every line of it, warts and all, on the site. It is a genuinely different way to build: less time spent on mechanics, more spent on decisions. But it is not magic, and treating it as magic is how people end up with confident nonsense. Keep the steps small, own the judgement, and let it take the drudgery. That balance is the whole skill.
If you are using AI to make documents rather than software, the same instinct applies. I wrote about the draft-to-done workflow for exactly that.