⚔️ Противоречия между экспертами
15 практиков CC не сходятся в главном: сколько свободы давать агенту и нужны ли тесты вообще. Единого «правильного» пути нет — есть контекст твоего проекта, твоя терпимость к риску и твоя тестовая культура. Эта страница — не арбитраж, а карта разногласий: чтобы ты осознанно выбрал сторону, а не унаследовал чужую по умолчанию.
Дебат 1: тесты — страховка или тормоз
Самый острый раскол сообщества. Одни считают TDD единственным способом безопасно доверять агенту код. Другие — что тесты замедляют цикл, а реальную защиту даёт внимательное ревью человека.
- Boris Cherny — тесты дают агенту быструю обратную связь без участия человека на каждом шаге
- Kent Beck — TDD как «superpower» с агентами: unit-тесты не дают вносить регрессии незаметно
- obra / Superpowers — brainstorm → план → TDD, тесты как страховочная сетка перед автономным шагом
- Harper Reed — spec-driven development: спецификация и тесты фиксируют контракт до кода
- Mitchell Hashimoto — спецификация всегда до кода, тесты фиксируют границы поведения
- Steve Yegge — chat-oriented programming: агенты пишут 80% кода, скорость важнее покрытия
- Nick Dobos — отгружай быстро, чини потом; вкус важнее процесса
- Peter Steinberger — десятки агентов параллельно, ревью вместо тестов как основной гейт
- Geoffrey Huntley — автономные циклы («ralph»): инструменты вместо инструкций, тесты замедляют цикл
- Eric Buess — автоматизируй рутину агентами, проверяй результат, а не процесс
| Аргументы «за» тесты | Аргументы «против» / за скорость |
|---|---|
| Агент не может незаметно сломать поведение — красный тест ловит регрессию сразу | Написание и поддержка тестов съедает время, которое можно потратить на фичи |
| Тест — это спецификация в исполняемой форме, снижает двусмысленность промпта | Агент может писать тесты под свою же (ошибочную) трактовку задачи — зелёный тест не гарантия |
| Долгие автономные сессии без теста рискуют «уехать» далеко не туда | На проверенном stack и с внимательным ревью человек ловит баги не хуже тестов |
| Тесты — общий язык между несколькими агентами/сессиями, работающими параллельно | Для прототипов и MVP тесты — преждевременная инвестиция, требования ещё поплывут |
Спор не «тесты хорошо / плохо», а «где узкое место риска». Если ошибка стоит дорого (платежи, данные пользователей, конкурентная кодовая база) — сторона TDD права почти всегда. Если ошибка дешева и обратима (лендинг, прототип, внутренний скрипт) — ревью и скорость выигрывают экономически.
Дебат 2: автономия агента или контроль на каждом шаге
Вторая ось — сколько поводка давать агенту. «Дай свободу» отпускает агента на десятки итераций без вмешательства. «Контролируй» требует вычитывать каждую строку прежде чем она попадёт в код.
- Geoffrey Huntley — «ralph»: агент крутится в цикле сам, человек проверяет результат, не процесс
- Steve Yegge — большие задачи целиком агенту, не дробить на микротаски с постоянным надзором
- Andrej Karpathy — vibe coding: не вычитывать каждый шаг, доверять модели на высоком уровне
- Mitchell Hashimoto — читает каждую строку диффа вручную, скептичен к автогенерации без вычитки
- Simon Willison — «never trust, always verify»: каждый вывод агента требует независимой проверки
- Armin Ronacher — пиши код так, чтобы агента (и его результат) можно было легко проверить; наблюдаемость важнее автогенерации
| Сигнал в пользу «дай свободу» | Сигнал в пользу «контролируй» |
|---|---|
| Задача хорошо специфицирована, границы понятны заранее | Задача на периметре безопасности, платежах, правах доступа |
| Есть автоматические гейты (тесты, линтеры, CI), которые ловят отклонения | Автоматических гейтов нет или они неполные |
| Откат дешёвый — можно перезапустить цикл, изменения обратимы | Изменения затрагивают продакшн-данные или необратимы |
| Разработчик уже видел этот класс задач, знает типичные ошибки агента | Новый домен для команды — нет опыта, что именно может пойти не так |
Дебат 3: скорость доступа или дисциплина потолка
Karpathy формулирует это как явную дихотомию: vibe coding поднимает пол — снижает порог входа для тех, кто вообще не пишет код. Agentic engineering поднимает потолок — throughput профессионала на качестве продакшна. Это разные оси, и путать их — источник половины споров про «правильный» способ работать с агентом.
- Nick Dobos — агенты пишут черновик, вкус важнее процесса, не тормозить на формальностях
- Andrej Karpathy — термин «vibe coding»: описываешь на высоком уровне, доверяешь модели написать
- Kent Beck — «augmented coding»: агент усиливает разработчика, не заменяет; дисциплина TDD обязательна
- Harper Reed — spec-driven development как потолок качества, а не тормоз
Важный нюанс: сам Karpathy не занимает одну сторону навсегда — он констатирует, что «ты по-прежнему отвечаешь за свой софт, нельзя вносить уязвимости потому что ты vibe-кодил». Его формула компромисса: новый дефолт — 99% времени ты не пишешь код напрямую, а оркестрируешь агентов и выступаешь как oversight. Это требует лучших спецификаций, лучших тестов, лучшей инфраструктуры — то есть дисциплины внутри скорости, а не вместо неё.
«Доступ» и «потолок» — не конкурирующие цели, а разные метрики успеха. Для хобби-проекта и обучения важен пол (низкий порог входа). Для продакшн-кода в команде важен потолок (throughput при сохранении качества). Смешение метрик — то, что превращает технический выбор в идеологический спор.
Дебат 4: одна большая задача или маленькие итерации
Ещё одна практическая развилка: скармливать агенту всю фичу целиком или дробить на маленькие проверяемые шаги.
- Steve Yegge — chat-oriented programming: большие задачи, не микротаски. Дробление на мелкие шаги — оверхед координации, который съедает выигрыш от агента
- Логика: агент с большим контекстом видит всю картину и делает более согласованные решения, чем при склейке из фрагментов
- Boris Cherny — маленькие итерации важнее больших промптов: короче цикл проверки, быстрее находишь, где агент свернул не туда
- Логика: ошибка в маленьком шаге дешева и локальна; ошибка в конце огромной задачи требует переписывать всё
Компромисс, который на практике используют обе стороны: размер шага зависит от того, насколько хорошо задача специфицирована и насколько дёшево откатить ошибку. Хорошо описанный рефакторинг с тестовым покрытием можно доверить агенту целиком (Yegge-стиль). Новая бизнес-логика с неясными границами требует итераций по 1 файлу за раз (Cherny-стиль) — иначе агент «уедет» далеко от намерения раньше, чем ты успеешь это заметить.
Сводная таблица: ось спора и как выбрать сторону
| Ось спора | Лагерь А | Лагерь Б | Как выбрать |
|---|---|---|---|
| Тесты | TDD как страховка (Beck, Cherny, obra, Reed, Hashimoto) | Ревью вместо тестов (Yegge, Dobos, Steinberger, Huntley, Buess) | Цена ошибки высокая → TDD. Ошибка дешёвая и обратимая → ревью и скорость |
| Автономия агента | Длинные автономные забеги (Huntley, Yegge, Karpathy) | Контроль каждого шага (Hashimoto, Willison, Ronacher) | Есть автогейты (тесты/CI/линт) и задача понятна → свобода. Периметр безопасности или новый домен → контроль |
| Цель работы с агентом | Поднять пол — доступ для не-программиста (vibe coding, Karpathy) | Поднять потолок — throughput профи (agentic engineering, Beck, Reed) | Хобби/обучение/прототип → доступ важнее. Продакшн команды → потолок важнее |
| Размер задачи агенту | Одна большая задача целиком (Yegge) | Маленькие проверяемые итерации (Cherny) | Задача хорошо специфицирована и покрыта тестами → крупный кусок. Границы размыты → мелкие шаги |
| Кто пишет тесты | Агент пишет и тесты, и код (принято по умолчанию у части «no-tests» лагеря — тесты не критичны) | Тесты пишет человек по бизнес-требованиям (Willison, Beck) | Критичная бизнес-логика → тесты человека. Рутинный CRUD/бойлерплейт → можно доверить агенту |
Чек-лист: как найти свой подход
- ☑ Размер проекта. Соло-прототип/лендинг — можно ближе к «свобода + скорость» (Dobos, Huntley). Командный продакшн-репозиторий — ближе к «контроль + TDD» (Hashimoto, Beck).
- ☑ Критичность. Платежи, персональные данные, права доступа — построчное ревью и тесты обязательны независимо от прочих факторов (Willison, Ronacher).
- ☑ Тестовая культура команды. Уже есть привычка писать тесты — TDD с агентом ляжет естественно. Тестов исторически не было — сначала выстрой ревью-дисциплину, тесты внедряй постепенно.
- ☑ Толерантность к риску и цена отката. Откат дешёвый (git revert, staging) — можно давать агенту длинные автономные прогоны. Откат дорогой (прод-данные, публичный API) — маленькие шаги и контроль на каждом.
- ☑ Тип задачи. Рутинный рефакторинг с понятными границами — крупный кусок агенту (Yegge-стиль). Новая бизнес-логика с неясными требованиями — мелкие итерации (Cherny-стиль).
- ☑ Твоя роль в моменте. Изучаешь новый домен вместе с агентом — контролируй, чтобы не унаследовать чужую ошибку молча. Работаешь в знакомой области — можно довериться скорости.
Итог: контекст решает, не догма
Ни один из 15 экспертов не претендует на универсальную истину — каждый описывает, что работает в его проектах, с его уровнем риска и его командой. Смотри на страницы Boris Cherny, Kent Beck и Mitchell Hashimoto как на дисциплинированный полюс; на Steve Yegge, Geoffrey Huntley и Nick Dobos — как на полюс скорости. Твой реальный подход почти наверняка будет где-то между ними, и это нормально. См. также сводную шпаргалку практик, где паттерны сгруппированы без привязки к «лагерям».