Claude AI in Four IDEs: Why the Developer Became the Main Bottleneck for Agents

On Habr AI, there's an article about how AI assistants simultaneously accelerate development and create a new type of overload. When working on several projects simultaneously, the main limitation is no longer Claude AI or the quality of code generation, but the attention of the developer themselves.

The Bottleneck is Human

The author describes an almost everyday scene: four IDEs are open, each running one or more sessions with Claude AI, and you constantly have to jump between them manually. Somewhere you need to plan the next step, somewhere you need to quickly check a critical fragment, somewhere you need to devise a test so you don't have to read code line by line. In theory, agents should work while a person rests. In practice, everything stops exactly at the moment when the operator needs to eat, sleep, or simply leave the room.

"Not the model with its flaws, but me."

This is an important observation for the entire wave of AI-driven development. Even if a model writes faster than a human, it's still the human who remains the context dispatcher: holding in their head the state of projects, deciding where a review is needed and where input/output checks are enough, and constantly switching between tasks. Because of this, the promised automation turns into not a calm autopilot, but a denser and more nerve-wracking form of managing several semi-autonomous processes.

Tests Instead of Review

From the article, it's clear that the author increasingly replaces traditional code review with scenario-based testing. The logic is simple: if a task doesn't carry direct financial risk, it's faster not to dig into each module, but to check the system as a black box. In the example with a smart contract on EVM, the agent was given a set of engineering constraints—offline nonce, rejection of unnecessary RPC requests, constant gasLimit, round robin across addresses—and then instead of reading code, they began attacking the solution with questions and test runs.

• Parallel review from current and clean context
• Checking what happens when price sources are interrupted
• Control of gasPrice logic and risk of burning deposits on fees
• Measuring latency of tick processing and async sending
• Dry run with mocks instead of real transactions

This approach allows you to quickly identify weak points without deep immersion in implementation. According to the author, step by step around the main bot, it was necessary to build background services for balance control, transaction confirmation, and nonce management. The result turned out to be working, although the main check went not through reading source code, but through sequential simulation of failures and known problematic scenarios. This shifts the role of the developer from code writer to quality and risk operator.

Expert, Not Passenger

But the scheme only works where the human themselves understands how the solution should be structured. As long as the developer is stronger than the model in their domain, they can guide it with short expert hints, set the right checks, and quickly spot dangerous gaps. As soon as the team reaches a section where the operator has no confident answer, an illusion arises that the agent will now conduct its own research and choose the best path. It's here, according to the author's observation, that the magic abruptly ends.

Hence the main conclusion of the text: the developer of the future is not simply a person who knows how to open a chat with a model, but an AI expert-operator with almost senior-level thinking. They need to run several projects in parallel, make architectural decisions, take responsibility for results, and manage queues of tasks for agents. The author sees the next step in orchestrating not just the models themselves, but the operators: a shared context space where you can pick up stalled tasks, see the history of decisions, and hand over control without losing the big picture.

What This Means

AI tools already increase developer throughput, but they don't eliminate the need for experience, concentration, and responsibility. The nearest deficit in the industry is not access to yet another model, but ways to manage multiple agents without constant manual context switching and burnout.