LLM в ежедневной разработке: где помогает, а где мешает

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

Сайт, который вы читаете, я делал в паре с языковой моделью: свой движок на PHP, админка, аналитика, разметка для поисковиков. Опыт получился показательный — и потому, что многое вышло быстро, и потому, что ошибки были настоящие. Хочу рассказать про обе стороны.

Где выигрыш очевиден

Первый черновик чего угодно. Пустой файл — самая дорогая часть задачи. Модель закрывает её за минуту: каркас класса, структура конфига, регулярка, SQL-запрос. Дальше вы правите, а не сочиняете с нуля. Ускорение здесь не в разы, но стабильное.

Незнакомый синтаксис и забытые детали. Точный формат .htaccess, флаги rsync, как в этой версии PHP правильно сделать то, что в новой делается одной строкой. Раньше это были двадцать минут в документации и на форумах, сейчас — один вопрос.

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

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

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

Где начинаются проблемы

Уверенный тон при ошибке. Это главная ловушка. Неправильный ответ выглядит ровно так же, как правильный — тем же спокойным тоном, с той же аккуратной аргументацией. Человек, который не знает ответа, обычно это как-то выдаёт. Модель — нет.

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

Здесь простое правило: всё, что можно перепутать с чужим, проверяется отдельно. Особенно если речь о людях, датах, цифрах и цитатах.

Незнание вашей системы. Модель не знает, что на этом сервере старая версия PHP, что в конфиге хостинга включена неочевидная настройка, что вон тот каталог трогать нельзя. Она предложит решение, правильное в среднем, — и неправильное здесь.

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

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

Правило, которое работает лучше всего

Я свёл всё к одному принципу: доверяй ровно настолько, насколько легко проверить.

• Код, который можно запустить и увидеть результат — проверяется мгновенно. Здесь можно двигаться быстро.
• Код, который трогает данные, деньги или прод — только после явной проверки, лучше с бэкапом до.
• Факты о реальном мире — всегда через источник. Без исключений.

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

Что изменилось в самом процессе

Заметная перемена: сместился центр тяжести работы. Раньше основное время уходило на написание кода, а ревью было коротким. Теперь наоборот — черновик появляется быстро, а основная работа в том, чтобы его прочитать, понять и решить, что оставить.

Это требует другой дисциплины. Соблазн «выглядит правильно, поехали» очень сильный, особенно когда код аккуратно отформатирован и снабжён комментариями. Но аккуратность оформления ничего не говорит о правильности — это, пожалуй, самая коварная особенность работы с моделями.

И ещё одно: отвечать за результат всё равно вам. Никого не интересует, кто написал строку, которая уронила прод. Поэтому код, который вы не понимаете, нельзя отправлять дальше — независимо от того, кто его сочинил.

Кому это заменит работу

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

Поэтому вопрос «заменит ли ИИ разработчиков» кажется мне неправильно поставленным. Ближе к реальности другое: меняется соотношение навыков. Писать код становится дешевле, а понимать, проверять и отвечать за него — дороже.

Собственно, это и раньше было главным в профессии. Просто теперь стало заметнее.