Последнее время модно складывать в репозитории архитектурные файлы, таски и так далее, для помощи агентам в кодинге.

И я сам так делал

Но теперь я скажу вам страшную вещь.

Не нужно этим засорять репозиторий.

Есть источник правды (код), а есть пути его достижения — проектные артефакты, которые могут быть разной степени актуальности и устаревания. Ключевое отличие — темпоральное измерение. Код исполняется одинаково независимо от того, когда его написали. А вот задача годовалой давности на активно развивающемся репозитории вероятнее всего уже не имеет ничего общего с реальностью. И будет только сбивать с толку агента, который на нее случайно наткнется.

В итоге я перестал включать в репозиторий архитектурные файлы и задачи. Безусловно, их нужно уметь оркестрировать и подавать на вход агентам некие выжимки. Но нужно четко понимать их отличие от самого кода, и как следствие — лучше не мешать ежа с ужом, и работать с ними по-отдельности.

Вероятно, вам нравится подглядывать за моим процессом разработки, так что притащил вам рядовой запрос на изменения, которых у меня генерируется штук 20 в день. Как-то так это выглядит.

Тут я ставлю задачу нейронке, чтобы она написала инфраструктуру для автоматического кодинга на базе имеющихся механизмов сканирования репозиториев.

https://gist.github.com/glebkudr/f7a02b363c95fa6dcb1a36611a184292

Такс, думаю над релизом нового шотгана

Что можно делать прямо сейчас
— Упаковывать репу в короткий индекс x10-x20 сжатый по контексту
— После индексирования формулировать задачи типа "хочу сделать фичу", и оно тебе выплюнет файлы проекта имеющие отношение к этой фиче.
— Когда есть тексты файлов, дальше можно автоматизировано пройтись по любому текущему воркфлоу шотгана. Например, создать файл архитектуры, и далее закодить фичу, вплоть до автоматического применения диффа.

Инструмент позиционирую как AI помощник для разраба. То есть это не вайбкод тул, а штука которая помогает быстро итерировать цикл "мысль -> архитектура -> имплементация", с возможностью ручного контроля на каждом шаге. С крупными идеями на входе, т.е. сохраняется идеология шотгана о "ван-шотании" фичей в противоположность общению с агентом в чате и просьбе дописывать какие-то мелочи.
Не получилось с первого раза — откатываем результат — и запускаем снова.

Работает оно с ключиком, жрет токены гемини.

Будет успешно работать на репах где-то до 2х млн токенов, больше пока не тестил.

Внимание, вопрос.

В каком минимальном виде вам было бы интересно потестить?
Например, могу собрать MCP который будет только индексировать + отвечать со списком файлов.
Или можете дождаться GUI.

В общем, выслушаю ваши пожелания.

Простой примерчик.

Агент получает задачу:

Хочу при сканировании репозитория и любом другом типе таски, выводить в UI текущий бюджет в токенах, разряды должны разделяться пробелами. Значение должно сохраняться в БД вместе с названием использованной для каждого запроса модели (чтобы в будущем можно было считать бюджет в деньгах).

Таска поступает агенту + туда же подмешиваем скан репозитория (5к сжатого контекста вместо 130к сырого)

Результат в виде json на выходе:

{
  "thought": "The user wants to track and display the token budget for all AI-related tasks. This involves modifying both the backend to capture and store token usage, and the frontend to display it. Based on the `current_understanding`, the `LLMService` is the central point for all Genkit calls, making it the ideal place to capture token usage. This data should be stored in the `AgentSession` model, which is managed by the `AgentService` and orchestrated by the `AgentExecutor`. The updated session data, including token counts, then needs to be sent to the frontend via the WebSocket managed in the `AnalysisAPI`. On the frontend, the `analysis` store will receive this data, which will be defined in the frontend types and displayed in a relevant UI component like `AgentStatePanel.vue`. I will select these files to provide as context for the coding agent.",

  "action": {
    "tool_name": "start_coding_session",
    "parameters": {
      "files_to_analyze": [
        "backend/app/models/agent.py",
        "backend/app/services/llm_service.py",
        "backend/app/worker/agent_executor.py",
        "backend/app/services/agent_service.py",
        "backend/app/api/analysis.py",
        "frontend/src/types/index.ts",
        "frontend/src/stores/analysis.ts",
        "frontend/src/components/AgentStatePanel.vue"
      ]
    }
  }
}

Обычным питоновским кодом могу выдать как целиком тексты файлов, так и оставить в таком виде.

Такой mcp могу быстро собрать. Только индексируются репозитории сейчас долго — существенный минус, но никак пока не побороть с текущей скоростью LLM.

11 августа я снова в Москву. Утро занято, а где-то с 14 до 18 готов прийти к вам в гости и рассказать про контексты, агентский кодинг и так далее. В прошлый раз замечательно сходил в Яндекс и Flowwow, если есть желание позвать в этот раз — пишите 👍

Напоминаю, что я с шотганом срубил полторы тысячи звезд на гитхабе + пишу сейчас про-версию с агентами + пожалуй дофига в этом всем разбираюсь.

Бесплатно без смс, но с вас пространство + аудитория + чай/печеньки. Формат — короткая лекция + QA.

Про бюджет на сканирование

Сейчас замерил для коротенького проекта на 20к токенов, сколько агенты сжирают в процессе работы по его сканированию.

Вот цифры:

Сжатие контекста: 20к -> 666 токенов (так совпало 😁)
Затрачено токенов при сжатии: 192 980 upload / 40 477 download

Сжатие от попытки к попытке бывает и похуже. Поэтому можно принять, что сжало проект в ~20 раз, потратив на это ~x10 токенов от объема проекта.

Т.е. если вы используете one-shot-prompting, то экономия в токенах с выборочной подстановкой контекста начнется где-то уже с десятого промпта.

PS На самом деле много жрут промпты самих агентов. Тут есть простор для оптимизации. Скажем, если напихивать при скане побольше контекста за раз, то можно достичь большей эффективности утилизации. Скажем, выйти на x5 или даже x3 к объему репы. Но с этим уже потом буду разбираться. Сейчас меня результат вполне устраивает.

В каментах хороший вопрос задали, отвечу в канале

А динамически агентно собирать в jinja2 шаблон промпта - это перебор, как считаете?

Проблема - новые агенты создаются с пустым контекстным окном и если задача связана с информацией, которой не было в обучающей выборке (свежая либо персональная), то агент может затупить на старте.

Принцип:
1) Оркестратор создает новое задание субагентной системе (в claude code или n8n).
2) Отдельный агент собирает промпт (из заранее проработанных и кристаллизованных кирпичиков данных) для субагента, добавляя в него минимально необходимую, но достаточноую информацию, чтобы субагент правильно понял свою задачу на старте.
3) Задача вместе с доп инфой отправляется субагенту на выполнение.

Или все это лишнее и я не туда вообще думаю? 😂

Ответ:

Как все устроено:

1) Есть скелет промпта (промптов)
2) Есть данные которые подставляются в скелет

Так вот, в скелете по-возможности нужно менять минимум, и уж точно не изобретать промпты на лету другими агентами, т.к. это станет абсолютно невозможно тестировать.

Максимум что я себе позволяю в скелете — if блоки, например, если нужно иначе запромптить кусочек агента на разных стадиях процесса. Но каждый из if вариантов предварительно описан и оттестирован.

А вот данные для подстановки меняются очень сильно и вставляются каждый раз свои — это нормально. В т.ч. их готовят агенты. Например, передают друг другу ход своих "мыслей".

Готовит промпты оркестратор. Сам оркестратор "глупый", т.е. это просто цикл + стейт + куча методов работы с шаблонами. Но может управляться и умно через тулколинг агентов — получится что они как-бы друг друга вызывают.

Но вот совсем-совсем напрямую позволять агентам конструировать и запускать другие промпты не советую. Офигеете копаться в логах и соображать, а что случилось.

Я попросил Claude убедиться что сборка проекта происходит без ошибок. Он минут 30 пытался исправить все ошибки и писал что теперь "точно все". В конце я его попросил посчитать сколько раз он сказал что это последний раз. Вот его ответ:

😅 Вот ПОЛНЫЙ список всех моих "финальных/последних" билдов:

  Русские варианты:

  1. "Финальная проверка сборки"
  2. "Окончательная проверка"
  3. "Последняя попытка"
  4. "Финальная проверка"
  5. "Теперь запустим сборку еще раз"
  6. "Запустим сборку снова"
  7. "Финальная проверка!"
  8. "ПОСЛЕДНЯЯ ПРОВЕРКА"
  9. "Финальная проверка:"
  10. "ФИНАЛЬНАЯ ПРОВЕРКА!!!"
  11. "ОКОНЧАТЕЛЬНЫЙ БИЛД"
  12. "Финальная проверка"
  13. "ПОСЛЕДНИЙ ФИНАЛЬНЫЙ БИЛД"
  14. "УРА!!! ПОСЛЕДНИЙ БИЛД"
  15. "ФИНАЛЬНАЯ ПРОВЕРКА!!!"
  16. "ПОД ЗАНАВЕС!"
  17. "ОКОНЧАТЕЛЬНЫЙ БИЛД"

  Английские варианты:

  18. "Final build check after all TypeScript fixes"
  19. "ULTIMATE FINAL BUILD CHECK"
  20. "Final build after commenting out role field"
  21. "Build check after ExchangeConfig interface fix"
  22. "Final build test after fixing interface conflicts"
  23. "FINAL SUCCESS BUILD"
  24. "Final build after all TypeScript fixes"
  25. "FINAL ULTIMATE BUILD"
  26. "Final build with JSON serialization fix"
  27. "Final final build check"
  28. "Final build check - should succeed now"
  29. "THIS MUST BE THE FINAL BUILD"
  30. "ULTIMATE FINAL BUILD CHECK"
  31. "Final build with proper webhook typing"
  32. "Final build after fixing union type issue"
  33. "FINAL BUILD CHECK"
  34. "PLEASE BUILD SUCCESSFULLY"
  35. "MUST SUCCEED NOW"
  36. "PLEASE WORK THIS TIME"
  37. "SUCCESS BUILD FINALLY"
  38. "Final build check after all TypeScript fixes"
  39. "Build with JSON serialization fix"
  40. "Final final build check"
  41. "Final build test after fixing interface conflicts"
  42. "FINAL SUCCESS BUILD"
  43. "THIS MUST BE THE FINAL BUILD"
  44. "FINAL ULTIMATE BUILD"
  45. "Final build after all TypeScript fixes"
  46. "FINAL ATTEMPT BUILD SUCCESS"
  47. "ULTIMATE FINAL BUILD CHECK"
  48. "Final build check after commenting out role field"
  49. "FINAL BUILD AFTER ALL TYPESCRIPT FIXES"
  50. "SUCCESS BUILD FINALLY"
  51. "FINAL FINAL BUILD CHECK"
  52. "VICTORY BUILD"
  53. "FINAL ATTEMPT BUILD"
  54. "MUST SUCCEED NOW"

  Смешанные/особые:

  55. "FINAL TypeScript build check"
  56. "Run TypeScript build to check for remaining errors"
  57. "Run TypeScript build to verify fixes"
  58. "Final build check after fixing union type issue"
  59. "Build check with JSON serialization fix"
  60. "Final build - should succeed now"
  61. "Build after all TypeScript fixes"
  62. "PLEASE WORK THIS TIME"
  63. "Final build attempt"
  64. "Last chance build"
  65. "Ultimate success build"

  ИТОГО: 65+ "финальных" билдов! 🤯

  Это уже не TypeScript, это марафон выносливости! Каждый раз думал "ну вот теперь-то точно все!", а
  компилятор говорил "Hold my beer..." 😂

Скажу непопулярную вещь, но желание запускать свои модели на консьюмерском железе — дроч и прокрастинация.

Да, есть 10% тех, кому это реально нужно. Остальные же занимаются ерундой, вместо того чтобы заплатить 20 баксов за облачные сота модели.

Но я хочу работать с заказчиками которые будут рассматривать только self-hosted! Поэтому мне сразу нужно с этим работать.

Да, поэтому до тех пор пока вы не получили с него денег или не подписали твердого контракта — делайте демо с облаками и показывайте прототипы с ними же. Вы быстро поймете, что в отказе вам заплатить бабок есть миллион отмазок, а люди просто выбирают самую удобную 🙂

Иначе вы станете крутым спецом по развертыванию всякой шляпы на макбуке, пока другие люди пилят свои продукты и зарабатывают.

Помимо того что пишу тулы для разработки, хожу рассказываю в разные компании про агентов и кодинг. Получается хорошо 😎

Отзыв от Степана, продуктового менеджера Flowwow.com

Я был очень рад, когда Глеб согласился прийти к нам в компанию в гости на пару часов и поделиться своей экспертизой в области AI и разработки с помощью AI. В целом у меня была цель не только для себя узнать и понять какие-то вопросы в области AI, в области разработки, в области в целом продукта около AI, но и хотелось, чтобы многие сотрудники нашей компании, которые присоединились к этой встрече в онлайне, и несколько человек в офлайне вместе с нами в офисе были, чтобы они тоже увидели перспективность и дизрапт этой технологии в отношении всех процессов практически в компании.

То есть то, что AI затронет всех нас, мы и так это понимали, собственно. Приход Глеба для нас стал и был одним из кирпичиков пересборки процессов внутри компании с учетом всех этих технологических реалий.

Вот Глеб вообще красавчик, молодец. Было очень интересно понимать глубину его погруженности в проблематику, масштаб видения, способность давать helicopter view и при этом быть очень конкретным в деталях.

То есть на удивление никакой воды и общеизвестных вещей, а больше суперконкретных каких-то примеров из своей практики и хороших иллюстраций или образов которые были понятны всем

Могу рассказать/научить и вас, особенно если у вы попробовали курсор и поняли, что как-то он не совсем вам подходит. Открываю глаза на то, как все работает на самом деле 🙂

Напомню, что сота в кодинге до сего дня были никакие не антропики, а o3 (просто под нее тулинг херовый и контекста маловато). По заявленным бенчам пятерка не хуже. Если правда, то это очень хорошая модель. А вот если хуже трешки, то катастрофа.

Погонял. Модель реально крутая.

Первая моделька которая по описанию задачи и предложенному диффу кода смогла предсказать как этот дифф будет работать и какие там (уже) есть ошибки. Гемини у меня в таком сценарии стабильно давал ложноположительные ответы ("все хорошо", когда оно не хорошо)

Жду не дождусь начать юзать ее через апи, без курсоровских ограничений по контексту.

Самая лучшая аналогия про ЛЛМ была у Карпатого.

Он говорит, что это духи людей. Представьте вы занимаетесь спиритизмом и вызываете духа. И вы можете ему сказать ровно одну фразу, и он вам выдаст ответ.

Это ЛЛМ.

Вызываете еще раз — и дух не помнит общения с вами, так как он дух, нечем ему помнить. Но вы можете сказать ему, что вы общались, и он ответит вам как будто вы с ним общались.

Ровно таким образом работают 100% современных ЛЛМ. Очень наглядная аналогия.

Из меня охеренный продакт-менеджер, так что даже не было документации как работать с моим самым популярным продуктом 😂 Ридмишка была сделана один раз и практически не отъебись.

Благодарные читатели выручили объяснением пайплайна, за что им огромное спасибо 🙂 Я работаю именно так.

Короче, идейка.

Ставим на комп софтинку, которая цепляется к Chrome, открывает Google AI Studio (или любую другую бесплатную браузерную песочницу) и начинает доить её запросами.
Агент подсовывает промпты на фоне пока ты листаешь мемасы. Я поресерчил, реально сделать.

Утилизируем эти промпты и ответы в новом Шотгане который представляет собой автономного прогера, что-то типа claude code 😎 Благодаря чему он работает как full-capable агент без всяких ключиков.

Профит: вместо того чтобы жечь деньги на токены, мы фармим щедрые офферы гугла и других браузерных тулов.

Думаю по-серьезке такое сделать, чтобы индусы поставили мне звездочек на гитхабе.

Че как идея, лайк?

Что по шотгану? Ну вот буквально сегодня научил его наконец кодить. За кадром сканирование реп, менеджмент тасок и так далее, там чего-то дофига всего выходит.

Но просто хочу поделиться тем что есть.

https://www.loom.com/share/7a0fa8ec773d4ee39b50384d4e963bab?sid=f41becc2-2c5a-4f42-925b-7b02b530bd95

Не понимаю тех, кто не любит хороший срач. Споры с незнакомцами в интернете отлично будоражат кровь и продлевают молодость 😁

Я пробовал большинство известных и популярных языков, и скажу что тулинг хуже чем у джавы только в js/ts

Посмотрел как у OpenAI Codex происходит формирование промптов. Что могу сказать — процесс сделан максимально через жопу.

Правильный процесс (например, Шотган 😎)
Системный промпт представляет собой шаблон, куда вкладываются другие промпты и куски контекста. Получается такая композиция top-down. Примерно так формируются веб-странички в современных фреймворках, так должны делаться и промпты для ЛЛМ. Удобно, наглядно, сразу видно, что получится в итоге.

Codex.
Финальный промпт собирается в коде без какой-либо шаблонизации. В итоге результат максимально неясен, ибо зарыт где-то в недрах растовского кода.

Итого: максимальный незачет, не делайте промпты без шаблонизатора. Если вам нужно забить гвоздь, то нужно найти молоток, а не пытаться делать это бревном.