AI makes writing code faster - so why are we not shipping faster?

I have had this question in various forms quite a few times now.

In my experience, using AI to type code faster only gives you, maybe, a 10% improvement in throughput across the whole pipeline. You can move much faster, but it requires some much broader thinking and some very boring, mundane work.

So how do you actually deliver software faster to users with AI, in practice?

Sure, the AI tools help us generate code faster – but that very quickly runs into two new bottlenecks. Interestingly, the remedy for both harks back to the same kinds of things that have been considered "best practice" for a decade or more and documented in "Accelerate" and "GIST", amongst many others. At least, that's my opinion.

🍼 Bottleneck 1: Reviewing the AI-generated code

Developers are drowning in code to review and in practice you can only do so much before it overwhelms you.

We – still – have the rule that all code must be reviewed by a human. But, being perfectly honest, I can see that policy coming under pressure. The author of Clean Code, "Uncle Bob" famously stated on X in 2026 that he "no longer reads code generated by AI". This is a provocative statement and it received pushback, not least from Grady Booch who is clear that he reviews all AI-generated code. The real answer probably lies somewhere in the middle, based on individual circumstances and the specific code in question. Personally, I think the pressure from organisations to move faster (outside of safety-critical systems) will inevitably lead to something closer to Bob's approach.

Indeed "review fatigue" is already setting in: humans just can't spend all day reviewing code and continue to do it well. The real risk is that organisations continue to insist on "all code must be reviewed by humans" and the mitigations are therefore not put in place – while the reviews themselves end up superficial at best. That's the worst of all worlds.

I think that the mitigation you need, if you are not going to review all code manually, is to make sure the system is fully covered by automated testing. This is one of the key findings from "Accelerate". The research in that book shows that organisations that ship software more often also have lower defect rates, with test automation among the capabilities driving both. In my view, it only works when you have actually implemented automated testing, and the decision to ship more frequently is what forced that testing to get better.

To move faster with AI development only makes this even more important because you may end up relying on the tests in the absence of humans reading the code. In effect, review the tests, not the code.

Required skills / changes to the system

• Understand the different types of tests, such as unit tests, integration tests and UI tests and set deliberate rules for when to use each type. In particular, UI tests are very fragile and tell you little about the ability of a system to behave correctly end-to-end. They are important for some things, but Integration tests running against APIs are much more scalable.

• Have clear boundaries and API surfaces to make the system testable – especially for integration tests.

  • Systems that integrate with other systems need to think carefully about having clean service boundaries so integration tests can run without spinning up 3rd party systems. You need to be able to mock those 3rd party systems in your tests without it being a huge exercise.

  • Solve the "login" problem so you don't have to stand up a 3rd party Identity Provider in your test environment.

• Learn how to write integration tests that express the business outcomes rather than technical features. Use tools such as Cucumber/Gherkin and Verify.

• Implement careful review of the tests (especially the integration tests) as they are essentially the "runnable spec" for the system. With Cucumber/Gherkin the product owner can – and often should – review these and may even make changes to them. In some cases, you may get the AI to first iterate on a set of these tests with the product owner before doing any actual coding.

• Integrate additional deterministic quality-gates (e.g. Security and Test Coverage analysis)

How hard is this to do?

There is nothing inherently difficult in solving this bottleneck. The problems are all well understood and technical solutions exist. But it is likely to be expensive as there is a lot of plumbing work to be done.

How expensive will depend massively on the type and age of the system. For example, a system that primarily integrates and moves data between different systems will take a lot of work, whereas a system that is mostly self-contained will require a lot less work to make testable. Similarly, systems that have evolved over a long period of time are more likely to have tight couplings between different parts of the system that makes testing hard.

Expect at least several person-months – even when assisted by AI.

🍼 Bottleneck 2: Requirements and Acceptance

When features are being developed that much faster, the business analysts and product owners start to struggle with producing mature requirements fast enough. Similarly, when features arrive faster, the product owner and/or the organisation often struggle to review and adapt fast enough.

We are seeing that with several clients already.

It is common to have a fairly stringent requirements maturity process to ensure that requirements are well understood before we start writing code. That made sense when "code writing" was the most expensive part of the process.

But when the code generation (and UI mockups) are cheap, it's worth thinking differently.

For many requirements, it will work better to focus on the outcome you are trying to achieve. Spend your energy clearly defining what users and the business will be able to do when the "feature" is delivered rather than how it is delivered. Focus on user stories over use cases, if you like. Then let the team run experiments to quickly iterate and see what actually works. Ideally, run experiments in production: Add multiple versions of a new feature, let 1% of users try each one and monitor.

Of course, some requirements require much more detailed flow and data analysis, whereas others are more UI focused. Act accordingly and consider using AI to help with writing the former.

Ultimately, what I have described above is GIST – just faster.

Required skills / changes to the system

• Feature flags with cohorts and gradual rollout.

• Monitoring of user behaviour – both technically and have the skills to use it to interpret which features work for users.

How hard is this to do?

This is likely to be the most uncomfortable change to make and the one requiring the most change management.

In order to move faster, you have to reduce the amount of control. More changes being put in front of users more often. Less up-front testing of those changes (because the users become the testers). I am not talking about testing if the feature technically works, more about whether it works in a way that users like.

This reduction of control is a big thing and it may not be the right thing in your situation. The expression "move fast and break things" was coined for a reason!

That said, when you are pushing features out faster, there will also be more technical errors actually hitting end users. We are seeing this already, in the wild. The difference is that when you go into Excel Online and a button doesn't work, chances are it will work when you come back tomorrow because Microsoft monitor this and roll forward, rapidly.

So we are talking about putting stuff in front of (some) users that they may not always like and in some cases it doesn't even work. And we rely on measuring and monitoring to quickly identify and fix problems.

And we are talking about freeing up the whole team to identify and release different ways to achieve the outcome that the product owner has asked for.

For many, that is very, very different to how they currently operate and it will be deeply uncomfortable. But as GIST and Accelerate already identified years and years ago – this is the kind of world you need to live in, if you want to push software development to be faster.

What next?

Okay, so where do you go from here?

I recommend three things:

Build a Testing Strategy

The thing that will likely take the longest is to make your system fully testable. Start by reviewing your system and your code to identify all the things that will block you from performing automated testing. The key is that you need to run automated tests without having access to any 3rd party system.

After that, you can start to look at the actual tests etc – but focus on testability first. It is almost always the real blocker.

Review how you want to manage and deliver requirements

This is the area that will be most uncomfortable so start having conversations internally about what your relationship with your users looks like in a world where you deliver rapid change directly to users. Can you realistically reduce control? Do you have regulatory limitations? Contractual? Can your organisation cope with rapid changes?

Think about all the stakeholders you need to engage. If you sell software to others, you want to include sales and probably legal. If you develop software for internal use, you want to include representatives of your internal customers.

Invest in user experience monitoring

Invest in software that can monitor how users engage with the software and roll that out as early as possible so you can get a baseline.

Then learn how to properly use it. You need to be able to see from the data whether users like or dislike a new feature. That is a skill that takes time and effort to build.

If you need some help, please contact us. We are working with several companies on these areas at the moment.