--- title: "What building with AI changed about how I work" slug: what-building-with-ai-changed-about-how-i-work section: tech date: 2026-09-06T22:47:00.000Z canonical: https://roland.leth.ro/blog/tech/what-building-with-ai-changed-about-how-i-work description: "Working with Claude Code since the spring: I type much less and decide much more. Where the deciding lands, what it costs, and what I'd tell someone starting." --- Claude Code has been how I work since the spring, and the short version of what changed is that I type much less and decide much more. That’s a bigger shift than it sounds, because deciding used to happen while I was typing, spread thin across an afternoon and mostly invisible to me. It doesn’t work that way anymore, and the deciding has to happen somewhere. ## Where all of it lands The through-line of everything I’ve written here is that the model is quick and fluent in the middle of a task and has no opinion about its edges. Sometimes it does, which makes it more dangerous, but don’t be fooled. It doesn’t know what I consider good or finished, so that has to be written down. It doesn’t remember what was decided last week, so that has to be written down too. It reports on what it did rather than on what happened, so the report is a claim and not a result. And it won’t look underneath the thing I asked for, so assumptions nobody wrote down get inherited as fact, including ones I never made. None of those are complaints, they’re properties. Each one has a fix, and each of the fixes happened throughout this year, after getting bit by them. ## What it costs The setup and harness configuration is never finished, which I’ve stopped treating as a problem. The most recent addition to mine is a few days old and came out of planning these posts, and there will be another one the next time something goes wrong in a way I don’t want repeated, or when I’ll want something tweaked in my workflow. More code arrives than it used to, so more reviewing happens than it used to. There was a stretch where features landed faster than I could look at them properly, and the reviews that followed were mostly filling gaps rather than catching mistakes, which is what going faster than you can think looks like from the inside. No amount of tooling fixes that, because it’s a pace decision, just be aware speed can bite you and calibrate accordingly. The time saved also isn’t where I expected. Typing per se was never my bottleneck, and it turns out writing the code was a smaller part of the job than working out what the outcome should be. What I got back is the ability to brainstorm, to take a direction seriously, build enough of it to see whether it holds, and throw it away without losing too much; it used to be expensive enough that I’d do it once and then talk myself into keeping the result. I’ve always loved building products and getting involved in business, product and UX decisions, so now I’m doing more of this and less code typing, which fits my needs perfectly, so from my perspective, it’s not a cost, it’s a bonus. ## What I’d tell someone starting Write down the thing you’ve corrected twice. Decide before it writes rather than solely relying on reviewing after. Assume nothing carries between sessions unless you made it carry. Read every report as a claim rather than a result, and go and look at the thing itself when it matters. And when a stretch of work is going unusually well, treat that as the moment to check what you assumed at the beginning, just to make sure the model is aligned. AI likes to talk, a lot. It will also respond with jargon, complex technical wording, give you mountains of data as evidence and none of that is wrong, but sometimes it’s hard for us, as humans, to follow it. When that happens, ask it to explain in plain terms, or as if you were a user, or even ask it to ELI20-25 (explain like I’m 20-25). It will give you something significantly easier to understand and digest. Take your time to configure the model to your preferences, needs and style. Take your time to update them whenever you’re hit with a problem. Take your time to read other people’s rules and skills and maybe adopt a few, or get inspired to create some of your own (tip: your model can help with that as well). I don’t know how much of this survives the next year. The mechanisms keep moving, and the files I’ve described will probably look different by then, as they are different now from 6 months ago, or might be replaced by something better. The habits underneath have been steadier: decide first, write it down, check the claim, ask what I assumed, make sure the model holds my premises and assumptions. Those haven’t really needed updating much, if at all. I haven’t covered everything in this series, that’d make it neverending, but I hope I covered enough to give you a sense of what a model lacks, what it needs from you, where it can fail, where it needs a nudge and where you should invest your time when setting up the harness. Questions, disagreements, or your own version of any of this: [@roland.leth.ro][] or [@rolandleth][]. The rest of the series is listed in [What changed my mind about building with AI][series]. [prev]: /blog/tech/the-model-wont-question-your-premise "The model won’t question your premise" [series]: /blog/tech/what-changed-my-mind-about-building-with-ai "What changed my mind about building with AI" [@roland.leth.ro]: https://bsky.app/profile/roland.leth.ro "@roland.leth.ro on Bluesky" [@rolandleth]: https://x.com/rolandleth "@rolandleth on X"