Ask HN: что делать, когда выпускаешь код, написанный ИИ, который не понимаешь?
Один инженер признаёт, что уже не может объяснить систему, которую построил с нуля и над которой работал четыре-пять лет. Выход он видит не в более тщательном ревью кода.
В треде Ask HN спросили, как инженеры справляются с выпуском кода, написанного LLM, который они до конца не читали. Инженер Hasura признаёт, что после перехода от автодополнения в IDE к CLI Claude и Codex его собственная система стала расплывчатой. Решение, по его мнению, в формально верифицируемом коде.
Самый резкий контраргумент: вы и так выпускаете код, который не читали. Так всегда работали ведущие инженеры.
Вопрос и одно признание
В треде спрашивают, как жить с выпуском кода, написанного ИИ, который вы не понимаете. Самый откровенный ответ дал инженер PromptQL (Hasura):
«Чем дальше я уходил от деталей реализации, тем расплывчатее становилась семантика. Дошло до того, что я не могу добросовестно сказать, что понимаю систему, которую построил с нуля.» — инженер PromptQL (Hasura), работающий над коннекторами к данным
Его решение намеренно не предполагает возврата к чтению диффов. По его словам, ревью экономически не окупается, и он хочет, чтобы языки и программы стали формально верифицируемыми, чтобы код доказуемо «делал то, что написано на упаковке».
«Вы уже так работали как ведущий инженер»
Один комментатор сравнил ситуацию с работой ведущего инженера до эпохи ИИ: вы контролируете системы многих инженеров, не можете проверить всё и держите высокоуровневый дизайн, а не низкоуровневые детали. Человеческое ревью уменьшает число багов, но не устраняет их. Тот же автор признал, что правильность доверия «умным калькуляторам» вместо людей выяснится позже, но «пока работает».
Другой комментатор описал это как смену роли на проджект-менеджера, а скептик ответил, что те, кто промптит LLM, выпускают продукт ближе к работе продакт-менеджера, чем инженера.
Где на самом деле проходит проверка
Несколько человек описали конкретные ворота, а не философию. Создатель автовекторизующего компилятора написал:
«Я прошу его написать кучу тестов, и у меня есть реальные нетривиальные программы, которые он скомпилировал. Перед релизами он проходит „ворота“, которые буквально занимают часы на пяти разных архитектурах.» — spacedcowboy, создатель автовекторизующего компилятора
Он по-прежнему ревьюит код, но признаёт, что не может сказать, будто проверил всё. Ветеран разработки под платформы Apple описал обратный эффект: когда печатает LLM, он тестирует больше, чем когда писал руками, и находит ошибки реализации, а не ошибки кодирования. Один комментатор провёл границу по слоям: HTML/JS/CSS полностью написаны вайб-кодингом, а SQL-схему он по-прежнему пишет сам, потому что ошибки там обходятся гораздо дороже.
Нерешённая дыра
Основатель инструмента ERD для ИИ-ассистентов назвал пробел, который остальные обходят стороной: когда ИИ пишет и код, и тесты, они могут соглашаться друг с другом и пропускать одну и ту же ошибку. На это никто не ответил ничем, кроме «больше тестов».
Общий вывод треда: те, кому это удобно, опираются на независимую проверку (многочасовые ворота, формальные контракты, схемы, которые пишет человек). Тем, кто беспокоится, остаются только собственные тесты модели.
Получайте такие разборы каждый день
Главные истории Hacker News — на email, в Telegram или RSS.
Wine теперь работает на OpenBSD благодаря обходному пути для отсутствующего регистра ЦП
OpenBSD не может задать регистр gsbase, который ждут программы для Windows, поэтому порт имитирует префикс %gs в командах.