Устаревшая документация хуже, чем её отсутствие — она отравляет контекст LLM. Агент доверяет тому, что видит. Garbage in — garbage out, только garbage выглядит как аккуратный markdown.

Это вторая часть серии. Первая часть — «Слепое пятно LLM-разработки: контекст за пределами кода».

Качество работы LLM — функция от качества контекста на входе. Это утверждение звучит банально, однако зачастую разработчики оптимизируют модель, выбирая между GPT, Claude или Gemini, и промпт, но не контекст в целом. Между тем, разница между «агент с правильным контекстом» и «агент без контекста» — не 20% и не 50%. Эта разница находится в дистанции вариантов между «решил задачу за 5 минут» и «потратил час, сломал два сервиса, и результат пришлось откатить из‑за массы новых проблем».

Я solo‑разработчик. В моей экосистеме десятки актуальных проектов: платформа из десятков микросервисов, AI‑инференс кластер на неспецифическом железе типа mac studio и dgx spark, масса shared‑библиотек, инфраструктура на нескольких физических и десятках виртуальных хостов.

Последний год «пишу» код почти исключительно через LLM и Cursor. Начинал с deepseek на уровне «подскажи как написать функцию для...» и дошел до полноценной оркестрации на Claude 4.6: я формулирую задачу, агент анализирует условия и кодовую базу, обсуждаем архитектурный план, агент пишет код и тесты, запускает тесты, фиксит ошибки, получает от меня обратную связь по результатам ручной проверки.

Это работает хорошо, когда агент глубоко понимает контекст. И катастрофически плохо, когда контекста недостаточно. Эта статья — про то, как я решаю проблему контекста системно.

Оговорка о применимости

Описанная методология разрабатывалась и обкатывалась на одной из наиболее сильных моделей для работы с кодом — Claude 4.6 Opus с контекстным окном в миллион токенов. Это важно зафиксировать: большое окно контекста означает, что агент физически способен «увидеть» knowledge base, а сильные аналитические способности модели позволяют извлечь из неё пользу, а не утонуть в шуме.