Вчера зашотганил где-то 50к токенов в проект.

Действовал так.

Сначала промпт-архитектор расписал мне архитектуру.
Потом промпт-менеджер побил на большие задачи. Их получилось больше 20 штук.
Потом я последовательно делал задачи в связке шотган <> AI Studio, тупо повторяя один и тот же промпт

Мы последовательно реализуем задачи из папки /tasks.

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

После реализации проапдейть и сами тексты задач.

Диффы применял с помощью claude 4 в курсоре.

И что вы думаете?

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

Надо теперь отдельным промптом запустить исследование, что ж мы такого понаделали 😁

PS Гипотеза того, что шотган позволяет люто поднять качество питоновских проектов по сравнению с курсором подтвердилась. На 50к свежих токенов (~5 тысяч строк) тесты нашли всего 2 явных ошибки типизации.

Как я бросил курсорить и начал шотганить

Прошел почти месяц с официального релиза Шотгана.

За это время проект приобрел 1200 звездочек на гитхабе, 150 форков, индусы сняли про него несколько видео суммарным числом просмотров сильно более 100к, а инструмент занимает центральное место в моей работе с кодом.

Что это и почему я его применяю?

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

Это прежде всего идеология:

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

И чем дальше, тем больше я убеждаюсь, что это верный подход.

— Большие контексты позволяют сохранять согласованность имен переменных в динамических ЯП типа Питона или JS.
— Большие контексты "склеивают" вместе архитектуру, позволяя модели делать меньше лапши и больше согласованного кода
— Мы банально экономим запросы в курсоре, и не выходим за 20 баксов в месяц 🙂

Сейчас мой пайплайн кодинга такой:

Сетап
1) Я описываю идею проекта подробно, запускаю в шотгане промпт архитектора и несу результат в gemini (Google AI Studio, модель 2.5 pro).
2) Отвечаю на вопросы сети и провожу циклов 2-3 улучшения промпта, скармливая ей собственный результат и все более его уточняя.
3) Когда промпт готов, несу его в курсор, выбираю Claude 4 и готовлю бойлерплейт проекта

Рабочий процесс
Когда бойлерплейт готов, я приступаю к более регулярной работе. А именно.

4) Описываю набор фичей, которые мне нужны. Несу это архитектору (далее соответствующий промпт в Шотгане + ответ от гемини я буду называть именно как обращение к персонажу).
5) Ответ архитектора тащу проджект-менеджеру и прошу сформулировать задачи + систематизировать архитектуру проекта в файлах.
6) Задачи несу разработчику и прошу их последовательно их имплементировать.
7) Возникшие баги ищу с тестировщиком и несу результаты разработчику или архитектору, в зависимости от того, насколько сложна причина их породившая.

Цикл повторяется до следующей крупной фичи.

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

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

По ощущениям это максимально далеко от "вайба", а скорее что-то типа "AI assisted program engineering", потому что временами мозги кипят, и в голове нужно держать контекст проекта в том же объеме, что и нейронке, грамотно формулируя, что же ты хочешь от нее получить. Ведь при плохой формулировке она и сделает какую-то фигню, а не то, что нужно.

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

Что дальше?

На самом деле, самое тупое во всем этом процессе - ждать по три минуты на каждом шаге, а далее копипастить результаты между инструментами.

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

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

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

А почему бы нам не удалить нахер все твои данные?

А и правда. Удалю их, так же и нужно всегда делать если у тебя не заводится какой-то один левый контейнер, да? 😂

Это я случайно курсор обновил. Осторожнее с этим психопатом 🙈

Это самая загадочная проблема с которой я сталкивался!

Это самые страшные слова, которые вы можете услышать от ЛЛМ при написании кода 😁

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

И что вы думаете? Они сохранялись. При загрузке. А после этого я жал на кнопку save и вот в этот момент они откатывались.

Два, сука, часа.

У нас есть камерный чатик топовых челов которые пишут про AI

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

Каналы камерные и уютные. Максимум пользы, минимум хайпожорства.

Каждый из нас подготовил один пост на тему AI кодинга. Чтобы посмотреть другие посты автора — переходите к нему в канал.

-> Vibe Cursor Coding

-> AI / Vibe coding - советы и best practices

-> Как получилось, что юристы используют среду для разработчиков?

-> Stitch: от вайб-кодинга к вайб-дизайну и обратно

-> Как я бросил курсорить и начал шотганить (я тут тоже есть!)

-> Вайб-кодим Google Apps Script для офисных задач: как LLM превращает часы рутины в минуты магии

-> Context7 — один из лучших инструментов для AI-разработки

-> Топовый AI Coding Workflow: Cursor & AI Studio

-> Как Cursor AI превращает текст в готовые макеты Figma

-> Простое веб-приложение за 30 минут с помощью Lovable

Мне очень нравится состав тусовочки и формат публикаций. Изучайте и подписывайтесь 🙂

Выпал тут на неделю на конфу, возвращаюсь.

Если еще не попробовали o3 в курсоре — обязательно попробуйте. Модель очень умная, как ей и полагается. Как и всегда в курсоре, ей дается мало контекста, но она сильно лучше решает задачки в девопсе и всякие стремные баги, за которыми раньше приходилось бегать к ней в веб-интерфейс, а сейчас все работает прямо из чатика.

А вот шотганить все равно нужно. Умная она-то умная, и точечные баги разгребает влет, но я тут собрал очередной проектик на 50к токенов и приплыли, контекст напрочь теряет, если ей никто не помогает со стороны (гемини, шотган, привет).

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

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

Поэтому анализ должен быть другим.

Берете любой утекший промпт публичного сервиса.

Засовываете его в ЛЛМ и спрашиваете — типа, эй объясни, что тут и почему происходит.

А потом берете этот анализ и просите ее повторить 😁 И вот у вас уже свой уникальный промпт.

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

У вас есть руки — копипастить. А у нее мозг — думать.

Всегда так делаю 😎

Смешно сейчас было. Работал в проекте с шотганом. Дал ему задачу, он пошел ее делать.

Архитектуру расписал, на таски побил, все четко.

Потом смотрю — а это блин не тот проект вообще.

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

Короче, следите за тем, что происходит, иногда нужно вникать 😁

Все знают, как смешно ЛЛМ-ки пишут тесты. Хардкодят "assert true", проверяют абы что и вообще, творят дичь.

Но я открыл метод борьбы с этим, восхитительный в своей простоте.

Буквально: "Проверь, что тесты не говно"

Ну или чуть подробнее

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

— вставляем это в промпт тестировщика в шотгане.

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

А если какие-то нужно, то вторым промптом мы говорим.

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

Вот анализ тестировщика

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

Ну и все. Обвязываем это промптом разработчика, и генерим диффы.

Работает прекрасно, а ваши тесты будут мягкими и шелковистыми.

Кстати, важно. Почему в начале промпт тестировщика? Потому что он задизайнен на стектрейсинг и поиск багов. То что нужно для анализа внутренних связей в программе и того, что там что-то работает не так, как нужно.

А сколько спринтов бы это планировалось в вашей компании? 😁

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

+1 в пользу "инженерии контекста" вместо "инженерии промптов".

Люди ассоциируют промпты с короткими текстовыми заданиями, которые вы даёте ИИ в повседневной работе. Но в любом промышленном приложении на базе LLM настоящая тонкая наука и искусство — это именно инженерия контекста: умелое наполнение контекстного окна нужной информацией для следующего шага. Это наука, потому что правильная настройка включает в себя формулировку задач, объяснения, примеры (few-shot), RAG, сопутствующие данные (возможно мультимодальные), инструменты, текущее состояние и историю, а также сжатие… Если информации мало или она неподходящего вида — LLM не получает необходимого контекста и работает хуже. Если слишком много или не по делу — растут издержки и падает производительность. Делать это правильно — далеко не тривиально. И это искусство, потому что требует интуитивного понимания "психологии" LLM и "духов" людей, которые с ними взаимодействуют.

Помимо самой инженерии контекста, LLM-приложение должно:

— грамотно разбивать задачи на потоки управления,
— правильно упаковывать контекстные окна,
— вызывать подходящие LLM с нужными способностями,
— обрабатывать цепочки генерации и верификации в UI/UX,

и многое другое: контроль, безопасность, оценки, параллелизм, упреждающая подгрузка и т.д.

Таким образом, инженерия контекста — лишь один небольшой элемент всё более сложной прослойки нетривиального ПО, которая координирует отдельные вызовы LLM (и многое другое) в полноценные приложения на базе LLM. Термин “обёртка для ChatGPT” устарел и крайне некорректен.

https://x.com/karpathy/status/1937902205765607626

Кто-то может не в курсе, веду еженедельные встречи запускаторов продуктов.

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

Тащим за уши и помогаем всем 👍

Вчера вот была лекция в стиле «систем дизайн для самых маленьких». А до этого делились подходами в кодинге, тому как разворачивать сетки у себя на компе и так далее.

Встречи в 18 часов по четвергам, полтора-два часа. Теплая компания. Для пропустивших доступны записи. Стоимость 20 т.р. в месяц.

Завтра закрою вход до следующего набора (когда он будет не знаю, но не раньше августа)

Для тех, кто хочет начать кодить, но не знает как — самое то.

Присоединяйтесь

Промпт для промптов.

Закидываете сюда любой промпт и тулза его вам сделает лучше. Я попробовал — хорошо работает.

Можно заменить наивным подходом "оцени и улучши..." без лишних слов, но тут этот мета-промпт уже отшлифован и работает еще лучше.

Теория тут — можно скопировать тексты отсюда и применить в любой ЛЛМ, не обязательно ChatGPT.

GPT тула тут — тем, кому лень разбираться.

А вот тут пример работы.

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

Чуток упоролся в философию. Но вообще, современному инженеру это важно кмк.
—

Сознание не нужно🙏

Глеб: Я больше скажу — сознания нет нихера, это просто иллюзия, созданная хорошей работой с памятью

А что такое хорошая работа с памятью?

Глеб: У нейросеток есть процесс протекания одного мыслительного кванта, на абсолютно stateless машинерии. Соответственно все что и находится за этими пределами — память.

Низкоуровневая это по сути промпт. Имеет аналоги в человеческом мозге, например пятно поля зрения. Влезает в контекст модели целиком.
Высокоуровневая — все остальное. Начиная с поля зрения целиком, заканчивая тем, каков был вкус мороженого купленного бабушкой 30 лет назад. Фишка этой памяти — никак целиком не влезает в контекст, и чтобы извлекать из нее пользу, нужно ее всячески препарировать и нарезать.

Способность эффективно работать памятью — это подготовка из нее контекстов и дополнение/изменение в процессе самой работы ллм за счет вызова тулов "запомнить эту хрень" или "частично забыть/сжать воспоминания"

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

Хорошей памяти ни у одного агента на рынке _пока_ нет (но будет, фигли, куда денемся)

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

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

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

Проблемная зона AI-кодинга: почему Shotgun Code работает не везде

Встретился на днях с Глебом Кудрявцевым, автором популярного Shotgun Code(1.4k ⭐️)
Обсудили интересную проблему "мертвой зоны размера контекста" в AI-кодинге

Давайте закрепим о чем же на мой взгляд термин "Vibe Coding"

Как вы помните ранее я писал что многие говорят про "AI написал мне приложение за день", но реальность сложнее
Недавно сам я за 7 дней собрал MVP AI-платформы транскрибации: 16k строк кода, 820 вызовов Cursor, 3 компонента
Что я понял? Так это то что AI не заменяет экспертизу он ускоряет её

За успешным vibe coding стоят годы опыта в архитектуре, понимание паттернов и системное мышление
AI пишет код, но направляет его человек. Разница между "вроде работает" и production-ready системой — в экспертизе разработчика
Vibe coding ≠ магия Это смена роли: от кодера к архитектору и тестировщику

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

Про Shotgun и контекст, что работает сейчас и еще подходы что пробовал лично я

Сам Shotgun отлично подходит для проектов до 20-200k строк
- Весь код влезает в контекст(сразу сделаю оговорку что дальше мы используем большие и мощные модели в кодинге)
- LLM легко понимает структуру
- Можно делать cross-file изменения
- README генерируется без проблем

Дальше начинается проблемная зона 200k-1M строк
- Слишком много кода для простого dump'а
- LLM теряется в объеме информации
- README получается поверхностным
- Нет семантического понимания архитектуры
- Вообще не понятно, как все это автоматизировать

Даже с большими контекстными окнами проблема остается LLM физически не может эффективно обработать и осмыслить сотни тысяч строк кода как единое целое

Решение, к которому пришли и то что сейчас делает Глеб (следим за его репо и обновлениями) цепочка агентов для семантического анализа

Нужен промежуточный слой

1. Агент-архитектор - анализирует структуру проекта
2. Агент-аналитик - выделяет ключевые компоненты и связи
3. Агент-документатор - составляет понятный README на основе семантики

Результат: вместо "вот куча кода, разберись сам" получаем "вот top-down структура, вот ключевые модули, вот как они взаимодействуют".

Практический вывод

Shotgun Code нужно дополнить семантическим анализом для средних проектов.
Простой dump кода уже не работает - нужно понимание архитектуры через AI-агентов


Shotgun Code: GitHub Хороший инструмент, но есть куда развиваться!

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

1) Контекст. Ну тут уже прожужжали все уши. Контекста недостаточно, ах вот бы туда напихивать побольше и т.д. И я тут кое-что делаю.

2) Окно внимания (attention bottleneck). А вот это уже интереснее. Мало рассуждают в этом ключе. Заострю подробнее.

Есть такая метрика производительности ЛЛМ, как "точность поиска фактов". Дают длинный контекст и просят ответить на нечто, там упомянутое. Короче — просят найти иголку в стоге сена. И вот это некоторым образом коррелирует с тем, насколько нейронка умеет хорошо с контекстом работать.

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

Например,
"Отвечай жирным шрифтом, каждый абзац начинай со смайлика, формат json..." и так N штук.

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

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

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

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

Что ж, посмотрим, что нам предложит GPT5 😎

Всем курсора, пацаны.

Шаманю нечто, под кодовым погонялом шотган-про.

Агенты работают туда-сюда, заводится шарманка.

Но знаете, в чем трабла? В тупом веб сокете. Два дня убил на отладку этой сволочи.

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

Боль, унижение. Но ничего, зато сейчас смогу наконец промпты помучить.

Внезапно понаеду в Москву в пятницу. Утро занято, вечер занят. Нужно занять день, и я придумал формат, что могу понаехать к кому-нибудь из моих читателей в офис и рассказать про то, как и для чего готовить ИИ, как делать агентов, вайб-кодинг и все такое.

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

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

Кто первый сообразит и предложит — того и тапки 🙂(но могу и отказаться/без обид)

Пишите в личку @glebkudr1

UPD — разобрали