On AI and velocity

In the AI era, can we improve developer velocity 10x?

And more importantly: how do we deliver value to the clients 10x faster?

To answer this question, we first need to understand what actually slows developers down.

Here is roughly how a typical software company worked in pre-AI times. Very senior developers are highly valuable to the company. In many cases, the more senior, the more valuable. These engineers may not write a lot of code, but they understand the stack, know how things actually work, and can provide useful feedback that saves precious development time if they are involved in discussions early.

On the other hand, junior colleagues often lack exactly this context and understanding. The best junior engineers are those who learn quickly, stay focused, and work hard. They can be extremely productive when given a well-defined task.

What changed with AI?

LLMs are highly efficient systems for generating text relevant to the context they have, and they are fast. Really fast. They can generate hundreds or thousands of lines of code in the time it would take a developer to write a few functions manually.

The code often looks remarkably convincing. It really looks like it could work, and some of it is actually useful. Sadly, quite a lot of it is… not there yet.

Why does this matter? Before AI, writing code was already only a relatively small part of software development. A large Microsoft study based on 5,971 developer responses found that roughly 15–17% of developers’ time was spent on coding, depending on the type of workday. Even that category included reading code and tests, not just writing new code. The rest was debugging, testing, reviewing, meetings, email, planning, helping colleagues, documentation, and so on. (discovery.ucl.ac.uk)

And, presumably, they did some thinking. Hopefully.

AI dramatically reduces the time required to generate code, but that does not automatically reduce the time required to understand whether the code is correct. In fact, it can do the opposite. Developers now need to read not only what other developers wrote, but also what AI generated.

Since AI can produce code much faster than humans can read it, we have created a fairly obvious bottleneck: generation became cheap, while reading and verification became a lot more expensive.

If developers carefully read, understand, and verify every line generated by AI, much of the theoretical productivity gain disappears. The obvious workaround is therefore not to read everything. Under pressure from management to become more productive now that we have AI, that is increasingly what developers do: skim the change, look at the diff, run the tests, and move on.

This sometimes works, but then sometimes… spectacularly fails.

Where does AI slop come from?

AI does not have perfect context. It has whatever context we give it, and when something is missing, the model does not normally stop and say: “I have insufficient context to make this architectural decision.” It makes an assumption and proceeds.

Those assumptions can be perfectly reasonable while still being imperfectly aligned with the actual requirements and objectives of the project. The implementation works, the tests pass, and the code looks clean, yet the change is unnecessarily large, duplicates an existing abstraction, tests pin the implementation instead of an external contract, code violates an architectural rule, solves the wrong layer of the problem, and very often adds code that’s disabled, unwired, and unused.

This is, I think, one of the main reasons we are not seeing developers suddenly become 10x more productive simply because they have access to AI. The real-world evidence is also much less spectacular than the demos.

A large randomized field study covering 4,867 developers at Microsoft, Accenture, and a Fortune 100 company found that developers with an AI coding assistant completed about 26% more tasks, with larger gains among less-experienced developers. (pubsonline.informs.org)

In an early METR study, experienced open-source developers working on repositories they knew well even took 19% longer when using early-2025 AI tools. At the same time, they believed AI had made them faster. (arxiv.org)

Later, with newer AI tools from August 2025, the results went in the other direction. With developers who had participated in the original study, AI was associated with an estimated 18% speedup. Newly recruited developers showed a smaller estimated speedup of around 4%. (metr.org)

There is a caveat here. METR itself says these newer numbers should not be taken as precise estimates, mostly because developers increasingly didn’t want to participate in tasks where they were not allowed to use AI, and because people started using multiple agents at the same time. So measuring this stuff is becoming harder exactly because AI is becoming a normal part of development.

Far from the 10x productivity gains. At least with today’s AI. The more interesting question is how we change that.

How do we actually improve productivity?

While every company has its own requirements and problems, I have found a few ideas useful across most engineering organizations.

1. Improve the quality of AI-generated content

Engineers need to learn how to provide AI with better context, but more importantly, we should stop expecting every engineer to provide that complete context manually every single time.

Repositories should contain clear, machine-readable “general guidance”: architecture, design principles, preferred patterns, testing expectations, conventions, known traps, and things the AI simply should not do. The better the context, the fewer assumptions the model needs to make.

2. Aggressively reduce AI slop

Better models help, but we should not rely on the generating model to review itself. After a change is generated, use a fresh context to review it adversarially, provide feedback, and iterate a few times fixing findings and making a fresh review.

Example review tasks: Does this actually solve the requested problem? Does it follow the project’s architecture and general guidance? Does it introduce security risks? Did it introduce unnecessary abstractions? Is the diff much larger than necessary? Could we get the same result with significantly fewer changed lines? Did it quietly make assumptions that should have been confirmed?

3. Let AI run the full application locally

AI should not stop after writing code. Give it a local development environment where it can bring up the full application, interact with it, inspect logs, run tests, open the UI, reproduce failures, make changes, and iterate autonomously.

Otherwise we end up with a funky loop where AI blindly writes a partial change, a human deploys it, the human visually inspects it, explains the problem, the AI changes it, and the human deploys it again. The human in the loop becomes unnecessarily frustrated and underutilized. An expensive testing component.

What works better is: enable AI to iterate autonomously until the full feature is implemented and verified to work end-to-end in a realistic local or staging environment. And then the human reviews changes, tests the application, and provides feedback.

4. Use AI as an adversarial reviewer before humans spend time reviewing

Documents, architecture proposals, design documents, slides, and important messages should be critically reviewed by AI before they are shared. Not summarized. Reviewed. Adversarially.

What is unclear? What does not follow logically? What assumptions are hidden? What questions will people ask in the meeting? What is an orthogonal issue and could be removed or discussed separately? What should be shortened?

This makes the discussions between humans much more efficient because the obvious weaknesses have already been found before expensive human attention is spent on them, and humans can better focus on what actually matters.

5. Generate slides from existing documentation or code

We still spend an absurd amount of highly paid engineering time digesting information and converting it from one format into another. If a design document already exists, the first version of the slides should be generated automatically from it.

If code is version controlled, it’s fairly straightforward to update documentation and slides based on code changes. Designs change and decisions are often made during development, that’s pretty normal. Updating documentation and slides is something for which there is often “not enough time”, and we end up with two sources of truth: documentation and slides saying one thing and code doing something else.

Which is correct? That’s the knowledge typically kept in the heads of senior engineers.

Fortunately, LLMs are great at reading and writing text, and code changes are highly precise, which makes them a great input for LLMs. Instead of expecting somebody to manually notice that the implementation has moved away from the design documents months ago, this can all be kept coherent.

6. Automate summaries

Release notes are an obvious example where AI can be of good use. The information already exists in commits, pull requests, issues, changelogs, and project management systems, so AI should turn that into useful release notes automatically.

The same applies to meeting preparation, project status updates, incident summaries, weekly reports, handovers, and many other forms of organizational glue work. None of this is glamorous, but all of it consumes a huge amount of engineering time, and the time not spent doing these chores is the time that can be spent on something that is actually valuable for the company and the customers.

The bigger point

The path to 10x developers is probably not making developers type code 10x faster. Typing was never an issue. Typing meaningful code and dealing with the ripple effects was always the problem. Asking AI to type meaningful code without sufficient context is not the best approach.

Instead of optimizing the 17% of a developer’s day, let’s optimize the other 83% as well.

And this is also where developer velocity and customer value finally meet. Customers don’t really care whether we generate the code in ten minutes or ten hours. They care how quickly we understand what they need, build the right thing, verify that it actually works, deploy it, and get it into their hands.

So the real opportunity is not to make one part of software development 10x faster. It is to shorten the entire loop from a requirement to something useful running for the customer.

How do we get there? The remaining bottlenecks are context, judgment, verification, iteration, and communication. The companies that figure out how to give AI the right context, let it iterate independently, and automatically filter out bad output before humans ever see it will get much closer to the promised productivity gains.