There's a book that sits on a short list of titles that quietly shaped the way software gets built: Code Generation in Action by Jack Herrington, published in 2003. I picked it up years ago and it rewired something in how I think about the relationship between a developer and the code they write. Reading it, you get the sense that the most leveraged thing a programmer can do is not write the next feature — it's write the thing that writes features.
The idea that launched Rails
DHH has cited Herrington's book as one of the inspirations behind Ruby on Rails. The core insight is simple but radical: if you find yourself writing the same structural patterns over and over — database accessors, form handlers, CRUD scaffolding — the right move isn't to get faster at writing them. It's to generate them. Rails took that principle and turned it into a philosophy: convention over configuration, scaffolding over boilerplate, the generator as a first-class citizen of the framework. rails generate model is Herrington's thesis made executable.
What made that moment powerful wasn't just the time savings. It was the shift in what a developer's job actually was. You stopped being the person who typed out the repetitive stuff and became the person who defined the patterns. The generator handled the translation.
Where I fit into this lineage
I came to Herrington's book from the AI side rather than the web framework side. I was already thinking about pipelines, templating, and dynamic code construction — and the book gave me a vocabulary and a historical frame for ideas I'd been reaching toward. It confirmed something I'd suspected: code generation isn't a hack or a shortcut. It's a legitimate architectural discipline with a long pedigree.
That framing changed how I approached agentic systems. When you're building a pipeline where an LLM is constructing prompts, routing tasks, or writing code that gets executed downstream, you're doing code generation. The difference is that instead of a template engine reading a schema, you have a model reading context. The output is still structured, executable artifact — and the same questions apply: what stays fixed, what gets parameterized, and who is responsible for the pattern?
AI agents as the next evolution
Herrington's generators were deterministic. You gave them a schema and they returned consistent output. Rails generators still work this way — predictable, auditable, boring in the best sense. The limitation was always the boundaries of what you could formally specify. You could generate a model from a database schema, but you couldn't generate the business logic that made the model meaningful. That part still required a human.
AI agents dissolve that boundary. A well-designed agent doesn't just fill in a template — it reads the surrounding codebase, understands conventions, infers intent from context, and generates code that fits. It can handle the parts that were always too ambiguous to formalize. The scaffolding Herrington described was powerful because it automated the rote work. Agents are powerful because they can automate work that was never rote to begin with.
This isn't a replacement for the underlying insight — it's an amplification of it. The principle that a programmer's highest leverage is often one level of abstraction up from the code itself still holds. DHH applied that to web application structure. The current generation of AI tooling applies it to the entire development process. The generator is now a collaborator.
What doesn't change
What I keep coming back to from Herrington's book is that the hard part of code generation was never the templating — it was deciding what to generate and why. Defining the right abstractions, choosing what to encode as convention, knowing when a pattern is stable enough to automate. Those judgments are still entirely human. An agent that generates code well still needs a developer who can evaluate whether the generated code is the right code.
If anything, the bar for that kind of architectural thinking has gone up. When generation is cheap and fast, the bottleneck moves to judgment. Herrington was writing about that trade-off in 2003. It's more true now than ever.