Leadership Garden
I watched the same feature get built twice this year.
The first build took a weekend. One engineer wanted to export the data behind a chart as a CSV, described it to an agent, got a working implementation back, and had it running on her laptop by Monday. She showed it around. Everyone agreed it was slightly absurd how fast that had been.
The second build was the same feature inside the actual product. It took most of a quarter.
Nothing in the second version was harder to write. The code was, if anything, duller. The model was equally good on both occasions, which means the difference had nothing to do with the model.
If you lead an engineering organization, somebody senior is going to ask you why the second number is not collapsing toward the first. You need a better answer than “enterprise is complicated,” because that answer sounds like an excuse and half the time it is one.
The claim is smaller than the headline
Every few weeks someone announces that coding is solved. If they mean that a clearly specified problem can be turned into working code with very little human effort, they are close to right and getting righter. I have stopped arguing with that part. Watching an agent produce a competent implementation of something I described in two sentences still lands somewhere between useful and unnerving.
But look at what got measured. A specified problem went in, and code came out. The specification was the input.
Somebody produced that specification. In the weekend version, it was the same person who wrote the prompt, in her head, in about four minutes, answerable to nobody. In the product version, it took eleven weeks and involved most of a department.
What actually happened to the CSV button
The second build did not spend eleven weeks writing an exporter. It spent eleven weeks getting to the point where writing the exporter was a decision anyone could make.
An export already existed in an internal admin tool. It was built four years ago by a team that no longer exists in that shape, and it works, and nobody is sure what would break if it were reused.
Legal wanted to know whether this data was allowed to leave the product in a downloadable form at all. The answer lived in customer contracts, and the contracts did not agree with each other.
The service holding the data was not the service rendering the chart. The boundary between them was owned by a third team with a roadmap of their own and a strong opinion about what belonged on their side of it.
Then someone remembered that this had been shipped in 2023 and rolled back within a month. Nobody could produce the reason. Two people had two different stories, and both were plausible.
An agent could have written all four candidate implementations in an afternoon. What it could not do was tell anyone which one to write, and that was the entire eleven weeks.
We named the discipline after its most expensive part
For most of the history of this profession, producing the code was the slow step. Other steps were hard, but that one reliably dominated a schedule, so the discipline got named after it. We call ourselves software engineers and we mean, mostly, people who write software.
That naming was accurate for a long time and it is now doing damage, because when the expensive step gets cheap, the thing you named after it does not shrink. Everything else it was hiding becomes visible instead.
I keep seeing leaders read a productivity number, see that implementation got three times faster, and expect delivery to follow. Delivery moves a little. Then it stops. The tools did not fail. Implementation was never the whole cost, and the arrival of a cheap implementation is what makes that impossible to keep quiet about.
Four layers, and one of them got cheap
Any change worth shipping has to survive four questions, and they do not all live in the same place.
At the bottom, how do we express this in code? Above it, how should the system produce that behavior, given what already exists? Above that, how should a person experience it? And underneath all of it, the one that decides whether the other three were worth answering: which problem are we solving, and for whom?
Models are becoming excellent at the bottom question. They are useful at the second one, if you tell them enough, but they usually can’t make up for lacking judgment. They have opinions about the third that are worth roughly what an opinion from someone who has never met your users is worth.
The fourth question has not moved at all.
That is the shape of the thing. The layer that got automated is the layer that was always the most legible because it was the only one written down.
Context is everything that the repository does not contain
What separated the weekend build from the product build was not talent, and it was not tooling.
An organization knows things. Which abstractions are load-bearing and which were abandoned in place? The domain language, including the two words that mean the same thing for a historical reason that annoys everyone. Which parts of the system are permitted to fail? Which single customer is the reason for that odd flag in the config? Whether a given architectural decision was a real choice or just something that happened while nobody was watching.
Almost none of that is in the repository. Some of it is in a wiki that was last accurate two directors and reorgs ago. Most of it is distributed across people, unevenly, and reassembled in meetings.
A startup grows this as it goes, which is why small companies feel so fast and why that feeling does not survive their first hundred engineers. An enterprise inherits decades of it from people who have left.
So asking a model to build something new is a fundamentally different request from asking it to change something old. The greenfield task has one specification. The brownfield task has one specification plus every decision the system has ever absorbed, and the second list is not written anywhere you can point at.
That is not a complaint about models. It is a description of what we have been asking senior engineers to hold in their heads, unpaid and unacknowledged, for their entire careers.
What I would actually do with this
None of what follows is about tool selection.
Stop measuring adoption by output. Lines merged and pull requests opened tell you the bottom layer sped up, which you already knew. The number worth watching is how long a change waits between someone asking a question and someone being able to answer it. That gap is where your quarters are going. Measuring that gap is miserable, which is why almost nobody does it and why everyone reports merge counts instead.
Move your strongest people up a layer on purpose. This happens by accident anyway, and it happens badly. Your best engineer starts spending her week answering the questions the agents cannot answer, and because that work has no artifact, her next performance review is quieter than it should be. Make the move explicit. Say out loud that the job is now framing problems and adjudicating between plausible designs, and then evaluate her on that rather than on throughput; she is no longer producing.
Write down decisions instead of explanations. Documentation that describes what the code does has never had a shorter shelf life than it does now, since anyone can ask an agent that question and get a better answer than the wiki would have given. Documentation that records why a boundary is where it is, and what was rejected, is the only kind that still pays. Almost nobody writes it, because writing it means admitting a decision was made by a person who could have chosen otherwise.
“So write the context down”
The obvious objection, and I have had it put to me with some force by people who are better at this than I am, is that all of the above is a documentation problem wearing a philosophical hat. Put the conventions in a file the agents read. Record the boundaries. Solved.
Try it and watch what surfaces.
You sit down to write the rule about that service boundary, and you find there is no rule. There was a decision made in a hurry in 2022 by someone who has since left, which everyone has been treating as policy because it has survived. You go to record why the export was rolled back, and you get two accounts that cannot both be true. You try to write down which team owns the notification path, and you discover that the honest answer is a sentence with the word “basically” in it.
Writing it down is worth doing. An audit finds things, and that is the whole value of running one. What it is not is a weekend of technical writing, and anyone selling it that way has never tried to write the difficult page. The reason your context is undocumented is rarely that nobody got around to it. More often, documenting it requires somebody to decide something that has never actually been decided.
Every layer gets its turn
There is a comfortable version of all this where the abstraction simply rises, the way it did when compilers took over machine code, and everyone moves up and gets on with their lives.
I would be careful with that story. Every previous step made the layer below genuinely invisible. Nobody reads compiler output. Nobody audits the assembly. This step has not done that, and might not for a while. The code is still yours, you still own it at three in the morning, and you still have to understand it well enough to know when the confident thing you were handed is wrong.
Which means the work above implementation did not get lighter. It got more crowded, and it got crowded faster than most organizations have adjusted their structure to handle.
Code is the medium
Nobody has ever been paid to produce source code. They have been paid for what the code does once it is running, in front of people, inside a business that needed something to change.
We forgot that for a couple of decades because producing the code was hard enough to feel like the point. Code was never the point. Code was the expensive part, and expense makes a convincing impostor.
So is coding solved? For turning a clear specification into working software, close enough that arguing about it is a waste of a good afternoon. The interesting shortage was never there. It was in the eleven weeks it took to earn a specification worth handing to anything, and no one has automated that yet.
Go and look at where your last quarter actually went. If the answer is not “writing the code,” and I do not think it will be, then you already know which part of the job to get better at.