"Vibe Coding in Prod и деревья с листьями Попался доклад Эрика Шлунца из Anthropic - ""Vibe coding in prod"". Название довольно кликбейтное, потому что я думал, что щас он запустит Claude Code на каком-нить продакшн-сервере и начнет там вайб-кодить :) (__кроме шуток, такое тоже практикуется, но надо очень хорошо представлять себе, куда ____вы жмав__) Но нет, доклад оказался довольно взвешенным и хорошо описывает несколько базовых практик, которых обязательно нужно придерживаться: — 🟢 Будьте PM'ом для ИИ: вместо коротких команд, готовьте для агента полноценное ТЗ, как для нового джуна в команде. Чем больше контекста и чётче задача - тем лучше результат. 🟢 Вам нужно думать о ""стволе"" и ""ветвях"", а не о ""листьях"": делегируйте ИИ реализацию конечных, изолированных модулей (""листьев"" на дереве зависимостей), но оставляйте за собой проектирование ядра системы (""ствола"" и ""ветвей""). 🟢 Обеспечьте верифицируемость: ваша задача - создать условия, в которых результат работы ИИ можно легко и надёжно проверить. Это могут быть тесты, чётко определённые входные/выходные данные или другие формы верификации. 🟢 Помните об экспоненте: возможности ИИ растут нелинейно. График от METR, который показал Эрик, наглядно демонстрирует, что сложность задач, решаемых ИИ, удваивается каждые 7 месяцев. Нужно готовиться к миру, где ИИ сможет выполнять работу, на которую сегодня уходят недели или месяцы. __Кстати, тот график ____подробнее описан____ в серии постов про сценарий AI 2027.__ — Листья и деревья Идея про ""листья"" показалась мне особенно полезной - она просто и наглядно формулирует то, к чему мы уже пришли в ИИ-разработке. Вообще, с точки зрения старших технических специалистов, этот подход не нов - одной из их задач всегда была проработка архитектуры и фиксация высокоуровневых абстракций. А имея прочный базис, можно было безопасно делегировать реализацию конкретных фич, снижая риски и не накапливая критический техдолг. Почему это важно? ● Техдолг в ""листьях"" не так страшен. Их можно относительно дёшево переписать, если что-то пойдет не так, ведь от них мало что зависит. ● Техдолг в ядре системы - это проблема. Закрывать его больно, долго и дорого, вплоть до того, что может оказаться, что проще всё переписать. Будущую расширяемость и поддерживаемость очень сложно оценить - ""человеческая"" индустрия разработки так и не выработала надёжных стандартов, хотя попыток было много. Так что при разработке с ИИ возникает похожее разделение, и наша роль смещается в сторону проектирования надёжного базиса, который мы хорошо понимаем. Что это значит на практике ⚪️ Высокоуровневая архитектура должна оставаться под контролем Мы должны подробно проработать основные компоненты, их взаимодействие, контракты и API. Вся эта информация должна быть зафиксирована в виде, понятном для ИИ (документация, схемы, интерфейсы и т.п.). Чем более нестандартную систему вы делаете - тем более детальный нужен контроль, - просто в силу того, что ИИ лучше справляется с распространенными подходами. ⚪️ Реализация ""листьев"" делегируется ИИ Имея чёткие внешние контракты и набор тестов, мы можем отпустить контроль над тем, как именно реализован конкретный изолированный модуль. Можно всегда его переписать при помощи ИИ с нуля, если потребуется, и пока тесты и прочие верификации проходят, нас даже не особо волнует его внутренняя реализация. ⚪️ Вопрос гранулярности Насколько большим может быть ""лист""? Сейчас надёжной метрики у нас нет, это определяется эмпирически и зависит от проекта, используемой модели и инструментария. Но стоит понимать, что с ростом возможностей моделей, ""листом"" может стать целый сервис. А мы поднимаемся всё выше по уровням абстракции, двигаясь от кода к системной архитектуре, фичам, продукту. #ai #architecture #development"