Agents are going to write all the code

Predictions about this technology have a short shelf life. One calibration trick I like is to take a confident claim about AI and substitute "the cloud." It is a useful reminder of how difficult it is to distinguish a consequential shift from the particular future we have imagined for it. We can recognize that something important is happening and still be wrong about where the value will accumulate, what people will build, and how their work will change.

That uncertainty matters, but it need not leave us unable to act. You don't need a crystal ball to read a river. Coding has become a central measure of frontier-model progress, and the teams I know that have learned to work effectively with agents are not looking for a way back. More of the effort that once went into producing an implementation is moving toward deciding what to ask for and establishing whether the result is right.

My bet is that agents will eventually write essentially all the code. I don't know when, and there will be exceptions, but I expect the distinction between "all" and "nearly all" to become less important than what happens to the work around it.

For people who love programming, that is not an uncomplicated prospect. There is real pleasure in finding an elegant expression of an idea, in learning a language deeply enough that it begins to feel like an extension of thought. The prospect of that craft becoming cheap and abundant can feel like a loss even when the new capability is useful. I feel that loss too. An argument about productivity does not make it disappear.

Still, the craft has always sat inside a larger responsibility. We write code because we want something to exist, and then we have to understand what we have made: how it behaves, where it fails, what it asks of its users, and what happens when it changes. Writing the implementation has been one way we develop that understanding, not merely the means by which we produce an artifact. As agents take on more of the implementation, we will need to become more deliberate about how that understanding is acquired and maintained.

This is where expertise becomes more consequential, not less. A system does not become easier to govern simply because it becomes easier to produce. Cybernetics gives us a useful way to think about this: a controller needs enough range in its responses to handle the variety of disturbances that matter. In engineering terms, generating more software is only an advantage if we can still distinguish useful behavior from failure and intervene effectively. Agents can help us do that work too, but their capacity to produce an answer is not evidence that we have established its adequacy.

The organizational consequences follow from there. When implementation gets faster, requirements, review, integration, and operational judgment do not automatically accelerate with it. Work accumulates at whichever boundary can no longer keep up. Relieving that constraint may expose another, so the experience of adopting agents can be oddly frustrating: a team gains a remarkable capability without immediately becoming a remarkably more effective team.

That is why I think this is better understood as a redesign of engineering work than as a tools rollout. The difficult questions concern how an organization forms intentions, tests its assumptions, establishes confidence, and carries responsibility for what it ships. Licenses provide access to the technology. They do not answer those questions.

The learning involved also explains why the adoption curve matters. A team that has spent eighteen months experimenting has had time to discover which tasks are tractable, which apparent successes are misleading, and where its existing practices stop working. Those lessons can become part of how the team operates rather than remaining tricks known to a few enthusiastic individuals. New tools may make some of that knowledge obsolete, but access to the same model does not, by itself, give a later adopter the same judgment.

None of this requires abandoning skepticism. It requires making skepticism productive. A disappointing interaction with a chatbot tells you something about that interaction; it does not settle what a team could accomplish with a different workflow, better context, or a way to check the result. The useful question is what evidence would change your assessment, and whether your experiments are capable of producing it. That standard should apply equally to the enthusiast announcing a revolution and the skeptic announcing that nothing has changed.

I don't expect the destination to be simply good or bad. Automation can remove work we value as well as work we would gladly surrender, and the responsibilities left behind may be harder than the tasks it absorbs. I love writing code, and I expect to do less of it. I also expect there to be a great deal of engineering worth doing. Learning how to do that work well is how we earn a say in what comes next.