Операция выполнена!
Закрыть
Хабы: Управление разработкой, Искусственный интеллект, Программирование

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

Читать далее
Читайте также
НОВОСТИ

ПИШИТЕ

Техническая поддержка проекта ВсеТут

info@vsetut.pro