Миллионы токенов контекста - и полдня на первичную карту проекта. Так начался наш переход с учебных полигонов на реальный legacy. Ожидания рухнули за одну крупную сессию.

Дано: - рабочий агент: VSCode -> SourceCraft VSIX (агент) + SourceCraft Default (LLM); - заявленный потолок контекста 1,2 млн токенов. Заявленный != эффективный: RoPE/калибровку внимания/прочие механизмы мы не проверим; - legacy-монолит из прошлой статьи: multigeo IM + CMS + CRM + ERP + WMS, ~8к+ файлов; - крупная задача: модернизация 4 частей системы, правки в >400 файлов. Бизнес-логику пишем сами, интерфейсы берем из PNG-прототипов -> LLM превращает их в интерактивные html-css-js прототипы вне рабочего стека, после все это превращается в UI/UX + БЛ + БП -> внедрение.

Legacy, оно такое: файлы по 10-20к строк в стиле “мешанина”, без тестов и документации. DevOps на уровне таких-же куч sh и либ. Одним словом: классика 70-80% рынка ПО вне bigT.

Не согласны с такой “реальностью”? Ну тогда Вам можно только позавидовать 🙂

Проблема: Никто уже не пишет промты императивно - у каждого своя база артефактов/скиллов/{ВСТАВЬТЕ_НУЖНОЕ}. Вопросы другие: насколько ваш контекст эффективен (как определить) и на чем основана его эффективность (чем замерить)?

В начале мы жестко держались стандарта фреймворка. Сессия агента = чтение карты + конвенций -> сверка юнитов и СТОП на расхождениях -> паспорта юнитов -> код + связанные артефакты -> выполнение по блокам “требований” в границах “запретов” -> acceptance-критерии -> отчет -> прошивка артефактов.

На мелком контексте цепочка “копеечная” и оправдана. Но на реальном производственном полигоне первичные цепочки артефактов съедали 5-10% контекста сессии, а инженер заканчивал крупную сессию на 30-40% контекста.

Это слишком дорого.

С другой стороны: чрезмерно глубокая декомпозиция это как помещать каждое изменение в репозиторий отдельным коммитом (ведь база фрейма сейчас встроена в проект = растет вместе с ним).

Нужно как-то исправлять сиЁ безобразиЁ (с).

Нововведения: - “Мелко-контекстные” задачи упростили до одного артефакта: контекст + требования + acceptance-критерии + до/во время (заменяемый снапшот) + после. - Replacable Snapshot с установленной границей-диапазоном Budget Tokens: описательный LLM-механизм снапшота в пределах бюджета. - Ручной механизм (протокол) сборки единого артефакта по нужным экспертизам. Ценность контекста = продуктовая + техническая + {ВСТАВЬТЕ_НУЖНОЕ} экспертизы участников + AI-надслойка (AI в процессе ВСЕГДА + с набором скиллов а-ля BE-AMBITIOUS по умолчанию). - Автоматизированный (bash) механизм сбора и “очистки” контекста + ручной механизм оценки “загрязненности” контекста инженером перед стартом. - Артефакты по PDLC-механизмам Checkpoint Policy, Session Handoff Protocol, Evidence Bundle (в своем формате) только при реальных R3+ (ночные прогоны + утренний проверочный пакет + human-review по сводке). При ручном контроле инженером это оверинжиниринг.

Главные инсайты:

Переход к Software Engineering 3.0 (цепочка SE1 -> SE2 -> SE3 по Андрею Карпатому) “обесценил” умение писать и доставлять код, но не отменил необходимость понимать, как модель обрабатывает намерение. Большая часть in-out контекста - мусор, положенный в сессию собственными руками.

И это не про неработающие решения. Можно писать отличные промты и получать работающие приложения - но если это не генерирует ценность (прибыль вверх, расходы вниз в бизнес разрезе), это все равно мусор.

Неочевидное: “загрязненность” контекста зависит не только от инженерной экспертизы, но и от ML-экспертизы (DS/DA/DE) + всех смежных с задачей экспертиз.

Следующий шаг: Тестируем фреймворк на новом полигоне SmartBiz: 3 маркетплейса - автоматизация (n8n+), визуализация (Apache SuperSet+), AI (кастомные + proxy-роли). Первые попытки реального R3+: “ночные” бесконтрольные процессы + утренние мини-чеки как тренировочные полигоны.

Вопрос к аудитории:

Легко сказать: мусор на входе = мусор на выходе. А как лично Вы соблюдаете гигиену контекста - поделитесь? 🙏

#IT #AI #ИИ #XDLC #SDD #агенты #метрики #автоматизация #импортозамещение