When writing code stopped being the bottleneck

The cost structure of software projects has long rested on one assumption: writing code is slow and expensive. Effort estimates, team sizes, sprints, and pricing models have all been built on top of it. When someone asked “how much will this cost”, they were really asking “how many developer-weeks will typing this out take”.

That assumption no longer holds the way it used to. Implementation has sped up so much that in most projects it is no longer the phase that determines lead time.

That doesn’t mean software development has become easy, though. The hardest part has simply moved somewhere else.

The bottleneck moved, it didn’t disappear

When implementation speeds up, the queue shifts and piles up in front of some other phase. In practice that means three things: specification, review, and deployment.

Specification has always been the weakest link in projects, but its gaps used to surface slowly. An unclear requirement had a week to mature before it turned into code, and somewhere along the way someone had time to ask a clarifying question.

Now that question easily goes unasked. The problem is rarely that a requirement gets implemented exactly as wrongly as it was written. More often the requirement was never written precisely enough in the first place, so the gaps get filled with assumptions. And in the end result, assumptions look exactly the same as things that were specified.

The same applies to humans, of course. The difference is that an agent guesses faster, doesn’t stop to ask, and produces a result that looks confident.

This is also one of the most useful places to use AI: let it read the specification and tell you what’s missing. Which parts are open to interpretation, which edge cases haven’t been handled, what it would have to assume on its own. It’s a cheap check, and in many projects more productive than the same model writing code.

Review, in turn, has become a genuinely limiting factor. A developer can produce changes faster than another human can understand them. At this point many organizations make a quiet decision: review more lightly. It’s an understandable choice, and quite often the wrong one (at least for now).

Speed doesn’t fix architecture, it exposes it

A well-bounded system with clear responsibilities and proper interfaces benefits enormously from AI-assisted development. The context is small, the rules can be read from the code, and a change stays where it belongs.

A messy system behaves the opposite way. When business logic is spread across three layers and half the truth lives in database trigger functions, speed just piles up the mess faster. A change looks right locally and breaks something somewhere else entirely.

This is a familiar pattern for us at Koud, for example from Go projects. A simple language, a clear structure, and explicit error handling aren’t just aesthetic preferences. They are context that both a human and a machine can read without guessing.

Architectural quality has become a productivity factor in a way that never used to show up this directly on the bottom line.

Context is the new production input

The quality of agents isn’t decided by which tool you pick. It’s decided by what the tool sees.

Tests, types, documented interfaces, described domain concepts, and a consistent repository structure are, in practice, machine-readable specification. A project that has these in order gets many times more out of AI than one where the knowledge lives in people’s heads and old Slack threads.

There’s an uncomfortable conclusion hiding here too: AI doesn’t level out the difference between well and poorly maintained codebases. It multiplies it.

Quality assurance moves from the end of the line into the structure

When more changes are being produced, manual inspection doesn’t scale. The only sustainable answer is to move quality requirements to where they are checked automatically, every single time: comprehensive tests, strict linting, type checking, static analysis, dependency and security scanning, reproducible environments, and a reliable CI pipeline.

None of this is new doctrine. What’s new is that the price of neglecting it now materializes in weeks instead of years.

The role of human review changes at the same time. The question is no longer “is this line correct” but “is this the right solution, does it belong in this system, and what will it cost us a year from now”. That is evaluative work, not walking through a checklist, and it takes an experienced professional.

Legacy suddenly looks different

One of the most concrete changes concerns old systems.

The biggest cost of a modernization project has by no means always been writing the new system. It has been understanding the old one: digging undocumented logic out of code whose authors have already retired. This is exactly where today’s tools are exceptionally good. Walking through a codebase, mapping dependencies, and describing business rules in human-readable form used to take months.

Many systems deemed “too expensive to modernize” are worth re-evaluating. The calculation was made with different prices than the ones in force today.

This doesn’t mean you can hand a migration over to an agent entirely. It means the cost of the initial analysis and mapping has collapsed, so the decision is much easier to base on knowledge instead of guesswork.

What the client is actually buying

If implementation speed no longer separates vendors, it’s honest to ask what a software company is being paid for.

To us the answer is clear: judgment and responsibility. That someone decides what not to build. That someone recognizes when a quickly produced solution is actually done, and when it’s just a demo that looks done. That when production has a problem at 11 pm, the responsibility sits with a party named in the contract, not with the model vendor.

This is worth factoring into procurement as well. Hourly rates and estimated effort tell you less than they used to. You learn more by asking how the vendor reviews its work, what automation they have supporting quality, how technical debt is kept visible, and who carries responsibility for the end result.

Where we would start

If your organization is thinking about how to make AI part of software development, the first steps are not tool choices:

• Find out what is actually slowest for you. If it’s decision-making or approval rounds, faster code production won’t help at all.
• Get CI, tests, and environments in order before you grow the volume of changes. This is an investment that pays for itself quickly.
• Agree on ground rules for what may be done to production code and with what checks. Write them down, don’t assume.
• Solve the security and data questions up front: what code or data may go to which service, and on what terms.
• Start with a bounded piece of work that has a real owner and a measurable outcome. Internal experiments without an owner stay experiments.

Finally

The software industry is used to new technology promising to remove complexity. So far nothing has, though there have certainly been good attempts! Complexity has moved: from assembly to higher-level languages, from server rooms to the cloud, and now from writing to evaluating and directing.

Speaking for myself, I’d say AI-assisted development definitely doesn’t reduce the need for expertise, it raises its price. When anyone can produce working-looking code, the value moves to those who can tell which parts of it will hold up in production. For an inexperienced team speed is a risk; for an experienced one it’s leverage.

And that’s exactly why the most important question isn’t which tool you use. It’s whether someone on your side of the table can recognize when a quickly produced answer is wrong.