Vibe Coding in Prod и деревья с листьями

Попался доклад Эрика Шлунца из Anthropic - "Vibe coding in prod".
Название довольно кликбейтное, потому что я думал, что щас он запустит Claude Code на каком-нить продакшн-сервере и начнет там вайб-кодить :)
(кроме шуток, такое тоже практикуется, но надо очень хорошо представлять себе, куда вы жмав)

Но нет, доклад оказался довольно взвешенным и хорошо описывает несколько базовых практик, которых обязательно нужно придерживаться:

—

🟢 Будьте PM'ом для ИИ: вместо коротких команд, готовьте для агента полноценное ТЗ, как для нового джуна в команде. Чем больше контекста и чётче задача - тем лучше результат.

🟢 Вам нужно думать о "стволе" и "ветвях", а не о "листьях": делегируйте ИИ реализацию конечных, изолированных модулей ("листьев" на дереве зависимостей), но оставляйте за собой проектирование ядра системы ("ствола" и "ветвей").

🟢 Обеспечьте верифицируемость: ваша задача - создать условия, в которых результат работы ИИ можно легко и надёжно проверить. Это могут быть тесты, чётко определённые входные/выходные данные или другие формы верификации.

🟢 Помните об экспоненте: возможности ИИ растут нелинейно. График от METR, который показал Эрик, наглядно демонстрирует, что сложность задач, решаемых ИИ, удваивается каждые 7 месяцев. Нужно готовиться к миру, где ИИ сможет выполнять работу, на которую сегодня уходят недели или месяцы.

Кстати, тот график подробнее описан в серии постов про сценарий AI 2027.

—

Листья и деревья
Идея про "листья" показалась мне особенно полезной - она просто и наглядно формулирует то, к чему мы уже пришли в ИИ-разработке.

Вообще, с точки зрения старших технических специалистов, этот подход не нов - одной из их задач всегда была проработка архитектуры и фиксация высокоуровневых абстракций.
А имея прочный базис, можно было безопасно делегировать реализацию конкретных фич, снижая риски и не накапливая критический техдолг.

Почему это важно?
● Техдолг в "листьях" не так страшен. Их можно относительно дёшево переписать, если что-то пойдет не так, ведь от них мало что зависит.
● Техдолг в ядре системы - это проблема. Закрывать его больно, долго и дорого, вплоть до того, что может оказаться, что проще всё переписать.

Будущую расширяемость и поддерживаемость очень сложно оценить - "человеческая" индустрия разработки так и не выработала надёжных стандартов, хотя попыток было много.

Так что при разработке с ИИ возникает похожее разделение, и наша роль смещается в сторону проектирования надёжного базиса, который мы хорошо понимаем.

Что это значит на практике
⚪️ Высокоуровневая архитектура должна оставаться под контролем
Мы должны подробно проработать основные компоненты, их взаимодействие, контракты и API. Вся эта информация должна быть зафиксирована в виде, понятном для ИИ (документация, схемы, интерфейсы и т.п.).

Чем более нестандартную систему вы делаете - тем более детальный нужен контроль, - просто в силу того, что ИИ лучше справляется с распространенными подходами.

⚪️ Реализация "листьев" делегируется ИИ
Имея чёткие внешние контракты и набор тестов, мы можем отпустить контроль над тем, как именно реализован конкретный изолированный модуль.

Можно всегда его переписать при помощи ИИ с нуля, если потребуется, и пока тесты и прочие верификации проходят, нас даже не особо волнует его внутренняя реализация.

⚪️ Вопрос гранулярности
Насколько большим может быть "лист"? Сейчас надёжной метрики у нас нет, это определяется эмпирически и зависит от проекта, используемой модели и инструментария.

Но стоит понимать, что с ростом возможностей моделей, "листом" может стать целый сервис.
А мы поднимаемся всё выше по уровням абстракции, двигаясь от кода к системной архитектуре, фичам, продукту.

#ai #architecture #development