AI Agents and the Future of Software Development

What changed, concretely

A year ago, adding a fourth language to this site meant a long afternoon of mechanical edits. Recently it was a single instruction and a review pass. That is a real change in what a working day can produce, and it happened without any change in how well I understand the system.

The parts that got cheap are the parts I never enjoyed: renaming a concept everywhere, wiring a new field through five layers, writing the same test in a different shape. The parts that stayed expensive are the ones that decide whether the software is any good.

The bottleneck moved to specification and verification

When code is abundant, the scarce thing is knowing exactly what to build and being able to prove it exists.

I spend more time now writing a precise problem statement than writing code, and more time checking deployed behaviour than checking a diff. Twice in the last month a change compiled, passed its type checks and did nothing, because a serialiser dropped a field and because a generated file was produced before the data it needed existed.

An agent would have closed both tickets as done. Neither was done.

What I do differently

Smaller changes. A diff I can read in one sitting, verified in production before the next one starts. A rollback that I have actually tested. Tests that assert behaviour a customer would notice instead of implementation details that flatter a coverage number.

And a clear rule about facts: I do not let generated prose assert anything I cannot point at. Case studies on this site are assembled from data that already existed, not written from imagination, because a confident paragraph about a customer that does not exist is worse than an empty section.

What agents still cannot do

They cannot decide what the product should be. They cannot tell you that the feature you asked for will confuse the user, or that the business rule is wrong. They cannot know that the number in the paragraph is false unless something in the repository says otherwise.

They are also unreliable about failure. A model will report success because the operations it can see succeeded, while the actual outcome was dropped three layers later.

The prediction I am willing to make

I expect software teams to split by discipline rather than by headcount. Teams that already had tests, review and a rollback path will move faster than ever. Teams that shipped by intuition will ship more code they do not understand, and the failures will be quieter and more expensive.

The technology does not change what good engineering is. It changes how quickly the consequences arrive.

What I would tell a junior engineer now

Learn the system underneath the tool. Understand the request, the queue, the transaction boundary, the deployment. The model will write the code faster than you; the person who can say why it is wrong will still be the one who matters.