Frictionless and the friction you only find by going faster

Imagine your agent successfully converts a ticket into a pull request before lunch. The code itself took minutes, but now the PR just sits there for a day or so because of a flaky pipeline or a reviewer with a similar stack of PRs. Frictionless, the book by Nicole Forsgren and Abi Noda, names it: cheap code-writing shifts the constraint from creating the code to validating and delivering it.

You won’t notice where something’s slowing you down until you actually speed up other parts of the system.

This is a pretty typical thing bottlenecks do in any system.. the slow review queue and the tests you didn’t trust were pre-existing problems that most people on the team had been dealing with for years, but the faster code writing removed the thing that was masking them.

So, what do you fix first.. the pipeline, the flaky tests, or the review queue? The book suggests you start before you even fix anything, with a listening tour. Talk to engineers and find out where they’re really losing time. Then, score each candidate by reach (how many people it affects) times impact, weighted by your confidence in those estimates, and divide by effort. You’ll usually find that the cheap fix that helps a lot of people, like the flaky test everyone has to rerun automatically, rises to the top.

The order is more important than the formula: asking first means you don’t waste a quarter rearchitecting your delivery pipeline when the daily universal pain is one unreliable test that one person can fix in an afternoon.

I really do believe that we’re at this fortunate moment in time with artificial intelligence that what’s good for AI is also good for humans. Fast builds, tests, documentation, clean code, all helps AI, but it’s also just easier for humans to reason about.

I see this as cheap code raising the urgency of an old developer experience backlog. The boring backlog now has an argument that executives will listen to. Fast builds and clear documentation used to be quality-of-life requests. Now they determine whether agent speed makes it to production.

I just think at some point someone’s going to have to answer for the code that’s written. And I think people are just optimistic that no, they won’t. That an AI agent will answer for the code that was written.

There’s a question underneath all of this what-to-fix-first stuff that nobody has a good answer to yet. Each of the fixes on this list makes it easier to move a ticket into production with fewer humans touching the change. If the pipeline is fast and trustworthy enough to approve the agent’s change on its own, whose name goes on it?