Я внезапно понял, что пока писал новый шотган у меня уже почти получился 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) Сделать жесткий код, т.е. алгоритм, и роутить следующего агента согласно заранее заложенным в систему правилам.

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

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

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

Итого:

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

Вы посмотрите какой fabric, какой fashion!

Первый раз отсканил сегодня репозиторий подписчика.

Вышло увлекательно — за первые три запроса в ЛЛМ усвистел почти лям токенов. Посмотрел на список файлов и понял, что в gitignore репозитория не прописаны node_modules, в итоге там какая-то туча левых библиотек.

Срочно написал фильтр на своей стороне, запустил снова.

После этого поставил уже настоящий скан.

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

Доработал промпты, поставил еще раз.

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

Еще раз доработал промпты, но на этот раз задачу было принято считать законченной.

Ужал чуть ли не в сотку раз (700к -> 5к), жду теперь фидбэка, как этот скан в работе 🙂

PS Зачем нужен скан? Фишка в том, что это сжатый контекст репозитория. Можно пристегивать его к любым своим запросам к любым ЛЛМ и она сразу начинает понимать о чем вы с ней говорите, и отвечать вам не общей информацией, а конкретно по вашей кодовой базе и проекту.
Кому еще попробовать — пишите, личка в био. На 100к строк уходит примерно 10 баксов в токенах. Пока ручной сервис, для общественности код еще не готов.

Как решать сложные проблемы не на вайбе

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

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

Мы не можем просто их "не решать", так как заменить их нечем, а что-то делать нужно.

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

1) Описываем баг. Либо сами (подробно), либо кормим Gemini 2.5 pro в AI студии логи работы вашего кода и просим сказать, что там не так. Она съедает до 1 млн контекста — идеально для анализа логов (я работаю в основном по логам, т.к. много бэкенда, фронтам нужно иначе).
2) Несем результат в Шотган и выбираем промпт "Find bug" — получаем потенциальный стектрейс проблемы.
2.1) Если она понятна и проста, то далее тащим результат тоже в шотган и применяем dev промпт. Затем полученный дифф интегрируем хоть руками хоть курсором.
2.2) Если непонятна, то отдельным промптом просим Find bug агента дать вам список файлов, которые имеют отношение к проблеме, это пригодится нам далее.

3) Что если проблема не пофиксилась с первого/второго раза. Короче говоря, творческая в плохом смысле.

Тогда нас будет выручать GPT-5

Его особенность в том, что ему нужно очень сурово препарировать контекст.

Итак, открываете ChatGPT 5-thinking модель и даете следующий промпт:

Я делаю таску [такую-то]. В процессе работы я наткнулся на баг. Он заключается в [копируем сюда вывод Gemini по логам]. 

Расскажи мне причины бага, и почему он возник. 

Прикладываю контекст

Архитектура
====
 {описание архитектуры которое я надеюсь вы делаете для своих тасок, шотган -> Architecture}. 
===

Необходимые файлы /собираем индексилкой, или просто шотганом, ШотганПро умеет это делать автоматически). Важно — не весь проект/ 
===
[список файлов и их кода]
===

Мнение тестировщика, но я не уверен что оно корректное/замечание про неуверенность важно, т.к. иначе модель зацепится за эти выводы, а т.к. баг не пофиксился легко, то очень часто они неверные/
====
[складываем отчет от Gemini]
====

GPT-5 выплюнет в вас достаточно сложными рассуждениями и кусками кода, которые вы плохо поймете. Но это не беда, потому что:

4) Тащим теперь это в шотган к dev агенту или в курсор. Тупо копируем и говорим

Я делаю таску [такую-то]. В процессе работы я наткнулся на баг. Он заключается в [копируем сюда вывод Gemini по логам] /короче то же что и GPT-5/

Вот предложение архитектора
====
[Пространный бред от GPT-5]
====

Верифицируй и реши задачу

И вот это уже с большой вероятностью сработает

А далее можно продолжать фигачить ваш курсорный или CC-шный вайб в промышленных объемах =)

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

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

— Эй, GPT-5, у меня проблема
— (думает 15 минут) пупупу... твою проблему легко решить... яйцо в утке, утка в кролике, телеграфирую юстас алексу... /несет какую-то дичь/
— Спасибо GPT-5, скормлю твою херню другой сетке и попрошу выполнить что ты тут насоветовала, это всегда работает 🥰

Если есть кто-то увлекающийся вайб-кодингом и (обязательно) владеющий англоязычным твиттером не менее чем 1000 подписчиков — пишите, предложу вам совместно зарабатывать на шотгане 🙂

Личка в профиле.

У меня набралась мини-группа смотреть за тем, как я пишу код.

Основной фидбэк «ааа капец непонятно» 😁

Ну т.е я привык жонглировать промптами, херачу их туда-сюда между инструментами, и вообще, работаю быстрее чем думаю (последнее — главная проблема 😅).

Пришлось даже кое-что объяснять, хотя формат таким и не планировался.

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

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

Не могу остановиться писать кодера. Видимо это судьба разработчика — писать инструменты для разработки 😅

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

Запушил пять задач подряд без проблем.

Утром врубаю — не работает.

Оказалось, последним коммитом в этих пяти, агент—падла нахер мне сносит самую важную вьюху на фронте, а ревьюер типа — а, ну ок, в задаче про фронт ничего не было. ПРИЕМЛЕМО🤪

Вот такое восстание машин, буду разгребать, чего это они решили взбунтоваться

Секрет написания крутого кода в курсоре и не только

Техника из детской сказки «Репка»

Три последовательных промпта со вставкой результата на каждом шаге.

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

Работает намного лучше, чем просто «напиши такой-то код»

Пользуйтесь