Когда код подешевел: прототипы, OpenSpec и три тира валидации
Ключевые идеи
🪙 Код подешевел — узкое горлышко переехало в качество
Двадцать лет инженерных рефлексов натаскивали относиться к коду как к дорогому ресурсу: каждая строчка — обязательство, любую правку сначала продумать, отполировать, согласовать. Сейчас coding схлопнулся почти в ноль — 5 тысяч строк в день в нормальный день, 10–30 тысяч в активный. Большинство старых рефлексов мешают. Узкое горлышко переехало в две зоны: планирование и валидацию.
⚽ Прототипы вместо догадок: параллельные версии в отдельных репах
Запуск 2–3 версий прототипа параллельно вместо одного «правильного». Из пяти идей три выкидываете сами, две показываете коллегам, одна попадает в прод. Главное правило — в отдельных репозиториях, не в боевом. Иначе ваши черновики становятся для агентов «тут так принято» — и будущая генерация скопирует кривые паттерны.
🧭 Spec-driven workflow побеждает «один промпт в чатик»
Чатик ломается на сложности — миллион токенов лишь чуть отодвигает потолок. Нужен формат, который переносит знания между сессиями. OpenSpec структурирует: два предложения → proposal → дизайн → таски → apply. 8 из 10 пропозалов попадают в точку, 2 переделываются. Лишает удовольствия от «one prompt magic», но радикально сокращает потом валидацию и переделки.
🎯 Три тира систем — три радикально разных уровня валидации
Не все системы достойны одинакового внимания. Управление рекламными бюджетами клиента ($1K за 20 минут) — часы валидации, чтение кода, разные сценарии. Утренний дайджест клиентам — неприятно, если сломается, но не критично. Внутренняя админка — happy path, сломается — починим. Главный трейд-офф инженера сейчас: где не тратить своё время.
Ключевые выводы
🏎️ Качество = скорость. Не вложитесь в качество сегодня — через две недели потеряете в скорости. С этим слайдом можно идти к менеджеру, который требует «выпустим, потом починим».
📏 Время на валидацию — главная метрика. Не строки в день, не количество фичей. Сколько часов ушло на проверку, что код делает то, что нужно клиенту.
🚀 5 прототипов, выбрали 1 — это нормально. Только не в основной кодовой базе. Отдельные репы, переключение запросов между версиями, всё дёшево.
🏗️ Иерархия влияния на агента: Код > Скилы > CLAUDE.md. Что в коде написано, то агент и повторит. Скилы поверх — стандартные операционные процедуры. CLAUDE.md проигрывает первым двум.
🔄 Дрифт — это норма. Раз в неделю — анализ дубликатов, размера файлов, security-сканы. Поймали 8 реализаций одного и того же — добавили шаг полного скана базы перед каждой новой фичей.
🧪 Если агент не может запустить тесты — он их не запустит. Замокайте всё: базу, внешние системы. Цель — чтобы 20-минутный прогон спеки шёл без «ты сам запустишь».
🏷️ Три места, где Миша всё ещё читает код. Расчёт бизнес-метрик, управление бюджетами, изменения денежных потоков. Всё остальное — happy path и автоматизация.
Ресурсы
Spec-driven kits
OpenSpec — github.com/Fission-AI/OpenSpec — Основной spec-driven framework в нашей работе. Полный workflow: docs/workflows.md (/opsx:propose → /opsx:apply → /opsx:archive).
GitHub Spec Kit — github.com/github/spec-kit — Альтернативный SDD-кит от GitHub.
Где начать со скилами
sdx-project — github.com/xomyakus/spec-native-skills/tiles/sdx-project — Мой скил для запуска проекта с нуля: даёшь абстрактное описание, получаешь готовый каркас со спеками, roadmap и параллельными фазами.
Agent Skills (Addy Osmani) — github.com/addyosmani/agent-skills · объяснение в блоге — Подборка скилов с хорошим вводным разбором.
Tessl — tessl.io — Платформа со скилами + evals. Отвечает на вопрос «добавляет ли мой скил реальную ценность».
skills.sh — skills.sh — Реестр скилов.
Готовые скилы по областям
Frontend — anthropics/skills/frontend-design — официальный набор от Anthropic для дизайна интерфейсов.
UI/UX Pro Max — ui-ux-pro-max-skill.nextlevelbuilder.io — Наш любимый скил для дизайн-систем: 67 стилей, 96 палитр, 57 типографических пар. Делает результат, который не выглядит как дефолтный Claude UI.
Backend / full-stack — jeffallan/claude-skills — 66 скилов для backend и full-stack разработки.
Spring Boot kick-off (Baruch) — tessl.io/registry/jbaruch/spring-boot-4 — Отличный стартер для Spring Boot 4 от Baruch.
Security — trailofbits/skills · anthropics/claude-code-security-review · getsentry/skills — секьюрити-скилы от Trail of Bits, Anthropic и Sentry.
Testing — addyosmani/agent-skills — там же лежат test-driven-development и debugging-and-error-recovery.
Каталоги скилов
anthropics/skills — github.com/anthropics/skills — официальный набор от Anthropic.
awesome-agent-skills — github.com/VoltAgent/awesome-agent-skills — курируемая подборка 1000+ скилов.
Claude Skills Directory — claudemarketplaces.com/skills — публичный каталог.
Сообщество
Блог Миши — t.me/xomyakus_blog — Канал про системы, AI для больших систем, менеджмент и здравый смысл.
Чат блога — t.me/xomyakus_blog_chat — Обсуждения постов с канала.
Основные моменты
[0:00] 🎯 Контекст: $1K за 20 минут — цена ошибки в маркетинге
Finsi — AI-маркетинг-команды для B2C. Клиенты тратят $1K–6K в день, крупные — $1K за 20 минут. Любая ошибка стоит реальных денег + упущенные клиенты. Двое за три месяца переписали платформу — то, что «команда из десяти человек делала бы как минимум год». Параллельно продавая клиентам. Архитектура: UI-монолит + куча микросервисов.
[0:03] 🪙 Код подешевел, валидация подорожала
От 100 строк/день к 5000 в день — большинство 20-летних рефлексов не работают, «а какие-то начинают мешать. Мы привыкли ходить, а тут какие-то сверхзвуковые скорости». Узкое горлышко переехало: больше не coding, теперь планирование и валидация. Никто не читает код. «Год назад за то, что я сейчас буду говорить, я сам себя бы и уволил».
[0:06] ⚽ Прототипы: детский футбол vs параллельные эксперименты
Большинство в чате — это детский футбол: «все носятся за мячиком, орут, визжат — интересно, но результат не всегда такой, как хотелось». Альтернатива: 2–3 версии прототипа параллельно. Из 5 идей — 3 выбрасываете сами, 2 показываете коллегам, 1 идёт в прод. Главное условие: прототипы в отдельных репах. Иначе агент решит — «тут хреновенько написано, значит так здесь принято» — и будет повторять.
[0:11] 🔧 Скилы: SOP для запуска проектов с нуля
Стартовый шаблончик с настроенным фронтом, бэком, базой, тестами — это скил. Кидаешь абстрактное описание → получаешь готовый каркас. Реестры: tessl, skills.sh. Один из микросервисов запустили на Rust — потребляет 5 МБ памяти вместо тяжёлой альтернативы. «Кто ещё не разобрался со скилами — вы теряете такое количество времени, что это уже начинает быть криминалом».
[0:14] 🧠 Куда уходит время: два горба вместо одного
Раньше большая часть времени — на исполнение кода. Сейчас исполнение ~5%. Время распределилось на два горба: планирование и валидацию. Без планирования платишь двойную цену — переделкой. «У него уже есть контекст, который тащит его в определённую цель». Plan mode работает до определённого порога — дальше нужны спеки.
[0:17] 📝 OpenSpec: proposal → design → tasks → apply
Два предложения на вход — получаешь proposal: вот как это будет реализовано в твоей системе. 8 из 10 попадают в точку. 2 — «ты меня неправильно понял». Дальше дизайн, потом таски. Уменьшает радость от «одного промпта в чатик», но радикально сокращает потом валидацию. Эмпирическое правило: «одна спека ≈ 5К строк кода ≈ месяц-два работы старого разработчика». Не пережимайте: если детализировать всё, начнёте «программировать на английском языке».
[0:22] 🗃️ Кастомизация: Data Model как отдельный шаг
Поймали кейс — агент креативно сделал модельку: пять credentials в одной строке таблицы вместо пяти строк. Добавили отдельный шаг в OpenSpec — генерация модели данных перед кодом. Каждая команда находит своё узкое горлышко и втыкает туда шаг. Спеки работают в обе стороны: из кода → текст для legacy и прототипов, из текста → код для нового функционала. «LLM очень хорошо умеет читать код и обобщать его».
[0:26] 🚀 Raptor 1 → 2 → 3: альфа, бета, продакшн
Подход украден у Маска. Первые Raptor-движки выглядели страшно — все ракет-инженеры говорили «эта штука не будет летать». Зато быстро проверили гипотезы. Потом вторая версия лучше, третья — production. Это работает в софте: альфа собрана на коленке, но end-to-end. Бета — лучше по перформансу. Релиз — полноценный продукт. Не пытайтесь сделать идеально с первого раза.
[0:30] 🎯 Матрица критичности: 3 тира — 3 уровня валидации
Управление рекламными бюджетами и онбординг клиентов? Ломать нельзя. Часы валидации, разные сценарии, чтение кода. Утренний дайджест клиентам? Неприятно, но не смертельно. Сломалось — починили, потратили чуть-чуть эго. Внутренняя админка, дашборды? «Их очень много. Туда тратить время на валидацию вообще не имеет смысла». Сделали → используется → когда сломается, починим тогда. С чего начать применять SDD: tier 3, потом tier 2, потом tier 1.
[0:35] 🏗️ Иерархия влияния: Код > Скилы > CLAUDE.md
Самый сильный сигнал для агента — ваш код. Дальше скилы — SOP-процедуры. CLAUDE.md в каких-то проектах «практически не существует — два верхних этажа его настолько переопределяют, что заставить использовать правила из CLAUDE.md невозможно». Поэтому прототипы и микросервисы в отдельных репах: иначе агент скопирует плохой паттерн. Чистый код сегодня предотвращает плохую генерацию завтра.
[0:38] 🔄 Дрифт и Inventory step: 8 реализаций одного и того же
«Чиним один баг — починилось. Смотришь — а тут не починилось. На третьей итерации спрашиваю: почему мы три раза это чиним? — Смотри, у тебя в коде восемь реализаций». LLM оптимизирует для скорости и срезает углы: проще написать заново, чем найти существующее. Добавили в OpenSpec шаг — полный скан кодовой базы на reuse перед реализацией каждой новой фичи.
[0:41] 🧪 Тесты, моки и почему LLM «забудет запустить»
Полная пирамида тестирования, соотношение код:тесты ≈ 1:2. Замокали внешние системы — базу, интеграции. Зачем? Если агент не может запустить какие-то тесты, он скажет «я тебе оставила запустить» — и реализация падает в качестве. Цель: за 20 минут спека крутится с автоматическим прогоном всех тестов. «Большую часть времени я чувствую себя как manual QA more and more advanced, который автоматизирует сам себя».
[0:44] 🎁 Итоги и домашка до понедельника
Качество стало скоростью. Главная метрика — время на валидацию. Три места, где Миша всё ещё читает код: расчёт бизнес-метрик (потеря доверия клиента в 10× дороже всего), управление бюджетами, изменения денежных потоков. Все остальные узкие места — в workflow кодогенератора, не в выговорах коллегам: «Вместо магического промпта “make no mistakes” — оно должно оказаться в workflow вашего кодогенератора». Домашка: возьмите небольшой микросервис или давно отложенный функционал — попробуйте через спеку.
Q&A: Вопросы и ответы
🧪 Скилы и evals 🔗
Как тестировать скиллы у агентов? Нужно же по несколько раз одну и ту же задачу запустить со скилом и без него, чтобы получить воспроизводимые результаты?
Именно так. И это делает Tessl — запускает задачу со скилом и без него, повторяет много раз, сравнивает результаты. «Правильный harness для evals скилов — это ещё та чёрная магия. Поэтому сами туда не лезем, используем Tessl». Без таких сравнений ты просто веришь, что скил работает. Часто выясняется, что не работает — скил может выглядеть отлично на бумаге и ничего не менять в поведении агента.
Как именно проверить работу скилла? Что именно скилл привнес в кодогенерацию, как это оценить, не запуская оба варианта (с и без)?
Без A/B — почти никак, в этом и боль. Можно посмотреть, упоминается ли скил в reasoning агента, изменилась ли структура выхлопа, попадает ли результат в ваши конвенции — но это всё прокси. Реальный сигнал даёт только сравнение «с» и «без» на одинаковом промпте. Поэтому evals — не оверкилл, а минимальная гигиена для скилов в проде. Когда у тебя 30 скилов, без этого через месяц не отличишь полезные от мёртвого груза.
Насколько полезны автоматически сгенерированные скиллы? Скилы хорошо себя показывают, когда они составлены людьми и провалидированы экспертами.
Не соглашусь с тезисом. Большой скил руками уже не напишешь — это не реалистично. Реалистичный pipeline: сгенерировать draft, посмотреть, что получилось (тот же raptor 1 → 2 → 3), потом итеративно улучшать через evals в Tessl. Скил пишется за десять минут, evals занимают столько же. Эта самая презентация для Podlodka — собрана AI-скилом, включая манипуляции с картинками. Не идеально, кое-что руками поправил, но без скила собирать бы пришлось часа три вместо двадцати минут. Эксперт всё ещё нужен, но не на генерации, а на постановке задачи и валидации.
📋 OpenSpec и спецификации 🔗
Учитывает ли OpenSpec этап дистилляции мыслей?
Да, через режим Explore. Это для моментов «ни черта не знаю, что хочу делать»: чатишься с агентом полчаса-час, он гуглит, смотрит код, находит индустриальные решения. Потом весь этот контекст сжимается в один пропозал — и ты стартуешь свежий чат без багажа неудачных идей. По сути — rubber duck + deep research с финальным артефактом, который кладётся в OpenSpec и идёт дальше по pipeline. «Забывать — очень хороший скил».
Не переносится ли время разработки в чтение спецификаций?
«Сами spec-файлы я редко читаю. А вот пропозал и дизайн — в большинстве случаев да. За что люблю OpenSpec по сравнению со SpecKit — он более немногословный. Три странички документов читаются за пять минут». Чем дороже стоит фича в случае ошибки, тем больше времени уходит в спеки. Но в сумме выигрываешь: 50 строк proposal + 100 design + 200 task намного быстрее читаются, чем 30 файлов сгенерированного кода без структуры. Плюс ревьюит специфики в основном AI через скилы (drift detection, duplicate finder, complexity checker) — руками читаю только в трёх местах, где цена ошибки в деньгах клиента. На code review уходит 20-30 минут на спеку — против дней, которые ушли бы на reverse-engineering без неё.
Осторожно: фаза проектирования у меня сильно выросла. «У меня на столе пачка A3-листов с диаграммами — сложность системы уже не держится в голове». Сделали себе скилы, которые автоматически иллюстрируют части системы — потому что архитектурные диаграммы вручную с такой скоростью не обновишь. Когнитивная нагрузка растёт без шуток.
Что вы делаете со спеками после реализации? Читает ли их агент? Сжимаете ли их, чтобы не разрастались?
Это вторая вещь, за которую люблю OpenSpec — разделение на change (proposal, design, tasks — это «скаффолдинг, который вокруг здания, пока строят») и spec (живая карта системы). После реализации делаешь archive — change уезжает в отдельное место для истории, а delta из спек применяется к общей карте. Спеки нужны агенту именно как карта: он сначала смотрит туда, понимает, что меняет, потом идёт в код. На миллионе строк без этого начинает пропускать места.
Тёплая история про спеки как навигатор: я сделал себе отладочный экран daily agenda — для дебага данных, чисто для себя. Cofounder реализовывал новый функционал — агент сам нашёл эту страничку через спеки и предложил добавить туда новую секцию. Cofounder написал: «у нас оказывается такая страничка есть». Я даже забыл про неё. Агент нашёл, улучшил, клиенты пользуются.
Как бороться с расхождением спеки при постоянных доработках кода?
Никак. Точнее — OpenSpec обновляет текущие спеки автоматически: change-дельта применяется к общей карте при archive. Иногда забываем — увлёкся, допинал чатик до решения, ушёл слишком далеко от изначальной спеки. Тогда ретроспективно: «давай теперь по текущему чатику спеки обновишь, которые сейчас менял». Можно гонять отдельный скил, который проверяет drift, — делали пару раз, ничего криминального не вылезло. Подход прагматичный: где ломается — там фиксим, где не больно — пусть живёт.
🧠 Команда, нагрузка, стоимость 🔗
Возросла ли когнитивная нагрузка на разработчика или, наоборот, стало легче?
«Сильно возросла. Намного сильно возросла». В день, когда делаешь условные 30K строк, после него ты овощ. Раньше две недели на тот же объём — сходил кофе попил, чуть-чуть подумал, ещё кофе. Теперь думаешь пять часов подряд без перерыва. После такого дня иду трогать травку — «рекомендую хобби, спорт, что угодно. Помогает не выгорать». И это не про «AI заменит разработчиков». Наоборот: AI поднял планку — теперь все могут так делать, появляются новые требования, потребление растёт. Это Jevons paradox в чистом виде: чем больше ресурса, тем сильнее модель потребления раскручивается.
Какой размер команды разработки в компании? Есть ли разделение по ролям?
Двое. И это команда разработки, команда продаж, команда devops, HR, финансы — всё сразу. Внутри автоматизировали с AI-агентами всё, что можно: агенты собирают финансовые модели, вытаскивают инсайты из звонков с клиентами, смотрят, как мы продаём, и дают советы, где лучше или хуже. Параллельно ещё разрабатываем. Двух человек хватает на проект размером с 600K+ строк, на нескольких клиентских аккаунтах с реальными рекламными бюджетами. У ребят из моего круга AI-native-команд та же арифметика: 2-3 человека делают то, что год назад делалось командой из десяти.
Опасаетесь ли вы vendor-lock от Anthropic / Claude?
Опасаемся не vendor-lock, а нерабочих API: «у тебя API иногда не работает, у тебя приложение не работает из-за этого. Вот как с этим жить?» Поэтому для агентов в проде используем OpenRouter — можем за дёшево переключиться с Anthropic на Gemini. Регулярно пробуем все модели: Claude Opus, Gemini, Codex. «Они очень по-разному работают. На нашем объёме Opus работает лучше. Когда нужен хирургический метод — Codex показывает охрененные результаты». Если Anthropic в какой-то момент скажет «извините, дороже в 10 раз» — «это не будет vendor-lock, оно просто в 10 раз дороже начинает стоить. Окей, хорошо, мы пойдём». Tessl нам помогает иметь переиспользуемые скилы между всеми агентами — это и есть страховка.
Насколько AI дешевле / дороже разработчиков?
$200 подписки Anthropic на двоих хватает. «Мы пытались one-shot-ить с подписками — токены улетают в трубу. С OpenSpec на том же проекте упор в лимит не получается». Закладываюсь: через год та же подписка будет стоить $1K — но не потому что цены поднимут, а потому что следующая модель ест в 10 раз больше токенов, а на предыдущей уже работать не захочется. Enterprise по API уже сейчас дорого — но там покупаешь скорость: ответ за 5 минут вместо 20 (fastmod, в два раза дороже). На двоих мы по сути не наняли 5-6 разработчиков — «сэкономили от полумиллиона до миллиона долларов за год». Но это не «AI дешевле разработчика». Это AI расширяет возможности сильного инженера, и в командах, которые умеют им пользоваться, «потребность в сильных инженерах стала намного-намного больше».
И последняя мысль про рефлексы и стоимость: «Каждый раз думаешь — блин, это дорого будет. Потом — три промпта, и оно уже получилось. А не дорого. А можно ещё круче? Блин, ещё круче — и не дорого. Это, наверное, самый основной рефлекс, который приходится постоянно перепрошивать в себе. Быстро, недорого».