I just read AI Coding, One Year Later: What August 2025 Didn't See Coming by @lukeocodes, and one section stopped me cold. Not the benchmark tables — the last one:
"Despite the model gains, code review is still the bottleneck. The PR queue gets longer. Architecture decisions still need a person. The models are better at implementing within patterns but not at deciding which patterns to use."
Everyone reads that and thinks: we need a better model.
But do we? Or are we fighting the wrong fight?
Are we stuck in the brute force era?
Look at where the industry's energy goes. Bigger context windows. Higher SWE-bench scores. More guardrails, more tools, more credentials hanging off a single "AI brain" that we keep trying to make omniscient. We take one model, surround it with forty tool definitions, stuff its system prompt with JSON schemas, routing rules, and behavioral constraints — and then act surprised when it's slow, expensive, and still can't decide which design pattern fits the problem.
Is this brute force? And if it is — does brute force have a ceiling, not because the models are bad, but because the system design around them is?
What did Ford figure out 113 years ago?
In 1913, Henry Ford didn't build a better craftsman. He built a better system.
Before the moving assembly line, building a Model T took over 12 hours of highly skilled labor. Ford's insight wasn't "find stronger, smarter workers." It was: decompose the problem, give each station one task, and let specialization compound. Assembly time dropped to about 93 minutes. That system — designed 113 years ago — still runs every factory on Earth.
Now look at how we build AI systems in 2026. Aren't we still searching for the master craftsman? One giant model that knows everything, holds every credential, and does every task?
What would Ford say about that?
What if we built small specialists instead of one big brain?
So here's the question I keep coming back to: what would happen if we stopped trying to build the perfect generalist brain, and started building the production line instead?
Imagine a network of small, specialized agents:
A Pattern Agent that knows design patterns deeply — and only that. Its single job: given a problem and real data, decide which pattern fits best. Not "a model that also does architecture." A specialist.
A Coding Agent that implements within the pattern it was handed. No architectural debates, no scope creep.
A Research Agent that gathers context and documentation.
A QA Agent that reviews output against acceptance criteria.
Each one with a tiny system prompt. Each one knowing its own responsibility and nothing else. Each one asking the others for help when a task falls outside its specialty — the same way a welder on Ford's line never needed to know how to paint.
Wouldn't that directly answer the "what hasn't changed" section? Architecture decisions need a person today — but is that because the models are weak, or because we keep asking one bloated generalist to make them inside a 5,000-token system prompt crowded with tool schemas? What could a specialist do, if its entire context window were dedicated to pattern selection and fed real data instead of everything at once?
Haven't we solved this engineering problem before?
Here's what frustrates me: haven't we known how to build systems like this for decades? Did we just forget?
Smalltalk taught us that a healthy system is a set of isolated objects that communicate strictly through messages — no object inspects another's internals. Microservices taught us that small, independently deployable units beat monoliths. IRC showed us in the 90s that thousands of autonomous entities can coordinate dynamically just by joining channels, without central orchestration.
I spent over a decade building mission-critical systems in banking (Citibank, Bloomberg), and the pattern was always the same: the systems that survived had rigorous separation of responsibilities. The ones that collapsed were the monoliths. Why would agentic systems be any different?
Those questions are what pushed me to design IRC-A (Internet Relay Chat for Agents), an architecture that asks: what if...
Agents were stateless specialists that never hold credentials, database drivers, or knowledge of the wider ecosystem? "An intelligent agent should never know the ecosystem it runs in. It should only know its own responsibility."
Discovery were an infrastructure concern, not an intelligence concern? Agents wouldn't carry tool schemas in their prompts. They'd ask a lightweight gateway "who can do X?", get a cryptographically signed ticket, and talk to that specialist directly, peer-to-peer.
Prompt-bloat simply died? Specialist nodes would receive minimal, rewritten, structured prompts — not the entire conversational history. Time-to-first-token drops, costs stay flat, and indirect prompt injection gets neutralized because there's nothing malicious to inherit.
Traditional frameworks distribute knowledge — every node must understand the whole graph. Is that why adding one capability means refactoring and redeploying everything? What if we distributed capabilities instead: plug a new specialist into the network and it's discoverable immediately. No redeploy. No broken DAG.
So — are we fighting the wrong fight?
The models doubled their benchmarks in twelve months. Genuinely impressive. But if your architecture forces a single agent to hold forty tools, ten thousand tokens of system prompt, and credentials it should never have — won't a 95% SWE-bench model still drown in the same bottleneck?
Ford didn't wait for superhuman workers. He designed a system where ordinary specialization produced extraordinary output.
We keep investing in the brain. Isn't it time we invested in the factory floor?
Or am I wrong — is the superhuman craftsman really one model generation away?
I'm Sandro García, a solutions architect with 20+ years in financial systems and the author of the IRC-A protocol whitepaper. I'd genuinely love pushback on this: where does the specialization argument break? What's the strongest case for the single-brain approach?
Top comments (0)