In 2026, every vendor is selling you faster development. Cursor, Claude Code, Copilot: code comes out quicker and the demos look great in meetings. But a study published this year on 151 developers raises a question nobody wants to hear during the sales pitch: who is going to understand this code six months from now?
- 📉 Maintenance, not speed, 50 to 80% of a software system's cost comes after delivery, not during the build.
- ⚠️ The bottleneck moves, writing code costs less, but checking it costs more than it used to.
- 📊 DORA is still the benchmark, deployment frequency, lead time, change failure rate and recovery time: four hard metrics instead of gut feeling.
- 🎯 The real filter is human, a vendor that speeds up without disciplined verification is building debt, not a product.
The speed myth: why "writing fast" means almost nothing
Software isn't expensive to write. It's expensive to keep running. Dave Farley, a software engineer and respected voice behind the Modern Software Engineering channel, backs this up with numbers that should give speed merchants pause: maintenance costs three to four times as much as the initial build, and 50 to 80% of a software system's total cost of ownership comes after its first production release.
Farley co-authored a pre-registered controlled study, run in 2026 with 151 developers (95% of them experienced), to measure AI's real impact on downstream maintainability rather than typing speed. Most marketing benchmarks miss this distinction entirely: counting lines of code isn't software engineering. It's typing.
Why is writing speed a poor measure of success?
Because it only covers the first third of a project's life cycle. A module generated in an hour that takes three weeks to debug six months later hasn't sped anything up. It has just pushed the cost down the road, usually onto a developer who never wrote the first line.
Maximising short-term feature output makes no sense if nobody can maintain those features. That's exactly the trap busy executives fall into when they pick a vendor on the strength of a slick demo rather than maintainability metrics.
What AI really changes in software development, and what it doesn't
AI doesn't remove the cost of software development. It moves it. That's the argument made by Ralf Klemmer, a consultant who has spent 20 years working with companies such as United Internet and ProSiebenSat.1, in his video KI verändert die Softwareentwicklung: the question is no longer "how fast can you build?" but "do you even know what needs building?"
According to a study reported in the journal Science and cited by the Neurawork channel, roughly three quarters of new code at Google now involves AI assistance. The tempting conclusion, "faster software means cheaper software", is a miscalculation. The cost doesn't vanish. It just shows up on a different line: less time spent writing, more time needed to verify.
How has validation become the truly scarce skill?
It used to be that every line of code cost writing time. Today, according to Klemmer, verification has become "the new mandatory checkpoint". A senior developer who believes their value lies in writing better code than AI is fighting the wrong battle. Their value lies in judging whether what was built ever deserved to be built.
That's the case I've been making at GoLive Software for several years: producing code with AI is not the same as knowing how to build a real product. A non-engineer can generate working snippets, but they can't handle architecture, security, technical debt or the edge cases that never surface in a demo. Vibe coding is an excellent prototyping tool. It's a dangerous one for building a serious product without technical oversight, and that is exactly where choosing the right vendor matters.
DORA: the four metrics that separate real acceleration from a mirage
The only objective way to check whether a vendor is really speeding up your development is the four DORA metrics (DevOps Research and Assessment), from a research programme Google set up to study what separates high-performing development teams from the rest, as summarised by the Sleuth TV channel. These metrics don't measure individual developers. They measure a system.
| DORA metric | What it measures | Red flag to raise in the meeting |
|---|---|---|
| Deployment frequency | How often you ship to production | Fewer than one deployment a week on an active project |
| Lead time for changes | Time from a request to its production release | More than 2 weeks for a simple feature |
| Change failure rate | Share of deployments that break production | Above 15% with no documented remediation plan |
| Mean time to recovery | How quickly things return to normal after an incident | No written procedure, just "we handle it case by case" |
SOURCE: DevOps Research and Assessment (Google), summary by Sleuth TV · UPDATED 09/2026
When does a high deployment frequency become a real quality signal?
There's a stubborn belief that deploying more often increases risk. The opposite is true: the smaller and more frequent the changes, the better each one is understood, and the fewer errors pile up unnoticed. A vendor that deploys once a month isn't being more careful. It simply lacks the tooling to ship with confidence.
Ask any IT vendor to show you their actual deployment frequency on a comparable project. Their answer, or the lack of one, will tell you more than an hour-long sales pitch.
The real risk: when a vendor (or an AI) delivers fast but badly
A thread on r/developpeurs tells the story of a junior developer whose team had to wean him off AI for several months after realising he was "using AI too much without really learning or understanding what he was doing". The poster, who has been using AI himself for 4 to 5 months, describes a telling symptom: he feels he's become an "AI lead dev 70%" of the time, and has lost the motivation to learn languages like Rust or Go in depth.
That account echoes a study discussed on r/AIBubble, run by Faros.ai, a company that sells software development telemetry, covering 22,000 developers across 4,000 teams: it documents fuzzy throughput gains that came at the price of a heavy tax on the quality of the delivered product. A second, less robust but consistent study from the National Bureau of Economic Research points in the same direction for public open-source projects.
A product generated quickly without technical oversight often costs more to fix than it would have cost to build properly from the start. That's exactly the pattern described in these signs a vendor is bluffing you: impressive speed in the demo, total silence on who fixes things when production breaks.
Should you be wary of a vendor promising "ultra-fast" delivery thanks to AI?
Yes, if the promise of speed doesn't come with a promise of verification. A serious vendor will talk as much about automated testing, code review and technical debt management as about delivery speed. If speed is all they mention, they're selling a prototype, not a maintainable product. The question to ask is the same one I've seen raised about AI-generated offshore code and who pays when production breaks: is anyone at this vendor accountable for the outcome, or just for the volume of code produced?
The checklist before choosing who will speed up your development
Speeding up your product's development isn't about how many developers you throw at it, or how powerful their AI tools are. It's about disciplined, measurable verification, which boils down to four DORA metrics and a handful of pointed questions.
Before signing with an IT vendor or commissioning an IT audit, ask specifically: what's your deployment frequency on a project comparable to mine? How long between a request and its production release? What percentage of your deployments fail, and what happens next? Who on your team validates that an AI-generated feature has sound architecture, and not just a demo that works?
On golivesoftware.co, in August 2026, I can see the article on offshore software development in Vietnam capturing most of the blog's still modest organic traffic: 458 impressions for 2 clicks, according to Search Console. An article needs the same patience as a software project: what truly accelerates things takes time to build, not to announce. For an external benchmark on daily rates in France, the industry federation Syntec Numérique regularly publishes sector data.
I believe a small, well-organised senior team augmented by AI genuinely speeds up development, provided verification stays at the heart of the process. That's the model I champion in Vietnam with an offshore team and Claude Code: senior developers who use AI to multiply their judgement, not to replace architecture. AI isn't killing this profession. It's strengthening it for those who still know how to check what it produces.
So, should you really speed up your development at any cost? No. Speed up what can be measured, with DORA metrics and a vendor willing to show them to you, and deliberately slow down on verification, which is exactly where most rushed teams cut corners. A vendor that won't share its deployment frequency or change failure rate isn't speeding anything up. It's just deferring the bill.
Frequently asked questions
How much does AI-"accelerated" development really cost?
The cost of writing code goes down, but the cost of verifying it goes up, often by a similar amount. According to Dave Farley's study of 151 developers, maintenance remains the dominant share of total cost, between 50 and 80% over a project's lifetime. Development billed as fast, with no downstream maintainability data, doesn't prove any real savings.
Which DORA metrics should you ask an IT vendor for?
The four DORA metrics are deployment frequency, lead time for changes, change failure rate and mean time to recovery after an incident. A vendor that can provide them for a project comparable to yours demonstrates genuine operational discipline, not just a sales promise.
Does vibe coding let you ship faster without risk?
Vibe coding, the practice of generating code with AI without thorough technical review, is useful for prototyping an idea quickly. It becomes risky as soon as you're building a product for real users, because it neglects architecture, security and the handling of edge cases that never show up in a demo.
Can an offshore team speed up development without sacrificing quality?
Yes, as long as the team is made up of senior developers who use AI as a production tool rather than a substitute for technical judgement. The cost advantage of a well-managed offshore team, combined with AI, often lets you ship faster than a more expensive local team without sacrificing maintainability, provided verification remains central to the process.
Should you choose a vendor that promises ultra-fast delivery thanks to AI?
A promise of speed with no mention of testing, code review or technical debt management should set off alarm bells. A serious vendor documents its deployment frequency and change failure rate, not just the delivery timeline quoted during the sales process.
Vidéos YouTube
- We Studied 150 Developers Using AI (Here's What's Actually Changed...) — Modern Software Engineering
- Software Development with AI: What's Changing for Your Company Now — Neurawork
- KI verändert die Softwareentwicklung FÜR IMMER! — Ralf Klemmer
- DORA Metrics Explained — Sleuth TV
Discussions Reddit
- Des devs ici qui ont arrêtés l'utilisation des IA après en avoir abusé ? — r/developpeurs
- LLMs Cause Software Development Teams to Underperform — r/AIBubble
