В данном проекте описана моя история работы вайбкодером и путь взаимодействия с ИИ-агентами. Проект живой, информация будет наполняться и расширяться регулярно. Можно его просто изучить и найти полезную информацию, а можно форкнуть, запустить своего агента и попросить его найти полезные фичи и особенности для вашего проекта.
Я — системный аналитик и Tech & Area PO в финтехе, преподаватель системной аналитики НИУ ВШЭ, сооснователь школы аналитиков, инвестор и музыкант.
Я не пишу код руками. Я проектирую системы, принимаю решения по архитектуре и продукту, а реализацию делают ИИ-агенты. С апреля по август 2026 так собрано десять систем, более 2 000 коммитов — от алгоритмической торговли до продакшн-платформы, которой пользуется клиент. Семь из них описаны здесь.
Сами репозитории приватные. Этот репозиторий — про метод: как устроена работа, какие правила выведены из провалов и чем проверяется результат, если ты не читаешь код. Также описаны ридми и claude md c каждого проекта, а в ридми конкретных проектов детально описан проект, мой путь в нём и косяки, которые я собирал.
P.S. Описание проектов также было написано совместно с Claude. У меня не было цели детально и красиво всё описать - мне надо было лишь передать мысль (но когда дойдут руки выровняю весь текст).
Если захочется деталей, нужно показать код и пример моего взаимодействия с агентами — пиши в Telegram: @Basov_VA. Если хотите посмотреть мой профессиональный путь — вот моё резюме.
БАЗА - ИИ пишет код. Код, написанный ИИ, должен проверять саму ИИ. Чтобы это сделать, вы должны выучить пункт 1 и пункт 2 ниже.
1. Вы должны понимать что вы создаёте. Когда вы делаете приложение, продукт, продвинутого агента, вам необязательно понимать код и его детали (спасибо ИИ за это), но вы должны на 1000% понимать что вы хотите получить, как это должно работать и как вы поймёте что это то, что вы хотите. Если вы будете делать продукт и на 100% отдадите руль ИИ, то вы не поймёте куда он вас привезёт.
У меня есть проект myTrade, где я занимаюсь алгоритмической торговлей (полдробности в проекте). Я не понимаю на 100% всю математику проекта, всю логику тестов, но я понимаю как это должно работать и задаю вопросы ИИ - именно по логике и бизнесу - по всем шагам. Дополнительно и параллельно, агент мне ведёт вики для меня самого, чтобы я понимал, что то, что он пишет в коде имеет логический и бизнес смысл.
2. Вы должны понимать как проверить результаты и убедиться в том, что выполнен пункт 1. Вы не знаете что в коде. Кроме того, агент может принимать множество решений по ходу своей работы, поэтому вы ещё и не знаете что у него в голове. Агент может держать в себе множество контента, и вы никогда не узнаете что там на самом деле. Но можно написать проверочный код, который алгоритмически и недвусмысленно проверит что получилось по итогам работы агента. Именно такие гейты (см. далее) и являются основой всех моих тестов. А так как проверочный код пишет тот же агент, то чтобы проверить корректно ли написан тест, смотрите пункт 1. Да, есть работа субагентов, которая и призвана решать именно проблему "перекрёстного взгляда", но субагент является таким же агентом с таким же внутренним миром, в который вы никогда не сможете заглянуть.
Ещё пример - мой проект reports, где была крупная задача переработать отчётности из PDF множества эмитентов. Claude добросовестно всё проверял, заносил в БД, двигал файлы в распознано, но в конце оказалось, что многие файлы он переместил без разбора "просто потому что". Было множество проверок для проверки корректности распознавания, куча математики по цифрам, но не было теста, который проверит "добросовестность" Claude. И всплыл как раз этот страшный кейс - проверка выполненной работы на 100%, проверка выполнения работы на 0%. Поэтому был написан тест, который проверяет не качество работы, а полноту выполнения работы.
3. Контекст и широта мысли - ваши. На старте проекта проблем нет. Когда он толстый и большой, только вы можете понимать, что правки, которые мы вносим на последних фичах могут что-то потрогать вначале проекта. Только вы можете "широко мыслить" и видеть весь проект сверху. Поэтому тут просто продублирую пункт 1 - Вы должны понимать что вы создаёте.
Если вы доверите Claude весь проект на 100%, то будете ходить по кругу, делая новый кусок в конце и ломая кусок в начале. Чтобы более конкретно понять этот пункт, посмотрите архитектуру в проекте myTrade или напишите мне.
4. Нейронка себя понимает лучше чем вас. В каждом проекте у меня есть обязательно правило AI комментов. Claude или любой другой прямо по тексту оставляет самому себе готовые комменты, которые позволяют ему не спотыкаться дважды на одних и тех же граблях, а также допускать меньше ошибок. Это эффективнее, чем вести какую-то документацию и делать где то подобные отметки.
Есть множество вариантов как оптимизировать разработку (графы, wiki for development от Qoder и т.д.) - уверен, вы найдёте нужное. Я использую комменты + grep со стороны ИИ в рамках проектах. Главное - использовать что-то и в идеале со старта проекта.
В любой момент времени у меня 3–4 проекта идут автономно и один, который требует погружения. Если есть время (например, в выходные), количество автономных проектов раздувается до 5–6 (стараюсь не сильно насиловать своё железо). Автономный проект — это проект, в котором в данный момент идёт какая-то работа: крутится круг кодера, гоняются тесты и т.д. Я подключаюсь лишь на приёмке. Погружения требует тот, где сейчас проектируется что-то новое — там, где нужна моя голова.
Именно поэтому большая часть логики работы построена вокруг приёмки. Когда проектов несколько, а человек один, масштабируется только одно — машинная проверка вместо чтения кода.
Инструменты: Claude Max (Claude Code) и Qoder Pro — через него работают Kimi K3 и Qwen 3.8Max. Кодер — DeepSeek v4 Pro в автономном CLI-цикле. Три архитектора равны и взаимозаменяемы, у каждого своя память; кодер памяти не имеет, поэтому наряд обязан быть самодостаточным. Раньше кодером был ещё GLM-5.2, но он попал под сокращение.
На каждой проектной странице этот цикл описан со своими подробностями, но каркас у него один.
Смотрю по плану, что осталось, и даю команду для выполнения задачи. Контекст агент поднимает сам: код ведёт в план, в наряд и в историю git, пересказывать постановку заново мне не приходится. Дальше он решает, делает сам или пишет наряд кодеру — выбор исполнителя всегда за архитектором.
После каждой закрытой задачи прошу отчёт: что изменилось, что поправили, где смотреть результат. Мержи без меня не делаются ни в одном проекте. Перед мержем — полный прогон тестов, а не только тех, что рядом с правкой.
Дальше я залезаю в саму задачу — выборочно, туда, где логика сложная или где можно тихо испортить данные. Именно в логику, не в код: как это теперь работает, что поменялось в поведении, куда потечёт дальше. Слишком много раз было так, что мы аккуратно сделали в одном месте, а отвалилось там, где не трогали два месяца. Агент этого не увидит — у него в фокусе своя задача, а система целиком остаётся на мне.
Если ты не читаешь код, «готово» от исполнителя не значит ничего. Ни «тесты зелёные», ни «я всё проверил». Значит, нужен способ принимать работу, не открывая диф и не погружаясь в сам код.
Отсюда четыре опоры:
1. Разделение ролей. PO приносит задачу на уровне ценности, цели и бизнес- и пользовательских требований. Архитектор решает, как это строить. Кодер работает по наряду и не импровизирует с архитектурой. Это позволяет "сократить" ширину мыслей агента, что повышает его внимательность. Да, агент тоже сложно работает в режиме многозадачности.
Выбор исполнителя — всегда за архитектором, здесь исключений нет: он решает, делает сам или отдаёт кодеру. Я не могу оценить объём итогового кода, поэтому это решает архитектор, но критерии оценки даю я - у меня это недельные лимиты Сlaude. Декомпозицию ведём вдвоём с архитектором — кроме staffing, где её всегда делаю я сам, выполняя ещё роль продуктового аналитика.
Архитекторов три и они равны: Claude Opus, Kimi K3, Qwen 3.8Max. Один процесс на всех, личных зон нет. Кодер — DeepSeek в автономном цикле, круги внутри цикла считаю бесплатными, но после обновления стоимости дипсика в 20-х числах августа пересматриваю подход.
⛔ Задача = один исполнитель и один статус. Батч = один исполнитель. Если работу делают двое — это две задачи с разными номерами, а не одна задача в двух батчах. Правило выглядит формальным ровно до первого нарушения: у задачи с двумя исполнителями после первой приёмки некуда записать статус — она не сделана и не не-сделана, зависает, и через сессию никто не помнит, чья половина закрыта. Да и вам в целом гораздо сложнее контролировать прогресс.
2. Исполняемый гейт. Критерий приёмки — не «данные
отображаются корректно», а явный код, который проверит все связи, математику, ошибки и т.д. и потом напечатает ✅/⛔ по каждому пункту. Гейт
пишется до наряда. Батч без зелёного гейта архитектор не смотрит вообще - это позволяет не тратить много времени архитектора на бесполезные проверки; красный гейт — возврат
без разбора, потому что вывод гейта и есть список правок. Таким образом Deepseek делает, потом гоняет тесты, которые ему дали и перепроверяет сам себя.
Это выведено из двух наблюдений: дорого стоит не постановка задачи, а её приёмка; и зелёные тесты исполнителя ничего не доказывают — фикстуру пишет та же голова, что и код.
3. Данные, которые не врут. Строго запрещаю придумывать данные. Не знаешь — пусто плюс пометка, а не правдоподобное значение, ибо отсутствие данных видно, а выдумка этих данных - нет. У каждой величины источник и дата проверки. Также, если надо изучить данные, то запрещаю выдавать непрочитанное за прочитанное. В системах про деньги и здоровье это вообще база. Поэтому во всех разборах или анализе - ссылка на источники, конкретные цитаты и т.д.
4. Тесты, тесты и можно ещё тесты. Каждая фича и каждая бизнес-функция обязательно покрыта тестами: автотесты на фичи, E2E на бизнес-прогоны. Прогон после каждой задачи и каждого батча, а перед приёмкой с моей стороны — полный прогон всех тестов плюс E2E.
Плюс два правила, которые экономят больше всего: память агента хранит только состояние и правила поведения, вся фактура — в git; и считаем не деньги, а лимит — расход равен длине контекста, умноженной на число запросов, поэтому фаза равна сессии. Нет смысла говорить Claude "экономь вызовы", если у вас есть плавающее окно лимитов от Anthropic.
Подробно, с обоснованиями и ценой каждого правила — в CLAUDE.md.
Стек выбирал вместе с Claude и держу узким намеренно: чем меньше разных технологий, тем больше решений переносится между проектами.
Основной стек: Python 3.11–3.13 (uv) · FastAPI · SQLAlchemy / SQLModel + Alembic · Celery + Redis · PostgreSQL, TimescaleDB, SQLite · React 19 + TypeScript + Vite + Ant Design · Flutter.
Всё живёт в Docker. Тесты: pytest · Vitest · Playwright.
Железо — весь парк веду сам, вместе с Claude:
- MacBook Pro M5 Pro, 24 ГБ — основная рабочая машина, здесь идут все сессии архитекторов и кодера, отсюда же деплой (P.S. в планах убрать кодера на расчётный узел, чтобы бедолага работал 24/7)
- Расчётный узел — i9-12900K (24 потока), 94 ГБ RAM, ~5 ТБ NVMe, GPU Tesla V100 16 ГБ
(Tesla не задействована — в планах развернуть ИИ). Proxmox, Debian, Docker + TimescaleDB. База ~155–180 ГБ, свыше
1 млрд строк котировок (на 14.08.26). Постгрес затюнен под объём, бэкапы двухконтурные
(снапшот виртуалки +
pg_dump) с квартальным restore-тестом. Используется на 99% под сложную математику и накопление данных для проекта myTrade. - Торговый VPS — отдельная машина под боевого крипто-робота и ничего больше: расчёты и база остаются на узле. Латентность до брокера ~2.5 мс, настройка как код
- UAT-стенд — площадка приёмки релизного поезда, живёт на отдельной ветке; только под проект staffing
- Прод-стенд — боевой контур платформы: HTTPS, релиз одной командой, миграции по регламенту; только под проект staffing
- Сервер Telegram-ботов — общий на четыре проекта: systemd-таймеры и Docker, реестр подселения с портами и лимитами памяти, чтобы соседи не ломали друг друга
Инфраструктура настраивается как код — скриптами и раннбуками в репозиториях. Адреса, ключи и пути в этой витрине не публикуются.
| Файл | Что внутри |
|---|---|
| CLAUDE.md | ⭐ Главное. Общий свод правил: роли, гейт, данные, тесты, память, экономика. Рабочий файл — кладётся в корень репозитория и работает |
| AGENTS.md | Точка входа для не-Claude агентов и ориентир для кодеров |
| папки проектов | По каждому — описание системы и её собственный CLAUDE.md |
CLAUDE.md здесь намеренно полный — он показывает все правила и их основания. В боевом
проекте после обкатки его стоит ужать под себя: выкинуть неприменимое, часть перенести
в память агента. Как это делать — написано в самом файле.
| Проект | Что это | Масштаб | Статус | Основной ИИ-исполнитель (архитектор) |
|---|---|---|---|---|
| mytrade | Флагманский проект — алготрейдинг MOEX и крипта: три независимых движка, исследовательский конвейер стратегий с walk-forward и дефляцией. В будущем - построение алгороботов. | 623 коммита, 06–08.2026 | в активной разработке, идут первые боевые тесты | Fable 5 |
| staffing | Платформа подбора аутстафф-персонала: парсинг вакансий, скоринг кандидатов, чек-листы, аналитика ИТ-рынка. На данный момент расширяется в зеркальную сторону — подбор позиций для физических лиц за пределами аутстафф | 449 коммитов, 04–08.2026 | боевой прод, на стадии MVP и демо у клиента. Название изменено | Opus 5 |
| notifications | Микросервис для уведомлений: шаблоны, маршрутизация, журнал доставки. Спроектирован и собран под ключ — полноценное боевое решение | 143 коммита, 07.2026 | выведен в коммерческий контур, описание могу рассказать лично (не для репозитория) | Opus 5 |
| reports | Личная инвест-система: отчётности, новости, цены и портфель копятся в БД и в заданных ритмах превращаются в решения по эмитентам | 601 коммит, 06–08.2026 | работает, план развития идёт | Opus 5 |
| paperbirds | Ко-пилот моей музыкальной инди-группы: поиск площадок и опен-коллов, база контактов, черновики питчей | 207 коммитов, 07–08.2026 | функционал работает, реализовано ~30% плана | Qwen 3.8 Max |
| students | Ассистент наставника фулстек-аналитиков: планы студентов, разбор встреч, сборка резюме, SA-ревью | 46 коммитов, 06–08.2026 | работает | Opus 5 |
| scalping | Менторство от Claude по ручному скальпингу: тренажёр распознавания, автожурнал сделок, утренний скринер | 142 коммита, 07–08.2026 | ядро — обучение, инструменты вторичны, реализовано ~40% плана | Opus 5 |
| health | Личный мониторинг здоровья: заключения врачей, Apple Health и браслет в единой картине | 57 коммитов, 07–08.2026 | функционал работает, реализовано ~30% плана | Kimi k3 и Qwen 3.8 Max |
Плюс два проекта на ранней стадии, не описанные здесь: лидогенератор и CRM для дилера строительной компании и мобильное приложение ухода за растениями на Flutter.
- Код и данные не публикуются. Здесь только описания и правила работы агентов. Нужны детали — пиши в Telegram: @Basov_VA.
- Проектные
CLAUDE.mdприведены как есть, по-русски — это рабочие файлы. Секции про инфраструктуру и некие секреты вырезаны, места вырезов помечены. - Проценты выполнения — по моему плану развития. Функционал может работать целиком, а плана быть сделано треть.
- Лицензия — MIT. Берите отсюда что угодно: копируйте, меняйте, применяйте у себя, в том числе в коммерческих проектах. Ссылка на источник — приятно, но я её не требую.