On AI and velocity

Can we improve developer velocity 10x with AI, and how do we deliver value to clients 10x faster?

Start with what slows developers down.

A typical software company worked roughly like this in pre-AI times. Senior developers are 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 work, and can provide useful feedback that saves development time if they are involved in discussions early.

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

What changed with AI?

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

The code often looks convincing, like it could work. Some of it is useful; much of it is not there yet.

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

Presumably some of the time went to thinking.

AI reduces the time required to generate code, but that does not automatically reduce the time required to understand whether the code is correct. It even increases the effort required to avoid breakages, just because it loves changing huge amounts of code. 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 an obvious bottleneck: generation became cheap, while reading and verification became much more expensive.

If developers 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, more and more developers do that: skim the change, look at the diff, run the tests, and move on.

This sometimes works, and sometimes it 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 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 larger than necessary, 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 often adds code that’s disabled, unwired, and unused.

This is, I think, one of the main reasons we are not seeing developers become 10x more productive from access to AI alone. 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 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: the study estimated an 18% speedup for developers who had participated in the original study, and around 4% for newly recruited developers. (metr.org)

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. Measuring this is becoming harder as AI becomes a normal part of development.

That is far from 10x productivity gains with today’s AI. The question is how to change that.

How do we improve productivity?

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 we should stop expecting every engineer to provide that complete context every time.

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

2. Reduce AI slop

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

Example review tasks: Does this 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 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 writes a partial change, a human deploys it, the human inspects it, explains the problem, the AI changes it, and the human deploys it again. The human in the loop becomes a frustrated, underutilized, and expensive testing component.

Instead, enable AI to iterate autonomously until it implements the full feature and verifies that it works end-to-end in a realistic local or staging environment. Then the human reviews changes, tests the application, and provides feedback.

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

Before you share documents, architecture proposals, design documents, slides, or important messages, have AI run an adversarial review.

What is unclear? What does not follow? 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 AI has already found the obvious weaknesses before anyone spends expensive human attention on them, and humans can focus on what matters.

5. Generate slides from existing documentation or code

We still spend a large amount of expensive engineering time converting information from one format into another. If a design document already exists, have AI generate the first version of the slides from it.

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

Senior engineers usually know which one is correct.

LLMs are great at reading and writing text, and code changes are precise, which makes them a good input for LLMs. Instead of expecting somebody to notice months later that the implementation drifted from the design documents, we can keep documentation, slides, and code coherent.

6. Automate summaries

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

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 large amount of engineering time, and engineers can spend the saved time on something valuable for the company and the customers.

The bigger point

The path to 10x developers is probably not making developers type code 10x faster. The bottleneck was typing meaningful code and dealing with the ripple effects, so asking AI to type meaningful code without sufficient context is the wrong approach.

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

Customers don’t 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 works, deploy it, and get it into their hands.

The opportunity is to shorten the entire loop from a requirement to something useful running for the customer.

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 have it filter out bad output before humans ever see it will get much closer to the promised productivity gains.