.png)
3 weeks ago
2
My current working environment is two-component: JetBrains for code work, where every setting has been refined over years, and VS Code as a collection for AI extensions, which typically release there much earlier. I’ve tried the entire spectrum: from cline (by the way, a very fast model is now available for free: Code-Super-Nova) and windsurf to Roo Code.
Ultimately, I settled on Kilo Code, the boldest fork of Roo Code with the greatest number of features and, judging by OpenRouter’s rankings, a massive user base. There was a sense that if everyone uses it, then it must be the best tool. Its “Modes” philosophy seemed like the most thoughtful at the time: you give a complex task to the Orchestrator, and it decomposes it for the coder, debugger, or architect.
Sounds logical. But after months of use, I identified two interconnected fundamental problems in its core architecture, which turn work into an endless cycle of token waste and lost time.
Connect on social networks:
The first and main problem is the Orchestrator itself. In its default implementation, it has no access to tools for reading or editing files. It is locked in the “Chinese room” paradigm, meaning it receives reports from sub-agents and issues new instructions, remaining completely blind to the actual state of the project.
It doesn’t even have an approximate, low-polygon map of the project, no basic understanding of architecture or file structure. In practice, it looks like this: I ask to add a new feature. Instead of first studying the code, the Orchestrator works like a dumb “prompt improver”: it simply takes my task, maybe slightly rephrases it, and blindly passes it to the coder. It doesn’t manage the process because it has no information for decision-making.
As a result, the Orchestrator degenerates into a simple task queue dispatcher. I often caught myself thinking: “I would have done this manually three times faster than watching these awkward attempts and monitoring how it goes down the wrong path while the butterfly sub-agents are forced to figure out the project themselves.”
The second problem is a direct consequence of the first and destroys any efficiency. Imagine a typical scenario:
Orchestrator delegates a task to the coder.
Coder works for an hour, studies the project, reads documentation, loads dozens of files into context, accumulating deep understanding of the architecture.
Task completed. Coder returns the result.
Blind Orchestrator passes the next task to... a new coder.
The first coder‘s context is completely erased. The sub-agent “dies,” taking all accumulated knowledge with it.
I literally observed this in real time: a coder worked for an hour, and then with the next task a new coder again went into the README, and I thought how unfortunate that the previous coder had perished. This new “mayfly” agent starts from absolute zero, re-learning what the system already knew a minute ago:
Request 1: Search the codebase index (if enabled).
Request 2: Read file structure.
Requests 3-5: Sequential reading of key files, one at a time.
In total, about 5 requests with growing context are spent just to restore the level of understanding that already existed.
Like many others, I tried to solve the memory problem by forcing agents to write detailed reports before “death.” But this is just a trap. Agents start spending 80% of their time writing reports to each other.
Each new agent still starts by reading this “memory,” which only increases token consumption and startup time. Instead of solving the context loss problem, we get additional overhead for documentation synchronization.
These two problems create a closed loop. The Orchestrator prefers to create new agents because if it simply “switched modes” on an existing one, its own management context would be cluttered with coder work logs, and it couldn’t return.
This also spawns recursive calls that people massively complain about online: coder calls another coder, that one calls the next, and the cycle never returns to the original Orchestrator.
┌─────────────────────────┐ │ Blind Orchestrator │ │ (Not even a map) │ └──────────┬──────────────┘ │ 1. Blind delegation ▼ ┌─────────────────────────┐ │ Sub-agent (Coder) │ │ (Accumulating context) │ └──────────┬──────────────┘ │ 2. Works, then “dies” ▼ ┌─────────────────────────┐ │ Blind Orchestrator │ │ (Doesn’t remember) │ └──────────┬──────────────┘ │ 3. New agent ▼ ┌─────────────────────────┐ │ New Sub-agent #2 │ │ (Learning from zero + │ │ reading others’ mem) │ └─────────────────────────┘Looking at this diagram, you understand: such a system is only suitable for a list of obvious tasks where you manually broke everything into subtasks and specified all necessary files. It’s incapable of analysis and adaptation.
Both problems stem from a fundamental defect: an orchestrator without access to state and disposable sub-agents without context preservation.
How it should work:
The Orchestrator must have vision. It must have read rights to the repository and maintain at least a low-polygon project map to build solutions based on code facts.
Agents must be a team. Instead of “death” and “birth,” we need a system where one agent can ask another: “Have you already worked with this module? What’s important to consider there?” Memory should not be an external document to reread, but a living context preserved between mode switches.
I was terribly disappointed when I realized that such a popular tool is built on such a weak philosophy. It was a pity about the time spent trying to fix this system with custom prompts.
While tools with the right architecture don’t exist, simplicity beats complexity. My current workflow looks like this:
I write out a complex task in detail in a chat with a powerful model.
Save the result to a .md file, based on which I create todo.md.
Assign the coder in Kilo Code to execute tasks from this list one by one, controlling the process.
With a large context window, this approach works. One powerful mode with manual control proves more efficient than an orchestration theater that burns tokens re-learning what the system already knew. The current paradigm of “blind orchestrator” and “disposable sub-agents” is an architectural dead end for real projects.
