Четыре режима разработки с ИИ: A / B / B+ / C

Входная дверь в серию про harness: четыре режима разработки — Classic (A), AI-Assisted (B), Agent-Driven (B+), Agent-First (C). Это не лестница, а четыре разные ставки: один режим оптимален одной команде и катастрофичен для другой на том же проекте. Рецепт помогает выбрать режим и решает мета-вопрос — сколько ИИ вообще нужно проекту. Для B+/C harness обязателен (ведёт к рецепту Harness Engineering), для A/B — почти не нужен.

СреднийDevOps с AI15 минCursor, Claude Code, Copilot, ExecPlan, ADR

Это не лестница — это четыре ставки

Главный тезис: режимы A / B / B+ / C — это не ступени, по которым команда «движется вперёд». Это четыре разные ставки, четыре способа выигрывать и четыре способа ломаться. Один и тот же режим может быть оптимален одной команде и катастрофичен для другой — на одном и том же проекте. Отличаются режимы по трём осям: кто пишет код, на что смотрит инженер (объект внимания) и какой throughput даёт команда. В A человек пишет каждую строку и владеет ей глубоко. В B человек ведёт, ИИ ускоряет печать (Cursor tab, Copilot) — прирост 30–50%, но узкое место то же: когнитивная полоса (cognitive bandwidth) одного человека. В B+ код пишет агент, человек ставит задачу и ревьюит решение, код остаётся читаемым людьми (human-readable). В C объект внимания — сама среда (environment), в которой работает агент; главный продукт инженера — harness.

Режим	Кто пишет код	Объект внимания	Throughput
A — Classic	Человек	Строки кода	Линейный по людям
B — AI-Assisted	Человек, ИИ ускоряет	Строки + AI-подсказки	1.5–2× от линейного
B+ — Agent-Driven	Агент	Задача и решение	2–3× · 2–3 треда
C — Agent-First	Агент	Среда (environment) агента	Нелинейный · 5–10 задач

Mode B — переходное состояние, а не «третий путь». Либо ступенька к B+/C, либо мягкая деградация в A под собственной массой AI slop. Долго в B жить, не выбрав сторону, нельзя.

Покрутите режимы: win / lose / break и матрица

Ниже — интерактив. Откройте вкладку каждого режима и сравните три блока: что выигрывает (win), что проигрывает (lose) и где может сломаться (break). Затем переключитесь на сводную матрицу — она ставит все четыре режима рядом по людям, скорости, стоимости, рискам и применимости, с фильтром по категориям. Не пересказываю содержимое матрицы прозой — её смысл именно в том, чтобы покрутить вживую: увидеть, как у A нулевая стоимость входа, но падающая конкурентоспособность; как у C нелинейный throughput ценой capability collapse и глубокого vendor lock-in; и как B+ держит human-readable код при росте 2–3×. Поиграйте с вкладками и фильтрами, прежде чем читать дальше — следующий шаг опирается на то, что вы там увидите.

Четыре режима разработки с ИИ — 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 раза.

+ Плюсы

Что выигрывает

Нелинейный рост при сохранении legibility

Параллельные worktrees дают throughput, недостижимый в B. Но код всё ещё читаемый — новый человек заходит и понимает его без специальной agent-onboarding-процедуры.

Снижение когнитивной нагрузки

В B разработчик принимает решения каждые 2 минуты. В B+ — раз в 30–60 минут, более ёмкие. Меньше уставшего мозга к концу дня.

Боундари-линтеры + строгие типы гасят AI slop

Критичное отличие от B: структурный дрейф ловится механически барьерами твоего стека — границы импортов (dependency-cruiser / import-linter), строгие типы (strict TS / mypy), правила архитектуры (eslint-plugin-boundaries, FSD и аналоги). Архитектуру держит машина, а не дисциплина.

Сегментация по проектам естественна

Поскольку код остаётся human-readable, можно работать в B+ с любым клиентом — даже NDA-строгим, даже регулируемым. Никаких разговоров «90% кода написано AI» с заказчиком.

Команда сохраняет навыки

Capability collapse, который грозит Mode C, в B+ не наступает. Разработчики продолжают читать код, ревьюить, понимать.

Меньше vendor lock-in

Скиллы, написанные как описание проекта, переносимы. Замена агента — большая часть инфраструктуры работает дальше.

— Минусы

Что проигрывает

Throughput не дотягивает до C

Один человек ведёт 2–3 параллельных треда — не 7–10. Узкое место — пропускная способность ревью. Разница между B+ и C: «ревью каждого MR» vs «ревью на уровне ExecPlan».

Когнитивный потолок ревью

3.5 MR в день от агента — успеваешь нормально ревьюить. 10 MR в день — не успеваешь. И тогда либо деградируешь к «glance-and-merge», либо упираешься в потолок.

Long-horizon задачи дробятся

ExecPlan на 7–25 часов автономной работы в B+ невозможен — ты не ревьюишь промежуточные шаги в таком объёме.

Тесты — для людей, не как сигнал агенту

В C тесты пишутся как сигнал о здоровье системы, а барьер test-integrity не даёт агенту ослаблять или удалять их ради зелёного прогона. В B+ тесты по-прежнему пишутся, чтобы их читал человек; высокое покрытие — побочный эффект, а не цель (гнаться за процентом — это Goodhart).

Скиллы как «описание» — не оптимальны

Скилл, написанный для человека, описывает идеи. Скилл для агента описывает операции. 70% от потенциальной полезности.

Quality document полу-формален

Когда у тебя 10+ клиентских проектов, отсутствие систематического сигнала о состоянии — слепое пятно, которое всё растёт.

⚠ Риски

Где может сломаться

01
Невидимый дрейф к Mode C под нагрузкой
Когда вырастешь по объёму — естественно потянет упрощать ревью. «Линтеры зелёные → мерджу не глядя». Это и есть Mode C, но без harness, который делает Mode C безопасным. Самая опасная траектория.
02
Потолок одного человека
B+ работает в исполнении сильного архитектора с дисциплиной repo-first. Это личный навык, не режим работы команды. Тиражирование на других тимлидов наткнётся на отсутствие их вкуса.
03
Команда расслоится
Те, кто освоил agent-driven flow на твоём уровне, будут расти. Те, кто остался в Mode B — отставать. На промежутке 6–12 месяцев — большой gap внутри команды.
04
Capability rot среднего звена
Мидлы в B+ не пишут код — они тоже направляют агента, но не наработали интуицию о том, как должен выглядеть хорошо устроенный код. Через 2 года умеют направлять и не умеют написать функцию без помощи.
05
MR-ы становятся больше
По мере того как агенты умнеют, их MR-ы растут. Скоро ты будешь смотреть на 800-строчный MR, написанный за 2 часа, и понимать, что 5 минут на ревью — фикция.

Позиционирование B+

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 на локальных моделях. Главное: сегментация — это явное решение, а не дрейф.

iii

Mode B+ — недооценённая позиция

Большинство команд либо в B (просто), либо в плохо устроенном начальном C (быстро). B+ как осознанный режим — редкость. Эта история лучше продаётся NDA-строгим и регулируемым клиентам, чем «у нас 90% AI-кода».

Mode B — переходное состояние

В нём нельзя жить долго: либо ступенька к B+/C, либо мягкая деградация в A под собственной массой AI slop. Долго в B оставаться без выбора стороны нельзя.

Главная ловушка B+ — дрейф к C без harness

Когда команда вырастет по объёму — естественно потянет упрощать ревью и довериться линтерам. Это и есть Mode C, но без инфраструктуры, которая делает Mode C безопасным. Самая опасная траектория.

Capability rot — нерешённая проблема рынка

Не у тебя одного, а у всех, кто работает в B+ и C. Универсального ответа нет. Главное — признать проблему явно и иметь осознанную программу: reading-first, sandbox-задачи руками, новые роли, pair-programming с агентом и сеньором.

vii

Полу-автоматизация — золотая середина

Между «полностью ручным B+» и «полностью автоматическим C» есть рабочее пространство, где скрипты собирают данные и черновики, а человек принимает решения. Это даёт 80% выгод C за 5% стоимости.

Сравнивая режимы, смотрите не на «плюсов больше», а на failure mode: главный риск A — уход сеньоров; B — тихо копящийся AI slop; B+ — дрейф к C без harness; C — capability collapse и сбой LLM-вендора. Выбор режима — это выбор риска, который вы готовы нести.

Сколько ИИ нужно проекту: правило выбора

Мета-решение: не «как быстрее внедрить агентов», а «сколько ИИ вообще нужно этому проекту». Правило простое и привязано к режиму. B+ и C — harness обязателен. Как только код пишет агент, «записано в правилах» перестаёт быть «реально соблюдается»: нужны механические барьеры (линтеры границ, strict-типы, structural tests, pre-commit + CI), иначе архитектурный дрейф ловить нечем. Без harness B+ незаметно сползает в плохой C. A и B — harness почти не нужен. Хватает лёгких частей: ADR на ключевые решения, Definition of Done (один чек-лист «что значит готово») и обычные линтеры. Команда на режиме B (человек ведёт, ИИ ускоряет печать) потратит время впустую, строя инфраструктуру для агента, который ей не нужен. Главная ошибка здесь — строить полный agent-first там, где достаточно хорошего автокомплита.

Режим	Нужен ли 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, уборщики

Решающий вопрос один: кто пишет код? Если агент — harness обязателен. Если человек — harness опциональна и сводится к ADR + DoD + линтерам. Всё остальное в выборе вторично.

B+ глубже: как не свалиться в плохой C

Позиционирование B+ на рынке: это недооценённая позиция. Большинство команд либо в B (просто), либо в плохо устроенном начальном C (быстро). B+ как осознанный режим — редкость, и он лучше продаётся NDA-строгим и регулируемым клиентам, чем «у нас 90% AI-кода»: AI-driven скорость + human-readable код + архитектурная дисциплина. Главная угроза B+ — невидимый дрейф к C без harness и capability rot среднего звена. Мидлы и джуны в B+ не пишут код — они тоже направляют агента, но не нарабатывают интуицию о том, как должен выглядеть хорошо устроенный код. Через 2 года умеют направлять и не умеют написать функцию без помощи. Универсального решения нет ни у кого; есть осознанная программа из четырёх рабочих моделей (см. чеклист). И помните три тезиса режима: ваша ценность — не строки кода, а точно поставленная задача; рефлекс «сам напишу — быстрее» — ловушка (агент медленнее на одной функции, но вы ведёте вторую задачу параллельно); ревью — это «решена ли та задача, что ставил, в правильном масштабе», а не построчное «выглядит нормально».

Программа против capability rot

Reading-first: джун читает кода больше, чем пишет (open-source, чужие PR, «explain to me» по своим MR)

Sandbox-задачи руками раз в 1–2 недели — алгоритм/рефакторинг без агента, с ревью у сеньора

Новые роли вместо грейдов: task framers, reviewers, harness engineers, domain experts

Pair-programming с агентом и сеньором 1–2 раза в неделю — калибровка вкуса к постановке задач

Glance-and-merge под нагрузкой: зелёные линтеры → мерджу не глядя — это уже плохой C

Полагаться, что B+ воспроизведётся сам: это личный навык тимлида, а не режим команды по умолчанию

Capability rot джунов и мидлов — нерешённая проблема всего рынка, не только вашей команды. Универсального ответа нет; единственная ошибка, которую можно не делать, — не признавать проблему и не иметь никакой программы.

«B+ Enhanced»: что взять из C по частям

Не нужно перестраивать процесс целиком, чтобы получить часть выгод C. Четыре точечных элемента дают примерно 30% выгод C за ~10% стоимости — и каждый полезен сам по себе. ExecPlan — только для задач больше рабочего дня и/или затрагивающих >5 файлов. Живёт в docs/plans/YYYY-MM-DD-name.md: Context, Goal (одно предложение), Out of scope, Approach (5–10 пунктов) пишет человек; Progress, Decisions, Surprises заполняет агент по ходу; Done — человек в конце. Диагностика: если не можешь за 30 минут написать первые четыре секции — задача ещё не готова к запуску. Quality.md полу-автоматизированный — скрипт собирает coverage, lint/dep-cruiser/knip violations, outdated deps и генерирует черновик; тимлид заполняет интерпретацию глазами 15 минут в неделю. Полная LLM-автоматизация преждевременна — без контекста проекта она пишет общие места. Скиллы как операции, не описания — пошаговый список действий + DoD + анти-паттерны + ссылка на пример в коде, а не «у нас FSD и Vitest». ADR-структура — самое дешёвое внедрение: один markdown = одно решение, 5–15 ADR на проект по 15–20 минут.

B+ Enhanced: ~30% выгод C за ~10% стоимости

ExecPlan для крупных задач (>1 дня / >5 файлов): человек пишет Context/Goal/Approach, агент — Progress/Decisions

Полу-автоматизированный quality.md: скрипт собирает цифры, человек — интерпретацию 15 мин/нед

Скиллы как операции: действия + DoD + анти-паттерны + ссылка на пример, по одному скиллу за раз

ADR: один markdown = одно решение, ретроспективно оформить уже принятые (FSD, выбор тестов)

Полная LLM-автоматизация quality.md сейчас — пишет общие места без контекста проекта

Полу-автоматизация — золотая середина: между полностью ручным B+ и полностью автоматическим C есть пространство, где скрипты собирают данные и черновики, а человек принимает решения. Это и есть 80% выгоды за 5% усилий.

Сегментация по проектам + куда дальше

Финальный тезис: на разных проектах одной компании могут одновременно работать разные режимы — и это явное решение, а не дрейф. Внутренние пет-проекты → C (можно рисковать, capability collapse не страшен). Новые открытые клиенты → B+ (скорость + human-readable код, который не стыдно показать). NDA-строгие и регулируемые → A или B на локальных моделях (код клиента не уходит в чужой LLM). Главное — выбрать режим под проект сознательно, а не сползти в него под давлением сроков. Куда дальше. Если по правилу из шага 3 вы попадаете в B+ или C — вам нужен harness, и эта дверь ведёт в рецепт «Harness Engineering»: там среда из пяти слоёв разворачивается в маршрут задачи из четырёх фаз, барьеры против конвенций и lessons-ledger, плюс карта серии по фазам rollout. Если же вы в A или B — полный harness вам не нужен: возьмите только лёгкие части (ADR, Definition of Done, линтеры из шага 3) и вернитесь сюда, когда соберётесь переходить в B+.

Тип проекта	Режим	Почему
Внутренние пет-проекты	C — Agent-First	Можно рисковать, capability collapse не критичен
Новые открытые клиенты	B+ — Agent-Driven	Скорость + human-readable код для заказчика
NDA-строгие / регулируемые	A или B (локальные модели)	Код не уходит в чужой LLM

Попали в B+/C — дальше читайте «Harness Engineering»: там выбор режима разворачивается в конкретную инфраструктуру и rollout по фазам. Остались в A/B — полный harness не нужен, хватит ADR + DoD + линтеров.

Результат

Вы понимаете, что 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 по фазам.

Связанная теория

production › harness engineering context › context engineering

Что дальше

Harness Engineering: собрать среду под режимы B+/C