Генерация кода с AI: о скрытых рисках в production
В статье по ссылке описан показательный случай: senior-разработчик обнаруживает, что Claude Code сократил разработку задачи с недели до двух дней. Но позже сгенерированный функционал дважды привел к сбоям в production. На первый взгляд код выглядел правдоподобно, но содержал труднообнаружимые ошибки, а глубоко проверять реализацию AI оказалось значительно сложнее, чем собственную. (https://calnewport.com/on-ai-coding-and-its-discontents/).
Код выглядел правдоподобно, но обнаружить тонкие дефекты было сложно, поскольку разработчик не сформировал достаточную ментальну модель кода, который писал не он.
Я постоянно прихожу к тем же выводам. AI требует четкого инженерного понимания, как доожен выглядеть код. Ускорение без полноценной ментальной модели системы приводит в дорогостоящим ошибкам в production и переработке.
Мне интересно, тут есть разработчики, которые интенсивно используют AI для production-разработки, особенно в незнакомых сложных предметных областях или при реализации нового крупного функционала.
Насколько вам удаётся делегировать реализацию AI и при этом действительно понимать, проверять и полностью отвечать за результат?
· 21.08
Могу сказать больше на основе Codex, но думаю принцип одинаков +-
мало ошибается если дать пример как должно работать (уже работающий пример), что должно получится, дать инструменты для сверки результатов, то есть спокойно могу делегировать написание стандартных задач типа создать экран получить данные.
если что то архитектурное то тут нужно смотреть, ненароком можно зайти в такие дебри что проще все удалить и сначала.
Из минусов возрастает когнитивная нагрузка на ревью, кода обьективно больше, проверять сложнее так как не ты писал хоть и по твоим лекалам. "А вдруг где то ошибка" и приходится смотреть все от сих до сих.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 22.08
Я тоже на Codex. В части "мало ошибается, если..." поддерживаю. Насчет когнитивной нагрузки на ревью я бы порекомендовал сокращать размер задач - размер генеренного кода. Меньше придется проверять, лучше помещается в голову.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 22.08
А насчет "а вдруг где-то ошибка" надо делать тесты с вручную установленными acceptance criteria через условный Cypress (если я правильно понял, у тебя фронтэнды)
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 22.08
К сожалению не всегда это зависит от меня но да, декомпозиция задачи наше все), а главное не требует оптимизации контекста и меньше галлюцинаций
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 22.08
Я по iOS и там у нас свои танцы с бубном)
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён