So, I think this is simply true: today it is about volume and speed. More features, more code, more releases, more than last quarter, faster than the competition. Quality and long-term thinking are in no target agreement anymore. They are what is left when time is left. And time is never left. I am not writing this as a complaint. I am writing it because I have seen the bill for it paid a few times, and because it is coming due again right now.
What used to count
I have built systems that still run today. Not because they were brilliant. Because back then someone asked: what happens to this in five years? Who maintains it when you are gone? What does it cost when it stops at three in the morning? At a bank, at a telco, at an insurer those were not polite questions. They were the questions that decided the budget.
Not everything was better. It was slow, often too slow, and some edge case cost half a year. But there was a notion that software is a building and not a post. That you live in it for ten years. That the people who build it are also the ones who have to live in it.
What counts today
Today I sit in meetings where a single number is on the slide, and it is always a quantity. Features per sprint. Pull requests per week. Releases per month. Story points, as if they were kilograms. Nobody asks anymore what happens to it in five years, because in five years nobody who decides today will still be there. The horizon is the quarter. Sometimes the week.
That is not an accusation against the developers. They do what is measured, all people do. It is an accusation against the measurement. Whoever rewards volume must not be surprised by volume.
And then came AI
And now a tool arrives that delivers volume and speed in an amount that was not conceivable before. I work with it every day, I do not want it gone, and I have written here often enough what it can do. But you have to say honestly what it does to a culture that was already only counting quantities: it pours petrol on it.
The slide that used to show twenty features now shows sixty. The pull request that used to have two hundred lines now has two thousand. And everyone is pleased because the number went up. That nobody knows anymore what is in the two thousand lines appears on no slide. That the review now takes longer than the writing, neither. The machine did not lower the quality. It made visible that quality had long since stopped being a goal.
The bill comes later, but it comes
I have experienced a few times what such a bill looks like, and it always comes the same way: not as a bang, but as sluggishness. First every feature takes a little longer, because it touches three places nobody understands anymore. Then nobody dares to change a module, so you build next to it. Then there are two modules doing the same thing, and three people who know which one when. Then the three people leave. And then someone stands there with a system that is five years old and feels like twenty, and gets a budget for a rebuild that starts the same story from the top.
That used to take ten years. With tools that generate two thousand lines in a minute, my feeling is it takes two. I cannot prove that, it is too early. But I see the first projects where after eighteen months nobody can explain anymore why the system looks the way it looks. I used to know that only from systems older than the people working on them.
What I do differently
I am not the one who says you should slow down. I do not think that works, and I do not want it either. The speed is here and it is good. What I do differently is what I fill it with.
Ask the old question, but fast. What happens to this in five years? Who maintains it? What if it stops at night? These questions cost five minutes, not half a year. You just have to ask them before the agent starts, not after.
Less as the goal. When I work with an agent, the task is not "build this" but "build this with as little as possible, and delete what you no longer need while you are at it". A sprint in which code disappears is a good sprint for me. That is written in the task, and it is counted.
One number that measures understanding. Can someone explain without the model why the system is built this way? If not, that is the most important number in the project, and it is red. Everything else on the dashboard does not matter then.
Keep the people who were there. Knowledge about a system lives in heads, not in documents. Whoever cuts the heads because the machine types faster cuts exactly what he will need most urgently in two years.
What stays
I know this sounds unfashionable. Long-term thinking is not a word you win a funding round with. But I have seen enough systems that were more expensive in year three than in year one to know that the bill always comes. It just never appears on the slide where the volume is.
Volume and speed are the only goals today, and AI delivers both like never before. That is not the machine's problem. It is the problem of what we demand from it. I would fill it differently: with less code, with the five-year question, with people who can explain the system. Not because it is nicer. Because otherwise the bill comes. It always comes.
Written by me. The thoughts, the values, the learnings, the mistakes: all mine. Grammar and spelling are corrected by a twin model of my own, trained on my texts. Sometimes that turns into a mix. Of course I read everything again, but nobody is infallible. Whatever stays in is mine too.