код с LLM: осторожно, не утонуть

рефакторинг, который сломал прод

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

проблема была в том, что LLM написала идеальный с точки зрения академии код, но не учла реальную нагрузку. там была цепочка из 5 map() по списку в 100к элементов, каждый с вызовом внешнего API. в учебнике норм, в проде - капец.

мой опыт: где это работает

я за последние полгода плотно юзаю LLM, но только для конкретных задач:

• написание тестов - даю скелет, она дописывает кейсы. правлю руками, но экономит 30-40% времени
• регулярки - признаю, пишу их криво. проще сформулировать словами
• перевод с легаси - старая java на go, например. но после этого всё равно ревью и бенчмарки

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

основная проблема

LLM не видит картину целиком. она не знает про ваши баги в соседнем микросервисе, про лимиты CPU, про то, что context.WithTimeout надо ставить везде. она выдаёт изолированное решение, которое в вакууме работает.

у нас в проде был случай: сгенерировали обработчик очереди, красивый, с ретраями. забыли, что сообщения могут дублироваться. прод упал через 3 дня.

что делать

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

и да, я всё ещё за LLM. просто без фанатизма. инструмент - он и есть инструмент.