Using Cursor and Claude, a 5-person engineering team can now build a billing webhook handler, a customer import tool, a Slack alert bot, an admin dashboard, a data deletion cron job, and three integrations in one afternoon. Sounds like some productivity. That sounds like the start of a maintenance bill that no one has even looked at yet.
This is what everyone is overlooking. You are responsible for any systems shipped. You need to manage secrets correctly, keep track of APIs as they change, update dependencies, monitor logs, respond to incidents, and debug weird edge cases at 2 a.m. Now code-generation is cheap. But there is a price to pay in owning the consequences. AI tools have enabled small teams to build more in software but not to debug, secure or support that software reliably. The problem starts at the gap.
Given the adoption numbers today, it’s hard to dismiss it as a niche issue. 90% of software development professionals now use AI tools, according to the Google DORA 2025 report. Over 80% of developers say they’re more productive when using AI for a median of two hours a day. Yes, a generation side has changed. Drastically. The error is in more code shipped with more software.
Why this matters is that software delivery is not just throughput. DORA has always measured speed and instability by looking at change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. In other words, the real job isn’t “write code fast.” It's "move fast and don't break it all". The generative AI data doesn’t exactly inspire confidence in that regard. The research by DORA shows that AI does improve local process metrics such as documentation quality and review speed, but it also correlates with a 1.5% reduction in delivery throughput and a 7.2% reduction in delivery stability per 25% increase in adoption.
It makes sense when you think about what happens when code is too easy to write. People stop shipping small, disciplined batches, and start pushing larger changelists. Bigger change lists are more difficult to review and test, and more likely to break in production. Another trap is the so-called speed. The editor is doing more of the work, which makes it quicker, developers say. It’s easy to think you are saving time because the machine is writing a lot of the code. But the work just moved. METR’s randomized controlled trial revealed that experienced open source developers predicted that AI tools would make them faster by 24%, and then later estimated they had saved 20% of their time. In the real world, the actual measured result was a 19% increase in task completion time when AI was allowed to help. Prompting takes time. Reviews take time. Repair takes time. It takes time to integrate the output. People are really bad at accounting for those costs when they’re making themselves feel busy.
And that cost is not evenly distributed. Senior engineers end up doing more of the review and cleanup work. AI-assisted programming maintenance research discovered that core developers reviewed 6.5% more code and had a 19% drop in original-code productivity after the introduction of AI coding assistants. So AI democratizes authorship and centralizes responsibility. Even experienced people have to figure out what’s safe, what’s broken, and what should never have been merged. And this is the point where we get to the real frontier of maintainability: understanding. A team is intentionally designing legacy software if it cannot safely debug it, change it and delete it.
As the Val Town blog on vibe coding puts it, it is okay to generate code you don’t understand for prototypes, but dangerous for long-lived systems. The question is not whether the code is there. Will the team still be able to explain it 6 months from now? This is where we can not ignore security anymore. Fast code generation is not the same as safe code. Nearly half of all code generated by AI already has known security flaws, new analysis has found. That’s not a rounding mistake. Much of this output is one step away from a liability.
Delegate tasks. Get software.
Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.
Take a look at vroni.comI respect your privacy. Unsubscribe at any time.