← На главную

Разработчик через LLM плодил дубликаты проверок доступа

10.07.2026 13:33 · hackernews

Разработчики часто перекладывают на LLM написание повторяющегося кода. Автор заметил это на собственном проекте: в нескольких местах (роут, фоновая задача, API-эндпоинт, вебхук) нужна была одинаковая проверка доступа. Он просто описывал задачу, модель генерировала рабочий код, и он его принимал.

Везде получалось одно и то же условие: if (user.isActive && user.hasPermission('read') && !user.isSuspended && account.status === 'open'). Четыре одинаковых проверки, просто скопированные с минимальными правками. Нормальный подход — вынести это в общий хелпер. Но автору было лень. Код работал, тесты проходили, а исправлять всё равно пришлось бы не ему, а модели.

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

Попросишь пятый эндпоинт — получишь пятую копию того же условия. Попросишь рефакторинг — модель сохранит все пять, потому что это выглядит как твой «стиль». Если так продолжается, можно ли доверять, что LLM потом исправит все дубликаты? По одному — не катастрофа. Но запахи кода накапливаются. Каждый дублированный if, каждая функция-«бог», каждый «почищу потом» добавляет новый слой сигналов для следующего промпта. В итоге выбраться из этого без ручного разгребания становится почти невозможно.

Самое обидное: автор думал, что переложил поддержку кода на LLM, а на самом деле просто тренировал модель на всё более плохие привычки. Вывод простой: пиши код так, как будто его будет поддерживать человек. LLM — это губка, которая впитывает всё, что ты делаешь, и повторяет это обратно. Так что убедись, что это хороший код.

Читать оригинал →