Опасно пропускать чтение кода: когда LLM пишут код быстрее, чем вы можете его прочитать

Предпосылка проста: что, если мы вообще перестанем читать код, сгенерированный LLM? Относиться к нему как к ассемблеру, байт-коду или транспилированному JavaScript — исходный код на высокоуровневом языке становится еще одной формой машинного кода. Эта идея взята из отчета ретрита Thoughtworks и поста в блоге Факундо Олано.

Почему это имеет смысл

LLM выдают недетерминированный вывод и генерируют код намного быстрее, чем человек может его прочитать. Проверять каждый diff больше нецелесообразно. Вместо того чтобы отказываться от строгости, перенесите ее в другое место: в спецификации и тесты.

Организационное условие

Это решение не для отдельного разработчика или команды — оно должно быть принято на уровне организации. Применим закон Амдала: максимальное ускорение генерации кода без реструктуризации процессов не дает реального прироста. Нельзя, чтобы одни разработчики выдавали по 20 тысяч строк мусора в день, а другие все еще читали и утверждали его.

Требования включают:

• Убрать человека из цикла, сократить согласования и бюрократию
• Практически бесконечный поток требований, инженеры автономно владеют своими потоками работы
• Переделка почти бесплатна, поэтому не предотвращайте неверную работу — выявляйте ее через спецификации/тесты

Предлагаемый рабочий процесс

Используйте стандартизированную спецификацию в Markdown как новую единицу знаний. Владельцы продукта и инженеры совместно работают над спецификацией и тестовыми сценариями для бизнес-правил. Заносите их в репозиторий вместе с реализующим кодом.

Автоматические проверки пул-реквеста верифицируют:

• Тесты проходят
• Код соответствует спецификации

Спецификация — а не код — это то, что команда понимает, проверяет и за что отвечает.

Ключевое различие

Спецификации — это не промпты. Тесты — не TDD. Речь идет о переносе строгости на уровень контракта, а не на уровень реализации.