Что делать, если проект после вайб-кодинга начал ломаться

Что делать, если проект после вайб-кодинга начал ломаться

Краткий ответ: если проект после вайб-кодинга начал ломаться, не просите AI сразу “переписать всё”. Сначала зафиксируйте рабочее состояние, сделайте backup, создайте копию проекта, включите логи, найдите конкретный сценарий поломки, проверьте безопасность, зависимости, базу данных, WordPress-хуки, AJAX, REST API, PHP-ошибки и только потом исправляйте код маленькими проверяемыми шагами.

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

Если проект сделан на WordPress, WooCommerce, PHP, jQuery, HTML, CSS и MySQL, особенно важно не трогать всё сразу. Одна “быстрая” правка может сломать форму, оплату, админку, шорткод, AJAX-запрос, базу данных или доступ пользователей.

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

Причина

Проект после вайб-кодинга ломается не потому, что AI “плохой”. Чаще причина в том, что код создавался без нормального контроля: задача менялась на ходу, промпты были общими, файлы переписывались большими кусками, старые решения не удалялись, а новые функции добавлялись поверх уже нестабильной логики.

В WordPress это особенно заметно. AI может создать шорткод, AJAX, таблицу в базе, обработчик формы, админскую страницу или WooCommerce-хук, но не всегда учитывает nonce, capability checks, sanitization, escaping, prefix таблиц, конфликт имён функций, порядок загрузки хуков и совместимость с темой.

Типовые причины поломок:

• нет backup и версии, к которой можно откатиться;
• AI переписал рабочий файл целиком вместо точечной правки;
• одна функция отвечает сразу за вывод, сохранение, валидацию и SQL;
• дублируются функции, классы, обработчики AJAX и CSS-селекторы;
• нет проверки прав пользователя перед сохранением данных;
• SQL-запросы собраны строками без подготовки;
• данные выводятся без escaping;
• ошибки скрыты, debug.log не проверяется;
• код работает только на одном тестовом сценарии;
• нет обработки пустых данных, ошибок API, отсутствующих полей и нестандартных ролей;
• новая функция ломает старую, потому что нет карты зависимостей;
• проект содержит куски кода, назначение которых уже никто не понимает.

Диагностика

Диагностика начинается не с переписывания кода, а с ответа на вопрос: что именно ломается, где, после какого действия и в каком окружении.

Симптом	Вероятная причина	Что проверить
После новой AI-правки перестал работать старый функционал	переписан общий файл, изменены функции или селекторы	diff изменений, старую версию файла, зависимости между функциями
Появилась критическая ошибка WordPress	PHP fatal error, конфликт функции, неверный хук	debug.log, error_log, последний изменённый PHP-файл
Не сохраняются данные	ошибка AJAX, nonce, capability, SQL, имя action	Network, admin-ajax.php, PHP-лог, запрос к базе
Форма отправляется, но данные пустые	не совпадают name полей, JS-селекторы или структура POST	HTML формы, console.log, $_POST, обработчик PHP
Работает только у администратора	неправильные роли или capability checks	current_user_can(), роли, права, nonce
В админке всё работает, на фронте нет	скрипт подключён только в wp-admin или конфликт темы	wp_enqueue_scripts, admin_enqueue_scripts, консоль браузера
Сайт стал медленным	тяжёлые циклы, запросы в цикле, отсутствие индексов	SQL-запросы, Query Monitor, wp_options, autoload
После обновления плагина всё сломалось	AI-код завязан на внутреннюю логику чужого плагина	хуки, changelog, debug.log, совместимость версий
Появились проблемы безопасности	нет sanitization, escaping, nonce, проверки прав	формы, AJAX, REST API, загрузку файлов, SQL-запросы

Если после AI-правки сайт показывает критическую ошибку, сначала восстановите доступ по инструкции критическая ошибка WordPress: что делать.

Решение

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

1. Остановите генерацию новых функций. Пока проект ломается, новые AI-правки поверх старых только увеличивают хаос.
2. Сделайте backup. Сохраните файлы, базу данных, текущий архив проекта и список последних изменений.
3. Создайте тестовую копию. Не исправляйте нестабильный проект сразу на рабочем сайте.
4. Найдите последнюю рабочую версию. Через Git, backup, архив, хостинг или старую копию файла.
5. Составьте карту функций. Какие файлы за что отвечают: админка, фронт, AJAX, база, формы, WooCommerce, cron.
6. Включите логи. WordPress debug.log, PHP error_log, консоль браузера, Network, SQL-логи.
7. Выделите критические сценарии. Вход, сохранение, форма, заказ, оплата, отправка письма, импорт, экспорт, фильтр.
8. Проверьте безопасность. Nonce, права пользователей, SQL, XSS, загрузка файлов, REST API, AJAX.
9. Исправляйте маленькими шагами. Один баг — одна правка — одна проверка.
10. Не давайте AI переписывать весь файл без причины. Просите точечный diff и объяснение, что меняется.
11. После каждой правки тестируйте старые сценарии. Вайб-кодинг часто ломает не то место, которое исправлялось.
12. Зафиксируйте новую стабильную основу. После стабилизации сделайте чистый backup и начните вести историю изменений.

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

Код

Важно: код ниже нужен для диагностики. Перед изменением wp-config.php, functions.php, плагина или базы данных сделайте backup. Не включайте вывод ошибок посетителям сайта.

Куда вставлять: в файл wp-config.php, выше строки /* That’s all, stop editing! */. Код включает запись ошибок в debug.log, но не показывает их пользователям.

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

После этого проверьте файл:

/wp-content/debug.log

Если проект на WordPress и есть доступ к WP-CLI, проверьте активные плагины, тему, cron и URL сайта:

wp core version
wp plugin list
wp theme list
wp cron event list
wp option get siteurl
wp option get home

Если нужно быстро найти опасные места в AI-сгенерированном PHP-коде, можно выполнить поиск по проекту. Команды запускаются на сервере или локально из корня проекта:

grep -R "eval(" wp-content/ -n
grep -R "base64_decode" wp-content/ -n
grep -R "$_POST" wp-content/ -n
grep -R "$_GET" wp-content/ -n
grep -R "$wpdb->query" wp-content/ -n
grep -R "admin_ajax" wp-content/ -n
grep -R "wp_ajax_" wp-content/ -n
grep -R "wp_redirect" wp-content/ -n

Важно: найденная строка не всегда является ошибкой. Проверяйте контекст: есть ли nonce, current_user_can(), sanitize_text_field(), esc_html(), esc_url(), wp_prepare или $wpdb->prepare().

Пример безопасной проверки AJAX-запроса в WordPress. Куда вставлять: в кастомный плагин или functions.php дочерней темы, если это временная диагностика.

add_action('wp_ajax_sc_test_action', 'sc_test_action_handler');

function sc_test_action_handler() {
    if (!current_user_can('manage_options')) {
        wp_send_json_error(array(
            'message' => 'Недостаточно прав.'
        ), 403);
    }

    check_ajax_referer('sc_test_nonce', 'nonce');

    $title = isset($_POST['title']) ? sanitize_text_field(wp_unslash($_POST['title'])) : '';

    if ($title === '') {
        wp_send_json_error(array(
            'message' => 'Пустое значение title.'
        ), 400);
    }

    wp_send_json_success(array(
        'message' => 'Проверка прошла успешно.',
        'title'   => $title
    ));
}

После диагностики на рабочем сайте отключите debug-режим:

define('WP_DEBUG', false);
define('WP_DEBUG_LOG', false);
define('WP_DEBUG_DISPLAY', false);

Что проверить в AI-сгенерированном коде

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

Структура

• понятно ли, какой файл за что отвечает;
• нет ли одинаковых функций в разных файлах;
• не смешаны ли HTML, SQL, логика и обработка AJAX в одной функции;
• можно ли удалить блок кода без поломки всего проекта;
• есть ли единый стиль названий функций, классов, CSS и JS.

Безопасность

• есть ли nonce в формах и AJAX;
• проверяются ли права пользователя через current_user_can();
• очищаются ли входные данные через sanitize-функции;
• экранируется ли вывод через esc_html(), esc_attr(), esc_url();
• подготовлены ли SQL-запросы через $wpdb->prepare();
• нет ли загрузки файлов без проверки типа и прав;
• нет ли eval, shell_exec, base64_decode без явной причины.

Надёжность

• что происходит, если API не ответил;
• что происходит, если данных нет;
• что происходит, если пользователь не авторизован;
• что происходит, если таблица базы не создана;
• что происходит, если плагин-зависимость отключён;
• что происходит после обновления WordPress или WooCommerce.

Производительность

• нет ли SQL-запросов внутри больших циклов;
• не загружаются ли все записи сразу без пагинации;
• не вызывается ли внешний API при каждом открытии страницы;
• не растёт ли wp_options из-за autoload-записей;
• не создаются ли лишние AJAX-запросы при каждом клике;
• есть ли кеширование там, где оно безопасно.

Когда можно исправлять точечно, а когда лучше переписать

Не каждый AI-проект нужно переписывать полностью. Иногда достаточно стабилизировать 2–3 опасных места. Но бывают случаи, когда точечные правки уже дороже нормальной переработки.

Состояние проекта	Что лучше делать	Почему
Есть один понятный баг	точечное исправление	риск небольшой, если структура проекта понятна
Ломается после каждой новой функции	аудит и рефакторинг	проблема уже в архитектуре, а не в одном баге
Нет проверки прав, nonce и sanitization	сначала закрыть безопасность	проект может быть уязвимым для пользователей и ботов
Файлы дублируют друг друга	очистка структуры	AI мог создать несколько разных реализаций одной логики
Код никто не понимает	документация + разбор зависимостей	без понимания нельзя безопасно развивать проект
Проект работает с оплатой, заказами или личными данными	аудит безопасности до новых функций	ошибка может повлиять на деньги, клиентов и данные
AI переписал ядро логики несколько раз	частичное или полное переписывание	дешевле заложить стабильную основу, чем чинить хаос

Результат

После нормальной стабилизации проект должен перестать ломаться от каждой мелкой правки. Важно получить не “вроде работает”, а проверяемое состояние.

• есть backup и понятная точка отката;
• проект запускается на тестовой копии;
• включены и проверены логи;
• найдены критические сценарии;
• понятно, какие файлы за что отвечают;
• удалены дубли функций и мёртвый код;
• закрыты основные риски безопасности;
• AJAX, REST API, формы и SQL проверены;
• основные сценарии протестированы после правок;
• есть список задач: срочно, позже, можно не трогать;
• AI используется как помощник, а не как автономный разработчик без проверки.

Дополнительные способы

Git перед новыми правками

Если проекта ещё нет в Git, начните хотя бы с локального репозитория. Это позволит видеть, что именно изменил AI, и быстро откатывать опасные правки.

Правило маленьких изменений

Один промпт — одна задача — один файл или один небольшой участок логики. Чем больше задача, тем выше риск, что AI начнёт переписывать рабочие части.

Отдельный файл с правилами проекта

Создайте короткий документ: структура проекта, стиль кода, запрет на переписывание файлов целиком, правила безопасности, правила jQuery, AJAX и базы данных. Давайте его AI перед каждой задачей.

Тестовые сценарии

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

Staging-копия

Все крупные AI-правки сначала проверяйте на копии сайта. На рабочем сайте можно вносить только уже проверенное решение.

Код-ревью перед внедрением

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

Частые ошибки

• Просить AI “исправь всё”. Обычно это приводит к большой перезаписи и новым ошибкам.
• Не сохранять рабочую версию. Без backup или Git сложно понять, когда проект сломался.
• Тестировать только один сценарий. AI-код часто работает на примере, но ломается на пустых данных или другой роли пользователя.
• Не проверять безопасность. Рабочая форма без nonce, проверки прав и sanitization — это риск.
• Смешивать всё в functions.php. Со временем файл становится опасным центром всех ошибок.
• Разрешать AI переписывать файл целиком. Так легко потерять рабочую логику.
• Не читать diff. Даже маленький промпт может изменить больше, чем вы просили.
• Оставлять дубли функций. Это вызывает fatal error и непредсказуемое поведение.
• Не проверять базу данных. AI может создать таблицу, но не учесть индексы, prefix, миграции и обновления.
• Игнорировать старые ошибки в debug.log. Они могут стать критическими после новой правки.

Диагностика проблем

Если проект продолжает ломаться, проверьте его как систему, а не как набор отдельных файлов.

Проблема	Что это ломает	Как исправлять
Функции объявлены без уникального префикса	конфликты с темой и плагинами	добавить префиксы или классы, проверить дубли
AJAX без nonce	безопасность и несанкционированные действия	добавить wp_create_nonce() и check_ajax_referer()
Нет current_user_can()	пользователь может выполнить чужое действие	добавить проверку прав перед сохранением
SQL без prepare	риск SQL-инъекции и ошибок данных	использовать $wpdb->prepare()
Вывод без escaping	риск XSS и сломанная верстка	использовать esc_html(), esc_attr(), esc_url()
Логика завязана на CSS-класс	фронтенд ломается после изменения верстки	использовать data-атрибуты и стабильные селекторы
Все данные грузятся одним запросом	медленная страница и нагрузка на базу	добавить пагинацию, лимиты, индексы
Внешний API вызывается при каждом открытии	зависания, лимиты API, долгий TTFB	добавить кеширование и обработку ошибок
Нет обработки ошибок	пользователь видит пустоту или белый экран	добавить проверки, fallback и логирование

Мини-чеклист стабилизации

• сделать backup файлов и базы;
• создать тестовую копию;
• включить debug.log;
• найти последнюю рабочую версию;
• составить список критических сценариев;
• проверить PHP fatal errors;
• проверить JavaScript console;
• проверить AJAX и REST API;
• проверить SQL-запросы;
• проверить nonce и права пользователей;
• проверить sanitization и escaping;
• удалить дубли функций;
• разделить большие функции;
• зафиксировать изменения в Git или архиве;
• после стабилизации сделать новый чистый backup.

FAQ

Почему проект после вайб-кодинга начал ломаться?

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

Что делать в первую очередь?

Остановить новые правки, сделать backup, создать тестовую копию, включить логи, найти конкретный сценарий поломки и определить последний рабочий вариант проекта.

Нужно ли переписывать проект полностью?

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

Можно ли снова использовать AI для исправления?

Можно, но не в режиме “сделай всё”. Лучше давать маленькие задачи: найти ошибку, объяснить риск, предложить diff, проверить функцию, написать тестовый сценарий. Финальное решение должен проверить человек.

Как понять, что AI-код опасен?

Опасные признаки: нет nonce, нет проверки прав, SQL без prepare, вывод без escaping, eval/base64_decode без причины, загрузка файлов без проверки, дубли функций, работа только у администратора и отсутствие обработки ошибок.

Что делать, если проект на WordPress?

Проверьте debug.log, functions.php, кастомные плагины, хуки, AJAX, REST API, wp_options, SQL-запросы, права пользователей, тему, дочернюю тему и конфликты с плагинами.

Почему после одной AI-правки ломается другое место?

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

Как безопасно давать AI новые задачи?

Давать маленькие задачи, запрещать переписывать файл целиком без разрешения, просить формат “было/стало”, требовать объяснение рисков и проверять diff перед вставкой.

Что важнее: рефакторинг или новые функции?

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

Как избежать повторения проблемы?

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

Вывод

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

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