Почему код от ChatGPT работает, но его сложно поддерживать

Почему код от ChatGPT работает, но его сложно поддерживать

Краткий ответ: код от ChatGPT часто работает в одном конкретном сценарии, но его сложно поддерживать, потому что он может быть написан без полной архитектуры проекта, без проверки крайних случаев, без единого стиля, без тестов, без нормальной обработки ошибок и без учёта будущих изменений. В WordPress это особенно заметно: AI может сгенерировать рабочий шорткод, AJAX, форму или плагин, но не всегда правильно учитывает хуки, безопасность, nonce, права пользователей, SQL, кеш, WooCommerce и совместимость с темой.

Главная проблема не в том, что ChatGPT пишет “плохой код”. Проблема в том, что код часто создаётся кусками: сегодня форма, завтра AJAX, потом сохранение в базу, потом экспорт, потом фильтр. Если нет общей структуры, проект начинает работать как набор заплаток.

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

Причина

ChatGPT хорошо решает локальные задачи: написать функцию, пример формы, SQL-запрос, обработчик AJAX, кусок CSS или PHP-фрагмент. Но поддерживаемость кода зависит не только от того, “заработало сейчас”.

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

Код от ChatGPT часто становится сложным в поддержке по таким причинам:

• нет общей архитектуры проекта;
• каждый новый фрагмент пишется как отдельное решение;
• одна функция делает сразу вывод HTML, обработку POST, SQL и проверку прав;
• нет единого стиля названий функций, классов, CSS и JS;
• не учитываются старые части проекта;
• AI может заменить рабочий код, чтобы добавить новую функцию;
• нет карты зависимостей между файлами;
• нет нормального логирования ошибок;
• нет тестовых сценариев;
• код работает только на “идеальных” данных;
• не проверяются пустые значения, ошибки API, отсутствующие поля и разные роли пользователей;
• в WordPress-коде часто забываются nonce, current_user_can(), sanitization, escaping и $wpdb->prepare().

Почему код работает, но становится опасным

Рабочий код и поддерживаемый код — не одно и то же. Код может успешно выполнить задачу один раз, но быть неудобным, нестабильным и рискованным для дальнейшей разработки.

Код работает сейчас	Но плохо поддерживается	Что это ломает позже
Форма отправляет данные	нет nonce и проверки прав	безопасность, спам, несанкционированные действия
Данные сохраняются в базу	SQL собран строкой без prepare	безопасность, ошибки базы, риск SQL-инъекции
Шорткод выводит HTML	HTML, SQL и логика смешаны в одной функции	доработки, поиск ошибок, повторное использование
AJAX возвращает ответ	нет обработки ошибок и статусов	отладку, UX, интеграции, повторные запросы
Фильтр работает на тесте	нет пагинации и лимитов	скорость, нагрузку на MySQL, wp-admin
JS-код кликает по кнопке	селектор завязан на случайный класс темы	работу после изменения верстки
Плагин запускается	функции без уникального префикса	конфликты с темой и другими плагинами

Диагностика

Диагностику AI-кода нужно начинать не с вопроса “что переписать”, а с вопроса “что именно делает этот код и какие части он может сломать”.

Проверьте проект по таким признакам:

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

Признак	Что означает	Что делать
Каждая новая правка ломает старую функцию	нет архитектуры и зависимостей	составить карту файлов и сценариев
Код работает только у администратора	не проверены роли и права пользователей	проверить current_user_can() и сценарии разных ролей
В файле functions.php сотни строк AI-кода	вся логика смешана в одном месте	вынести код в отдельный плагин или модули
AJAX работает нестабильно	ошибка nonce, action, URL, JS или PHP-ответа	проверить Network, admin-ajax.php и debug.log
База быстро растёт	данные сохраняются без контроля	проверить таблицы, индексы, autoload и очистку
Появляются PHP notice/warning	код не проверяет пустые данные	добавить проверки isset(), empty(), типы и fallback
Разработчик боится менять код	нет понятной структуры и точки отката	добавить Git, backup и поэтапный рефакторинг

Решение

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

1. Сделайте backup. Сохраните файлы и базу данных перед любыми правками.
2. Зафиксируйте последнюю рабочую версию. Через Git, архив, backup хостинга или копию файла.
3. Остановите новые AI-правки. Пока код нестабилен, новые функции только увеличат хаос.
4. Разделите проект на зоны. Админка, фронтенд, AJAX, база данных, формы, WooCommerce, cron, интеграции.
5. Включите диагностику. debug.log, error_log, консоль браузера, Network, Query Monitor.
6. Найдите критические сценарии. Вход, отправка формы, сохранение, заказ, оплата, экспорт, импорт, фильтрация.
7. Проверьте безопасность. Nonce, capability checks, sanitization, escaping, SQL prepare.
8. Уберите дубли. Одинаковые функции, повторные обработчики AJAX, лишние CSS/JS, старые версии кода.
9. Разделите большие функции. Отдельно получение данных, проверка, сохранение, вывод HTML.
10. Исправляйте маленькими шагами. Одна проблема — одна правка — одна проверка.
11. После стабилизации сделайте чистый backup. Это новая точка отката.

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

Код

Важно: код ниже нужен для диагностики и примера структуры. Перед изменением 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

Пример плохого AI-кода: он может работать, но его сложно поддерживать. Тут смешаны проверка, SQL, HTML и вывод.

function show_users_table() {
    global $wpdb;

    $company = $_GET['company'];

    $users = $wpdb->get_results("SELECT * FROM {$wpdb->prefix}users WHERE display_name LIKE '%$company%'");

    echo '<table>';

    foreach ($users as $user) {
        echo '<tr>';
        echo '<td>' . $user->display_name . '</td>';
        echo '<td>' . $user->user_email . '</td>';
        echo '</tr>';
    }

    echo '</table>';
}

Что здесь плохо:

• значение из $_GET используется без sanitization;
• SQL собран строкой без $wpdb->prepare();
• вывод идёт без esc_html();
• нет проверки прав пользователя;
• нет обработки пустого результата;
• функция сразу и получает данные, и выводит HTML;
• код сложно переиспользовать в AJAX, шорткоде или админке.

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

function sc_get_users_by_company($company_name) {
    global $wpdb;

    $company_name = sanitize_text_field($company_name);

    if ($company_name === '') {
        return array();
    }

    $like = '%' . $wpdb->esc_like($company_name) . '%';

    return $wpdb->get_results(
        $wpdb->prepare(
            "SELECT ID, display_name, user_email
             FROM {$wpdb->users}
             WHERE display_name LIKE %s
             ORDER BY display_name ASC
             LIMIT 100",
            $like
        )
    );
}

function sc_render_users_table($users) {
    if (empty($users)) {
        return '<p>Пользователи не найдены.</p>';
    }

    $html = '<table>';
    $html .= '<thead>';
    $html .= '<tr>';
    $html .= '<th>Имя</th>';
    $html .= '<th>Email</th>';
    $html .= '</tr>';
    $html .= '</thead>';
    $html .= '<tbody>';

    foreach ($users as $user) {
        $html .= '<tr>';
        $html .= '<td>' . esc_html($user->display_name) . '</td>';
        $html .= '<td>' . esc_html($user->user_email) . '</td>';
        $html .= '</tr>';
    }

    $html .= '</tbody>';
    $html .= '</table>';

    return $html;
}

function sc_users_table_shortcode($atts) {
    if (!is_user_logged_in()) {
        return '<p>Доступ закрыт.</p>';
    }

    $atts = shortcode_atts(
        array(
            'company' => '',
        ),
        $atts,
        'sc_users_table'
    );

    $users = sc_get_users_by_company($atts['company']);

    return sc_render_users_table($users);
}

add_shortcode('sc_users_table', 'sc_users_table_shortcode');

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

add_action('wp_ajax_sc_save_item', 'sc_save_item_ajax');

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

    check_ajax_referer('sc_save_item_nonce', 'nonce');

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

    if ($item_title === '') {
        wp_send_json_error(array(
            'message' => 'Название не заполнено.'
        ), 400);
    }

    wp_send_json_success(array(
        'message' => 'Данные прошли проверку.',
        'item_title' => $item_title
    ));
}

Пример jQuery-запроса для WordPress. Куда вставлять: JS-блок страницы, файл админки или подключённый script-файл. В реальном проекте nonce лучше передавать через wp_localize_script().

jQuery(document).on('click', '.sc-save-item-button', function(e) {
    e.preventDefault();

    var itemTitle = jQuery('.sc-item-title').val();
    var nonce = jQuery('.sc-save-item-nonce').val();

    jQuery.ajax({
        url: '<?php echo admin_url("admin-ajax.php") ?>',
        type: 'POST',
        dataType: 'json',
        data: {
            action: 'sc_save_item',
            nonce: nonce,
            item_title: itemTitle
        },
        success: function(response) {
            if (response.success) {
                console.log(response.data.message);
            } else {
                console.log(response.data.message);
            }
        },
        error: function(xhr) {
            console.log('Ошибка AJAX:', xhr.status);
        }
    });
});

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

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

Что проверять в коде от ChatGPT

1. Структура файлов

Если весь код лежит в одном файле, его сложно проверять. Минимально разделите:

• админские страницы;
• фронтенд-вывод;
• AJAX-обработчики;
• работу с базой данных;
• подключение CSS/JS;
• вспомогательные функции;
• интеграции с API.

2. Имена функций и классов

В WordPress нельзя использовать слишком общие имена: save_data(), get_users(), render_table(), ajax_handler(). Такие названия легко конфликтуют с темой или другим плагином.

Лучше использовать уникальный префикс проекта:

• sc_save_data();
• sc_get_report_users();
• sc_render_report_table();
• sc_ajax_save_settings();

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

Рабочий код без безопасности — это технический долг. Особенно если код сохраняет данные, работает с пользователями, файлами, заказами WooCommerce или настройками сайта.

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

4. Ошибки и пустые данные

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

Проверяйте:

• isset() для входных данных;
• empty() для массивов и строк;
• проверку WP_Error;
• fallback-сообщения для пользователя;
• логирование ошибок для администратора;
• корректные HTTP-статусы в AJAX и REST API.

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

Код может работать на 10 записях и ломаться на 10 000. В WordPress это часто проявляется в отчётах, фильтрах, импортах, WooCommerce и админских таблицах.

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

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

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

Результат

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

• понятно, какие файлы за что отвечают;
• есть backup и точка отката;
• критические функции отделены от второстепенных;
• дубли кода удалены;
• AJAX защищён nonce и проверкой прав;
• SQL-запросы подготовлены через $wpdb->prepare();
• вывод экранируется;
• ошибки логируются;
• пустые данные обрабатываются нормально;
• код можно дорабатывать маленькими частями;
• после правки понятно, что тестировать;
• проект можно передать другому разработчику без полного переписывания.

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

Использовать Git

Даже простой Git-репозиторий помогает видеть, что именно изменил ChatGPT. Это особенно важно, если AI предложил большой кусок кода.

Просить не полный файл, а точечный diff

Лучше просить формат “было/стало” для конкретного участка. Так меньше риск потерять рабочую логику.

Вести файл правил проекта

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

Писать список ручных тестов

Перед новой правкой должен быть список: открыть страницу, сохранить форму, проверить AJAX, проверить письмо, проверить роль пользователя, проверить WooCommerce, проверить debug.log.

Создать staging-копию

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

Не смешивать генерацию и внедрение

ChatGPT может предложить код, но внедрение должно идти через проверку: чтение, адаптацию, backup, тест и только потом публикацию.

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

• Вставлять код без чтения. Даже если код выглядит правильным, он может не учитывать ваш проект.
• Просить ChatGPT переписать весь файл. Так легко потерять рабочие функции.
• Не делать backup. Без копии невозможно быстро откатиться.
• Хранить всё в functions.php. Файл быстро превращается в хаотичный набор разных задач.
• Не проверять debug.log. Ошибки могут быть скрыты до следующего обновления.
• Не проверять безопасность. Рабочая форма без nonce и проверки прав может быть опасной.
• Не тестировать роли пользователей. У администратора всё работает, а у менеджера или клиента может ломаться.
• Не проверять пустые данные. Код часто ломается, когда записей нет или поле не заполнено.
• Не проверять WooCommerce. Маленькая правка может повлиять на корзину, checkout, оплату или письма.
• Делать новые AI-правки поверх старых без аудита. Так технический долг растёт быстрее, чем функционал.

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

Если код от ChatGPT уже сложно поддерживать, проверьте проект по конкретным симптомам.

Проблема	Что это значит	Как исправлять
Файл стал слишком большим	в одном месте смешаны разные задачи	разделить код на модули
Одинаковый код повторяется	AI решал похожую задачу заново	вынести общую функцию
Появляются Cannot redeclare function	функция объявлена дважды	найти дубли и добавить уникальный префикс
AJAX возвращает 400 или 403	ошибка action, nonce, прав или WAF	проверить admin-ajax.php, nonce, current_user_can()
Данные сохраняются неправильно	неверная структура POST или SQL	логировать входные данные и проверить $wpdb->prepare()
Сайт стал медленным	тяжёлые запросы, циклы, API, autoload	проверить Query Monitor, SQL, wp_options, cron
После обновления всё ломается	код завязан на внутренности плагина или темы	использовать официальные хуки и проверять совместимость
Код работает только на одном сайте	зашиты ID, URL, пути, названия классов	вынести настройки в опции и использовать функции WordPress

Мини-чеклист поддержки кода от ChatGPT

• сделать backup перед правкой;
• проверить diff изменений;
• не переписывать файл целиком без причины;
• использовать уникальные префиксы функций;
• разделять получение данных, сохранение и вывод;
• проверять nonce в AJAX;
• проверять current_user_can();
• очищать входные данные;
• экранировать вывод;
• готовить SQL через $wpdb->prepare();
• проверять пустые значения;
• логировать ошибки;
• тестировать роли пользователей;
• проверять WooCommerce-сценарии, если они есть;
• после правки проверять debug.log.

FAQ

Почему код от ChatGPT работает, но его сложно поддерживать?

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

Можно ли использовать код от ChatGPT в WordPress?

Можно, но его нужно проверять и адаптировать. Особенно важно проверить nonce, права пользователей, sanitization, escaping, SQL, хуки, AJAX, REST API и совместимость с темой и плагинами.

Что опаснее всего в AI-коде?

Самые опасные места: SQL без prepare, вывод без escaping, формы без nonce, AJAX без проверки прав, загрузка файлов без контроля, дубли функций и код, который переписывает рабочую логику проекта.

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

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

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

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

Как правильно просить ChatGPT исправить код?

Лучше давать конкретный участок, описывать ошибку, просить не менять логику без разрешения, требовать формат “было/стало” и просить объяснить, что может сломаться.

Как понять, что код уже пора рефакторить?

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

Что делать, если код ChatGPT уже стоит на рабочем сайте?

Сделать backup, включить debug.log, составить карту функций, проверить безопасность, найти критические сценарии, убрать дубли, разделить большие функции и тестировать изменения на staging.

Можно ли доверять ChatGPT генерацию плагина целиком?

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

Что лучше: исправлять старый AI-код или писать заново?

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

Вывод

Код от ChatGPT может быстро решить задачу, но поддержка требует большего: структуры, проверки безопасности, понятных зависимостей, логов, тестов, backup и аккуратного внедрения. Рабочий результат в одном сценарии ещё не означает, что код готов к развитию.

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