A question I get from founders about once a week: if I let a coding agent build my backend from scratch, with no template and no scaffolding, won't it eventually evolve into something genuinely token-efficient? No ceremony, no layers that don't earn their keep, just the code each feature needs.
The intuition is elegant. It is also wrong in practice, and the reason it is wrong tells you why architecture matters more now than it did five years ago, not less.
The seduction of the first three features
Compare two greenfield projects. Same product, same model, same operator.
Project A starts with a template that enforces layered structure. Controllers, use cases, ports, adapters. The first feature is expensive. The agent has to load the conventions file, infer patterns from the existing module, and generate roughly four files where a naive implementation would have used one.
Project B starts from scratch, with only a tech stack choice and a sentence like "build me the users endpoint." The first feature is almost free. The agent writes a controller that talks to the ORM inline. It works.
Stop counting at feature three and B has consumed a fraction of the tokens A did. The systems do the same thing. This is the local optimum that traps most "let it emerge" projects.
Three forces that flip the curve
By feature ten, B is more expensive than A, and the gap widens from there. Three forces drive that reversal, and none of them are visible at feature three.
Drift. Without a structural north, similar features get implemented differently. The users module uses a flat service. Orders ends up with a repository because the logic got hairy. Payments uses a command handler because you copied something from a blog post. Three patterns for what is essentially the same problem. Every time the agent is asked to touch something new, it has to read more files to answer the question "what is the pattern here?", and the answer is often "it depends on the module." That is entropy, and it grows non-linearly.
Refactor asymmetry. There is a moment, and it always comes, where you need to swap an ORM, add an event bus, or test a use case without standing up the infrastructure. If the domain logic was never separated from the infrastructure to begin with, that refactor is brutal. It touches every surface where business rules got inlined next to database calls. A single refactor of that kind can burn a hundred thousand tokens and erase the entire accumulated "savings" from having started lean.
Spec inflation. With a template in place, a spec can say "add the use case for X following the existing pattern" and the agent knows exactly what that means. Without a template, the spec has to be more explicit about structure, or the agent has to explore more of the codebase to reconstruct it. Every feature pays that tax, and it compounds quietly across every prompt the project will ever process.
The earned-abstraction myth
There is a seductive counter-idea that says: let abstractions be earned. Start zero-overhead, introduce structure only when repetition justifies it. On paper, perfect.
In practice with LLM-driven development, it fails for a specific reason. The strategy requires a human to detect the exact moment when repetition moves from "two occurrences, a coincidence" to "three occurrences, a pattern worth consolidating." Then to pause shipping and run a proactive refactor.
What actually happens is that you ship the feature and move on, because it works. The refactor gets postponed until it hurts, and by then the cost of doing it well has already exceeded the cost of having paid for structure upfront.
A template, in the end, is abstractions that do not require human discipline to activate.
Where starting from zero actually wins
There are real cases where the no-template path is the right call.
If the service has five endpoints and a planned lifespan under a year, the template is mis-amortized. If the domain is not yet well understood and you genuinely do not know whether it calls for DDD or a flat CRUD app, starting light and pivoting is reasonable. If your existing template is over-engineered, with layers nobody uses and naming that obscures intent, then yes, starting from zero can end up cleaner than inheriting the baggage.
All three of these are detectable at the start of the project. If you have already decided that DDD plus hexagonal fits the domain, you have already taken the position that the problem deserves the structure.
The crossover point
My estimate, without pretending to false precision, is that the crossover sits somewhere between feature five and feature ten. Before that, starting from nothing probably consumes fewer total tokens. After that, drift and refactors pull the curve the other way. Almost no serious DDD or hexagonal project stops at ten features. In practice that means if the project is worth doing at all, a template earns its keep.
The subtle trap
A bad template is worse than no template. If your scaffolding forces layers that do not justify themselves, or ceremonial naming, or patterns that only make sense in complex cases, you end up paying that overhead on every trivial feature.
The right question is not "template or no template." It is: how lean can the template be while preserving the conventions that matter?
A good template for LLM-driven development has three properties. First, conventions are explicit and compact, not spread across a dozen documents. Second, the ceremony floor is as close to zero as possible, so trivial features stay trivial. Third, the self-similarity is strong enough that once the agent has read one module, it can generate the next one without having to ask which pattern applies.
So why does architecture matter more now
Before agents, the cost of drift was paid by humans reading the code, and humans adapt. You learn the quirks of each module, you internalize "oh, payments is different because of the webhook stuff," and you move on. The cost was friction, bounded by your team's memory.
With agents, the cost of drift is paid in tokens and in the number of files the agent has to read before it can reason about a change. That cost is not bounded by memory. It scales with every feature you ship into an inconsistent structure, and it is paid again on every prompt.
Architecture used to be an investment in your team's long-term velocity. It is now also a line-item cost on every AI interaction your codebase will ever serve.
That is a harder thing to ignore.