Почему Claude 4.6 не спасает без контекста: главное слепое пятно LLM-разработки

Сильная LLM не спасает плохой ввод: если агент видит только фрагмент кода, а не архитектуру, зависимости и правила среды, ошибки становятся почти неизбежными. Разработчик, который почти полностью перешёл на AI-кодинг через Cursor и Claude 4.6, описал, почему контекст оказался важнее выбора между моделями.

Не модель, а контекст В LLM-разработке легко зациклиться на сравнении GPT,

Claude, Gemini и на шлифовке промптов. Но на практике выигрыш часто приходит не от смены модели, а от того, сколько полезной информации агент получает до первого действия. Если в контексте есть устройство сервисов, ограничения инфраструктуры, shared-библиотеки, соглашения команды и прошлые решения, модель действует как инженер, который уже работал в проекте.

Если этого нет, даже сильный агент начинает гадать, а догадки в проде обходятся дорого. Автор описывает это предельно жёстко: разница между “агентом с контекстом” и “агентом без контекста” измеряется не в процентах качества, а в последствиях. Один вариант закрывает задачу за несколько минут, другой — тратит час, ломает соседние сервисы и приводит к откату.

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

«Разница — это путь от решения за пять минут до часа ошибок и откатов».

Как ломаются агенты Когда AI пишет код почти автономно, ему недостаточно видеть только текущий файл.

В реальных системах логика разбросана между репозиториями, конфигами, инфраструктурой и неформальными правилами. Агент может корректно переписать функцию, но сломать интеграцию, потому что не знает о старой зависимости, необычной настройке хоста или соглашении, которое нигде явно не задокументировано. Чем больше система похожа на живую экосистему, тем дороже обходится отсутствие такого знания.

связи между микросервисами и очередность деплоя особенности shared-библиотек и внутренние API-контракты ограничения железа, виртуальных машин и локальной среды правила тестирования, ручной проверки и отката изменений Именно поэтому автор строит работу вокруг knowledge base, а не вокруг одного удачного промпта. Смысл в том, чтобы агент видел не только код, но и карту системы: что с чем связано, где слабые места, какие решения уже принимались и какие ограничения нельзя нарушать. Хороший промпт помогает задать задачу, но не заменяет память о проекте.

Без этого LLM остаётся быстрым, но близоруким исполнителем, который может уверенно вести не туда.

Системный слой знаний Подход обкатывался на Claude 4.6 Opus с контекстным окном до миллиона токенов.

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

Практический вывод простой: контекст нужно собирать как отдельный слой системы. Туда входят архитектурные заметки, описание сервисов, список зависимостей, устройство окружений, типовые сценарии тестирования и правила безопасных изменений. Чем лучше этот слой организован, тем ближе AI-агент подходит к формату полноценного техпартнёра: он не просто генерирует код, а понимает, куда именно этот код встраивается и что может задеть.

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

Иначе автоматизация ускоряет не разработку, а распространение неверных решений. Чем больше действий доверяешь модели, тем дороже обходится каждый пробел в знаниях.

Что это значит

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