Уютный IT адочек dan repost
Пришло время признаться: по вечерам я вайб-кожу. И вот чему я научился.
Профессиональный вайб-кодинг — это не когда ты красиво написал промпт, ушёл пить чай, а вернулся к готовому продукту. Это когда код пишет агент, механические проверки делает автоматика, а человек отвечает за то, чтобы всё это в итоге имело смысл.
Я не сравниваю SHA, не пересчитываю коммиты, "красоту кода", именование переменных и не перепроверяю за агентом каждое движение мышкой. Для этого есть CI: тесты, линтеры, сборки и прочие quality gates. Красное — не едем. Зелёное — можно начинать проверять, что мы вообще сделали.
И квалифицированные человеческие проверки обязательны! За последнее время я несколько раз получал вполне "готовые" изменения, которые:
1. собирались по частям, но не собирались целиком;
2. показывали интеграцию в интерфейсе, но не могли выполнить реальный запрос;
3. успешно выполняли запрос, но ломались на авторизации;
4. проходили профильные тесты, но падали в полном CI;
5. технически работали, но решали немного не ту задачу
6. реализовывали всё как запрошено, только в результате получалось, что запрошена фигня и требования надо полностью пересматривать.
И вот здесь начинается настоящая работа продуктового разработчика.
Я проверяю не то, правильно ли агент набрал команды. Я проверяю полный пользовательский контур целиком, опыт клиента, взаимодействие частей как целого.
Можно проверить, что кнопка есть, что сервер отвечает, что инструмент зарегистрирован. А потом пользователь нажимает кнопку — и получает пустой экран, странную ошибку биллинга или вежливое предложение купить подписку вообще у другой компании.
Поэтому для себя я выработал несколько правил.
1. До начала работы прошу агента повторить, что именно он собирается сделать, что не собирается и как будет доказывать результат.
2. Если возникает архитектурная развилка — решение принимает не агент. Он должен принести варианты, последствия и цену каждого.
3. Перед публикацией обязательно спрашиваю: что проверено узко, что проверено целиком, был ли отдельный simplify-проход и что осталось непроверенным.
4. После зелёного CI проверяю продуктовый сценарий руками. Причём не только happy path, но и один-два неприятных случая: истёкший токен, отказ в доступе, повторный запрос, отмена операции. В некоторых случаях неплохо бы провести более или менее крупный регресс — ответственность за понимание импакта изменения лежит на мне.
5. Если исследование касается реального стенда, отдельно требую от агента пруфов: подтверждены ли его утверждения исходниками, рассуждениями на основании общих знаний и треда выше или действительно проверено на выкаченной версии? Это три разных уровня правды.
Многое из этого постепенно уедет в quality gates. Полный typecheck, сборка конечного артефакта, интеграционные тесты, проверки безопасности и стандартные сценарии не должен каждый раз вспоминать человек. Если ошибка уже случилась дважды — это не повод внимательнее читать отчёты агента. Это повод превратить её в автоматический турникет.
Но универсальной трубы пока нет. Задачи разные, интеграции разные, а самые неприятные ошибки обычно находятся на стыках между компонентами и смыслами. Поэтому часть контроля остаётся ручной и ad hoc.
И, кажется, главный навык профессиональной вайб-код разработки — не умение заставить агента написать много кода.
Главный навык — понимать, где автоматике можно довериться, а где человеку всё ещё необходимо проконтролировать: "Мы точно сделали то, что нужно было сделать?"
Профессиональный вайб-кодинг — это не когда ты красиво написал промпт, ушёл пить чай, а вернулся к готовому продукту. Это когда код пишет агент, механические проверки делает автоматика, а человек отвечает за то, чтобы всё это в итоге имело смысл.
Я не сравниваю SHA, не пересчитываю коммиты, "красоту кода", именование переменных и не перепроверяю за агентом каждое движение мышкой. Для этого есть CI: тесты, линтеры, сборки и прочие quality gates. Красное — не едем. Зелёное — можно начинать проверять, что мы вообще сделали.
И квалифицированные человеческие проверки обязательны! За последнее время я несколько раз получал вполне "готовые" изменения, которые:
1. собирались по частям, но не собирались целиком;
2. показывали интеграцию в интерфейсе, но не могли выполнить реальный запрос;
3. успешно выполняли запрос, но ломались на авторизации;
4. проходили профильные тесты, но падали в полном CI;
5. технически работали, но решали немного не ту задачу
6. реализовывали всё как запрошено, только в результате получалось, что запрошена фигня и требования надо полностью пересматривать.
И вот здесь начинается настоящая работа продуктового разработчика.
Я проверяю не то, правильно ли агент набрал команды. Я проверяю полный пользовательский контур целиком, опыт клиента, взаимодействие частей как целого.
Можно проверить, что кнопка есть, что сервер отвечает, что инструмент зарегистрирован. А потом пользователь нажимает кнопку — и получает пустой экран, странную ошибку биллинга или вежливое предложение купить подписку вообще у другой компании.
Поэтому для себя я выработал несколько правил.
1. До начала работы прошу агента повторить, что именно он собирается сделать, что не собирается и как будет доказывать результат.
2. Если возникает архитектурная развилка — решение принимает не агент. Он должен принести варианты, последствия и цену каждого.
3. Перед публикацией обязательно спрашиваю: что проверено узко, что проверено целиком, был ли отдельный simplify-проход и что осталось непроверенным.
4. После зелёного CI проверяю продуктовый сценарий руками. Причём не только happy path, но и один-два неприятных случая: истёкший токен, отказ в доступе, повторный запрос, отмена операции. В некоторых случаях неплохо бы провести более или менее крупный регресс — ответственность за понимание импакта изменения лежит на мне.
5. Если исследование касается реального стенда, отдельно требую от агента пруфов: подтверждены ли его утверждения исходниками, рассуждениями на основании общих знаний и треда выше или действительно проверено на выкаченной версии? Это три разных уровня правды.
Многое из этого постепенно уедет в quality gates. Полный typecheck, сборка конечного артефакта, интеграционные тесты, проверки безопасности и стандартные сценарии не должен каждый раз вспоминать человек. Если ошибка уже случилась дважды — это не повод внимательнее читать отчёты агента. Это повод превратить её в автоматический турникет.
Но универсальной трубы пока нет. Задачи разные, интеграции разные, а самые неприятные ошибки обычно находятся на стыках между компонентами и смыслами. Поэтому часть контроля остаётся ручной и ad hoc.
И, кажется, главный навык профессиональной вайб-код разработки — не умение заставить агента написать много кода.
Главный навык — понимать, где автоматике можно довериться, а где человеку всё ещё необходимо проконтролировать: "Мы точно сделали то, что нужно было сделать?"