The ease of generating code has created a surreal expectation: that software is only what appears on the screen.

First of all, let me make this clear: I’m not against AI, far from it — I use Deepseek and Claude daily. That said, let me tell you about something that happened to me recently.

You’re building a new system for operations. When it’s time to refine requirements, no one from the business side has time, and no one wants to set priorities. What do you do? The basics done right: you deliver a decent MVP — with architecture, functional and reliable — and push the “nice to have” to the next version.

Time passes, and soon you hear It’s taking too long. Where’s feature X?

Then, instead of sitting down for an alignment meeting, someone from operations opens Claude and decides to get their hands dirty. Three days later, this person shows up with a system that has everything they asked for, and it’s pretty, clickable, navigable. Management, obviously, loves it, and the question starts floating in the air: “If so-and-so did this in three days with AI, why was it taking so long before?”

Well, here’s the thing — the answer lies precisely in what doesn’t appear on the screen. You open the code of the “magic system” and… well, it’s an experience: there’s no backend, the database is the browser’s localStorage, sitting right next to the JWT token, business logic is mixed into a single file — five thousand lines of raw JavaScript. No tests, no governance. Security? So yo. This has a name, and it’s vibe coding.

The parallel with AI-generated art is impossible to ignore: just as anyone can generate a pretty illustration with AI but that doesn’t make them an artist, vibe coding produces software with the appearance of a system, but with no one who understands what’s underneath and, when it breaks, no one to fix it. In both cases, the result is the same: the craft is trivialized and the perceived value of specialized work collapses.

Meanwhile, the “slow product” has a defined architecture, a relational database, migrations, CI/CD, observability, automated tests. In a five-minute demo, both look the same, but the difference is that one is a science fair project made to impress in a pitch, and the other is software designed to survive real users on a Monday morning, without waking anyone up at 3 AM two years later.

What bothers me isn’t jealousy because “AI is writing code.” What wears me down is seeing invisible work completely ignored. But then again, no one applauds a well-configured deployment pipeline, test coverage doesn’t give the UI rounded corners, and architecture, security, and monitoring are the bottom of the iceberg. It’s the work no one sees sustaining the work everyone sees.

If you really look at it, AI only brought to the surface the industry’s obsession with speed at any cost. The thing is, anyone (you don’t even need to be a developer), with minimal experience, knows that when everything is due yesterday, nothing is a priority. In that case, the result isn’t delivery — it’s a pile of technical debt growing in silence. We spent decades refining agile methodology, sprints, code review, CI/CD, only to, under the excuse that “AI speeds everything up,” go back to the good old go horse: do whatever you can, ship whatever comes out, test in production, and pray.

AI has made one thing glaringly obvious: if generating 500 lines of code became instant, the bottleneck of engineering was never typing. The real bottleneck has always been deciding:

• Deciding what not to do;
• Deciding which architectural trade-offs to take on now and which to defer;
• Deciding how not to turn the system into one big plate of spaghetti.

No AI makes these decisions for you.

There’s a recent study by GitClear showing exactly this: we’re generating code with AI at a frantic pace, but code churn (that code that gets written and then deleted or rewritten in the same week) has skyrocketed. In other words, we’re typing more, but creating better software is a different story. We’ve gone back to measuring productivity by lines of code, which is an absurd regression.

The problem isn’t the business side using AI to solve specific pain points. The danger is the lack of technical maturity to distinguish a system that looks ready from a system that is ready for the real world. Software engineering was never about producing as much code as possible, but rather about solving problems sustainably. Often, the best technical decision is knowing when not to add a feature, or not to treat everything as a fire; building good software requires thinking, and thinking takes time.

If we reduce ourselves to optimizers of “write code faster,” Jevons will laugh in our faces: we’ll spend the next decade just fixing the bugs we generated in three days.

Sorry for the rant, but I felt outraged, disappointed, and reflective about this situation. Anyway, see you in the next post.

See you soon!