AI makes building software cheaper

AI is making software development cheaper and faster, but Ron Jeffries' 2015 book 'The Nature of Software Development' warns that the biggest risk is building the wrong things at high speed. The author argues that with AI agents like Claude Code and GitHub Copilot, teams must focus on fast feedback loops and value delivery rather than traditional estimation, treating AI as a way to buy information and validate assumptions quickly.

AI makes building software cheaper I recently revisited Ron Jeffries' The Nature of Software Development . Even though it was written back in 2015—long before we had Claude Code /en/tags/claude%20code/ or GitHub Copilot—the core philosophy feels more urgent now than it did a decade ago. The trap of high-velocity garbage The biggest risk we face right now is that AI allows us to build the wrong things at an incredible speed. If an LLM agent can spin up a prototype, write the unit tests, and handle the initial refactoring in twenty minutes, the temptation is to just keep pushing. We can generate features faster than we can validate them. But Jeffries’ central premise is that value is the only thing that matters. Software only has value when it is actually shipped and used by a human. When implementation costs drop toward zero, the cost of a bad decision doesn't necessarily drop—it just happens faster. We can now execute a flawed architectural direction or a useless feature set in a single afternoon. Why fast feedback is the only real safety net In my experience rolling out these tools to my team, the most important shift isn't in the coding itself, but in the feedback loop. Jeffries argues that software is "lava"—it's constantly shifting because requirements, markets, and tech stacks change. You can't stand still. The old-school workflow was: 1. Plan everything 2. Build everything 3. Ship 4. Realize you were wrong With an AI-enhanced workflow, we have to pivot to a much tighter loop: 1. Identify a high-value slice 2. Use AI to build it rapidly 3. Ship it immediately 4. Gather real-world data 5. Adjust based on what we learned The goal of using AI shouldn't be to make our development cycles longer or more complex; it should be to make them significantly shorter. If an agent can cut a three-day task down to three hours, we shouldn't use that extra time to add more "buffer" to our planning. We should use it to get that code in front of a user sooner. Moving away from traditional estimation One thing that's been a point of friction in our sprint planning is how we handle estimates. Traditional "man-hour" estimations are becoming almost useless. How can you accurately estimate a task when you don't know if a specialized LLM agent will solve it in five minutes or if the edge cases will require a human deep dive for five hours? I'm starting to push my team to stop asking: "How long will this take?" And start asking: "What is the most valuable outcome we can prove next?" We need to treat AI as a way to buy information. Every time we use an agent to build a small piece of functionality, we aren't just writing code; we are running an experiment to see if our assumptions about the product are correct. The speed of the LLM is just a tool to help us fail faster or succeed sooner. Next My IP got blacklisted by an automated security layer and I had → /en/threads/7533/