Fred Brooks said "plan to throw one away; you will, anyhow." That was 1975 and it's more true now than ever.
He said this because when we approach software, we don't know how to properly build it until after it is built. Writing code is simultaneously creation and discovery: we learn how to make something through this process.
AI coding agents are driving the cost of a line of code to zero. But is it the right code?
My engineering practice is evolving to recognize this. The first implementation of something is a learning exercise. I'm discovering the shape of the problem: what the bounded contexts are, where the complexity actually lives, what I got wrong in the initial design. And I'm learning what I really want the agent to make.
Before this, throwing away code was too expensive. The backlog is always too long. So we'd patch, add layers of abstraction. Now I can have an agent rebuild a service from scratch in hours using the knowledge I gained from the first attempt. The code is disposable. The understanding is not.
This changes how I approach a release. Instead of aiming for "good enough to ship", I explicitly tell the agent that the primary purpose is to learn. We're validating assumptions, not feature completeness. Once I know how the thing should actually work, the "real" implementation is fast because I'm not discovering and building at the same time.
At first this was hard: I had a lot of ego in the code I wrote. The backlog pushes me to ship. But if the agent can regenerate it in a fraction of the time it would take to maintain the original, the sunk cost argument disappears.
What have you thrown away and rebuilt now that it's practical?
The framework behind this: Trust Topology →