In my previous post, ‘Agent-Friendly Go’, I touched on the rising tide of agentic software development. The conversation, however, is moving at a breakneck pace. Two recent pieces have forced a critical re-evaluation of how we arm our AI agents: Nik Shevchenko’s powerful critique of RAG and Armin Ronacher’s latest deconstruction of agentic tooling [1].
The consensus is crystallizing around a startlingly simple, almost heretical idea: in our rush to build sophisticated ‘tools’ for AI, we may be building the wrong thing entirely. The industry is chasing complex, abstract protocols while overlooking the most robust, composable, and battle-tested tool in the history of computing: code.
The RAG Hangover: Why Yesterday’s Solution is Today’s Problem
For a brief, shining moment, RAG (Retrieval-Augmented Generation) was the answer. In an era of small context windows, it was the crutch that gave Large Language Models a semblance of memory, allowing them to reference external documents.
That era is decisively over. With million-token context windows now the standard, clinging to RAG for complex tasks like autonomous coding isn’t just suboptimal; it’s a liability. As Nik Shevchenko argues in his fantastic piece [2]:
RAG is a blackhole that will drain your resources, time, and degrade reasoning… It is a ‘massive distraction, both for your team AND for the agent itself
This isn’t a niche opinion. It’s a sentiment echoed by industry leaders who have been in the trenches, trying to make it work at scale.
Most of the industry never actually did it that well… 99% of RAG implementations never did any chunking or never measured in a rigorous way… and now it’s already past the point where RAG is sufficient.
— Quinn Slack, CEO of Sourcegraph
The verdict is in. For any task that requires genuine reasoning and context-building—like programming—RAG is the wrong tool for the job. It’s a solution for a problem we no longer have.
Humans Don’t Read Vectorized Snippets
To understand why RAG fails, we need to stop thinking about information retrieval and start thinking about workflow replication. How do you actually get up to speed in a new codebase?
When you join a team and open a large monorepo, you don’t read isolated code snippets. You scan folder structure, explore files, look at imports, read more files.
You build a mental model through active exploration. You walk the file tree, analyze dependencies, and use tools like grep and find. You perform a series of deliberate, context-aware actions.
This is the process our agents must replicate. Not, as Nik so brilliantly puts it, a ‘schizophrenic mind-map of hyperdimensionally clustered snippets of code.’
This approach is more expensive. It consumes more tokens. It requires more steps. But that’s not a bug; it’s a feature.
It’s the cost of intelligence. Retrieval is passive; agency is active.
The Tool That’s Been Here All Along
So, if RAG is out, what’s in? The industry has started to float ideas like MCP (Machine-Centric Protocol), a structured way for agents to call ‘tools.’ But as Armin Ronacher points out, this might just be another layer of flawed abstraction. He argues MCP suffers from two major flaws:
- It isn’t truly composable. Most composition relies on the model’s inference, not on a deterministic workflow.
- It demands too much context. Every tool invocation consumes a huge number of tokens, often more than just writing the equivalent code.
His conclusion is a gut punch to anyone building complex tool-use frameworks:
My current take is that my data indicates that current MCP will always be harder to use than writing code, primarily due to the reliance on inference.
Let that sink in. The fancy protocol is harder to use than just writing the code. This leads us to the powerful, unifying idea at the heart of Armin’s post.
The way to think about this problem is that when you don’t have an AI, and you’re solving a problem as a software engineer, your tool of choice is code.
The most effective, composable, and understandable ‘tool’ you can give an AI agent is a command line and the ability to write and execute a script. The mental model shouldn’t be ‘how do I wrap this action in a tool definition?’ It should be:
How would I automate this with a shell script?
This approach is simpler, more direct, and infinitely more powerful. An agent that can ls, cat, grep, and pipe commands together is operating with the same primitives as you. An agent that can write a Python script to call a REST API is using a tool that is perfectly specified, requires no complex prompting, and is guaranteed to be composable.
Stop Building Abstract Tools. Write Executable Code.
The path forward is clear. We need to stop distracting ourselves and our agents. RAG, for the task of coding, is a dead end. Abstract protocols like MCP may prove to be an over-engineered detour.
The future of agentic development lies in embracing the principles that have powered software for decades. It’s about giving agents access to the real world through the most powerful interface ever created: the command line.
As Nik concludes:
Build memory. Build tools. Give your agents the affordances real engineers use. And let them work like humans do. We’re finally at a point where they can so let them.
The ultimate ‘affordance’ isn’t a JSON schema for a tool; it’s a shell prompt.
So, ask yourself: are you building complex, brittle abstractions for your agents to struggle with, or are you giving them the one tool that truly matters?
References
I hope you found this article helpful. If you want to take your agentic AI to the next level, consider booking a consultation or subscribing to premium content.