You've probably seen the famous skateboard-to-car agile development meme. This one where the "wrong" way shows a car being built piece by piece (wheel, chassis, body, car), and the "right" way shows a skateboard, then a scooter, then a bike, then a motorcycle, then a car...
I saw Tim Ottinger post about this on LinkedIn recently. His point was that most people see this as a delivery plan where the route to "car" is via "skateboard"...
You knew you wanted a car all along, you just shipped it in stages.
Ottinger's point is that this is exactly the wrong reading.
The skateboard isn't a stepping stone to the car. It's a real solution to a real problem. You give someone a skateboard and they use it. You learn something. Maybe what you learn sends you towards a bicycle. Maybe after the bicycle you discover your users need to move fifty people at once, and now you're building a bus. The endpoint was never fixed. The point is to keep solving the problem, not to arrive at a predetermined artefact.
AI coding agents are removing the construction bottleneck. Perhaps moving it elsewhere. This does make us faster, but is faster always better? Maybe the question is faster at what?
The skateboard diagram, Cagan, and the feature factory
Ottinger's critique maps almost exactly onto Marty Cagan's product operating model. Cagan's argument, across Inspired, Empowered, and Transformed, is that the best product teams are given problems to solve, not features to build. They discover the right solution through iteration, testing assumptions against reality. Maybe the answer is a car, maybe it's a bus, maybe it's something nobody anticipated.
John Cutler's "feature factory" is the opposite. Output is the measure of success. The backlog is a conveyor belt of predetermined solutions. Teams execute specs rather than solving problems.
All are describing the same dysfunction. Ottinger identified the mental model underneath it all: people see a delivery plan where they should see a discovery process.
Enter AI coding agents
AI-assisted coding amplifies all of this.
The feature factory was already a problem when building the wrong thing took weeks. Now you can ship the wrong thing faster, add more testing and review work, pile up more user confusion and support burden, and accumulate complexity and tech debt much faster.
If your team was already a feature factory, AI makes it a faster feature factory.
A team oriented around outcomes can try the skateboard, get feedback, try the scooter, learn something unexpected, pivot to the bus, all in the time it used to take to spec out the car. The discovery loop becomes much more practical when construction isn't the bottleneck.
What gets lost
There's a subtler problem beyond deciding what to build.
When a human writes code, understanding is a side effect. In the moment of building you had to work through the logic, understand the dependencies, and reason about edge cases. That forced comprehension was never valued because it came for free.
Several people have been writing about this. Margaret-Anne Storey coined the term cognitive debt earlier this year for the gap between what AI-generated code does and how well the team actually understands it. Addy Osmani expanded on it. Thoughtworks put "codebase cognitive debt" on their Technology Radar in April. It's gaining traction because it describes something people are noticing in practice.
I wrote about a related problem in Operational Debt. Running production systems over time earns you knowledge that isn't in the code: real-world usage patterns, failures that only show up under load, degradation behaviour that creeps in over months. When code generation speeds up by an order of magnitude, that operational knowledge can't keep pace.
Both of these are examples of the same pattern. AI removes the construction bottleneck, but construction was doing more than just producing code. It was also producing understanding. The code arrives faster. The understanding doesn't.
The invisible regulator
These look like separate problems, but they share a cause.
When building was slow, that slowness gave humans time to keep up. Product was a separate function because building the wrong thing was expensive. Comprehension came free because you couldn't build without understanding. Operational awareness scaled naturally because systems grew at human speed.
AI coding agents remove the regulator.
This isn't new, but it matters more now
I recently gave a talk at Async Brighton about what happens when you stop writing code as a software developer. One of the things I talked about was that while the tools are new, a lot of what makes them work well is old.
Gergely Orosz recently revisited Fred Brooks' 1986 "No Silver Bullet" paper in The Pragmatic Engineer. Brooks argued that no single technology would produce an order-of-magnitude improvement in software productivity because the hard part of software isn't the construction. It's working out what to build, how the pieces fit together, and how to deal with change over time. The construction is the easy part. It was the easy part in 1986, and it's even more the easy part now.
AI coding agents look like they might be the silver bullet Brooks said wouldn't come, and at a first glance you might think they are. But, while construction really has got an order of magnitude faster for many tasks, the bottleneck just moves. The hard problems are still product discovery, system comprehension, and operational knowledge. They always were. Construction was just in the way, making it hard to see them clearly.
What's next?
AI is making teams faster. But these gains aren't as large as expected for most teams. The graph below is from Abi Noda's DX newsletter. The interesting question is what separates the average from the P90.
My guess is that the P90 teams are the ones that had already done the work on their development process and were already oriented around outcomes rather than output. It's not that AI made them good, it made their existing discipline pay off faster.
The rules around complexity are changing too. The overhead of coordination and communication that used to force certain team structures might shift. I think smaller teams with strong fundamentals might end up with disproportionate leverage.
There's still no silver bullet. But for teams with strong SDLC and a focus on outcomes, faster can mean better.