Writing code fast used to be a skill. Now that AI does it, clients ask us: why does my project still cost so much? Because solving complex problems hasn't gotten cheaper. Only writing code has.
One of our developers once told us how he used to introduce himself: there was nobody who wrote Java as fast as he did. Light a cigarette, tunnel mode, and the code just poured out of him. That was a real skill, and it was worth money, because writing code was expensive.
Those days are over. Since tools like Claude Code arrived in software development (late 2024, early 2025), writing a lot of code quickly is no longer hard. And since then, we've been hearing a fair question from clients and prospective clients: if code has gotten this cheap, and even I can have Claude or ChatGPT write code, why does my project still cost so much?
The short answer: it has gotten cheaper. But solving complex problems isn't cheap, and that's exactly what AI still doesn't take off your hands. What has changed: smaller teams can now handle much bigger projects. What that means, and what a developer actually does all day, is what we explain here.
More code is written by AI every day, a lot more
Even at the AI vendors themselves, most new code now comes from AI. Google says three quarters of its new code is generated by AI and approved by engineers. At Anthropic, the maker of Claude, the number of code changes merged per day rose from around 2,500 to over 30,000 between May and September 2026. Git, the version control system that has been the industry standard for twenty years, couldn't keep up. Anthropic replaced it with a system of its own for its central code repository.
Dario Amodei, Anthropic's CEO, said in Davos in January 2026 that within six to twelve months, models could do most, maybe all, of what software engineers do today. Andrej Karpathy, who coined the term vibe coding, now calls the new work agentic engineering: you no longer write 99 percent of the code yourself, you direct agents and supervise them.
At first glance (and on LinkedIn), it therefore looks as if anyone can now build software themselves. That's only partly true. There's a huge gap between a demo and a real production system. Most solutions that non-developers build by vibe coding run in the demo and collapse in real operation: in 2026, thousands of such apps sat on the internet with openly accessible databases, customer data included.
If software development had really become as easy as the average AI enthusiast (formerly Bitcoin expert) on LinkedIn would have you believe, we'd be fools to regularly sacrifice weekends and sleep to build exceptional systems.
Why software projects still aren't free
If writing code is cheap, shouldn't software be cheap? It isn't, and there are measurements to prove it.
DORA is a Google research program that surveys thousands of development teams every year and measures how fast and how reliably they deliver software. In 2024, DORA found: the more AI a team used, the less stable the result got, and it didn't even get faster. In 2025, speed was up, stability still down. DORA's explanation: whoever delivers faster runs faster into everything in the process behind it that doesn't hold, missing tests, approvals, operations.
METR, an independent research institute that measures the capabilities of AI systems, observed sixteen experienced developers in 2025 working on real tasks with and without AI tools. With AI, they took 19 percent longer. Afterward, they estimated they had been 20 percent faster. In a follow-up study in early 2026, developers with newer tools were probably faster, but the gap between perceived and measured speed remained. The feeling of speed and actual speed are two different things.
And Anthropic itself writes, in the article introducing its Git replacement: every change is still reviewed by a human, just no longer line by line, but for its intent.
So even at the companies building the frontier models, real people still have to step in. The work that actually created value in a project was never typing lines of code. It was deciding: what gets built, what doesn't, and how the system survives production. That part hasn't gotten cheaper. Above all, it has gotten more complex, because AI systems now produce more code, faster, and all of it has to be decided on. And that matters enormously. An example from our own practice:
An AI system was supposed to run for several companies at once, and each company was only allowed to see its own data. Our internal AI workflow built almost all of it on its own, and everything looked finished. During review, one of our developers asked: what happens if I log in to company B with company A's credentials? Answer: you see company B's data. The separation was displayed, and the AI even claimed it was there, but it was never properly implemented behind the scenes. At first glance, and in a way a layperson could hardly check, the system ran perfectly. That is exactly where the danger of classic "vibe coding" lies.
Saying no is the new core skill
The most important skill a developer has today is saying which of the AI's proposals doesn't make it into the product. Another example from our practice:
In one of our projects, there had been an automatic approval for certain bookings for months. The AI was asked to extend an adjacent workflow, and in doing so, unasked, it built an entire manual approval process on top: roles, notifications, status transitions. Technically clean, fully functional, and completely superfluous, because the rule had long been handling it automatically. Without a developer who knows the product and says "we don't need that," it would have ended up in the system and caused problems from then on.
That's not an isolated case, it's a pattern. Anthropic, the maker of Claude Code, states in its own documentation that some model generations tend toward overengineering: they build more than was asked for, extra files, intermediate layers, safeguards. The result solves the immediate problem right away, and a year later nobody can change it. Analyses by the code analytics provider GitClear across hundreds of millions of code changes show the same thing: duplicated code has multiplied since 2020, and cleanup work is declining. Whoever doesn't recognize that gets a lot of code quickly and a problem slowly.
What a developer does today
A large part of the work consists of giving the model the plan and pointing out the right path. Software development is still a field where you only know many things after trying them: whether a solution is faster, runs cheaper, or is easier to use. With AI, a developer can run through more variants in a day than used to fit in a week. For that, he has to master the fundamentals of good software design, because the model knows them perfectly in theory but often takes the wrong turn in real implementation.
You can look at a problem from two perspectives: the eagle's view or the frog's view. The eagle sees the whole forest. The frog sees the stone right in front of it, but very precisely. The eagle's view used to belong to dedicated roles: product managers, architects, project leads. The developer was the frog, and that was fine. He had enough to do with the writing. Today a developer has to be able to switch between both views: understand the problem and the product from above, and check from below whether the AI placed the right stone. Really good developers could always do that. Now it's the prerequisite.
Why small teams
In our experience, even in large companies it has always been a few key people who made the difference. AI has only accelerated that. In Communications of the ACM, the journal of the world's largest computing society, two Microsoft executives write that generative AI is "seniority-biased," a term from a Harvard study: it benefits experienced developers the most, those who can judge whether a solution holds within the overall system. It benefits the inexperienced far less.
The uncomfortable side of that: according to a Stanford study, employment of software developers aged 22 to 25 has fallen by almost 20 percent since 2022. The tools don't replace the experienced, they replace the entry-level work on which people used to gain experience. That's a problem for the industry. For your project it means: it comes down to a few people, and you should choose them well.
We recently completed a project in the biotech sector, a fairly complex data pipeline. In our experience, that would once have taken two years, three developers, and at least two data scientists. Today the same thing is built by one capable developer, one domain expert, and some specialist knowledge in under a year.
We've deliberately set up our team for the new era: lean, with people who earned their senior status at established IT companies, large agencies, and consulting firms.
What this means for the price
The first things to get cheaper were everything that can be tried out: variants, prototypes, interfaces, standard features. A prototype that took six weeks three years ago now stands in days. Everything that has to hold up in production is getting cheaper too: the architecture, the connection to real data, the permissions, operations. But only with the right people. Without them, AI produces vast amounts of bad code faster than ever, and that can create more complexity than in the pre-AI era. In the end, that costs more than writing ever did.
What this means for your project
Maybe you already have a prototype, built yourself or by someone else, and it works. That was surely the right decision. Running it in production is usually the wrong one.
How we turn a prototype into a product is on our page on custom software, and what we do with existing systems is on the page on software modernization. And if you're facing the question of whether you need something of your own at all: we've answered that here.
You can't slide a foundation under a finished house after the fact. But we promise you this: we use at least as much AI in our workflows as any vibe coder.
Sources
- Anthropic Engineering: Redesigning source control (13.10.2026)
- DORA: 2024 and 2025 State of AI-assisted Software Development
- METR: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (July 2025)
- METR: Update (Feb. 2026)
- Russinovich, Hanselman: Redefining the Software Engineering Profession for AI, Communications of the ACM (Feb. 2026)
- Brynjolfsson, Chandar, Chen: Canaries in the Coal Mine? (Stanford Digital Economy Lab, 2025)
- GitClear: AI Copilot Code Quality (2025) and The Maintainability Gap (2026)
- Anthropic: Prompting best practices, section Overeagerness
- Cybernews: 16,000 Supabase databases exposed as vibe-coded apps leak sensitive user data (2026)