Claude AI в четырёх IDE: почему разработчик стал главным узким местом для агентов

На Habr AI вышел текст о том, как AI-ассистенты одновременно ускоряют разработку и создают новый тип перегрузки. Когда в работе сразу несколько проектов, главное ограничение — уже не Claude AI и не качество генерации кода, а внимание самого разработчика.

Узкое место — человек Автор описывает почти бытовую сцену: открыты четыре IDE, в каждой идут

одна или несколько сессий с Claude AI, а между ними приходится постоянно прыгать вручную. Где-то нужно спланировать следующий шаг, где-то — быстро проверить критичный фрагмент, где-то — придумать тест, чтобы не читать код построчно. В теории агенты должны работать, пока человек отдыхает. На практике всё останавливается ровно в тот момент, когда оператору нужно поесть, поспать или просто выйти из комнаты.

«Не модель с её косяками, а я».

Это важное наблюдение для всей волны AI-разработки. Даже если модель пишет быстрее, чем человек, именно человек остаётся диспетчером контекста: держит в голове состояние проектов, решает, где нужен review, а где хватит проверки на входах и выходах, и постоянно переключается между задачами. Из-за этого обещанная автоматизация превращается не в спокойный автопилот, а в более плотную и нервную форму управления несколькими полуавтономными процессами.

Тесты вместо ревью Из статьи видно, что автор всё чаще заменяет классическое code review на

сценарное тестирование. Логика простая: если задача не несёт прямого риска финансовых потерь, быстрее не влезать в каждый модуль, а проверить систему как black box. В примере со смарт-контрактом на EVM агенту дали набор инженерных ограничений — offline nonce, отказ от лишних RPC-запросов, константный gasLimit, round robin по адресам — а затем начали не читать код, а атаковать решение вопросами и прогонами.

• Параллельное ревью из текущего и чистого контекста Проверка, что будет при обрыве источников цен Контроль логики gasPrice и риска сжечь депозит на комиссиях Замер задержки обработки тиков и асинхронной отправки Dry run с моками вместо реальных транзакций Такой подход позволяет быстро нащупать слабые места без глубокого погружения в реализацию. По словам автора, шаг за шагом вокруг основного бота пришлось нарастить фоновые сервисы контроля баланса, подтверждений транзакций и nonce. Итог получился рабочим, хотя основная проверка шла не через чтение исходников, а через последовательное моделирование отказов и известных проблемных сценариев. Это сдвигает роль разработчика от писателя кода к оператору качества и рисков.

Эксперт, а не пассажир Но схема работает только там, где человек сам понимает, как должно быть

устроено решение. Пока разработчик сильнее модели в предметной области, он может направлять её короткими экспертными подсказками, задавать правильные проверки и быстро замечать опасные пробелы. Как только команда доходит до участка, где у оператора нет уверенного ответа, возникает иллюзия, что агент сейчас сам проведёт исследование и выберет лучший путь.

Именно здесь, по наблюдению автора, магия резко заканчивается. Отсюда и главный вывод текста: разработчик будущего — это не просто человек, который умеет открыть чат с моделью, а эксперт-оператор AI почти с сеньорным уровнем мышления. Ему нужно вести несколько проектов параллельно, принимать архитектурные решения, отвечать за результат и разруливать очереди задач у агентов.

Следующий шаг автор видит в оркестрации не только самих моделей, но и операторов: общем пространстве контекста, где можно подхватывать зависшие задачи, смотреть историю решений и передавать управление без полной потери картины.

Что это значит AI-инструменты уже повышают пропускную способность разработчика, но они не

отменяют необходимость в опыте, концентрации и ответственности. Ближайший дефицит в индустрии — не доступ к ещё одной модели, а способы управлять множеством агентов без постоянного ручного переключения контекста и выгорания.