I recently read The Nature of Software Development by Ron Jeffries, a book originally published in 2015.
At first, it might seem like a book from a different era of software development. We now have LLMs, coding assistants, and increasingly capable coding agents that can implement in minutes what previously took hours or days.
But my main takeaway was the opposite of what I expected:
The way we build software has changed dramatically. The principles that should guide us haven't.
If anything, AI makes many of Jeffries' ideas even more relevant.
The book's central idea is simple:
Value is what we want.
Everything else should help us deliver value sooner and learn faster: planning, architecture, teams, testing, and development practices.
The Natural Way
Software is lava. There is no safe place to stand.
Requirements change. Users change. Markets change. Technology changes. And, as we build, we learn things that invalidate assumptions we made before.
Jeffries' answer is not to try to predict everything. It is to build a process that allows us to continuously move, learn, and adapt.
This benefits everyone:
- Users get valuable software sooner.
- Businesses get ROI and information sooner, allowing them to change direction.
- Management gets visibility into the real state of the project.
- Developers get clear direction while retaining the freedom to use their skills.
The process is simple:
Think → build → learn → iterate → repeat.
Doing it well isn't.
And AI doesn't change this. It changes how quickly we can execute each step.
Value Is What We Want
Software only creates value when it is shipped and used.
That's why Jeffries advocates building small, valuable features instead of trying to build everything before releasing anything.
Most users don't need every feature. We should prioritize the features that provide the most value for the least effort and defer the rest.
Shipping early also gives us something incredibly valuable: information.
Sometimes the most important information we can get is that we're building the wrong thing.
This becomes even more important with AI.
AI is making software dramatically cheaper to produce. An agent can implement a feature, write tests, refactor code, or build a prototype in a fraction of the time it would take a developer to do everything manually.
But cheaper software doesn't mean more valuable software.
In fact, it creates a new problem:
When building software becomes cheap, deciding what is worth building becomes more important.
We can now build the wrong thing incredibly fast.
So AI doesn't make feedback less important.
It makes fast feedback more valuable.
Guiding by Value
We can't have everything.
Every project has limited time and money, so we need to deliberately choose what to build and what to defer.
Jeffries recommends planning for multiple releases from the beginning. Delivering frequently allows us to see what's actually happening, learn from users, and change direction when necessary.
This principle becomes even more important with AI.
If implementation becomes faster, we shouldn't use that speed to make our development cycles longer.
We should use it to make them shorter.
Instead of:
Plan everything → Build everything → Ship → Discover we were wrong
we want:
Choose valuable thing → Build a small slice → Ship → Learn → Adjust → Repeat
Agents make this loop cheaper.
They don't make long feedback loops safer.
This also changes how we should think about estimates.
Humans are bad at estimating software development, and AI makes detailed estimates even less useful because the cost of implementation can vary dramatically depending on how much work can be delegated to agents.
Instead of asking:
"How long will this take?"
we should ask:
"What valuable outcome should exist next?"
As Jeffries puts it, estimates focus our attention on the cost of things instead of their value.
From Feature Teams to Agentic Teams
Jeffries argues that teams should be organized around features rather than technical silos.
If a feature has to pass through separate frontend, backend, database and QA teams, every handoff adds coordination cost.
The more boundaries a feature crosses, the longer it takes to deliver.
AI can reduce some of these boundaries.
A developer can now use agents to help with research, implementation, testing, debugging, UI work, documentation and other parts of a feature.
This makes the idea of working around complete features even more powerful.
But it also changes where the bottleneck is.
When producing code becomes cheaper, the scarce skill increasingly becomes knowing what to ask for, providing the right context, evaluating the result, and deciding what to keep.
The developer's role moves upward:
Understand the problem → define the intent → delegate implementation → verify the result → make decisions.
AI doesn't make developers less important.
It makes judgment more important.
Building Feature by Feature
Jeffries advocates working feature by feature and learning from every iteration.
We should expect to get things wrong.
After each iteration, we learn more about the product, the users and the problem. That information should influence what we build next.
AI makes experimentation much cheaper.
We can prototype an approach, throw it away, try another one, compare implementations, and iterate much faster.
This makes vertical slicing particularly powerful.
Instead of spending weeks perfecting one technical layer, build a simple functional version that goes through the whole system:
User action → UI → API → Database → Tests → Working feature
AI can help us move through these layers faster.
The goal isn't to build the perfect version of one feature.
It's to build the best possible product at every moment.
If we do that throughout development, we are much more likely to have the best possible product when we ship.
Quality in an Agentic World
If AI can generate code faster, it can also generate defects faster.
Generation without verification is dangerous.
Jeffries argues that software should be kept nearly defect-free throughout development. Testing and fixing defects aren't activities reserved for the end of a project. They are part of building the feature.
This becomes even more important with agents.
The agent needs feedback about whether its implementation works.
Tests provide that feedback.
This makes testing particularly interesting in an agentic workflow:
Human defines intent → Agent implements → Tests verify → Agent fixes → Human reviews → Refactor → Ship
Tests are no longer just a safety net for developers.
They can become an interface between humans and agents.
Acceptance tests give the business confidence that the software behaves as expected.
TDD gives developers (and agents) fast feedback when something breaks.
And refactoring keeps the design healthy as the system evolves.
An agent can make a refactoring technically correct while still making the architecture worse. So, once again, we need human judgment.
The machine can produce the implementation.
Humans still need to provide intent and judgment.
The Real Risk of AI
There is a lot of discussion about AI making software development faster.
That's true.
But speed isn't the goal.
The real danger isn't that AI will make us build software too slowly.
It's that we'll build the wrong software incredibly fast.
We can now have an agent spend hours implementing a feature while we sleep.
We can generate thousands of lines of code without writing a single line ourselves.
We can create a beautifully engineered solution to a problem nobody actually has.
That's not progress.
That's waste at unprecedented speed.
And this is why the ideas in The Nature of Software Development still hold up so well.
AI changes the economics of building software.
It changes the role of the developer.
It changes how teams can work.
It changes how quickly we can experiment.
But it doesn't change what we ultimately want.
Value.
Final Thoughts
Ron Jeffries wrote The Nature of Software Development more than a decade ago, long before the current generation of AI and agentic coding.
Yet the fundamental principles remain remarkably relevant.
- Software is still uncertain.
- Users still change their minds.
- Businesses still need to make trade-offs.
- Estimates are still estimates.
- Features still need to create value.
- Software still needs to work.
And we still learn more from using software than from planning it.
What has changed is the cost and speed of execution. AI allows us to build faster and experiment more cheaply.
So we shouldn't abandon Jeffries' principles.
We should apply them more aggressively.
Use AI to build faster, but shorten the feedback loop.
Use agents to write more code, but be more ruthless about what code is worth writing.
Use AI to experiment cheaply, but be willing to throw away the wrong experiments.
Use agents to automate implementation, but keep humans responsible for intent, value and judgment.
The nature of software development hasn't fundamentally changed.
Our ability to execute has.
And that makes Jeffries' central lesson more relevant than ever:
The goal is not to build more software. The goal is to create more value.
