AI and me
I'll admit I was an AI skeptic at first. It looked like another bubble, much like crypto. But after using it bit by bit, I've had to revise that view: these tools are genuinely useful. The shift came when I started using them to spin up alternative implementations for architecture discussions. Writing code quickly is useful in itself, but the real value is in prototyping: giving a design conversation something concrete to argue about. We've all been in the architecture discussion that ends with someone saying "show me the code." They're right to ask. To judge a solution, you need to touch it and see where it breaks.
The thesis
The best way to make an architecture decision is to have several working versions of the same problem in front of you.
The mechanism is simple. A design discussion that stays abstract is cheap and comfortable, which is precisely the problem: nobody can see the flaw until there is something concrete to point at. "Show me the code" is not an engineering team being difficult; it is a request for the only evidence that will settle the argument. A diagram proves nothing. Working code — however rough — exposes what no amount of whiteboard reasoning will surface.
The real cost, then, is not writing the code. It is being wrong. As long as a wrong turn is cheap, you can afford to try two or three shapes of the same problem, put them side by side, and compare them on what they actually do. Which one handles merging two user accounts when one has already been deleted? Which one degrades gracefully when the store rejects the payload? You find out by running it, not by agreeing that it sounds reasonable.
It looks a bit like this:
This is what AI changed for me, more than the writing itself. Generating a second and third version used to cost me the time it took to write them, so I mostly didn't. Now the third option is cheap enough to be worth having, and the conversation moves to what was always the expensive part: deciding which one we want, and why.
That is also why I am not especially excited by the "code is written by machines now" narrative. If the writing was never the point, a tool that writes faster is not the interesting development. The interesting development is being able to afford to be wrong three times instead of once.
What I've handed over
Code isn't written anymore; it's requested. That is a loss, in a way. The blank page, the problem, the small triumph of the thing compiling on the first attempt — that used to be the best part of my day. I won't pretend I've made peace with giving it up. But peace isn't the point. It is hard to justify spending an afternoon writing by hand what a machine can produce in minutes, when the writing was never the part that needed me. The craft is still real, but it is no longer where the leverage is, and holding on to it out of love is just slow.
What I get in return is what I described above: a third option, cheap to produce, before I have committed to a shape. That is worth more to me than the typing ever was. I just didn't expect it to arrive by this route.
What I haven't
Architecture and UI are the two areas where, for now, I believe people still have the edge — and I want to be precise about why. In architecture, the model lacks institutional and historical context. In UI, the resistance is different: the subtle, hard-to-prompt nuances of taste, spatial intuition, and micro-interactions that belong to a particular product.
I can hold the context of my company, my product, and my users in my head at once. Not because I am special, but because I have been in the same building for years, and the accumulated weight of it is simply there. I know which edge case keeps coming back. I know which part of the product nobody touches because it is unpleasant to maintain. I know that the user who wrote in last week is frustrated in a specific way that changes what "the right thing" means here.
For an AI to have that, someone has to put it in the prompt every single time. This is not a fair comparison, and I am not making one — the asymmetry is structural. It means that the more consequential the decision, the more context it requires, and the less reliably a model without that context will land on the answer you want. Capability scales. Context doesn't.
Which is why I think this is the least glamorous and most important part of the job: not producing more code, but knowing what is true about your own product well enough to reject a plausible answer.
The hidden tax of reading
The resulting code is not the best code. Written by hand, it could be better — not a criticism of the tool, just the terms of the deal. What I lose is the intent. When I type it, I know why that branch is there and what I was trying to avoid. When it is generated, I have the output and, at best, a plausible account of the reasoning. That is why I still believe every change needs human review — and why anyone who skips it because the output looked convincing is reviewing with their hands over their eyes.
A wrong answer arrives with the same length, the same confident tone, and the same tidy structure as a right one. That is the part that still costs me: not the writing, but the reading I can't skip. Review stops being verification and becomes reconstruction.
So where should we focus today? On what has always mattered: making the decisions. The bottleneck was never the code. I have spent my career being slowed down by not knowing which way to go, and no amount of code removes that. If anything, a surplus of confident answers makes deciding harder, not easier — which is why I don't think this is mostly a productivity story. It is a decision-making story, and the decisions are still ours.