No Vibes Allowed: Solving Hard Problems in Complex Codebases (Рубрика #AI)
Интересное выступление от Dex Horthy, основателя компании HumanLayer, разрабатывающей инструменты для AI-assisted разработки. Его предыдущий доклад "12 Factor Agents: Patterns of reliable LLM applications" (см. мой разбор) в июне 2025 стал одним из самых популярных на конференции. Именно ему приписывают популяризацию термина "context engineering".
Исследование Stanford показало неприятную правду об AI-инструментах для кодинга (это было в выступлении "Does AI Actually Boost Developer Productivity?" от Yegor Denisov-Blanch, про которое я уже рассказывал)
- Большая часть "дополнительного кода", написанного с помощью AI - это переработка slop'а, который был написан до этого
- Агенты отлично работают на новых проектах, но в больших legacy-кодовых базах часто делают разработчиков менее продуктивными
Для решения этих проблем автор рассказывает про context engineering
- LLM - это stateless системы. Единственный способ получить лучший результат - подать лучший контекст на вход. При каждом вызове модель выбирает следующий шаг исключительно на основе того, что находится в текущем контексте.
- "Dumb Zone". У контекстного окна есть практический предел. После ~40% заполнения начинается деградация качества ответов. Если у вас подключено много MCP-инструментов, которые забивают контекст JSON'ами и UUID'ами - вы постоянно работаете в dumb zone.
- Методология: Research → Plan → Implement. Вместо наивного подхода "попросил → получил slop → поругался → попросил снова" команда Dex'а использует частую намеренную компактизацию контекста:
-- Research - понимание системы, поиск нужных файлов. Результат сжимается в markdown с конкретными файлами и номерами строк.
-- Plan - детальный план с code snippets того, что именно будет изменено. Чем конкретнее план, тем надёжнее выполнение.
-- Implement - выполнение плана. Если план хороший, даже "тупая" модель справится.
- Напоследок автор рассказывает про практические результаты вида: за 7 часов субботней сессии отправили 35,000 строк кода в проект BAML (300k LOC Rust) - обычно это была работа на 1-2 недели
Практические советы от автора
- Sub-agents - не для ролей, а для контроля контекста. Не создавайте "frontend agent" и "backend agent". Используйте sub-agents для изоляции тяжёлых операций чтения кодовой базы, возвращая только сжатый результат.
- Прогрессивное раскрытие контекста. Вместо одного огромного файла документации в корне репозитория - размещайте контекстные файлы на каждом уровне, подгружая только релевантное.
- On-demand сжатый контекст лучше статичной документации. Документация устаревает и врёт. Код - источник истины. Генерируйте research-документы на лету из реального кода.
- Trajectory matters. Если вы 5 раз поругали модель в одном контексте - она "научилась", что следующий шаг = ошибка + ругань. Лучше начать новый контекст.
- Культурные изменения должны идти сверху. Если вы технический лидер - выберите один инструмент и набивайте практику. Не прыгайте между Claude Code, Cursor и Codex
Главный вывод из выступления примерно такой
#Engineering #AI #Metrics #Software #DevEx #Productivity
Интересное выступление от Dex Horthy, основателя компании HumanLayer, разрабатывающей инструменты для AI-assisted разработки. Его предыдущий доклад "12 Factor Agents: Patterns of reliable LLM applications" (см. мой разбор) в июне 2025 стал одним из самых популярных на конференции. Именно ему приписывают популяризацию термина "context engineering".
Исследование Stanford показало неприятную правду об AI-инструментах для кодинга (это было в выступлении "Does AI Actually Boost Developer Productivity?" от Yegor Denisov-Blanch, про которое я уже рассказывал)
- Большая часть "дополнительного кода", написанного с помощью AI - это переработка slop'а, который был написан до этого
- Агенты отлично работают на новых проектах, но в больших legacy-кодовых базах часто делают разработчиков менее продуктивными
Для решения этих проблем автор рассказывает про context engineering
- LLM - это stateless системы. Единственный способ получить лучший результат - подать лучший контекст на вход. При каждом вызове модель выбирает следующий шаг исключительно на основе того, что находится в текущем контексте.
- "Dumb Zone". У контекстного окна есть практический предел. После ~40% заполнения начинается деградация качества ответов. Если у вас подключено много MCP-инструментов, которые забивают контекст JSON'ами и UUID'ами - вы постоянно работаете в dumb zone.
- Методология: Research → Plan → Implement. Вместо наивного подхода "попросил → получил slop → поругался → попросил снова" команда Dex'а использует частую намеренную компактизацию контекста:
-- Research - понимание системы, поиск нужных файлов. Результат сжимается в markdown с конкретными файлами и номерами строк.
-- Plan - детальный план с code snippets того, что именно будет изменено. Чем конкретнее план, тем надёжнее выполнение.
-- Implement - выполнение плана. Если план хороший, даже "тупая" модель справится.
- Напоследок автор рассказывает про практические результаты вида: за 7 часов субботней сессии отправили 35,000 строк кода в проект BAML (300k LOC Rust) - обычно это была работа на 1-2 недели
Практические советы от автора
- Sub-agents - не для ролей, а для контроля контекста. Не создавайте "frontend agent" и "backend agent". Используйте sub-agents для изоляции тяжёлых операций чтения кодовой базы, возвращая только сжатый результат.
- Прогрессивное раскрытие контекста. Вместо одного огромного файла документации в корне репозитория - размещайте контекстные файлы на каждом уровне, подгружая только релевантное.
- On-demand сжатый контекст лучше статичной документации. Документация устаревает и врёт. Код - источник истины. Генерируйте research-документы на лету из реального кода.
- Trajectory matters. Если вы 5 раз поругали модель в одном контексте - она "научилась", что следующий шаг = ошибка + ругань. Лучше начать новый контекст.
- Культурные изменения должны идти сверху. Если вы технический лидер - выберите один инструмент и набивайте практику. Не прыгайте между Claude Code, Cursor и Codex
Главный вывод из выступления примерно такой
AI cannot replace thinking. It can only amplify the thinking you have done - or the lack of thinking you have done.
#Engineering #AI #Metrics #Software #DevEx #Productivity