Projects don't take months because of programmers. They take months because the brief is missing. Obvious, right?
AI can write a simple app in a few hours today. Yet company projects still drag on for months. The problem has moved: the hardest part is no longer writing code, but saying precisely what it should do.
Programmers are needed. What changes is where projects get stuck.
One thing first, to avoid a misunderstanding. This article does not claim that a company should build everything itself with AI, or that programmers and designers are unnecessary. Quite the opposite.
Anyone who wants to build their own tool in a company is building a product, even if it is a digital one. They need someone who knows what the product should do and for whom: a product owner who writes a good brief and makes decisions. And they need people who finish what AI can't do on its own: architecture, code review, security and design.
AI writes code fast, but not always securely. In 2025, Veracode tested more than 100 language models. In 45% of tasks, the generated code contained a security flaw. An experienced person who can spot it is therefore more important, not less.
Speed isn't a given either. In 2025, the research organization METR followed 16 experienced developers on 246 real tasks. With AI tools they were 19% slower, although they themselves estimated they were 20% faster. Senior people carry a lot of weight when working with AI. What changes is where projects lose the most time. That is what the rest of this article is about.
Code is no longer the bottleneck
Just a few years ago, writing and reviewing code was the most expensive part of development. Today AI writes much of it for you. The bottleneck has become the brief: the ability to describe clearly what you want to build.
Developers call this spec-driven development, building from a specification. First you agree in writing what the system should do. Only then is code written.
This approach already has its own tools. In September 2025, GitHub released Spec Kit, an open toolkit that takes AI through four steps: specification, plan, tasks and implementation. After each step a person checks the result before moving on.
Trial and error is fast only at the start
The opposite also has a name: vibe coding, which we also cover in our article on prototypes. You tell AI what you want, it builds something, you adjust the request, it redoes it. Round and round until the result looks good.
For quickly testing an idea, that's excellent. The problem comes when it is meant to become a tool the company relies on. The same instruction can give a different result on every attempt, and nobody can say why AI made a particular decision.
The numbers from practice confirm it. The 2024 DORA report from Google Cloud, which surveys thousands of people in software development every year, found that as AI use grew, delivery throughput dropped by an estimated 1.5% and delivery stability by 7.2%. At the same time, people using AI reported higher personal productivity. Writing code faster does not by itself mean a faster project.
With a person
You don't tell a new supplier “build us a client portal” and expect them to get it right. First you write down together who logs in, what they see and what happens when something is missing.
With AI
The same applies. Without a specification, AI guesses what you meant. It has 30 ways to do it, and you spend longer going back and forth than it would take to write the brief.
A specification is a contract, not bureaucracy
In spec-driven development, you don't specify the solution, but the behavior and constraints. What the system should do, for whom, what happens on an error. These become requirements that work as a contract between you and whoever builds it.
You read and approve the requirements before the first line of code exists. Changing a sentence in a document takes a minute. Changing a finished app takes weeks. Only after approval comes a solution design with a task list, and then the implementation itself.
This isn't new. In 2001, Barry Boehm and Victor Basili summed up decades of measurements in a simple rule: a problem you find only after delivery often costs 100 times more than the same problem caught during requirements and design. And according to the Project Management Institute, inaccurate requirements management is the main cause in 47% of projects that missed their goals.
The process looks like this:
- Brief: what the system should do and under what conditions.
- Requirements: specific rules that you approve.
- Design: how it will be built, split into tasks.
- Implementation and tests: AI writes code and checks it against the requirements.
“An accounting office wants a portal where clients upload receipts. Trial and error would produce an upload form. A specification captures what matters right at the start: what happens to a receipt that can't be read, who gets notified when a client uploads nothing by the 10th, and that a client never sees another client's receipts.”
Tests come from the requirements too
The biggest benefit of a specification shows up later. When the requirements say what happens with correct and incorrect data, tests can be derived from them directly. AI then doesn't write code “by feel”, but so that it passes exactly the checks you approved.
For you, this means fewer surprises at handover. You know what you will get before it exists.
“We work in short cycles: a demo every 1 to 2 weeks and payments by phase. It works precisely because every phase starts with an agreed specification. In the meeting we don't discuss what you meant, but whether the result meets what we wrote together.”
When trial and error is enough, and when to write a specification
| SITUATION | APPROACH |
|---|---|
| You want to check whether an idea makes sense | Trial and error, a prototype in a day |
| Employees will use the tool every day | Specification |
| The system handles client data or money | Specification and tests, mandatory |
| Nobody in the company can say exactly what they want | Workshop first, then specification |
What this means for management
When someone tells you an app will take three months, ask how much of that is writing the brief. If the answer is “that will become clear during development”, the project won't drag on because of programming, but because of the back and forth.
AI has sped up development so much that the difference between a good and a bad project today comes down to the quality of the brief. And that is a job for people who know the company, not for programmers.
Ask yourself
Could you write on one page today exactly what the tool you want to build should do?
Sources: Veracode, GenAI Code Security Report (2025); METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (2025); Google Cloud, DORA Accelerate State of DevOps Report (2024); GitHub, Spec Kit (2025); Boehm and Basili, Software Defect Reduction Top 10 List (2001); PMI, Pulse of the Profession (2013).
