A few years ago we wrote about building software the uncomfortable way. It was all about stripping away features and shipping something embarrassingly small to find out if any of it mattered. The feedback loop was the product and everything else was waste.
We still believe that. However given the conditions have changed enough, we think the piece deserves a revisit.
The cost of building software is reducing. Where AI agents can generate working code from a well written specification in hours, the temptation to build more has never been stronger. Which is exactly when you need to stay uncomfortable.
From steering wheel to bazooka
The original article was fundamentally about feedback loops. Agile wasn't faster because of standups or two-week sprints, it was faster because it gave you a steering wheel and it was a way to correct course before you'd driven too far in the wrong direction.
Agentic code generation however changes those physics as the build itself is no longer the bottleneck. We now look at agentic code as a bazooka, where you've got to be pointing it at exactly the right outcome, because you can't steer it. If it turns out you were slightly wrong, that's fine. Re-aim and fire again. But that means the specification becomes almost everything.
The feedback loop still matters. What you're iterating on has changed.
The spec is the new scope
The original principle: reduce scope to the point of discomfort, then get it in front of real people.
That principle hasn't changed. But the lever has moved.
In ACDC (not the band but our framework for AI-native development) 50% of the sprint is ensuring the specification is correct. 20% is the build itself. The bottleneck has shifted from how fast you can build to how clearly you've defined what to build. Feed an agent a vague brief and you get vague code. Give it precise acceptance criteria, defined edge cases with explicit constraints and it builds exactly what you asked for.
One thing worth naming: specification is probably the wrong word as it carries baggage. Think of the static document a BA produces that nobody reads again. What we're talking about is closer to a living context layer such as company goals, architectural decision records, user journeys and real constraints. The richer and more honest that context is, the better everything the agent produces becomes. It compounds.
Uncomfortably simple now applies to what you choose to specify and not how thoroughly you specify it. One set of features with an outcome. Get that in front of real people. Then do the next one.
Conway's Law was always the point
The original article mentioned Conway's Law almost in passing, which was a warning that if you create an overly complex set of services early, your team structure will mirror it.
ATOM, our operating model for AI-native engineering teams, turns this from a warning into a design principle. Your org chart is your architecture now. Ensure that pods do not share codebases. One pod, one product, bounded and deployable. Agents inherit the shape of your team and if the team is tangled, the code will be too.
If you need to add capacity, add another pod. Don't make the existing one bigger.
Prototyping got faster and the discipline matters more
The original article was blunt: always throw the prototype away. It's an experiment. If it survived into production then the prototype was over engineered.
Our current thinking around this is much sharper: if the originator of the idea hasn't built or been involved in their own V1, they probably don't understand their own idea as much as they could.
ACDC makes prototyping the first stage to validate the vision before a single production line is written. The tools have made this faster and the principle hasn't changed.
Build, buy or generate
The original argument: buy until proven otherwise. APIs and SaaS had commoditised most infrastructure. Build only when you have genuinely unique problems.
The new addition is to generate. Projects that weren't worth commissioning yesterday will become viable tomorrow. Things that were deferred for years can now ship in months.
Gall's Law still holds: a complex system that works is invariably found to have evolved from a simple system that worked. A complex system generated from scratch by an agent without a clear brief works about as well as one designed from scratch by a developer who didn't have one. You have to start over with a working simple system.
Cheaper construction doesn't change where you start. It changes how fast you can iterate from there.
Invest in what makes agents iterate
The original advice: invest in the pipeline and the tests. Keep the rocket simple; invest in the launch platform.
In the agentic era this translates directly. Agents auto-generate unit tests. Automated validation is the backbone of ACDC — every build goes through it before a human sees it. The investment logic is identical; the economics are better.
The new addition is the specification stack. Every time models improve, organisations with better specs compound that improvement. Organisations without them don't.
The feeling doesn't change
When we wrote the original piece, we described a specific reaction which was the knee jerk discomfort when someone suggests making something smaller. The instinct to add features just in case. The feeling that stripping back further might break something important.
Agents don't remove that feeling. They remove the constraint that used to enforce the discipline anyway.
Stay uncomfortable. Ask what the smallest thing is that could answer the question. Build that. Put it in front of real people. Do it again.
The loop is what matters. It always was.
