The tech world is buzzing about AI coding tools. Lovable, Bolt, Cursor, GitHub Copilot, Codex, Claude Code, and dozens of other AI tools are generating code faster than ever. The narrative is clear: we have finally solved the coding bottleneck that has held back software development for decades.

There is just one problem with this narrative—it is completely wrong.

Code Was Never the Bottleneck

After years of working as both designer and engineer on complex projects with tight deadlines, I can tell you with certainty: writing code was never what slowed us down.

The real bottlenecks in software development are:

• Code reviews and knowledge transfer

• Testing and debugging

• Human coordination and communication

• The endless maze of Jira tickets, planning meetings, and agile rituals

These processes require thought, shared understanding, and sound judgement—things that cannot be automated away with better code generation.

The Hidden Cost of Generated Code

AI tools can produce working code in seconds. But what happens next? That code still needs to be:

• Understood by the team

• Reviewed for quality and security

• Integrated with existing systems

• Tested for edge cases

• Maintained over time

The marginal cost of adding new software is approaching zero, but the price of understanding, testing, and trusting that code has never been higher.

When code is generated faster than it can be reviewed and discussed, teams risk falling into a dangerous mode where quality is assumed rather than ensured. This creates enormous stress on reviewers and mentors, potentially slowing everything down.

Two Types of Code, One Big Confusion

Here is where many engineers get lost: there are fundamentally two different types of code we write.

• Throwaway Code: Scripts, prototypes, demos, and experiments. The goal is to figure out what to build or whether something can work. Quality does not matter—understanding does.

• Production Code: Core infrastructure, main features, and systems meant to be maintained for years. Quality, maintainability, and team understanding are paramount.

The cost difference between these two approaches used to be minimal. Now, with AI tools, that gap has exploded. AI excels at throwaway code but struggles with the collaborative, long-term thinking required for production systems.

The engineers who thrive with AI tools understand this distinction. They use AI for rapid prototyping and exploration, then carefully craft production code with their team. Those who treat all code the same will find AI tools either useless or actively harmful.

The Process Problem

Most companies are trying to jam AI tools into their existing development process. This is like trying to fix traffic by making cars faster—you are optimising the wrong part of the system.

Traditional software development follows this painful path:

1. The product manager identifies the problem

2. Research with users (often skipped)

3. Design and mockups

4. Product specification (5-30 pages)

5. Presentations and approvals

6. Technical specification

7. Development

8. Ship and pray

This process takes 6-18 months just to get from problem to solution. Making step 7 faster does nothing to address the real bottlenecks in steps 1-6.

A Better Way Forward

Instead of speeding up the final coding step, we should use AI to move building earlier in the process. Rather than spending months writing specifications, we can:

• Identify the problem

• Build a rough prototype in days

• Test with real users

• Iterate or kill the idea based on feedback

This approach eliminates most of the traditional process steps because you can prove concepts quickly and write better specifications based on actual working implementations.

One engineer, one designer, and one part-time product manager working this way can save months or years compared to having seven engineers build a poorly specified product.

The AI Tools Are Missing the Point

Many AI coding tools are optimising for the wrong metrics. They make it easier to generate massive amounts of code but harder to understand, review, and maintain it.

These tools often:

• Remove the enjoyable parts of development (coding, prototyping)

• Replace them with tedious tasks (reviewing generated code, reading AI-generated specifications)

• Create perverse incentives to generate more code rather than simpler solutions

This mirrors what happened when typewriters and word processors made laws longer but not better. More words did not equal better legislation—and more code does not equal better software.

What Engineers Want

Most engineers prefer:

• Writing code and having conversations

• Experimenting with new ideas

• Simplifying and deprecating unnecessary complexity

We do not enjoy:

• Reading lengthy specifications

• Sitting in unproductive meetings with 10+ people

• Reviewing code, we do not understand the purpose of

The best AI tools will amplify the parts of our job we love whilst minimising the parts we hate—not the other way around.

Making AI Work for Development

To truly benefit from AI coding tools, we need to rethink our entire development process, not just make the final step faster.

Use AI for:

• Rapid prototyping and exploration

• Testing feasibility quickly

• Generating throwaway code for experiments

Avoid using AI for:

• Production code that needs long-term maintenance

• Critical systems where every line matters

• Code that will be reviewed and maintained by teams

The future of software development is not about writing less code—it is about writing the right code at the right time for the right purpose.

Understanding that distinction will determine whether AI makes your team faster or just generates more problems to solve.

The real bottleneck in software development has always been understanding what to build and why. Until AI can solve that problem, we are just making the easy parts easier, whilst the hard parts remain unchanged.