Качество работы 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, а сильные аналитические способности модели позволяют извлечь из неё пользу, а не утонуть в шуме.
