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 (12)
Don't need a new model... need a new perspective of the model.
I guess that's all i should share.
Right a new perspective of HOW to use de model. We are charging all responsabilities into de model.
Well its that they're overloading it with unnecessary functions; and not giving it the Optimizations.
A way of thinking is much more powerful than a tool, but those thoughts need Optimizations too...
I would take ToT (Tree-of-Thought) and DoT (Direction-of-Thought) and CoT (Chain-of-Thought) any day over a pipeline.
But do you know what you need to make those work better than a pipeline? (just wondering, I'll tell you~ if not)
Just to clarify: I'm definitely not advocating for rigid pipelines (that's actually what I'm trying to move away from—static DAGs are far too brittle). The idea is dynamic, message-passing specialization.
That said, I'm completely with you on cognitive frameworks like ToT and DoT over tool-stuffing. But you left me hanging—what's that missing optimization in your view?
i think my message is being blocked?
Hi Blake! Your comments weren't blocked—I was just in the middle of a major production rollout this week and couldn't sit down to read and reply properly.
As a systems architect, I've been developing an open-source protocol for decentralized multi-agent networks (feel free to check out irc-a.org if you're curious). I'd love to see how your scratchpad/blueprint approach structures cognitive state, and explore whether any of those pieces complement the architecture. Always happy to give full credit for community ideas. Feel free to share more!
I will check it out, I am just not so trusting of open source, it's been difficult to even show anyone cause no one usually even answers back 😅 makes me want to keep the secret sauce tell I can afford to give it up. I have the cure for a lot of what enterprises are paying millions for; and im looking for someone that i can trust that wants to earn a big check for it honestly 🤫 but yeah ill check it out.
SIMPLE ANSWER:
ymal_scratchpadandymal_blueprinti guess im not allowed to tell you more.I was wondering if youbwanted a meta-os for the system you want
No cost, just agree to give me credit (work cited) for it if you write about it. no catch just that.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.