Разработчик вручную переписывает код ИИ, чтобы не терять понимание

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

Причина, то, что автор называет «когнитивным долгом». Если позволить ИИ-ассистенту свободно работать в проекте и писать целые функции за один проход, итог оставляет чувство неудовлетворённости и потери ориентации в собственном коде. Автор признаёт, что не любит вычитывать сгенерированные ИИ пул-реквесты, сотни строк чрезмерно осторожного, плохо прокомментированного и местами неверного кода, и готов делать это по обязанности на работе у работодателя, но категорически отказывается от такой рутины в личных проектах: они, по мнению автора, должны прежде всего приносить удовольствие от самого процесса, а не только от результата.

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

Главный эффект, который автор выделяет отдельно, «пространственная карта» кодовой базы: автор точно знает, где в проекте живёт каждый фрагмент функциональности, и это ускоряет как последующие правки, так и формулировку будущих запросов к ИИ. Автор сравнивает подход с советом, который получал от опытных программистов в подростковом возрасте: не копировать примеры кода из книг или форумов, а перепечатывать и адаптировать их вручную, чтобы полностью понять, тот же принцип, применённый теперь к коду, сгенерированному ИИ. В инструкциях для ИИ-агентов в личных проектах у автора прописано именно такое ограничение, не трогать репозиторий напрямую.

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

Ключевые факты

• Автор использует ИИ-ассистентов в личных проектах, но не даёт им писать код напрямую в репозиторий: код генерируется в чате, а переносится в редактор вручную построчно.
• Скорость работы ниже, чем при полном доверии ИИ: вместо потенциального десятикратного ускорения автор получает примерно двукратное по сравнению с кодингом вообще без ИИ.
• Ручной набор чужого кода строит «пространственную карту» кодовой базы, автор точно знает, где что лежит, что ускоряет и правки, и формулировку будущих запросов к ИИ.
• Метод сравнивается с советом наставников из юности автора: не копипастить примеры кода из книг и форумов, а перепечатывать их вручную, чтобы усвоить полностью.
• Автор опасается, что индустрия ПО в целом накапливает «когнитивный долг», который придётся возвращать, и для себя считает недопустимым выпускать код, который не понимает до конца.

Почему это важно

Материал описывает частный, но узнаваемый ответ на массовую практику 2026 года: код всё чаще пишут ИИ-агенты, а люди лишь проверяют пул-реквесты. Автор указывает на побочный эффект этой нормы, постепенную потерю понимания собственного кода теми, кто должен за него отвечать, и предлагает конкретный, пусть и нишевый, способ этому противостоять.

Кому это важно

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

Как это применить

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

Можно ли доверять

Это личное эссе одного разработчика о собственном опыте, а не исследование с измеримыми данными: оценки «в 10 раз» и «в 2 раза», субъективные прикидки автора, не результат замера. Практика описана как применяемая «несколько месяцев», без более точных сроков, названия используемого ИИ-ассистента или деталей проектов, на которых она проверялась.

Риски и подводные камни

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

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

— автор блога