Why Software Craftsmanship Matters More Now, Not Less

For about a decade, the industry has been quietly trading craftsmanship for velocity.

The trade made sense. Code was the scarce resource. The disciplines that constrained complexity were treated as preferences a strong team could afford and a fast team could skip. The fast team usually won the quarter. The craft team usually won the decade. But decades are long and quarters are short, and most organizations optimize for what they can measure this Friday.

The economic logic from the previous article in this series has not changed. What changed is which disciplines the economics now favor.

When agents produce code in seconds, the disciplines that constrain what they produce, in what shape, and to what standard stop being preferences. They become the constraint mechanisms that make agent output something humans can verify, maintain, and reason about. The industry deprioritized craftsmanship when humans were the executors. That was always a trade. In the agent era, it stops being a trade and starts being a liability.

“If skills sold, truth be told, I’d probably be lyrically Talib Kweli. Truthfully I want to rhyme like Common Sense, but I did five mil. I ain’t been rhyming like Common since.”

That is the trade. Said plainly by someone who made it and never pretended otherwise.

How I came to believe this

I did not arrive at craftsmanship as a theoretical position. I was formed in a crucible.

A small cohort of us from GMU’s computer science department, chaired at the time by Peter Denning, the pioneer of virtual memory whose working-set model became the reference standard for memory management, were hand-picked by the IT department to execute a mainframe-to-client-server migration. Looking back, what we pulled off was genuinely difficult work. We competed with each other in the right ways: about architectural elegance, about code quality, about getting the thing right rather than just getting it done. I had to invent composite algorithms to survive the memory squeeze going from mainframe to 32-bit. None of that work would have been possible without craftsmanship as the shared ideal.

That training is the lens through which I have read every codebase since. It is also the reason I keep noticing what is now happening at industrial scale: the disciplines that made hard things possible are the same disciplines that make agent output trustworthy. The era did not invent the need. It amplified it.

The three disciplines, repriced

Most of the craftsmanship stack matters more in the agent era than it did before. Three disciplines carry a disproportionate share of the weight. Each one solves a problem the agent introduces by its nature, in a way the human reviewer cannot replicate after the fact.

Ubiquitous language used to be DDD’s connective tissue between domain experts and engineers. In the agent era, it becomes the connective tissue between the specification, the agent, and the code. Without it, the agent invents its own vocabulary on every generation. A customer becomes a user becomes an account holder becomes a party, and the codebase becomes a tower of synonyms that obscures what the system is actually modeling. A team that maintains a ubiquitous language gives the agent a fixed vocabulary to paint inside of. A team that does not gives the agent a thesaurus.

Domain-driven design used to be the discipline that kept business complexity contained. In the agent era, it becomes the bounding mechanism that tells the agent where one concept ends and another begins. Agents are creative. Creative without boundaries produces concept sprawl. The same business idea ends up implemented three different ways across three different modules because the agent had no map of where it was allowed to operate. DDD provides the map. Bounded contexts are not architectural decoration. They are the fences that keep the agent on the property.

Hexagonal, clean, and onion architectures used to be the disciplines that separated business logic from infrastructure concerns. My favorite of the family is Onion, Jeffrey Palermo’s framing of the same essential principle. In the agent era, all three serve a function their original authors did not have to articulate: they tell the human reviewer where to look when the agent’s output goes sideways. The metaphor I keep coming back to is paint by numbers. The painter is the agent. The numbers are the architecture. The painter can be as creative as it wants inside the lines, and a well-layered system gives the human reviewer a map of where to look when something on the canvas does not match the picture on the box. When a regression appears, the architecture narrows the search space from the whole system to this layer, this port, this adapter. That is what it means to know where the bodies are buried. A free-form agent sprawl is a system nobody can investigate quickly. A well-layered system is.

I have inherited the alternative more times than I can count. The clearest version of it was at a human capital management company that had grown by acquisition and cobbled together a stack of SaaS products through M&A. The integrated codebase read like Picasso, Mondrian, and Monet had taken turns on the same canvas. Business logic lived in the application code, in inline SQL, and in stored procedures, all at once and in different proportions in different modules. Every change carried a hidden blast radius. A function modified in one place would detonate something on the other side of the system that had no logical reason to be connected to it. The code compiled. The code ran. Under load, the memory leaks and database locks surfaced, and many nights and weekends were lost to a caliber of problem that craftsmanship would have prevented entirely.

That is what the absence of these disciplines costs. The agent era does not eliminate that cost. It scales it.

The objection worth taking seriously

Every argument for craftsmanship in the agent era runs into the same counter-argument. It usually sounds like this:

“The agent can refactor anything in seconds. Why do I need clean architecture if I can just regenerate?”

The objection is worth taking seriously because it would be a real objection if it were true. It is not, on two separate fronts. Two failure-modes are hiding inside the same counter-argument.

The first failure-mode is directional. Regeneration without a target produces motion, not progress. The agent has no opinion about what better looks like. Without an architectural reference, the agent will regenerate the system forever and never converge on the version you wanted, because the version you wanted was never specified in a form the agent could optimize toward. Craftsmanship is what gives the regeneration a toward. Without it, regeneration is just expensive randomness.

The second failure-mode is economic. The objection assumes regeneration is free. It isn’t, and it is getting less free. The initial phase of the agent era was subsidized. AI companies absorbed the real cost of inference to seed adoption. That phase is ending. Token pricing is becoming more honest. Reclamation efforts are underway. Until LLMs are fully commoditized, regeneration is going to be priced as the non-trivial operation it always was. Most software development is an economic endeavor first and foremost, and TCO has always been the discipline that separated software-as-engineering from software-as-experimentation. The agent era does not exempt anyone from that math. It enforces it more strictly.

The agent does not pay for the tokens. The humans who own the system do.

The objection survives neither failure-mode. The team that treats regeneration as free is going to discover the price the same way the HCM company did. Under load.

What craftsmanship is now

It is survival.

The system without these disciplines is not slower. It is one the team will not be able to maintain when the agent reaches its limit and a human has to read the code. And the agent reaches its limit more often than the hype suggests. AI is itself software, consumed for most teams as SaaS, available some number of nines percent. That means it is unavailable some other percent, and Murphy’s Law guarantees those gaps will land on the days that matter most. The replacement of humans across planning, building, operating, and supporting software is not happening on any timeline that exempts a team from being able to read its own codebase.

When the agent is unavailable, when the bill forces discipline, when the system hits a class of problem the model cannot solve, the humans who inherit the code have to read it, reason about it, and fix it. Craftsmanship is what makes that possible.

The agent does not need craftsmanship. The humans who will inherit its output do.

The next article in this series is the receipt for what unconstrained agent output actually costs an organization. It surfaces in expanded attack surface, in maintenance debt, in cognitive load, and in the bills that arrive at the end of the month.

Further reading: Article 4 of this series, ”Code Is Cheap. Trust Is Expensive”, Article 2, ”Defining AI-Augmented Engineering”.