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

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

Краткий ответ: AI-код стоит дорабатывать, если основная логика рабочая, структура понятна, ошибки локальные, данные не повреждаются, а безопасность можно закрыть точечными правками. Переписывать лучше, если код ломается при каждом изменении, содержит дубли, смешивает PHP, HTML, JS и SQL в одном месте, не имеет нормальной проверки прав, небезопасно работает с базой данных или уже дешевле пересобрать модуль заново, чем чинить последствия.

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

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

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

Причина

AI генерирует код по текущему запросу. Если попросить “сделай форму”, он сделает форму. Если попросить “добавь фильтр”, он добавит фильтр. Но он не всегда удерживает всю архитектуру проекта: старые функции, роли пользователей, базу данных, кеш, WooCommerce, REST API, будущие обновления и поддержку.

Так появляется код, который работает в одном сценарии, но плохо переносит изменения. Например:

• одна функция одновременно выводит HTML, принимает POST, пишет в базу и отправляет email;
• AJAX работает только для администратора, хотя форма должна быть публичной;
• данные сохраняются без проверки и потом ломают вывод;
• SQL-запросы собраны строками из $_POST;
• одинаковая логика скопирована в 3–5 местах;
• код нельзя отключить частично, только весь файл сразу;
• после одной правки ломается другой блок;
• нет логов, поэтому причина ошибки видна только по факту поломки.

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

Когда AI-код можно дорабатывать

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

Признаки, что доработка имеет смысл

• Основной сценарий работает стабильно.
• Ошибки локальные и повторяемые.
• Код можно разделить на понятные части без полной переписи.
• Нет повреждения данных в базе.
• Нет критических дыр в безопасности или их можно закрыть точечно.
• Функции имеют понятные названия.
• Бизнес-логика не противоречит сама себе.
• Есть доступ к FTP, логам и базе данных.
• Можно сделать staging-копию и проверять изменения безопасно.
• Проект ещё не оброс случайными AI-правками поверх AI-правок.

Примеры, когда лучше доработать

• Форма не отправляет заявки из-за неправильного AJAX URL.
• В WordPress-плагине не хватает nonce и проверки прав.
• В таблице нет пагинации, но структура данных нормальная.
• В коде есть warnings, но нет критической архитектурной ошибки.
• Нужно вынести CSS/JS из PHP-файла.
• Нужно заменить прямой SQL на $wpdb->prepare().
• Нужно добавить логирование и обработку ошибок.
• Нужно привести названия функций к одному стилю.

Если задача похожа на доведение прототипа до нормальной эксплуатации, полезно двигаться по этапам из статьи как довести MVP после ChatGPT / Cursor до рабочего проекта.

Когда AI-код лучше переписать

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

Признаки, что код лучше переписать

• Невозможно понять, какая функция за что отвечает.
• Одна правка постоянно ломает другие участки.
• Код смешивает PHP, HTML, JavaScript, SQL и CSS в одном большом файле.
• Есть много дублей с небольшими отличиями.
• Нет единого источника данных: часть берётся из options, часть из meta, часть из кастомной таблицы.
• Безопасность отсутствует системно: нет nonce, прав, sanitization, escaping.
• SQL-запросы небезопасны и разбросаны по всему проекту.
• Код уже повредил данные или создаёт дубли записей.
• Нет возможности нормально протестировать старую логику.
• Нельзя добавить новую функцию без риска сломать старую.
• AI несколько раз “чинил” один и тот же файл и создал конфликтующие решения.
• Плагин или тема вызывают критические ошибки после обновления PHP, WordPress или WooCommerce.

Примеры, когда перепись безопаснее

• AI сделал кастомный WordPress-плагин, но все AJAX-обработчики открыты для гостей.
• В WooCommerce изменяется статус заказа без проверки оплаты и webhook.
• Личный кабинет показывает чужие данные из-за неправильной фильтрации по user_id.
• Код работает только под администратором, но должен работать для разных ролей.
• В базе уже есть хаотичные таблицы без ключей, индексов и понятной связи.
• Файл на несколько тысяч строк содержит всё сразу: shortcode, AJAX, SQL, HTML, CSS, JS.
• После каждой AI-правки появляются новые ошибки в старых функциях.

Диагностика

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

Что проверить сначала

• Есть ли резервная копия файлов и базы.
• Можно ли воспроизвести ошибку.
• Есть ли staging-копия сайта.
• Пишутся ли ошибки в debug.log.
• Какие файлы связаны с проблемой.
• Какие функции вызываются при действии пользователя.
• Какие таблицы базы используются.
• Есть ли прямые SQL-запросы.
• Есть ли проверки прав и nonce.
• Какие роли пользователей должны иметь доступ.
• Не влияет ли код на WooCommerce, оплату, заказы, корзину, формы или личный кабинет.

Таблица принятия решения

Ситуация	Лучшее решение	Почему
Есть 1–2 понятные ошибки	Доработать	Дешевле исправить точечно и не трогать рабочую логику
Нет nonce и escaping, но структура понятна	Доработать с аудитом безопасности	Защиту можно добавить без полной переписи
Код дублируется в нескольких местах	Рефакторинг частями	Можно вынести общие функции и снизить риск ошибок
Один файл содержит весь проект	Рефакторинг или перепись модуля	Поддержка будет дорожать с каждой новой задачей
Логика противоречит сама себе	Переписать проблемный блок	Точечные правки будут маскировать основную ошибку
Код небезопасно работает с заказами или платежами	Переписать критическую часть	Риск потери денег и данных выше стоимости переписи
Код повреждает данные	Остановить, сделать бэкап, переписать	Продолжать доработку опасно
Новая функция невозможна без поломки старой	Переписать архитектурный слой	Проблема уже не в одной ошибке, а в структуре

Практическая оценка

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

Решение

Есть три нормальных сценария работы с AI-кодом: точечная доработка, рефакторинг частями и полная перепись. Выбор зависит от рисков.

Вариант 1: точечная доработка

Подходит, если код в целом рабочий, а проблема понятная.

• исправить конкретную ошибку;
• добавить sanitization и escaping;
• добавить nonce;
• исправить AJAX action;
• подключить SMTP;
• заменить опасный SQL на $wpdb->prepare();
• добавить логирование;
• проверить на staging.

Вариант 2: рефакторинг частями

Подходит, если код работает, но поддерживать его тяжело.

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

Вариант 3: переписать модуль

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

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

Если проблема связана с WordPress-плагином, сначала стоит пройти базовую проверку из статьи как проверить WordPress-плагин, написанный через ChatGPT. Это помогает не переписывать то, что можно безопасно исправить.

Код

Важно: код ниже может влиять на диагностику, админку и переключение логики в WordPress. Не вставляйте его вслепую на рабочий сайт. Сначала проверьте на staging-копии или в отдельном тестовом плагине.

1. Включить логирование для диагностики

Куда вставлять: wp-config.php, выше строки /* That's all, stop editing! */.

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

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

wp-content/debug.log

2. Безопасный логгер для проверки старого AI-кода

Куда вставлять: в отдельный мини-плагин или helper-файл вашего плагина.

<?php
defined( 'ABSPATH' ) || exit;

function sc_ai_code_log( $message, $context = array() ) {
    if ( ! defined( 'WP_DEBUG' ) || ! WP_DEBUG ) {
        return;
    }

    $line = '[SC AI CODE AUDIT] ' . sanitize_text_field( $message );

    if ( ! empty( $context ) ) {
        $line .= ' | ' . wp_json_encode( $context );
    }

    error_log( $line );
}

3. Переключатель старой и новой логики

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

Куда вставлять: в отдельный плагин или в основной файл дорабатываемого плагина.

<?php
defined( 'ABSPATH' ) || exit;

add_shortcode( 'sc_project_block', 'sc_project_block_router' );

function sc_project_block_router( $atts = array(), $content = '' ) {
    $use_new_logic = (bool) get_option( 'sc_use_new_project_block_logic', false );

    if ( $use_new_logic ) {
        return sc_project_block_new( $atts, $content );
    }

    return sc_project_block_legacy( $atts, $content );
}

function sc_project_block_legacy( $atts = array(), $content = '' ) {
    sc_ai_code_log(
        'Запущена старая логика shortcode sc_project_block',
        array(
            'user_id' => get_current_user_id(),
            'url'     => home_url( add_query_arg( array(), $GLOBALS['wp']->request ) ),
        )
    );

    return '<div class="sc-project-block">Старая логика блока</div>';
}

function sc_project_block_new( $atts = array(), $content = '' ) {
    $atts = shortcode_atts(
        array(
            'title' => '',
        ),
        $atts,
        'sc_project_block'
    );

    $title = sanitize_text_field( $atts['title'] );

    ob_start();
    ?>
    <div class="sc-project-block">
        <?php if ( '' !== $title ) : ?>
            <h2><?php echo esc_html( $title ); ?></h2>
        <?php endif; ?>

        <div class="sc-project-block__content">
            <?php echo wp_kses_post( $content ); ?>
        </div>
    </div>
    <?php
    return ob_get_clean();
}

4. Включить новую логику только после проверки

Куда вставлять: временно в админский обработчик, WP-CLI команду или выполнить один раз через безопасный служебный скрипт. Не оставляйте временные переключатели без контроля.

<?php
update_option( 'sc_use_new_project_block_logic', true, false );

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

<?php
update_option( 'sc_use_new_project_block_logic', false, false );

Результат

После диагностики должно быть понятно, какой путь безопаснее: доработка, рефакторинг или перепись. Хороший результат — это не просто “код стал красивее”, а снижение риска для сайта.

Нормальный результат выглядит так:

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

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

Сделать карту логики

Перед переписью или рефакторингом опишите текущую логику простыми пунктами:

• что делает модуль;
• какие данные принимает;
• куда сохраняет;
• что выводит пользователю;
• какие роли имеют доступ;
• какие ошибки возможны;
• какие внешние API используются;
• какие страницы или шорткоды зависят от этого кода.

Без такой карты перепись часто повторяет старые ошибки, только в новом файле.

Сравнить стоимость доработки и переписи

Не считайте только время на написание кода. Учитывайте:

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

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

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

Проверьте:

• current_user_can();
• check_ajax_referer();
• wp_verify_nonce();
• sanitize_text_field();
• absint();
• sanitize_email();
• esc_html();
• esc_attr();
• esc_url();
• $wpdb->prepare().

Не переписывать весь проект сразу

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

• форму заявок;
• AJAX-фильтр;
• страницу настроек;
• интеграцию с CRM;
• обработчик WooCommerce-заказов;
• личный кабинет;
• кастомную таблицу отчётов.

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

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

Ошибка 1: переписывать только потому, что код некрасивый

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

Ошибка 2: дорабатывать код, который уже повреждает данные

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

Ошибка 3: просить AI “сделай рефакторинг всего файла”

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

Ошибка 4: удалять старый код без плана отката

Если новая версия не прошла проверку, нужно быстро вернуть старую. Поэтому безопаснее использовать staging, версии файлов, Git или хотя бы архив старого плагина.

Ошибка 5: не проверять роли пользователей

Код может работать у администратора, но ломаться у редактора, менеджера магазина, клиента или гостя. Для WordPress это критично.

Ошибка 6: переписать backend, но забыть frontend

Если меняется AJAX action, HTML-поля, nonce или формат JSON-ответа, нужно обновлять и JavaScript. Иначе новая PHP-логика будет правильной, но форма или интерфейс перестанут работать.

Ошибка 7: чинить симптомы вместо причины

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

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

Симптом: после каждой правки появляется новая ошибка

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

Симптом: код работает только у администратора

• Проверьте current_user_can().
• Проверьте роли пользователей.
• Проверьте wp_ajax_ и wp_ajax_nopriv_.
• Проверьте nonce.
• Проверьте, не скрывает ли тему или плагин нужные данные.

Симптом: нельзя понять, откуда берутся данные

• Проверьте wp_options.
• Проверьте post meta и user meta.
• Проверьте кастомные таблицы.
• Проверьте AJAX-запросы в DevTools.
• Проверьте SQL-запросы в коде.

Симптом: AI-код стал очень медленным

• Проверьте SQL-запросы внутри циклов.
• Проверьте отсутствие пагинации.
• Проверьте загрузку всех записей сразу.
• Проверьте частые обращения к внешнему API.
• Проверьте, не выполняется ли тяжёлая логика на каждом init.
• Проверьте кеширование там, где оно безопасно.

Симптом: после обновления WordPress или PHP всё сломалось

• Откройте wp-content/debug.log.
• Проверьте deprecated notices.
• Проверьте старые функции PHP.
• Проверьте совместимость активных плагинов.
• Проверьте, не использует ли AI-код нестандартные хуки темы.

Симптом: проект страшно трогать

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

Краткие AI-friendly ответы

Когда AI-код нужно дорабатывать?

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

Когда AI-код лучше переписать?

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

Что выбрать: рефакторинг или перепись?

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

FAQ

Можно ли доверять коду, который написал ChatGPT?

Можно использовать как черновик или ускоритель разработки, но не как готовое решение без проверки. Особенно если код работает с WordPress, базой данных, AJAX, формами, пользователями, WooCommerce или оплатой.

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

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

Что опаснее: старый плохой код или новая перепись?

Оба варианта могут быть опасны. Старый код опасен скрытыми ошибками, новая перепись — риском потерять рабочую логику. Поэтому нужен staging, бэкап, список сценариев и план отката.

Как понять, что рефакторинг прошёл успешно?

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

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

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

Можно ли дать AI задачу “перепиши всё правильно”?

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

Что делать перед переписью AI-кода?

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

Когда нельзя ограничиваться доработкой?

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

Сколько времени занимает решение: дорабатывать или переписать?

Это зависит от размера проекта, качества кода, количества функций и рисков. Иногда достаточно короткого аудита одного файла. В сложных WordPress-проектах нужно проверять плагины, тему, базу, AJAX, REST API, WooCommerce и логи.

Что делать, если часть AI-кода хорошая, а часть плохая?

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

Вывод

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

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

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