LLM-код теперь можно не читать — с таким предложением выступает автор, переосмыслив свою позицию. Раньше он писал, что безответственно думать, будто LLM сами починят любую проблему, ведь программист отвечает за результат. Но что если руководство компании осознанно идёт на риск ради скорости? Стартапы постоянно так делают.
Если организация даёт мандат — использовать LLM, чтобы тратить меньше времени на написание кода, — это просто новое ограничение. Значит, нужно понять, как выглядит хорошая инженерия в таких условиях. Можно перестать читать LLM-сгенерированный код. Так же, как мы не читаем ассемблер, байткод или транспилированный JavaScript. Тогда наш высокоуровневый исходник — это просто ещё одна форма машинного кода.
Этот инсайт пришёл после отчёта Thoughtworks. LLM выдают недетерминированный код быстрее, чем мы успеваем его прочитать. Поэтому нельзя серьёзно ожидать, что мы сможем ревьюить каждый diff. Но это не значит отказаться от строгости — нужно перенести её в другое место.
Тут важно: это не решение команды или разработчика. Это организационное решение. И дело не только в ответственности — работает закон Амдала. Если просто ускорить генерацию кода, не перестраивая структуры и процессы вокруг, никакого реального прироста продуктивности не будет.
Невозможно, чтобы одни разработчики выдавали по 20 тысяч строк кода в день, а остальные пытались это читать и аппрувить. Не получится использовать агентов, если единицей работы всё ещё остаётся «добавить новый endpoint в RESTful API». И Product Owner не сможет генерировать достаточно задач, чтобы занять целую команду, если каждый инженер берёт четыре таска одновременно, да ещё агентов гоняет в нерабочее время.
Выход — убрать человека из цикла. Меньше координации, бюрократии, gate-keeping. Нужен бесконечный поток требований. Инженеры должны работать как псевдо-продакт-дизайнеры — владеть целыми потоками работы и принимать автономные решения. Переделывать почти бесплатно, так что не надо тратить силы на предотвращение ошибок.
Куда перенести строгость? Как и в отчёте Thoughtworks — в спецификации (это не то же самое, что промпты) и в тесты (это не TDD). Если бы автор внедрял такой процесс сегодня, он сделал бы стандартизированную Markdown-спецификацию новой единицей знания в проекте. Product Owner и инженеры вместе пишут этот spec и тесты для бизнес-правил. Всё это хранится в репозитории вместе с кодом. Автоматические проверки в pull request должны сверять, что код соответствует спецификации. Именно spec, а не код, команда должна понимать, ревьюить и нести за него ответственность.