So you vibe-coded another app over the weekend. It works on your machine. It has a login screen, a database, a few clever features, maybe even a decent design.
Congratulations.
I mean that only half sarcastically. It is fun. I do it too. Building small things with agents feels different from the old way of building small things. The distance between an idea and something you can click has collapsed. Sometimes the result is better than what I would have built myself in the same amount of time, without AI.
But I am getting tired of the same story being told as if it proves something important about software engineering.
For a profession that likes to take itself seriously, we should be more careful about what we celebrate. The number of tokens your team burned is not a success metric. The number of lines of code produced with those tokens is not a success metric either. If anything, it should make us nervous.
Code is still a liability.
That did not change because an AI wrote it. Someone still has to understand it. Someone still has to run it, debug it, secure it, migrate it, explain it, and eventually delete it. The old rule still applies: the less code you own and maintain, the easier your job becomes.
We create software to solve business problems. The smallest solution that actually solves the problem is usually the best solution. This was true before AI. I don’t see why it would suddenly stop being true now.
What changes is the temptation.
When code becomes cheaper to produce, we produce more of it. A helper script becomes a service. A service becomes a product. A product grows a dashboard, permissions, notifications, settings, integrations. It all feels cheap at the moment of creation. The bill comes later.
Other professions understand this better than we do.
If you use twice as much concrete in a building, the building does not automatically become twice as stable. It matters where the concrete goes. It matters what load it carries. There are places where more concrete helps. There are places where it is waste. And if you put too much weight in the wrong place, you can make the building worse.
Software has the same problem, but we are much worse at measuring it.
We talk about complexity, but mostly as a feeling. This codebase feels messy. This architecture feels clean. This team moves slowly. That team somehow keeps shipping. We have metrics for many tiny things, but very few useful ways to compare the complexity of a codebase with the complexity of the business problem it is supposed to solve.
I think this is where AI could become genuinely useful.
Not by writing more production code. The more interesting question is whether it can help us understand the systems we already own.
Can it help us find the parts of the codebase that carry too much weight? Can it generate small reproduction cases for bugs that usually take hours to isolate? Can it build better test scaffolding around risky areas? Can it explain why a change is slow, where coupling has grown, which abstractions are no longer paying for themselves?
This kind of work used to be expensive. Not because it was unimportant, but because nobody had time for it. Teams were already busy building the product. Investing deeply into system understanding often felt like a luxury.
That may be the real opening.
If AI gives us more engineering capacity, spending all of it on more production code feels like the least imaginative option. Production code is the hardest place to start. It is where the stakes are highest, the context is messiest, and the cost of a subtle mistake is real.
There is plenty of code around production code that is easier and safer to automate first: tests, diagnostics, migration checks, performance measurements, debugging tools, complexity reports, throwaway scripts that help you understand what is actually happening.
That work is less glamorous than shipping another weekend app. It does not make for a good screenshot. But it might matter more.
The serious use of AI in engineering may not be writing more code. It may be finally understanding the code we already own.