Всем привет!
Меня зовут Александр, я COO в SaaS-платформе аналитики данных. Последний год активно изучаю внедрение AI-решений в кросс-функциональные процессы. Делюсь полезными материалами, которые считаю стоят внимания. В основном про AI, изменение процессов, тренды и продуктовое видение.
У себя в телеграм-канале делюсь сжатыми и структурированными саммери статей.
Сегодняшний перевод — Vibe Coding is not an excuse for low-quality work
Addy Osmani — работает в Google 12 лет, сейчас в роли руководителя Chrome Developer Experience.
ИИ-ассистенты обещают революцию в программировании, позволяя за минуты создать то, на что раньше уходили дни. Но за этой скоростью скрывается опасность — код, который выглядит рабочим, но разваливается при первом же необычном сценарии. "Vibe coding" требует не отказа от инженерной дисциплины, а нового уровня ответственности за то, что генерирует искусственный интеллект.
Дополню, подход к работе с AI как с очень активным джуном актуально не только для разработки, но и для любых других задач перед AI. Расширю эту идею, как в жизни мы активного сотрудника направляем на развитие, качественно онбордим и описываем трек развития, так же и AI необходимо объяснять/обучать какие есть данные, как с ними работать, QA и пр. Например в папках GPT (или проектах) если корректно размечать все данные в понятной структуре, то хороший результат практически всегда ожидаем.
"Двигайся быстрее и ломай еще больше вещей."
Эта вариация старой мантры Кремниевой долины звучит в недавних инженерных кругах, когда в чат входит "vibe coding". Да, разработка с помощью ИИ трансформирует то, как мы создаем программное обеспечение, но это не дает свободу отказываться от строгости, проверки или мастерства. "Vibe coding" не является оправданием для некачественной работы.
Давайте признаем хорошее: программирование с помощью ИИ может быть настоящим прорывом. Оно снижает барьеры для новых программистов и не-программистов, позволяя им создавать рабочее программное обеспечение, просто описав то, что им нужно. Это разблокирует творчество – больше людей могут решать собственные проблемы с помощью кастомного программного обеспечения, часть тренда, который некоторые называют декомпозиция персонального программного обеспечения (использование небольших инструментов, созданных с помощью ИИ, вместо универсальных приложений). Даже опытные инженеры могут получить преимущества.
Однако, как скажет вам любой опытный инженер, скорость ничего не значит, если колеса отваливаются на ходу. И именно здесь начинают проявляться трещины – в разрыве между вайбом и реальностью создания поддерживаемого, надежного программного обеспечения.
Жесткая правда: качество не приходит автоматически
Несмотря на весь ажиотаж, vibe coding заслужил немало скептицизма от опытных разработчиков. Основная критика: то, что ИИ может быстро выдать код, не означает, что этот код хороший. Фактически, может быть весьма опасно принимать вывод ИИ за чистую монету. Шутливая жалоба о том, что "два инженера теперь могут создать технический долг на пятьдесят", содержит зерно истины. Непроверенный код, сгенерированный ИИ, может массивно увеличить технический долг, скрытые проблемы, которые делают программное обеспечение хрупким и дорогим в обслуживании.
Многие ранние проекты, созданные в стиле vibe coding, выглядят хорошо на поверхности ("это работает, можно выпускать!"), но скрывают минное поле проблем: отсутствие обработки ошибок, плохая производительность, сомнительные практики безопасности и логически хрупкий код. Можно сказать, такие проекты построены на песке. Я использовал термин "код-карточный домик" – код, который "выглядит завершенным, но разваливается под давлением реального мира". Если вы когда-либо видели первую большую функцию младшего разработчика, которая почти работает, но рушится при одном неожиданном вводе, вы поймете идею. ИИ может быстро выдать много кода, но объем ≠ качество.
"ИИ похож на очень старательного младшего разработчика в вашей команде" - идея, хорошо проиллюстрированная в этом изображении от Forrest Brazeal
Опасности не являются чисто гипотетическими. Рассмотрим поддерживаемость: Кто будет поддерживать модуль, написанный ИИ, если он непонятен или чрезмерно сложен? Если даже оригинальный разработчик полностью не понимает решение ИИ, будущие модификации становятся кошмаром. Безопасность – еще одна огромная проблема – ИИ может генерировать код, который кажется работающим, но имеет уязвимости SQL-инъекций или небезопасную обработку ошибок. Без тщательной проверки они могут проскользнуть в production. Существует также риск подгонки под промпт: ИИ будет делать именно то, о чем вы просите, что может не быть именно тем, что вам действительно нужно. Человеческие кодеры часто корректируют дизайн по мере реализации, обнаруживая ошибочные предположения на ходу. ИИ не заметит эти ошибочные предположения, если человек в цикле не заметит и не исправит их.
Все это не говорит о том, что ИИ не может писать хороший код – иногда может – но скорее о том, что контекст, тщательное изучение и экспертиза необходимы, чтобы отличить хорошее от плохого. В 2025 году мы по сути используем очень энергичного, но неопытного ассистента. Вы бы не позволили разработчику-первокурснику проектировать всю вашу систему без надзора; аналогично, вы не должны слепо доверять коду ИИ без надзора. Ажиотаж вокруг "магии ИИ" должен соответствовать реальности принципов программной инженерии.
Итак, как нам найти баланс? Ключ НЕ в том, чтобы полностью отбросить vibe coding – оно может быть невероятно полезным – но в интеграции его дисциплинированным способом. Инженеры должны подходить к помощи ИИ как к инструменту с известными ограничениями, а не как к мистическому джинну кода. На практике это означает сохранение человека в цепочке и поддержание наших стандартов качества. Давайте рассмотрим, как это выглядит.
ИИ как ваш стажер, а не замена (сохранение человека в цикле)
Чтобы эффективно использовать vibe coding, измените свой образ мышления: относитесь к ИИ как к суперскоростному, но младшему разработчику в вашей команде. Другими словами, вы – старший инженер или руководитель команды – все еще несете ответственность за результат. ИИ может быстро создать первый черновик кода, но вы должны рассмотреть его критическим взглядом, доработать его и проверить, соответствует ли он вашим стандартам качества.
Опытные разработчики, которые успешно используют ИИ, интуитивно следуют этому шаблону. Когда ИИ-помощник предлагает код, они не просто нажимают "принять" и двигаются дальше. Вместо этого они:
Читают и понимают то, что написал ИИ, как если бы это написал младший разработчик в их команде.
Рефакторят код в чистые, модульные части, если вывод ИИ монолитный или беспорядочный (что часто бывает). Старшие инженеры разделят blob ИИ на "меньшие, сфокусированные модули" для ясности.
Добавляют обработку недостающих крайних случаев. ИИ часто пропускает крайние случаи или условия ошибок, поэтому человеку нужно вставить их (проверки на null, валидацию ввода и т.д.)
Усиливают типы и интерфейсы. Если ИИ применил слабую типизацию или допустил «протекающую» абстракцию, разработчик может усилить их, превратив все неявные предположения в явные и формализованные соглашения (контракты).
Ставят под сомнение архитектуру. Выбрал ли ИИ неэффективный подход? Возможно, он использовал метод "грубой силы" там, где должен был использоваться более оптимальный алгоритм, или, возможно, он ввел глобальное состояние там, где достаточно было бы чистой функции. Человек должен критически рассматривать эти решения.
Пишут тесты (или, по крайней мере, вручную тестируют поведение кода). Обращайтесь с кодом ИИ как с любым PR от коллеги: он не принимается, пока не протестирован. Если ИИ написал модульные тесты (некоторые инструменты это делают), дважды проверьте, что эти тесты не поверхностны.
Делая это, вы вносите инженерную мудрость в код, сгенерированный ИИ. Комбинация может быть мощной – ИИ быстро создает много кода, а ваш надзор гарантирует, что он надежен. Фактически, исследования и анекдоты предполагают, что опытные разработчики получают больше пользы от инструментов кодирования с ИИ, чем новички. Причина ясна: опытные имеют знания, чтобы правильно направлять ИИ и исправлять его ошибки. Новички могут быть склонны относиться к ИИ как к непогрешимому авторитету, каким он не является.
Итак, возникает критическое правило: Никогда не принимайте код, написанный ИИ, в вашу кодовую базу без проверки. Относитесь к нему как к коду от нового сотрудника: проверяйте каждую строку, убедитесь, что вы понимаете его. Если что-то не имеет для вас смысла, не предполагайте, что ИИ знает лучше – часто это не так. Либо уточните промпт, чтобы ИИ прояснил, либо перепишите эту часть самостоятельно. Рассматривайте вывод ИИ как черновик, который должен пройти проверку кода (даже если эта проверка только от вас). В команде это означает, что если разработчик использовал ИИ для генерации части кода, он должен быть готов объяснить и защитить его при проверке кода коллегами. "Это работает, поверь мне" не пройдет – команде нужна уверенность, что код понятен и поддерживаем людьми.
Еще одна лучшая практика: сохраняйте людей у руля дизайна. Используйте ИИ для реализации, а не для принятия решений по фундаментальной архитектуре. Например, вы можете использовать vibe coding для быстрого создания CRUD REST API на основе существующей схемы – это хорошо определенная работа. Но вы не должны просить ИИ "спроектировать масштабируемую микросервисную архитектуру для нашего продукта" и затем слепо следовать ей. Дизайн высокого уровня и критические решения должны оставаться под руководством человека, с ИИ в качестве помощника для утомительных частей. По сути, позвольте ИИ обрабатывать черновую работу, а не мозговую работу.
Коммуникация и документация также становятся решающими. Если вы просите ИИ сгенерировать нетривиальный алгоритм или использовать незнакомую библиотеку, найдите время, чтобы задокументировать почему было выбрано это решение (так же, как вы бы сделали, если бы написали его сами после исследования). Будущие разработчики – или вы сами в будущем – не должны оставаться в догадках о намерении, стоящем за кодом, созданным ИИ. Некоторые команды даже записывают промпты, используемые для генерации важного кода, фактически документируя "разговор", который привел к коду. Это может помочь при отладке позже: вы можете видеть предположения, которые были даны ИИ.
В итоге, Человеческий надзор — это не просто «желательно», а строго обязательно. В тот момент, когда вы убираете человека из цикла, вы просто бросаете кости на качество вашего программного обеспечения. Пока ИИ не может по-настоящему заменить целостное понимание опытного инженера (мы еще не там), vibe coding должно быть партнерством: ИИ ускоряет, человек проверяет.
Правила высококачественного vibe coding (практические рекомендации)
Давайте кристаллизуем обсуждение в некоторые действенные правила и лучшие практики для команд, принимающих разработку с помощью ИИ. Думайте об этих правилах как о новом руководстве "двигайся быстро, но не ломай всё" – наборе ограждений для поддержания качества на высоком уровне, когда вы работаете с кодом по вайбу.
Правило 1: Всегда проверяйте код, сгенерированный ИИ – Без исключений. К каждому блоку кода, который производит ИИ, следует относиться так, как будто его написал младший инженер. Делайте проверку кода либо индивидуально, либо с коллегой. Это включает код от Copilot, ChatGPT, Cursor или любого ИИ-агента. Если у вас нет времени на его проверку, у вас нет времени на его использование. Если сливать код ИИ не глядя, проблем не избежать.
Правило 2: Установите стандарты кодирования и следуйте им – Инструменты ИИ будут имитировать любой код, на котором они были обучены, что представляет собой смешанный набор. Определите руководства по стилю вашей команды, архитектурные паттерны и лучшие практики, и убедитесь, что любой код, сгенерированный ИИ, переработан для соответствия. Например, если ваше правило – "все функции нуждаются в комментариях JSDoc и модульных тестах", то вывод ИИ должен получить эти комментарии и тесты, прежде чем он будет готов. Если ваш проект использует определенную архитектуру (скажем, слоистую архитектуру с сервисными/репозиторными классами), не позволяйте ИИ вставлять какие-то специальные вызовы базы данных в код пользовательского интерфейса – исправьте это, чтобы соответствовать вашим слоям. Подумайте о создании проверок линтинга или статического анализа специально для распространенных ошибок ИИ (например, отмечая использование устаревших API или чрезмерно сложных функций). Это автоматизирует контроль качества на вклады ИИ.
Правило 3: Используйте ИИ для ускорения, а не автопилота – На практике это означает использовать vibe coding для ускорения хорошо понятных задач, а не для того, чтобы думать за вас. Отличные применения: генерировать шаблонный код, формировать компонент, переводить с одного языка на другой, создавать черновик простого алгоритма из псевдокода. Рискованные применения: поручить ИИ проектировать ваш модуль с нуля с минимальным руководством или генерировать код в области, которую вы совсем не понимаете (вы не узнаете, если он неправильный). Если вы намерены сохранить код, не оставайтесь в режиме вайба – переключитесь в инженерный режим и укрепите его.
Правило 4: Тестируйте, тестируйте, тестируйте – ИИ не гарантирует правильность волшебным образом. Пишите тесты для всех критических путей кода, написанного ИИ. Если ИИ написал код, он может даже помочь вам написать некоторые тесты – но не полагайтесь исключительно на тесты, сгенерированные ИИ, так как они могут пропустить крайние случаи (или могут ложно проходить из-за той же ошибочной логики). Делайте также ручное тестирование, особенно для пользовательских функций: пройдитесь по пользовательскому интерфейсу, попробуйте странные входные данные, посмотрите, как он себя ведет. Многие приложения, созданные по принципу vibe coding, хорошо работают для "счастливого пути", но разваливаются при неожиданном вводе – вы хотите поймать это до того, как это сделают ваши пользователи.
Правило 5: Итерируйте и улучшайте – Не принимайте первое, что дает вам ИИ, если оно не удовлетворительно. Vibe coding – это итеративный диалог. Если начальный вывод неуклюжий или запутанный, вы можете попросить ИИ улучшить его ("упростите этот код", "разделите это на меньшие функции" и т.д.). Или вы можете взять черновик и переработать его самостоятельно. Часто хороший подход – использование ИИ в циклах: промпт для реализации, выявление слабостей, затем либо промпт исправлений, либо ручная корректировка, и повторение.
Правило 6: Знайте, когда сказать нет – Иногда vibe coding просто не является подходящим инструментом. Часть его ответственного использования – это распознавание сценариев, когда требуется ручное кодирование или более глубокая дизайнерская работа. Например, если вы имеете дело с критическим защитным модулем, вы, вероятно, хотите тщательно спроектировать его и, возможно, использовать ИИ только для помощи с небольшими частями (если вообще). Или если ИИ продолжает выдавать запутанное решение простой проблемы, остановитесь и напишите его сами – вы можете сэкономить время в конечном счете. Важно не стать чрезмерно зависимым от ИИ для решения каждой проблемы. Не позволяйте фразе «Это сделал ИИ» стать оправданием тому, что вы не понимаете свой собственный код. Если после нескольких попыток ИИ не производит то, что вам нужно, возьмите контроль обратно и кодируйте это старомодным способом; по крайней мере, у вас будет полное понимание тогда.
Правило 7: Документируйте и делитесь знаниями – Убедитесь, что любой код, поступающий от ИИ, документирован так же тщательно, как и написанный вручную код (если не более). Если были неочевидные решения или если вы подозреваете, что другие могут быть сбиты с толку тем, что произвел ИИ, добавьте комментарии. В командных обсуждениях будьте открыты о том, что было сгенерировано ИИ, а что нет. Это помогает рецензентам уделять больше внимания этим разделам.
Следуя этим правилам, команды могут наслаждаться преимуществами продуктивности vibe coding, смягчая худшие риски. Думайте об этом как о дополнении человеческих разработчиков, а не их замене. Цель состоит в том, чтобы co-создавать с ИИ: позволить ему обрабатывать повторяющуюся тяжелую работу на высокой скорости, в то время как люди занимаются творческими и критическими мыслительными частями.
Когда vibe coding работает (и когда разваливается)
Также важно признать где vibe coding сияет и где нет. Не каждый проект или задача одинаково подходят для рабочего процесса, управляемого ИИ. Вот разбивка, взятая из отраслевых обсуждений и раннего опыта:
👍 Отличные варианты использования:
Быстрое прототипирование является, пожалуй, лучшей областью применения vibe coding. Если у вас есть идея для небольшого приложения или функции, использование ИИ-помощника для быстрой сборки прототипа или концепта может быть невероятно эффективным. В подобных ситуациях не страшно, если код получился немного «костыльным»; вы просто хотите подтвердить идею. Многие инженеры добились успеха в выходных проектах, используя только ИИ для кодирования – забавный способ быстро проверить концепцию. Еще один хороший вариант использования – одноразовые скрипты или внутренние инструменты: например, скрипт для анализа файла журнала, небольшой инструмент для автоматизации личной задачи или внутренняя панель мониторинга для вашей команды. Они обычно имеют низкие ставки; если скрипт сломается, это не конец света. Здесь vibe coding может сэкономить время, потому что вам не нужно совершенство производственного уровня, просто что-то, что работает сейчас.
Vibe coding также хорошо работает для обучения и исследования. Если вы работаете с новым языком или API, просьба к ИИ сгенерировать примеры может ускорить ваше обучение. (Конечно, проверяйте вывод ИИ по официальной документации!) В исследовательском режиме, даже если код ИИ не идеален, он дает вам материал для изучения и обучения. Это как иметь ассистента преподавателя, который может показать вам попытки, которые вы затем улучшаете.
Кроме того, генерация кода ИИ может преуспевать в структурированных, шаблонных задачах. Нужно создать 10 похожих классов данных? Или реализовать шаблонный CRUD-слой? ИИ отлично справляется с такого рода механическими повторениями, освобождая вас от рутины. Пока шаблон ясен, ИИ будет следовать ему и сэкономит вам нажатия клавиш (просто проверьте, что он правильно следовал шаблону).
👎 Не очень хорошие варианты использования:
С другой стороны, программное обеспечение корпоративного уровня и сложные системы – это те области, где vibe coding часто терпит неудачу. Что-либо, требующее глубокого понимания бизнес-логики, высокой параллельности, строгой безопасности или соответствия требованиям, не следует полностью доверять генерации ИИ. ИИ не знает ваших бизнес-ограничений или требований к производительности, если вы явно не укажете их (и даже тогда он может не получить это правильно). Например, финтех-приложение, обрабатывающее платежи, или аэрокосмическая система управления должны соответствовать стандартам, которые современный ИИ просто не оборудован гарантировать. В этих областях ИИ может помогать в частях, но человеческий опыт и тщательный контроль качества имеют первостепенное значение для конечного продукта.
Vibe coding также испытывает трудности с долгосрочной поддерживаемостью. Если вы строите кодовую базу, которая будет жить годами и над которой будут работать многие разработчики, начинать ее с разнородного набора кода, созданного ИИ, может быть плохим фундаментом. Без сильного руководства архитектура может быть непоследовательной. Часто лучше потратить дополнительное время заранее на построение чистого каркаса (с помощью ИИ или без него), чем латать весь продукт через последовательные промпты ИИ. Многие ранние последователи заметили, что начальное время, сэкономленное на vibe coding, может быть потеряно позже во время очистки кода и рефакторинга, когда проект должен масштабироваться или адаптироваться.
Еще один сценарий, к которому следует относиться с осторожностью, – это критические алгоритмы или оптимизации. ИИ может произвести алгоритм сортировки или запрос к базе данных, конечно, – но если вам нужно, чтобы он был высоко оптимизирован (например, пользовательская процедура управления памятью или алгоритм, который должен работать за сублинейное время), вы в той области, где человеческая изобретательность и глубокое понимание все еще превосходят. ИИ может дать вам что-то, что работает на малых данных, но разваливается при масштабировании, и он не обязательно предупредит вас об этом. Человеческий инженер по производительности проектировал бы и тестировал с учетом этих соображений с самого начала.
Наконец, любая ситуация, где объяснимость и ясность являются главными приоритетами, может быть не идеальной для vibe coding. Иногда вам нужен код, который другие люди (или аудиторы) могут легко прочитать и понять. Если ИИ создает запутанный подход, это может затруднить понимание. Пока ИИ не сможет надежно создавать простой и ясно структурированный код (к чему он не всегда мотивирован – иногда он чрезмерно многословен или странно абстрактен), необходимо человеческое вмешательство, чтобы сохранить вещи простыми.
В итоге, vibe coding – мощный ускоритель, но не серебряная пуля.
Используйте его там, где скорость имеет большее значение, чем шлифовка, и где у вас есть возможность итерировать и исправлять. Избегайте использования его как однократного решения для критически важного программного обеспечения – это как нанять гонщика для вождения школьного автобуса; неправильный инструмент для работы. Возможно, однажды ИИ будет настолько продвинутым, что vibe coding действительно сможет быть стандартом для всей разработки – но сегодня не тот день. Сегодня он работает лучше всего как помощник для правильных проблем и с правильным надзором.
Заключение: вайбируй ответственно - принимай вайбы, но уважай ремесло
Vibe coding и разработка программного обеспечения с помощью ИИ в целом представляет собой захватывающий скачок вперед в наших инструментах. Он здесь, чтобы остаться, и будет только становиться более сложным отсюда. Прогрессивные инженерные команды не должны игнорировать его – те, кто эффективно использует ИИ, вероятно, будут опережать тех, кто не делает этого, так же как команды, которые приняли более ранние волны автоматизации и лучшие фреймворки, опережали тех, кто писал все с нуля. Сообщение этой статьи не в том, чтобы отвергать vibe coding, а в том, чтобы подходить к нему с открытыми глазами и с сохранением инженерной дисциплины.
Главный вывод в том, что скорость ничего не значит без качества. Более быстрая поставка богатого ошибками, неподдерживаемого кода – это ложная победа – вы просто быстрее движетесь к обрыву. Лучшие инженеры будут балансировать между двумя: используя ИИ для более быстрого движения без поломки вещей (по крайней мере, не больше, чем мы уже ломаем!). Это о нахождении той точки, где ИИ делает тяжелую работу, а люди обеспечивают, чтобы все держалось правильно.
Для технических лидеров и инженерных менеджеров призыв к действию ясен: задайте тон, что ИИ – это инструмент, который следует использовать ответственно. Поощряйте экспериментирование с vibe coding, но также установите ожидания (возможно, через некоторые из правил, которые мы изложили), которые защищают вашу кодовую базу. Сделайте обзоры кода обязательными для вкладов, сгенерированных ИИ, создайте среду, где задавать "эй, это имеет смысл?" приветствуется, и инвестируйте в повышение квалификации вашей команды для эффективной работы с ИИ. Это может даже означать обучение разработчиков тому, как писать хорошие промпты или как критически оценивать предложения ИИ. Это новый набор навыков, аналогичный переходу на языки высокого уровня или на распределенный контроль версий в прошлом – те, кто адаптируются раньше, пожнут выгоды.
Мы также должны сохранять в перспективе, что действительно важно в программной инженерии: решение проблем пользователей, создание надежных систем и непрерывное обучение. Vibe coding – средство для достижения цели, а не самоцель. Если это помогает нам лучше и быстрее обслуживать пользователей, фантастика. Но если это соблазняет нас пропустить должную осмотрительность, от которой пользователи в конечном счете зависят (например, качество и безопасность), то мы должны сдерживать это. Основы – ясное мышление, понимание требований, проектирование для изменений, тщательное тестирование – остаются такими же важными, как всегда, если не более.
В итоге, пожалуй, этос должен быть: "Двигайся быстро, но не ломай вещи – или если ломаешь, убедись, что знаешь, как их исправить." Используйте вайбы для кодирования со скоростью света, но подкрепите это прочным фундаментом инженерного совершенства. ИИ может сосуществовать с мастерством; фактически, в руках мастера он может быть мощным резцом. Но рука мастера все еще необходима для направления этого резца для создания чего-то действительно долговечного и хорошо сделанного.
Итак, продолжайте вайбировать, разработчики – просто делайте это с осторожностью. Примите будущее, но не отказывайтесь от принципов, которые привели нас сюда. Vibe coding не является оправданием для некачественной работы; скорее, это возможность поднять то, чего мы можем достичь когда мы объединяем человеческое суждение с генеративной мощью машины. Команды, которые усвоят это, не только будут двигаться быстро – они будут строить вещи, достойные сохранения.
Счастливого кодирования, и поддерживайте вайбы высокими и качество еще выше.