Key Takeaways
- Shipping got dramatically faster with AI agents, but validating whether a feature actually solved the user's problem didn't get any faster.
- Small, iterative development was never really about speed. It was about catching a bad assumption before too much got built on top of it.
- If a team ships ten times faster, validation doesn't get to speed up ten times to match it. Learning something real from a user still takes the time it takes.
- Before building the next feature, confirm the last one actually solved the problem it was built for.
For the last several years I've used generative AI tools every day for software engineering, and something keeps nagging at me.
I can hand an agent a feature, let it run on its own for an hour, and have the thing deployed before lunch. That changes what "producing features" looks like day to day. Take a list of user stories, write the specs if I even bother, turn the agents loose, review the diff, deploy, move to the next thing. I catch myself doing exactly that, and flowing cards across the board feels good. Shipping has never been easier.
But somewhere in that loop, I think we're tempted to skip one of the most important parts of the job: finding out whether what we just deployed actually delivered the value we assumed it would.
Did the first feature we shipped today actually solve the end user's problem? That's the question I keep circling back to.
We didn't start working in small, iterative cycles just because building software used to be expensive and slow. That was part of it, sure. The bigger reason was that we knew we were working off assumptions, and putting something small in front of real users was how we learned early and often, failed fast, and changed course when we were wrong.
None of that has changed. What changed is the cost and the wall clock time of implementation. Building software got dramatically easier. Knowing whether we built the right thing didn't get any easier at all.
If a team can ship ten times faster, validation doesn't get to speed up ten times to match it. Learning something real from a user still takes the time it takes, no matter how fast the code gets written.
Which means the shipping needs to slow down, not the validation. Deploying a feature before lunch doesn't tell us it solved anything. It tells us it's live. Before we build the next feature on top of it, we need to know whether the last one solved the problem it was built for.
We can ship features faster now. That's not a reason to keep piling more of them onto the backlog. It's a reason to spend some of the time we saved confirming the last one worked before we move any farther down the list. Deploying a feature because we finally can isn't the same as deploying it because it's the right thing to build next.