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

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

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. Классический пример такой уловки хорошо знают европейские понаехи — тебя могут прописать, но для этого нужен банковский аккаунт, но банковский аккаунт не дают без прописки.
Считаю, прекрасно. Ну и зачем нужны эти кожаные, а?

Незначительная деталь для вас, историческая веха для Шотгана

Первый полностью автоматизированный коммит 😎

Слушайте, вопрос—вброс. А чего все псят на gpt-5 кроме чисто продуктового факапа с переключением моделей?

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

Контекста в 272к с индексацией очень даже хватает. Стоит разумных денег.

Ну медленная чуток, но зато за ней нужно очень мало переделывать.

Чем вы недовольны-то? 🙂

Идейка. Вы кидаете донат 5к/месяц, а я стримлю свою работу, как я пишу код — 2 часа в неделю по вечерам после 21 мск. Прям по-честному максимально, мои реальные проекты и все как я делаю. По ходу буду в войсе и на ваши вопросы отвечать.

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

Короче у меня сегодня агенты срались между собой, ревьюер буллил кодера, было очень смешно читать лог.

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

Gpt-5 в этой роли очень хорош, первая модель на моем опыте, которая хорошо понимает диффы и не просто с ними соглашается, а реально вникает в логику

Ну что, десять плюсиков набрали, открываю формочку 👍

За 5 т.р. в месяц показываю свой реальный рабочий процесс по кодингу, как я делаю фичи в шотгане и не только, обсуждаю это с вами в процессе.

https://careerfactory.ru/gleb-ai

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

Будем медленно печально спускаться с горы. сегодня в 22 начнем.
Ща вот линтеры в шотгане мучаю и стратегию применения git diff (а то долго чего-то) — велкам на эти зажигательные темы 😁

Я внезапно понял, что пока писал новый шотган у меня уже почти получился lovable 😂

Показывал сегодня на стриме — у меня в облаке крутится сервак с движком. Засасывает туда гит репу, делает таски с помощью ллм-ок, а далее коммитит изменения обратно.

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

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

Интересный юзкейс для скана репозитория — помощник в написании требований

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

https://chatgpt.com/share/689ddb8e-60a4-8004-8c24-6465e7ee9fff

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

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

https://gist.github.com/glebkudr/3156feda883b5f66d113b746ddeb5a12

Секрет в глубине и технике сканирования — подготовки данных, на основе которой мы конструируем ответы.

С помощью этой техники можно писать
— Продуктовые требования
— Тест-планы
— Архитектурные спеки
— Проводить ревью предложений на полноту/краевые случаи

Если вам/вашей компании интересно начать писать бизнес-требования или приведенные выше документы через мой сервис — пишите, подпишем NDA, сделаем вам скан кода, и попробуем в работе.

Попробовал Jules. Ну что могу сказать, мой шотган лучше 😂 Реально блин уже подписку нужно прикручивать и продавать, а не страдать фигней.

Самое сложное в курсоре и подобных агентах вовсе не "придумать" код, а применить полученные диффы к файлам. Капец какая дурацкая и плохо формализуемая процедура. Я догадывался что такое может быть, но блин, там просто кроличья нора.

Почему диффы? Потому что генерить файлы целиком с нуля тяжело + чревато ошибками. Все кодинговые тулы внутри себя работают с диффами. Но там где-то 5-6 слоев обработки сверху и страховок через дополнительные LLM вызовы, если что-то пошло не так.

Не так идет почти всегда 😂

Не даром в курсоре натренировали собственную сетку чисто под эту задачу. Прекрасно их понимаю.

Ну что, делаем шотганом две задачи в параллель.
Ваши ставки?

🤩 — все будет топ
🌚 — кровь кишки расчлененка

Голосуем!

Победила дружба!

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

Ну че, как там на вайбе? 😁 Выжмем максимум?

Как мой кодинговый цикл работал до вчерашнего дня?

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

Проблема — дифф применяется только целиком или отбрасывается тоже целиком. Неэффективно, т.к. в памяти агенту нужно держать весь дифф + уметь его достраивать, а они в целом это плохо умеют.

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

Скрестите за меня пальцы 😁

Ключевое решение, которое вы принимаете в построении агентской системы.

Какую именно логику вы отдаете агенту, а какую оставляете в жестко алгоритмизированном коде?

Решение сложное.

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

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

Всего есть три очевидных способа.

1) Дать каждому из агентов принимать решение самостоятельно. Т.е. после своего вызова он знает, кому именно он передает работу.
2) Сделать агента-диспетчера, который принимает работу от каждого участника и передает следующему.
3) Сделать жесткий код, т.е. алгоритм, и роутить следующего агента согласно заранее заложенным в систему правилам.

Проблема тут в том, что однозначного ответа, какой способ лучше, нет.

В каждом свои приколы.

— Чтобы агент принимал решения, мы должны в него сгрузить кучу инфы про другие инструменты, состояние процесса, и намерение пользователя. Это не всегда легко, и зачастую приводит к логическим ошибкам. А еще — увеличивает контекст + расходует окна внимания модели.
— Гибкие агенты могут "пойти вразнос", за счет нечеткой логики, в системе могут образовываться безвыходные циклы, или наоборот, "глухие углы", когда часть задач никогда не будет выполнена. Это все крайне сложно дебажить.
— Детерминированный код позволяет писать понятные тесты и добиваться предсказуемого поведения, но очень ригидный, если что-то пошло не так, то система не склонна к этому адаптироваться.
— Для детерминированного вызова агентов сложно набивать контекст, да и само программирование требует кучи кода в противовес к тому, чтобы просто засунуть нужные вызовы в промпт.

Итого:

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