Programming in the age of AI: what actually changed

The debate about AI and programming has two camps and both are wrong. One says developers will be replaced within a year. The other says it is a toy that writes broken code. The reality is duller and more interesting at once.

What genuinely changed

Not the ability to write code. That was always the easy part of the job.

The ratio changed. A developer used to spend a large slice of the day on things they knew how to do but still had to type out: writing the test that mirrors the one next to it, generating CRUD, converting data from one shape to another, looking up syntax in the docs. Routine that needed no thought, only time.

That layer got dramatically cheaper. Which is good news, because it was the tedious part.

What did not change at all: deciding what to build. Understanding why it should be this way and not that. Working out why the system falls over once a week at 3am. Telling a client that what they want is a bad idea.

The centre of gravity moved from writing to reading

This is the most significant change, and the least discussed.

When a model gives you eighty lines in ten seconds, your work is not done — it just started. You have to read that code and decide whether it does what you think it does. And that is harder than writing it, because writing builds understanding as a side effect. Reading requires you to build it deliberately.

Model-written code also has one insidious property: it looks good. Well-named variables, comments, consistent style. Exactly the signals we have used for years to judge quality at a glance. Except here they guarantee nothing.

We once reviewed a function that looked textbook and quietly ignored one edge case. It would have passed review, had anyone merely skimmed it.

Where it genuinely helps

From what we see in our own work:

• Tests. The single biggest win. Writing twenty input variants is work nobody wants to do, which is why it does not get done. A model handles it and you concentrate on whether it tests the right things.
• Unfamiliar code. "Explain what this class does" on a ten-year-old undocumented project saves hours.
• A first version. Not the final one. But an empty file is a worse starting point than something you can rewrite.
• An unfamiliar language or framework. When you know what you want and only lack the local idiom.
• Tedious conversions. JSON to types, SQL to a migration, one format into another.

Where it hurts more than it helps

Architecture. A model proposes what it saw most often — the average of the internet. In architecture, average is usually the wrong answer, because your constraints are not average.

Debugging unusual failures. Race conditions, memory leaks, "works on my machine". The model suggests the most likely causes, which is precisely what you already tried.

And anything depending on context the model does not have. It does not know you cannot change that table because accounting reads from it. It does not know this endpoint is called by a customer you have a contract with. This is the core of our whole approach — a model is exactly as good as the context it was handed.

Juniors, and the uncomfortable question

There is no tiptoeing around it: the routine work juniors learned on for years is now automated. That creates a real problem nobody has properly solved.

There is another side, though. A junior with a model reaches a working result far faster and can learn on bigger things sooner. The risk is learning to accept code rather than understand it.

The difference between those two paths is one question they have to ask: "why did it write it this way?" Ask it and you learn faster than any generation before. Skip it and you learn nothing, and will not notice.

What this does to quality

When writing code is cheap, code multiplies. More code means more places for a bug and more to maintain. Generation speed is not free — you pay later.

Which is why tests, static analysis and code review matter more, not less. They are the only gates that work identically whether a human or a model wrote the code. And unlike our eyes, they cannot be fooled by nice formatting.

The summary

Programming did not shift toward whoever types fastest. It shifted toward whoever knows more precisely what they want, and more reliably notices when they got something else.

Which, incidentally, is exactly what was hard about this job before. It just can no longer be hidden behind being busy typing.