КупилиClaude.Команданепоменялась.
Прикладной фреймворк для CTO и фаундеров. AI-driven — это способ работы, а не набор инструментов. Какая среда позволяет ему масштабироваться, какая нет, и как форма команды меняется вокруг.
Большинство лидеров останавливаются там, где начинается настоящая работа
Даёшь сильному разработчику Claude Code. Первая неделя ощущается как суперспособности. Задачи, которые раньше отнимали полдня, делаются за двадцать минут. Рефакторинги, к которым никто не прикасался два года, тихо случаются за выходные. Тесты пишутся. Описание к PR пишет себя само.
Вторая неделя такая же. К концу месяца этот разраб выкатывает где-то в 2–4 раза больше, чем выкатывал до — по lead time на задачах, которые он ведёт end-to-end, не по LOC и не по числу PR. Все счастливы. Ты уже рассказываешь другим CTO, что «раскатали AI».
А потом плато.
Тот же разраб всё ещё в 2x. Команда вокруг — нет. Джунам тоже дали Claude, и они выкатывают код, который работает, но никуда не вписывается. PM по-прежнему пишет PRD в Confluence, который агент никогда не читает. QA по-прежнему ручной прогон в конце. Постмортемы по-прежнему складываются в папку Notion, которую никто не открывает. Один человек научился управлять агентом. Среда вокруг него не успела.
«Купили Claude Code на всех. Через месяц пришли — почему ничего не поменялось?»
Если PRD живут в Confluence и обновляются раз в неделю, архитектура только в чьей-то голове, QA — ручной прогон после фичи, а скиллы у каждого в своих чатах, никакой Claude Code не спасёт. Он ускорит то, что работает. Бардак ускорит тоже.
Это место, где большинство компаний останавливается. Обычный вывод — «AI работает не для всех ролей» или «вернёмся к этому в следующем году». Ни то, ни другое — не правда. Среда у тебя всё ещё та, что была до Claude, и Claude теперь — единственное, что в ней сдвинулось.
Инструменты — это лёгкая часть. Среда вокруг них — это и есть работа. Всё ниже — про то, как её построить.
Три убеждения, которые команда должна реально разделять
Без них ничего из следующих разделов не держится. Если по какому-то реакция команды «согласны теоретически», туда и надо возвращаться до того, как раскатывать процессы.
- 01
AI — рабочий инструмент для каждой роли
Продукт, разработка, QA, аналитика, дизайн. Если AI «только для разрабов», половина боттлнеков остаётся на месте, а вторая половина просто переезжает в очередь к девам.
- 02
Решают скиллы и контекст, а не модель
90% плохих результатов AI — нехватка контекста, не слабая модель. Экспертиза команды должна жить в коде: скиллы, спецификации репо, ADR. Тогда агент подхватывает её сам.
- 03
Лидеры строят среду
Сеньоры тратят время на платформу, скиллы и конвенции, которые делают мидлов и джунов быстрыми. Они перестают быть лучшими индивидуальными контрибьюторами. Они становятся причиной, по которой остальные могут ими быть.
Где агент тебя не спасёт
До того как строить среду — назвать, что она не починит. Какие-то категории работы агент всё ещё делает плохо. Притворяться обратным — это как выкатывать медленный код и жить с ним.
Год назад я писал про маленький трюк, который мы придумали: быстрые SELECT-ы поверх миллионов смарт-контрактов с постоянными апдейтами в ClickHouse. Подробно тут не пересказываю; суть в том, что мы обошли очевидный подход с GROUP BY / FINAL полностью.
Недавно проверил, дойдёт ли Claude до того же решения, если вести его за руку по той же логике. Не дошёл.
Чётко проявились три закономерности.
- По умолчанию агенты пишут то, что работает, а не то, что работает хорошо.Тянутся за GROUP BY, FINAL, JOIN-ами, очевидной формой. Про производительность нужно отдельно напоминать. Если не напомнить — получаешь то, что проходит тесты и жжёт CPU.
- Когда указываешь на проблему, оптимизируют текущий путь, а не предпосылку.Тыкаешь в проблему в решении — агент крутит текущее решение. Не отшагивает и не спрашивает, нужна ли вообще эта операция. У меня в сессии Claude защищал свой GROUP BY вместо того, чтобы спросить — а можно ли без него?
- Если про это ещё никто не писал — новое решение не подберут.Агенты крутятся вокруг канонических паттернов. Что-то реально новое, трюк на пересечении свежей фичи и нестандартного использования, сами они не найдут.
Главное ограничение. Я могу применить известные паттерны к новой задаче, но изобрести новый паттерн на пересечении свежей фичи и нестандартного использования — это получается реже, чем хотелось бы.
— Claude, на вопрос, почему не дошёл до нашего решения
Не забывай включать свою голову. Везде, где оптимальное решение лежит в стороне от протоптанных троп (дизайн запросов на странной форме данных, нестандартная concurrency, тонкая работа с криптопротоколами, перформанс на системах, к которым стандартные советы не подходят), агент выдаст тебе то, что работает, а не то, что хорошо. Поймать разницу — на тебе.
Среда, которую строят лидеры
Что лежит рядом с кодом, как это организовано, правило script-first и старые фундаментальные вещи, на которых всё ещё держится система. Это лейаут, который я гоняю в Hexens и Trenda. Одна и та же форма работает в обоих. Две команды, обе меньше сотни человек, обе с культурой разработки, которая двигается. На 500-человечном enterprise legacy с зарегулированным compliance те же принципы работают, но календарь растягивается и политическая поверхность меняется — это другой документ.
Три типа репо держат всю трансформацию
У каждого своя роль и свой потребитель. Вместе они — субстрат, на котором работает AI. Это то, что лидер собственно строит.
feature-id идёт через все три репо. Взял в product-docs, нашёл в скиллах, видишь как ложится в сервисные репо.
Что лежит в каждом коде-репо
Одно репо на сервис: backend, frontend, mobile, infra. Субстрат, в котором собственно работает агент. У каждого одна и та же форма, чтобы агент не переучивал лейаут при переключении.
<service-name>/
├── AGENTS.md # правила для агента: что можно,
│ # что нельзя, что проверить
│ # перед мержем. Указывает на
│ # платформенный скилл — агент идёт
│ # по ссылкам, когда нужно глубже.
│ # → skill: <stack>-platform
├── docs/
│ ├── README.md # обзор сервиса: для чего, owners,
│ │ # как поднять, зависимости
│ └── features/ # локальные заметки фич
├── src/
└── tests/AGENTS.md — точка входа: тонкий указатель на платформенный скилл. Сам скилл линкует дальше на code-style, конвенции, либы; агент идёт по этим ссылкам только когда нужны детали. Поменял конвенцию один раз в платформенном скилле — все сервисные репо подхватили. docs/ — для того, что относится только к этому сервису; сквозные вещи живут в product-docs.
Платформа, которая превращает интент в доставку
Центральный артефакт трансформации. Скиллы — это как человек просит. Агенты — это кто тащит работу за ними. Между ними сидит MCP. Внутри каждого агента: куча скриптов, которые делают примерно 90% реальной работы.
ai-platform/
├── skills/ # точки входа для человека
│ ├── new-task/ # PM / аналитик → новая задача
│ ├── be-task/ # backend разраб → реализация
│ ├── fe-task/ # frontend разраб → реализация
│ ├── review/ # ревью PR
│ ├── test/ # генерация и прогон тестов
│ ├── deploy-stg/ # деплой на staging
│ └── release/ # релиз в прод
│
├── agents/ # фактические исполнители,
│ │ # скиллы общаются через MCP
│ ├── product-review/ # ↔ new-task
│ │ ├── README.md
│ │ └── scripts/ # ~90% работы агента
│ ├── developer/ # ↔ be-task, fe-task
│ │ └── scripts/
│ └── review/ # ↔ review
│ └── scripts/
│
└── mcp/ # MCP-серверы между скиллами и агентамиСкилл — это интерфейс («новая задача», «сделай ревью»). Агент — исполнитель. MCP — протокол между ними. Внутри агента: скрипты, а не промпты, для всего детерминированного. Агент выбирает скрипт, запускает, возвращает результат. Это то, что держит систему стабильной и дешёвой.
Конкретный пример как это работает у нас: new-task не просто пишет PRD. Он ещё оценивает, простая ли задача — может ли быть полностью реализована агентом end-to-end. Если да — в Jira создаётся тикет с лейблом agent, и developer-agent сам подхватывает его. Большинство простых фиксов едут в прод без того, чтобы человек касался реализации. Подробнее — в Script-first ниже.
PM → skill:new-task → agent:product-review
↓
скрипты: читают PRD-шаблон, сканируют код,
находят связанные фичи, формулируют вопросы
↓
обратно к PM: уточняющие вопросы
↓
PM отвечает → агент коммитит PRD в
product-docs/features/<id>/prd.md
↓
в трекере создаётся тикетПример flow для скилла new-task. Без скриптов это open-ended чат; со скриптами — детерминированный путь.
Общий слой знаний
Одно репо на продукт, <product>-docs. Источник правды, который читают и люди, и агенты. То, чем Confluence пытался быть, но не стал.
<product>-docs/
├── README.md # карта продукта: что это, owners, slack
│
├── architecture/
│ ├── overview.md # высокоуровневая картина
│ ├── services/ # карточка на каждый сервис
│ │ └── <service-name>.md
│ ├── flows/ # сквозные сценарии
│ └── adr/ # архитектурные решения
│ └── 0001-<title>.md
│
├── features/
│ └── <feature-id>/ # папка на фичу,
│ │ # имя — ID из трекера
│ ├── prd.md
│ ├── architecture.md # что строим, как
│ ├── tests.md # критерии приёмки / e2e
│ └── decisions.md # развилки и почему пошли так
│
├── tests/
│ └── e2e/ # сквозные тесты живут с доками
│
└── glossary.md # термины продукта<feature-id> — это стержень. Один и тот же ID живёт в трекере, в именах веток всех сервисных репо и в этой папке. Когда агент берёт HEX-1234, он читает features/HEX-1234/prd.md и идёт прямо в нужную ветку в каждом сервисном репо. Никакой ручной сшивки контекста.
Не заставляй агента делать то, что мог бы сделать скрипт
Правило, которое тихо решает, останется ли твоя среда стабильной, быстрой и недорогой. Или нет.
Правило: всё, что может сделать детерминированный скрипт, делай скриптом. Проверки, лукапы, трансформации, фан-ауты, верификации. Агента вызывают для того, что скрипт не покрывает: суждение, неоднозначная интерпретация, многошаговое рассуждение по незнакомой территории. Я этот тезис разбирал раньше — со стороны стабильности (скрипты не галлюцинируют; агенты — да). Anthropic выпустил статью в 2025, которая приходит к тому же выводу с другой стороны: токены. И там цифры — это то, на что стоит посмотреть.
Когда агент подключён к десятку MCP-серверов, все описания инструментов грузятся в контекст сразу. Это сотни тысяч токенов до того, как агент увидел твой запрос. Дальше хуже: каждый промежуточный результат тоже идёт через модель. Попросил агента достать транскрипт из Google Drive и положить в Salesforce — и весь этот транскрипт проехал через контекст дважды. Просто чтобы переложить из одного места в другое.
Их решение то же самое: пусть агент напишет скрипт, который дёрнет нужные тулы за один проход, отфильтрует данные на месте и вернёт только то, что нужно. До/после:
Одна и та же задача, со скриптом и без. Конкретные числа варьируются; порядок — нет.
Получается, script-first решает не только стабильность. Это стабильность плюс скорость плюс стоимость. Чем больше шагов уходит в код, тем меньше модель угадывает и тем меньше токенов гоняется туда-сюда без дела.
JetBrains Air оформили это конкретно в своём agentization cookbook. Весь путь верификации лежит в одном скрипте, verify.sh. Один запуск, каждая проверка, которой не нужна модель: линт, типы, тесты, билд. Рядом — Task Briefs в docs/agent/tasks/<id>.md: скоуп, критерии приёмки, план верификации, всё это пишется до старта. Если используешь superpowers, эта часть приходит из коробки. Туда же добавляются стоп-условия: агент эскалирует при изменениях в auth, в схеме БД, на диффе больше 500 строк.
Это один из вариантов. У каждой команды будет свой. Дело не в раскладке директорий. Дело в том, что агент никогда не должен угадывать, можно ли мерджить PR. Должен быть скрипт, который отвечает.
Скучные вещи всё ещё выигрывают
Old-but-gold практики, которые каждая команда использовала десять лет назад и почему-то перестала, как только AI начал писать код.
Есть момент, который повторяется на продуктах, которые я строил с нуля с агентом в роли основного исполнителя. Агент уходит в бесконечный цикл, пытаясь найти баг. Пробует одно, пробует другое, упирается в ту же стену. В какой-то момент я просто сдаюсь и иду читать код глазами.
Причина обычно не в агенте. У продукта нет логов. Нет request ID. Нет audit trail кто что делал. Нет понимания, в каком состоянии была база, когда пришёл запрос. Агент пытается рассуждать про чёрный ящик, и чёрный ящик выигрывает.
Всё, на что твоя команда опиралась до AI, всё ещё несущее после AI. Логи, request ID, action trail, feature flags, трейсы. Скучные базовые вещи. Подумай, что помогло бы тебе в последний раз, когда ты дебажил в два часа ночи. Положи это в код, потом скажи агенту, что оно там есть. Новые инструменты усиливают систему; они не заменяют её фундамент.
Как команда движется каждый день
Как команда в такой среде реально работает в течение недели. Две части: ритуалы, которые не дают принципам дрейфовать, и тот четвёртый этап, про который мало кто говорит, благодаря которому среда компаундит.
Пять вещей, которые стали ритуалом
Ничего из этого не зависит только от инструментов. Каждый ритуал существует, чтобы какой-то принцип не сползал тихо обратно к старому укладу.
- Канбан внутри кварталаПоток вместо спринтов. Квартальное планирование остаётся для крупных ставок и направлений; внутри квартала катим, когда фича готова, а не когда срабатывает спринт-таймер.
- Каждый разраб — фича-оунерОт PRD до прода, через все сервисы, которых фича касается. Нанимаешь за ownership, не за стек. Стек учится за недели; ownership — это диспозиция.
- Время на ресёрч — рабочее, шеринг обязателенВремя на изучение AI-инструментов, чтение доков Anthropic или эксперименты с open-source скиллами — выделенное, не отжатое у вечеров. Пятничный демо (тридцать минут, что зашло, что нет) — это где цикл замыкается. Ресёрч, который не вернулся в команду, — невидимый.
- Сначала автоматизируем мелочьAI делает дешёвым скриптовать скучные вещи: PR-лейблы, release notes, саммари дежурств, апдейты зависимостей. Это те места, которые выжигают сеньоров, и первое, к чему команда должна притронуться в первую неделю.
- AI-ревью до человеческогоПервый проход — агент по скиллу ревью. Человек ревьюит уже подчищенный PR, тратя циклы на архитектуру и интент, а не на стиль и тривиальные ошибки.
Четвёртый обязательный этап
После сложной задачи — особенно после особенно мерзкого бага — я прошу агента нормально всё это задокументировать. Что конкретно сделали. Какие были неочевидные моменты. Почему вообще появился баг. Как не наступить на те же грабли в следующий раз.
То, с чем ты остаёшься после хорошо решённой задачи — это не только код. Это понимание того, как ты к нему пришёл. Это тоже артефакт.
Классический цикл разработки — plan → implement → review. Есть четвёртый этап, который стоит держать как обязательный, его часто называют «compound engineering»: после того как задача сделана, записать что выучили, чтобы система это получила в следующий раз.
Эффект не виден сразу. Но со временем, после каждой задачи, среда вокруг команды становится лучше. Тихо, без того, чтобы кто-то ставил квартальную цель «улучшить среду»:
- решение сохранено рядом с кодом, а не в чьей-то голове;
- что сработало и что нет — записано;
- переиспользуемые выводы вытащены в платформенный скилл;
- внутренние правила и паттерны для агентов обновлены;
- добавлены проверки, чтобы тот же класс багов отлавливался автоматически.
Каждая сложная задача в итоге улучшает и продукт, и саму систему, которая его делает. Именно это превращает среду в компаундящую, а не деградирующую.
Не добавляешь метрики. Меняешь вопросы, которые задаёшь.
Внедрение AI меняет, какие числа вообще что-то значат. Ни одного из очевидных (строки в день, PR в день) в списке нет. Три угла, на которые стоит смотреть.
Среда реально становится лучше?
Эти числа говорят, что compound engineering работает — или превратился в ритуал, в который никто не верит. Первая — главная: это и есть compound-тезис в измеримой форме.
- Постмортемы, которые закрылись обновлением скиллаИз всех постмортемов — какая доля реально вылилась в коммит в скилл или новую автоматическую проверку. Меньше половины — значит compound-этап протекает. Документ написали, но обучение не вернулось в систему.
- Lead time на фичуОт закоммиченного PRD до фичи в проде. Падает квартал к кварталу — система компаундит. Стоит на месте — compound это театр.
- Возвратность баговКак часто класс багов появляется снова после того, как постмортем сказал «больше не будет». Около нуля — постмортемы доходят до скиллов. Что-то ещё — апдейт скилла не случился.
- Time-to-productive для нового джунаСколько дней от старта до первой выкаченной фичи. В зрелой среде это недели, а не месяцы. Платформенный скилл учит агента тому, что иначе заняло бы три сессии парного программирования.
А агент в принципе нормально пишет?
Угол, который большинство команд пропускают — и место, где тихо проваливается большинство внедрений. Эти числа говорят, делает ли платформенный скилл реальную работу или просто лежит в папке.
- Bug rate: AI-код vs человеческийЕсли у AI-кода больше инцидентов, чем у человеческого — твои скиллы не несут достаточно конвенций. Если показатели примерно равны или AI выигрывает — платформа работает.
- Раунды ревью до мержаСколько раз PR катают по комментариям, прежде чем смержат. AI-проход ревью должен опускать это в среднем до одного человеческого раунда. Несколько человеческих раундов — скилл ревью требует работы.
Что перестаём мерить, что начинаем
AI меняет, какие числа вообще что-то значат. Какие-то старые метрики тихо перестают нести сигнал. Какие-то новые становятся теми, что проверяешь в понедельник утром.
- Перестаём: строки в день, PR в деньЭто были прокси для индивидуального вывода. AI их сломал. Сеньор, который пишет один PR в неделю с глубоким архитектурным импактом, на таких дашбордах выглядит слабо. Просто перестаём ими пользоваться.
- Начинаем: time-to-first-PR для новыхСколько времени проходит от принятого офера до замерженного кода. Чем быстрее становится — тем лучше среда онбордит людей, а не только агентов.
- Начинаем: cycle time на кросс-функциональные решенияОт вопроса со стороны продукта до ответа, легшего в PRD. Коротко — петля между PM-через-агента и разработкой плотная. Длинно — где-то в цепочке всё ещё нужен человек-переводчик.
Что меняется в орге
Структурные сдвиги, которые возникают как следствие первых разделов. Downstream-эффекты, не отдельные инициативы — то, что мы видим возникающим на нашем масштабе, а не закреплённая норма индустрии. Лейаут репо и скиллов из §04 прогнан в реальности; то, что ниже, — направление, на которое всё остальное нас выводит.
- Ценность смещается от индивидуального вывода к строительству средыЕсли всё, что ты делаешь — это используешь Claude или Cursor, чтобы выкатывать быстрее, ты теперь конкурируешь с сотней таких же. Порог «быстро что-то сделать» падает очень быстро. Те, чьё влияние растёт — это те, кто строит процессы, задаёт правила безопасности и масштабирования, создаёт среду, в которой остальные могут эффективно работать. Всё ниже — следствие этого.
- Большие отделы дробятся30 человек становятся тремя командами по 10. Каждая команда самодостаточная: продукт, backend, frontend, QA-компетенция внутри. Меньше передач, быстрее решения.
- Ownership ценится на всех уровнях, включая джуновТащить результат — это вход в систему, а не привилегия сеньоров. Джун, который может довести небольшую фичу end-to-end (с AI как множителем), двигается быстрее мидла, который не может.
- Продакты пишут PRD через скиллУ продакта нет доступа к репо; у агента есть. Продакт промптит, агент коммитит PRD в product-docs/features/{feature-id}/prd.md. Продакты — часть цикла разработки, не становясь разработчиками.
Три фазы — от Запуска до Зрелости
Каждая фаза определяется тем, что есть из разделов про репо, процесс и команду к её концу, а не повторным описанием принципов. Фазы — это порядок, не календарь; каждая должна закончиться раньше, чем начнётся следующая.
Страх ушёл, скиллы начали жить
→ Убрать страх делать не так. Дать команде поиграться. Положить первые скиллы.
Сервисные репо
- AGENTS.md в основных репо.
- Sandbox на каждую ветку у пилотов.
Репо скиллов/MCP/агентов
- Первые скиллы коммитятся в общий репо. Сыровато, не идеально, но версионируется.
- ai-learnings репо, чтобы первые находки не растворялись в Slack.
Процесс
- Claude Code раскатан на всех: dev, QA, продакты, аналитики, фронт.
- Еженедельный AI-демо в календаре. Время на ресёрч выделено.
- Фронт пробует Figma Make / Claude Design. Продакты вайбкодят пет-проект, чтобы прочувствовать границы.
Команда
- Ничего структурного пока. Фаза 1 — про снятие страха, не про перестройку оргструктуры.
AI стал инструментом — делаем рычагом
→ Дисциплина контекста, скиллы как система, product-docs на месте. Меряем lead time.
Сервисные репо
- Единое имя ветки на фичу во всех репо.
- Постмортемы апдейтят скиллы, инциденты перестают повторяться через агентов.
Репо скиллов/MCP/агентов
- Скиллы по стекам закоммичены (backend, frontend, mobile, QA), версионируются, ревьюятся.
- Скилл для legacy — предсказуемый рефакторинг.
Продуктовые репо
- Первый <product>-docs репо: architecture/, features/<feature-id>/, tests/.
- Архитектура существующих сервисов закоммичена в architecture/.
- PRD-шаблон, который AI может заполнить чисто (Context / User stories / Acceptance / Edge cases / Out of scope).
Процесс
- Дисциплина контекста — норма команды: люди перестают говорить «напиши функцию» и говорят «напиши с учётом этих ограничений».
- AI-ревью до человеческого.
- Меряем lead time. Базовая цифра для перехода на канбан.
Команда
- Продакты и аналитики внутри AI-цикла; аналитики делают черновики PRD из записей встреч.
- Квартальное планирование остаётся; спринты на выход.
Роли растворяются. Фича доходит от идеи до прода, а команда в основном наблюдает.
→ Автоматизировано всё, что можно. Скиллы превратили каждого в универсала. Роли размываются. Это North Star, а не план на полгода. Большинство команд будут жить где-то между фазами 2 и 3 бесконечно, и это нормально.
Сервисные репо
- Каждое активное репо имеет актуальный AGENTS.md.
Репо скиллов/MCP/агентов
- Скиллы покрывают каждый стек и каждую сквозную тему (ревью, рефакторинг legacy, авторинг PRD, дизайн-система), все написаны script-first по умолчанию.
Продуктовые репо
- Legacy полностью задокументирован в product-docs (агент читает, разраб валидирует).
- У каждой фичи полная папка features/<feature-id>/.
Процесс
- Канбан внутри квартала. Релизы независимы от планирования. Фича готова — фича едет.
- Каждый квартал берём чуть больше, чем в прошлом. Планка двигается.
Команда
- Каждый разраб — фича-оунер end-to-end.
- Тимлид → Lead Engineer: последнее слово в своём стеке, но сам деливерит фичи.
- Продакты коммитят PRD через скилл, без доступа к репо.
- Простые фичи начинаются с продакта-через-агента и приходят как PR на ревью разработчику.
- Границы ролей растворяются: продукт читает код, разрабы пишут продукт, аналитики делают и то, и другое.
Что может пойти не так
Девять ловушек. Ни одна не очевидна, пока в неё не попал.
- 01
Скорость против стабильности
Пойти слишком быстро и потерять стабильность продукта. Каждая фаза должна закончиться раньше, чем начнётся следующая. Не в календаре, а реально на земле.
- 02
Сеньор, который не адаптируется
Это не общекомандный страх. Конкретный случай: твой сильнейший IC, который заслужил право пушбекать, и тихо пушбекает. Продолжает работать так, как работал всегда. За год становится самым медленным человеком в команде, потому что все остальные компаундили, а он нет. Лидер должен называть это прямо: отказаться — это не остаться на месте, это откатиться назад.
- 03
«А зачем я теперь нужен»
Разрабы могут читать AI как угрозу, а не как усилитель. Лидер должен сказать прямо: вы здесь за ownership и судьбу, а не за строки кода в день.
- 04
Страх сокращения ролей
Команда становится меньше и сильнее. Фрейм честный: оптимизация — это победа и сильная строчка в резюме. Отставание на год — вот это реальный минус.
- 05
Технический долг ускоряется
AI может писать хороший код, но только если ему сказать как. Без правильных скиллов и ревью получаешь код, который работает, но небрежный. Слабые мидлы это не поймают. Закоммитят, а счёт прилетит через полгода.
- 06
Энтропия AI-кода
AI пишет код быстрее, чем люди успевают его рецензировать. Review-скилл и человеческая рецензия закрывают часть разрыва, но не весь — ревьюеры не справляются со скоростью нескольких агентов, которые шипят параллельно. Это структурное свойство, а не история про слабых разработчиков. Контрмера — не «больше дисциплины», а кэп на пропускную способность: ограничь число одновременных feature-веток на человека, заложи integration-debt недели каждые N релизов, отказывайся мерджить фичи, контекст которых ревьюер не может восстановить из доков. Без кэпа энтропия копится тихо и всплывает, когда что-то ломается через три фичи одновременно.
- 07
Накопление расходов
Script-first дисциплина — единственное, что отделяет контролируемый AI-счёт от безудержного. Мерь токены на сшитый PR, а не на разработчика. Цифра «на разработчика» льстит всем и не говорит ничего про leverage. Если стоимость на PR растёт, а lead time стоит — ты платишь за театр.
- 08
Vendor lock-in
Фреймворк здесь построен на конвенциях Claude Code: AGENTS.md, формат скиллов, агентские инструменты вокруг. Миграция на другого агента возможна, но не бесплатна — контекст-файлы, промпты скиллов и обвязка вокруг них переписываются. Реалистичная позиция — single-vendor сейчас, multi-vendor через 12–18 месяцев, когда конвенции агентских форматов стабилизируются между провайдерами. Заходить в lock-in — осознанный размен. Не делай вид, что это не размен.
- 09
Смена модели
Каждый релиз модели может тихо поменять поведение скилла. Скилл, который писал чистые PRD-каркасы в прошлом квартале, после смены модели может начать дрейфовать, и ты не заметишь, пока кривой PRD не уйдёт в работу. Митигация — smoke-test для каждого скилла: маленький набор фиксированных входов, выходы которых ты глазами проверяешь на каждой смене версии модели. Без этого «работало вчера» превращается в тихо копящийся класс багов.
Если что-то из этого зашло у твоей команды или сломалось интересным образом — я в Telegram, @stayhightech. Контрпримеры воспринимаю всерьёз.
Рабочий документ. Следующая версия закроет безопасность. Текущая — v0.4, обновлена 2026-05-25.