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

Что можно делать прямо сейчас
— Упаковывать репу в короткий индекс 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.
Финальный промпт собирается в коде без какой-либо шаблонизации. В итоге результат максимально неясен, ибо зарыт где-то в недрах растовского кода.

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

Почему я пишу все свои проекты на Mongo

1) Я не хочу отдавать бабки дяде из облаков, поэтому вариант облачной БД отпадает. Supabase пока пока.
2) Важный и единственный выбор это на самом деле SQL vs NoSQL. Ну и внутри них допустим, еще свои разновидности.

И вот тут какая-нибудь постгря выглядит мощнее. Казалось бы, бери да пользуйся.

Но на деле SQL базы удобны только когда ты хорошо заранее спроектировал модель данных и хорошо понимаешь что куда и зачем.

Это полностью противоречит концепции индихакерства, когда обычно ты нихера не знаешь что куда и зачем, а так же на что будет похож твой проект через десяток итераций 🙂

Монга же идеальный вариант наговнякать чтобы протестить. А если оно будет загибаться от нагрузок, значит у тебя уже редкий успех и ты идешь просто все переписывать с командой разрабов хоть на чем. Хоть на той же постгре.

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

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

PS Для эмбеда и всяких однопользовательских плагинов же нет ничего лучше SQLite. Ее можно юзать как свалку документов, и тулинг гораздо проще постгри. Очень благодатная штука, если у вас проект на одного пользователя.

PSS Если вам файлики хранить, то берите комплектном к монге S3-совместимое хранилище, например Minio, его вам за глаза хватит, совместимо с любыми серьезными облачными провайдерами, если понадобится переехать.

Код, отвечающий за обработку статуса applying_changes, находится внутри основного цикла агента (_run_agent_loop), но точка входа (метод run) запускает этот цикл только если статус сессии — RUNNING. Это создаёт ситуацию «Уловка-22», при которой код обработки недостижим именно тогда, когда он нужен больше всего.

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