5 правил профессионального вайбкодинга, которые делают работу безопаснее и надёжнее на 90%

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

Но пока что искусственный интеллект работает не идеально и может допускать ошибки и уязвимости. Чтобы увеличить надёжность результатов работы ИИ, есть несколько правил. Применять их можно даже без опыта разработки, достаточно использовать те же ИИ-инструменты. Что это за правила, рассказывает руководитель больших данных, высоконагруженных систем и машинного обучения Битрикс24 Александр Сербул.

Александр Сербул

Руководитель больших данных, высоконагруженных систем и машинного обучения Битрикс24

Когда вайбкодинг — это риск

Искусственный интеллект позволяет нам писать код на любом языке: описать желаемую цель простым языком и получить работающий результат. Это потрясающая возможность. Но при этом нужно помнить ограничения этой технологии.

Нейросеть — это инструмент, который работает только внутри процесса разработки, а не вместо него. Изначально вайбкодинг был инструментом для создания прототипов и MVP — первых версий продукта с минимальными возможностями.

Создатель AI-агента Open Claw Питер Штайнбергер говорит: «Вайбкодинг — это навык, который прокачивается». Это значит, что использовать публично и в открытом доступе под нагрузками для критически важных процессов написанный ИИ код можно только при полном понимании того, как он работает.

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

Правило 1: выбираем строго типизированный язык

Программа работает с разными типами данных: числами, строками, логическими значениями.

Некоторые языки программирования более гибкие, например PHP, Python или JavaScript. В них можно менять типы данных по ходу работы программы — это может быть удобно разработчику, но для ИИ повышается вероятность допустить ошибку. Другой вариант — типизированные языки, которые заставляют разработчика сразу указывать, какие типы данных где находятся: TypeScript, Java, Kotlin, Rust. Человеку с таким языком работать труднее, но нейросети их понимают хорошо, и количество ошибок нейросети резко снижается.

Для гибких языков программирования решение тоже есть: можно добавить дополнительные аннотации типов и проверки-валидаторы типов данных. Пример такого валидатора — MyPy для Python.

В работе это будет выглядеть так: нам нужна функция, которая должна складывать числа, но нейросеть случайно передаёт туда строку. Без проверки это приведёт к ошибке уже во время работы. С типизацией система сразу скажет: «Сюда можно передавать только числа».

Поэтому первое правило для профессионального вайбкодинга: выбирать строго типизированный язык или добавлять валидаторы типов данных.

Правило 2: включаем базовую проверку с помощью линтеров

Линтеры — это инструменты, которые автоматически проверяют код: стиль, потенциальные ошибки и уязвимости. Они помогают сделать код проще и понятнее, а значит — снизить вероятность ошибок.

Написать работающую программу можно по-разному. Одним из важных навыков для программиста считается писать понятный код. Это важно не только при работе в команде, но и при одиночной разработке: программа должна оставаться понятной, если вы открываете её через месяц или полгода. Именно поэтому годами создаются правила стиля в программировании, которые помогают писать понятный людям код.

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

Поэтому берем за правило всегда добавлять линтеры для базовой проверки.

Правило 3: пишем тесты

Есть ещё одна проблема, которую в 1936 году сформулировал британский математик Алан Тьюринг. Её смысл в том, что невозможно написать программу, которая гарантированно определит корректность другой программы.

Хотя полностью быть уверенным в правильной работе компьютерной системы нельзя, некоторые конкретные случаи проверить всё-таки можно. Для проверки этих случаев пишут другие программы — тесты. Они сильно снижают количество возможных ошибок, и нейросети хорошо справляются с созданием таких проверочных программ.

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

Правило номер три: добавляем в запросы к нейросети создание тестов, которые должны запускаться при любом изменении кода. Это строгое правило, которое является частью разработки.

Правило 4: считаем тестовое покрытие

Следующий шаг, который нужен для надёжного вайбкодинга: общее тестовое покрытие.

Покрытие показывает, какая часть приложения проверяется тестами. Иначе может оказаться так, что тесты есть, но значительную часть кода они не проверяют. Покрытие измеряется в процентах. Например, покрытие в 75% может означать, что тесты проверяют 750 строк из 1000.

Покрытие — это показатель не качества тестов, а того, насколько код вообще проверяется. Даже 100% покрытие не гарантирует отсутствие ошибок, но его отсутствие почти всегда означает, что часть системы вообще не проверяется.

Правило четвёртое: считайте процент тестового покрытия. Минимальный процент — 70-80% программы.

Правило 5: проверяем входные данные, фреймворки и зависимости

Есть ещё несколько дополнительных ограничений, которые делают систему более устойчивой.

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

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

Минимальное количество фреймворков. Чтобы разработка была проще и быстрее, программисты используют инструменты с готовыми фрагментами кода: библиотеки и фреймворки. С фреймворком одна команда может заменить несколько десятков строк кода.

Проблема в том, что фреймворк — это отдельная сложная программа, и почти к каждому есть сложная объёмная документация. Фреймворк — это сложная внешняя система со своей логикой и обновлениями. Чем больше фреймворков — тем сложнее поддержка и выше риск ошибок. Поэтому если задачу можно решить за 50-100 строк обычного кода, не нужно пытаться сократить их за счёт добавления фреймворка.

Контроль зависимостей. Каждый дополнительный инструмент в программе будет новой зависимостью, потому что без него приложение не работает. Примеры зависимостей — библиотеки и фреймворки.

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

При этом зависимости нужно всё время контролировать: проверять, что используются актуальные версии, и что в них не обнаружено уязвимостей.

Чтобы упростить процесс такого контроля за продуктом, можно использовать специально подготовленные платформы для ИИ-разработки, вроде Битрикс24 VibeCode или Replit. Такие платформы работают по разному: выстраивают ограничения для агентов, другие сразу направляют ИИ для работы с конкретными технологиями. Ещё в них используются техники минимизации рисков: серверы с запущенными приложениями недоступны для атаки снаружи, а данные из приложений фильтруются через слой защищённого официального REST API.

Пятое правило: проверять входные данные, минимизировать количество фреймворков и постоянно обновлять зависимости и проверять их на уязвимости.

Насколько надёжнее становится результат вайбкодинга

Со всеми перечисленными правилами-этапами можно выстроить достаточно надёжный процесс. Соблюдая ограничения, нейросеть создаёт контролируемый, поддерживаемый и намного более безопасный код.

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