Четыре режима разработки с ИИ: A / B / B+ / C
Входная дверь в серию про harness: четыре режима разработки — Classic (A), AI-Assisted (B), Agent-Driven (B+), Agent-First (C). Это не лестница, а четыре разные ставки: один режим оптимален одной команде и катастрофичен для другой на том же проекте. Рецепт помогает выбрать режим и решает мета-вопрос — сколько ИИ вообще нужно проекту. Для B+/C harness обязателен (ведёт к рецепту Harness Engineering), для A/B — почти не нужен.
Это не лестница — это четыре ставки
| Режим | Кто пишет код | Объект внимания | Throughput |
|---|---|---|---|
| A — Classic | Человек | Строки кода | Линейный по людям |
| B — AI-Assisted | Человек, ИИ ускоряет | Строки + AI-подсказки | 1.5–2× от линейного |
| B+ — Agent-Driven | Агент | Задача и решение | 2–3× · 2–3 треда |
| C — Agent-First | Агент | Среда (environment) агента | Нелинейный · 5–10 задач |
Покрутите режимы: win / lose / break и матрица
Четыре режима разработки с ИИ — A / B / B+ / C
Это не лестница, по которой команда «движется вперёд». Это четыре разные ставки: четыре способа выигрывать и четыре способа ломаться. Один режим может быть оптимален одной команде и катастрофичен для другой — на одном и том же проекте. Выберите режим, сравните win / lose / break, затем покрутите сводную матрицу.
Это переходная позиция между B и C, но достаточно характерная, чтобы выделить её как отдельный режим. Код пишет агент, человек управляет: разбирает задачу, ставит, параллельно ведёт другую задачу в другом worktree, ревьюит на уровне MR — не построчно, но и не «прошли проверки → мерджу».
«Я не пишу код. Я направляю агента.» — это не про инструменты. Это про смену объекта внимания: с строк кода — на формулировку задачи и проверку решения.
Три тезиса для команды
- 01Твоя ценность — не строки кода, а правильно поставленная задача
Эффективнее не тот, кто быстрее печатает, а тот, кто точнее формулирует и быстрее замечает, что сделано не то. Это другие навыки, и их можно тренировать.
- 02Рефлекс «сам напишу — быстрее» — это ловушка
Конкретно эту функцию ты напишешь за 5 минут, а агент за 8. Но пока агент работает, ты двигаешь вторую задачу. К концу дня разница 2–3×, не 1.5×. Каждое действие медленнее, общая производительность выше.
- 03Ревью — это «решена ли та задача», а не «работает ли код»
Главная ошибка — читать diff построчно и думать «выглядит нормально». Правильный вопрос: «сделано ли то, что я просил, в правильном масштабе». Часто агент решает в 1.5 раза больше нужного или в 0.7 раза.
Что выигрывает
Параллельные worktrees дают throughput, недостижимый в B. Но код всё ещё читаемый — новый человек заходит и понимает его без специальной agent-onboarding-процедуры.
В B разработчик принимает решения каждые 2 минуты. В B+ — раз в 30–60 минут, более ёмкие. Меньше уставшего мозга к концу дня.
Критичное отличие от B: структурный дрейф ловится механически барьерами твоего стека — границы импортов (dependency-cruiser / import-linter), строгие типы (strict TS / mypy), правила архитектуры (eslint-plugin-boundaries, FSD и аналоги). Архитектуру держит машина, а не дисциплина.
Поскольку код остаётся human-readable, можно работать в B+ с любым клиентом — даже NDA-строгим, даже регулируемым. Никаких разговоров «90% кода написано AI» с заказчиком.
Capability collapse, который грозит Mode C, в B+ не наступает. Разработчики продолжают читать код, ревьюить, понимать.
Скиллы, написанные как описание проекта, переносимы. Замена агента — большая часть инфраструктуры работает дальше.
Что проигрывает
Один человек ведёт 2–3 параллельных треда — не 7–10. Узкое место — пропускная способность ревью. Разница между B+ и C: «ревью каждого MR» vs «ревью на уровне ExecPlan».
3.5 MR в день от агента — успеваешь нормально ревьюить. 10 MR в день — не успеваешь. И тогда либо деградируешь к «glance-and-merge», либо упираешься в потолок.
ExecPlan на 7–25 часов автономной работы в B+ невозможен — ты не ревьюишь промежуточные шаги в таком объёме.
В C тесты пишутся как сигнал о здоровье системы, а барьер test-integrity не даёт агенту ослаблять или удалять их ради зелёного прогона. В B+ тесты по-прежнему пишутся, чтобы их читал человек; высокое покрытие — побочный эффект, а не цель (гнаться за процентом — это Goodhart).
Скилл, написанный для человека, описывает идеи. Скилл для агента описывает операции. 70% от потенциальной полезности.
Когда у тебя 10+ клиентских проектов, отсутствие систематического сигнала о состоянии — слепое пятно, которое всё растёт.
Где может сломаться
- 01Невидимый дрейф к Mode C под нагрузкой
Когда вырастешь по объёму — естественно потянет упрощать ревью. «Линтеры зелёные → мерджу не глядя». Это и есть Mode C, но без harness, который делает Mode C безопасным. Самая опасная траектория.
- 02Потолок одного человека
B+ работает в исполнении сильного архитектора с дисциплиной repo-first. Это личный навык, не режим работы команды. Тиражирование на других тимлидов наткнётся на отсутствие их вкуса.
- 03Команда расслоится
Те, кто освоил agent-driven flow на твоём уровне, будут расти. Те, кто остался в Mode B — отставать. На промежутке 6–12 месяцев — большой gap внутри команды.
- 04Capability rot среднего звена
Мидлы в B+ не пишут код — они тоже направляют агента, но не наработали интуицию о том, как должен выглядеть хорошо устроенный код. Через 2 года умеют направлять и не умеют написать функцию без помощи.
- 05MR-ы становятся больше
По мере того как агенты умнеют, их MR-ы растут. Скоро ты будешь смотреть на 800-строчный MR, написанный за 2 часа, и понимать, что 5 минут на ревью — фикция.
Mode B+ — недооценённая позиция на рынке. Большинство команд либо в B, либо в плохо устроенном начальном C. B+ как осознанный режим — редкость. Его можно продавать клиентам: AI-driven скорость + human-readable код + архитектурная дисциплина.
Сводная матрица: фильтр по категориям
| AClassic | BAI-Assisted | B+Agent-Driven | CAgent-First | |
|---|---|---|---|---|
| Люди и фокус | ||||
| Кто пишет код | Человек | Человек, AI ускоряет | Агент | Агент |
| Объект внимания инженера | Строки кода | Строки + AI | Задача и решение | Среда работы агента |
| Кто принимает архитектурные решения | Человек | Человек | Человек | Через ExecPlans, частично делегируется |
| Что считается «хорошей работой» | Чистый код | Быстрая выдача чистого кода | Точная постановка задач, ревью | Проектирование среды, длинные задачи |
| Скорость и масштаб | ||||
| Throughput команды | линейный | 1.5–2× | 2–3× | нелинейный |
| Параллельных задач у инженера | 1 | 1 | 2–3 | 5–10 |
| PR в день на инженера | 0.5–1 | 1–2 | 2–3 | 3–5+ |
| Long-horizon задачи (>7ч автономии) | нет | нет | дробится | да |
| Тиражирование между проектами | нет | нет | частичное | полное |
| Стоимость | ||||
| Стоимость входа | нулевая | низкая | средняя | высокая |
| Стоимость поддержки | высокая | средняя | средняя | средняя по людям, высокая по инфре |
| Расход токенов на единицу работы | 0× | ~0.5× | 3–5× | 8–15× |
| Vendor lock-in | нет | средний | средний | глубокий |
| Качество и риски | ||||
| Code legibility для людей | максимальная | высокая | высокая | средняя/низкая |
| Защита от архитектурного дрейфа | на дисциплине | на дисциплине | механическая | механическая + уборщики |
| Роль тестов | проверка людьми | проверка людьми | пишутся для чтения людьми | сигнал здоровья, не ослаблять (test-integrity) |
| Главный риск | Уход сеньоров, отставание | AI slop накапливается | Дрейф к C, capability rot | Сбой вендора, capability collapse |
| Применимость | ||||
| Скорость онбординга нового человека | Недели–месяцы | Недели | Недели | Дни (если harness есть) |
| NDA-строгие клиенты | идеально | хорошо | хорошо | сложно |
| Конкурентоспособность 2026–2027 | падает | стабильна | растёт | растёт быстрее |
| Конкурентоспособность 2030+ | низкая | под вопросом | если удержится как режим | зависит от рынка LLM |
| Типичный размер команды | Любой | Любой | 5–20, важна роль тимлида | 3–50+ при наличии harness |
| Кому подходит | NDA, регулируемые отрасли, малые команды без давления скорости | Команды в начале AI-перехода, проекты с непредсказуемой архитектурой | Зрелые команды с сильным тимлидом, аутсорс с разнородными клиентами | Команды с готовностью к перестройке и высоким объёмом однотипных задач |
Главные тезисы
Не нужно «переходить из A в B, потом в B+, потом в C». Каждый режим — самостоятельная стратегия со своими ставками и failure modes. Один режим может быть оптимален одной команде и катастрофичен для другой.
На разных проектах одной компании могут одновременно работать разные режимы. Внутренние пет-проекты — C. Новые открытые клиенты — B+. NDA-строгие — A или B на локальных моделях. Главное: сегментация — это явное решение, а не дрейф.
Большинство команд либо в B (просто), либо в плохо устроенном начальном C (быстро). B+ как осознанный режим — редкость. Эта история лучше продаётся NDA-строгим и регулируемым клиентам, чем «у нас 90% AI-кода».
В нём нельзя жить долго: либо ступенька к B+/C, либо мягкая деградация в A под собственной массой AI slop. Долго в B оставаться без выбора стороны нельзя.
Когда команда вырастет по объёму — естественно потянет упрощать ревью и довериться линтерам. Это и есть Mode C, но без инфраструктуры, которая делает Mode C безопасным. Самая опасная траектория.
Не у тебя одного, а у всех, кто работает в B+ и C. Универсального ответа нет. Главное — признать проблему явно и иметь осознанную программу: reading-first, sandbox-задачи руками, новые роли, pair-programming с агентом и сеньором.
Между «полностью ручным B+» и «полностью автоматическим C» есть рабочее пространство, где скрипты собирают данные и черновики, а человек принимает решения. Это даёт 80% выгод C за 5% стоимости.
Сколько ИИ нужно проекту: правило выбора
| Режим | Нужен ли harness | Что ставить |
|---|---|---|
| A — Classic | Почти нет | ADR, обычные линтеры |
| B — AI-Assisted | Почти нет | ADR, Definition of Done, линтеры |
| B+ — Agent-Driven | Обязателен | Барьеры границ, strict-типы, pre-commit + CI |
| C — Agent-First | Обязателен (полный) | Полный harness: structural tests, skills, уборщики |
B+ глубже: как не свалиться в плохой C
Программа против capability rot
«B+ Enhanced»: что взять из C по частям
B+ Enhanced: ~30% выгод C за ~10% стоимости
Сегментация по проектам + куда дальше
| Тип проекта | Режим | Почему |
|---|---|---|
| Внутренние пет-проекты | C — Agent-First | Можно рисковать, capability collapse не критичен |
| Новые открытые клиенты | B+ — Agent-Driven | Скорость + human-readable код для заказчика |
| NDA-строгие / регулируемые | A или B (локальные модели) | Код не уходит в чужой LLM |
Результат
Вы понимаете, что A / B / B+ / C — это не лестница, а четыре ставки с разными failure modes, и можете выбрать режим под команду и проект. Ключевое правило: кто пишет код, решает всё — для B+/C harness обязателен, для A/B хватает ADR + Definition of Done + линтеров. B+ — недооценённая позиция, которую держат программой против capability rot и точечными элементами «B+ Enhanced». Сегментация по проектам — явное решение, а не дрейф. Если вы в B+/C — следующий шаг это рецепт «Harness Engineering», где выбор режима разворачивается в конкретную среду и rollout по фазам.