Народ, если вы думаете продавать что-то с ЛЛМ-ками, то вот мои наблюдения.

Рынок в стадии обучения

Вас таких продвинутых — пара десятков НА СТРАНУ. 99% народа не вдупляет не то что ваши выводы, а даже факты из которых взялись предпосылки для этих выводов 😉

То есть.

Если строите на этом бизнес — то либо фигачьте b2c/smb сервис, где клиенту вообще пох нейронки там или гравицапа. Тупо консьюмерскую таску закрыть и все.

Либо делайте b2b с упором на объяснение, нахера вы делаете то, что вы делаете. Потому что естественный спрос еще крайне далек от плато, адопшн нейронок в самой ранней кривой роста, и в бизнесе кратно отстает от b2c сферы.

Что новенького по порно-генерации?

Сегодня совершенно случайно набрел на мир adult-LoRA в civit.ai

Отключил все фильтры, включая тентакли (да, там есть такой), и окунулся в пучины нейронок.

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

В каментах дал ссылку на одну из качественных моделей в этом деле (18+, требуется регистрация, осуждаем и все такое). Можете оценить сами, так сказать, глубину и перспективу.

Ну а видео подтянется.

Вчера первый раз смог запустить ShotgunPro на репе самого ShotgunPro.

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

Так вот, запуск позволил сжать репу в 12 раз.
Из 130к токенов она превратилась в 11к json-кода, полностью описывающем его смысл.

В другом кейсе — бойлерплейт на Astro сжало из 100к до 1.4к, то есть аж в 60 раз, но там было мало внутренней логики.

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

Итоговая оценка качества получившегося сжатия будет основана на качестве поиска необходимых для фич файлов.

То есть берем два кейса.

А) Промпт "выдай файлы для создания функционала X" + весь контекст репозитория.
Б) Промпт "выдай файлы для создания функционала X" + сжатый контекст репозитория.

Задача промпта Б — показать, что он отдает файлы не хуже, чем промпт А. На паре задачек уже это вижу, но хочу потестировать сильнее.

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

Ходил недавно на конфу ConversationsAI и участвовал в круглом столе про будущее менеджмента с AI. Получилось задорно и весело.

Если не хотите смотреть все, просто посмотрите фрагмент 46:17 о том, кого с моей точки зрения, не заменят с помощью AI 😁

https://youtu.be/boOB1MkQb70?si=xNZfMVz_83WOcAo4&t=2775

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

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

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

Глеб, покажи свои ТЗ для нейросеток?

Ну вот. Просто sneak peak того, что валяется в работе прямо сейчас.

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

https://teletype.in/@glebkudr1/7_tkSXUGjFq

Если ваши промпты короче, чем этот — что-то вы делаете не так 😁

Дорогие дети, а сегодня мы проходим букву Е

Е — ебучий питон

4.1. Подтвержденная причина: Опечатка в коде доступа к атрибуту
Анализ однозначно показывает, что сбой вызван опечаткой в файле backend/app/worker/agent_executor.py. Код пытается получить доступ к response_data.actions, в то время как правильным атрибутом является response_data.action.

Mood 😁

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

if session.plan_update_status == 'pending_confirmation':
is_affirmative = msg_content.lower().strip() in ["yes", "да", "confirm", "ok", "y", "д", "да, продолжай"]

Создатель редиса кодит с AI буквально как я.

— Не пользуется вайб-агентами
— Полностью контролирует контекст нейросети
— Вручную копипастит результаты 🙂

Смущает меня тут только третий пункт. Копипаста все же неэффективна. Поэтому в ближайшее время буду дописывать в шотган-про возможности по кодингу без копипасты.

У нас есть секретный чат топовых AI блогеров. Строгий фейс-контроль, внутри только те, кто сами кодят (много), ex ML, CTO и так далее. Серьезные люди, короче.
Классный чатик, люблю его.

via @baginsai @bogdanisssimo

Шотган v2 кусающий себя за хвост, описывающий себя в json

http://jsonblob.com/1400596103002513408

Конденсация 130к токенов -> 5к токенов.

Самый прикол, что можно сравнить два таких сконденсированных состояния, и gemini даст неплохое описание эволюции системы между ними.

Например, сравнение двух стейтов — до крупного патча и после.

Кайфово играться, теперь бы превратить это в продукт 🙂

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

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

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

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

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

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

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

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

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