Uncle Bob больше не читает код, который пишут его агенты

Мартин написал первую программу в 1964 году, в двенадцать лет: мать подарила ему модель компьютера, который программировался белыми трубками на колышках — по сути трёхбитный конечный автомат. Дальше книги по FORTRAN, COBOL и PL/I без единой машины под рукой: программы он писал на бумаге и выполнял в голове. 02:17

С языковыми моделями до конца 2025 года он играл без энтузиазма. Перелом случился примерно на Рождество: Мартин взял агента, дал ему написать код, получил плохой результат — но код появился. Он подключил агента к текущему проекту и следующие недели подчищал за ним. 04:22

Дальше он вспомнил две идеи начала 2000-х, которые тогда посчитал непрактичными. Первая — метрика CRAP: покрытие тестами смешивается с цикломатической сложностью функции, на выходе оценка её паршивости. Мартин прогнал её по большому проекту, получил список плохих функций — и понял, что чинить их вручную будет вечность. 06:04

Вторая — mutation testing: программа переставляет в исходниках знаки, меняет «меньше» на «больше», «равно» на «не равно», и после каждой подмены гоняет весь набор тестов. Тесты обязаны упасть. Если не упали — мутант выжил, и его надо убить. В 2000 году один прогон занимал у Мартина целую ночь: тесты шли четыре минуты, а запусков были сотни. 07:02

Обе техники упирались в человеческий труд. Агенты сняли это ограничение: они быстры и им безразлично, насколько работа скучная. Мартин попросил агента прогнать CRAP по только что написанному коду и почистить результат, затем добавил mutation testing — ночной прогон ужался до получаса. 08:23

Так сложился его принцип: агенты работают, инструменты проверяют, а сам он старается не открывать код вообще. Вместо чтения — оценки CRAP, выборочные точечные проверки и стопка тестов. 09:01

Мэтт задал прямой вопрос: раз агенты быстрые, почему бы просто не давить задачами, пока баги не кончатся? Ответ Мартина построен на наблюдении декабря. Он давал маленькому агенту задание за заданием, не убирая мусор между ними, и видел, как тот замедляется: правит одно — ломает соседнее, чинит соседнее — ломает первое, и начинает ходить по кругу. 11:22

Вывод Мартина: модели подвержены грязному коду так же, как люди. Разница только в пороге, и где именно он проходит — пока никто не знает. Ниже порога агент справляется, выше — начинает буксовать, ломать соседнее и множить беспорядок.

Начинал Мартин как все: расписывал в промпте, как делать TDD, как писать чистый код, каким должен быть результат. Документ дорастал до пяти-десяти страниц. Дальше выяснилось, что модели относятся к таким правилам, как пираты к кодексу — скорее как к рекомендациям. 13:38

Мартин полез разбираться и вышел на эффект lost in the middle: по мере роста контекста начало и конец сохраняют вес, а середина проваливается. Длинная инструкция обречена — первые три предложения ещё живут, пятидесятое и восьмидесятое растворяются. 14:03

Предел у этого подхода есть: если проверок навесить столько, что агенты станут медленнее людей, игра проиграна. Пока Мартин держит перевес в два-четыре раза и границы ещё не нащупал. 16:42 Он прямо называет это обменом: производительность здесь и сейчас меняется на качество. 17:36

Мартин перечисляет два выигрыша от разделения на роли. Первый — параллельность: на его ноутбуке спокойно живут больше трёх кодеров одновременно. Второй важнее: узкая задача держит контекст маленьким, эффект lost in the middle слабеет, и наверх промпта можно положить чуть больше правил — их станут выполнять. Плата — старт нового агента съедает десять-пятнадцать секунд и заново собирает контекст. 19:25

Коммуникационные издержки между агентами Мартин называет чудовищными — и всё равно конвейер обгоняет человека с большим запасом. Он формулирует это как инвестицию: производительность тратится сейчас, чтобы вернуться позже.

Мэтт добавляет к этому понятие траектории сессии. Контекст задаёт не только знания, но и направление: если агента один раз развернули в сторону проверки интерфейса, он будет проверять интерфейс до конца сессии, что бы вы дальше ни просили. Сбросить траекторию можно только вместе с контекстом. 23:25

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

До недавнего времени архитектуру он держал на ручном управлении: давал агентам построить систему, потом допрашивал их — какие тут модули, как они связаны, кто от кого зависит. Ответы, по его словам, приводили в ужас. После этого он проектировал структуру сам и выдавал агентам план внедрения. 26:12

Чтобы видеть систему, Мартин попросил агентов собрать ему архитектурный вьюер: UML-подобная диаграмма модулей и зависимостей, клик по модулю раскрывает подмодули, клик по подмодулю показывает код. Так он спускается на любой уровень, не читая репозиторий подряд. 27:03

Аргумент за хорошие границы тот же, что и за чистый код: то, что аккуратно разбито и снабжено дисциплинированными интерфейсами, человек удерживает в голове — и модель тоже. Свалите в модуль всё подряд, и агент будет метаться внутри, не понимая, где он и что делает.

Мартин напоминает, что в приложении к его книге есть длинный спор с Аустерхаутом на эту тему — и что ему было весело, хотя за собеседника он не ручается. 31:11

На вопрос, что он изменил бы в книге, Мартин отвечает: пороги. У агентов огромная и абсолютно точная краткосрочная память, поэтому допустимый размер функции для них шире человеческого. Он регулирует это через CRAP: человеку держал бы ниже четырёх, агентам поставил шесть и подумывает о восьми. 33:01

При стопроцентном покрытии оценка CRAP шесть означает шесть путей через функцию, и все шесть закрыты тестами. Смысл метрики именно в связке: сначала покрыть всё тестами, потом ограничить цикломатическую сложность. Мартин добавляет, что спорил об этих числах с самими агентами — и что доверять спору с агентом нельзя, но спорить он всё равно продолжает. 33:41

Второй пункт неожиданнее. Мартин остаётся сторонником TDD для людей и отказывается навязывать его агентам: заставлять модель писать строку теста, потом строку кода, потом снова строку теста он смысла не видит. Агентам он разрешает работать в манере Аустерхаута — функция, тест к ней, следующая функция. Даже когда он требовал строгий TDD, агенты всё равно скатывались к этому. 34:01

Мэтт спрашивает, что происходит до конвейера: гонять неправильную работу через пять агентов расточительно. Мартин отвечает, что соблазн знаком с семидесятых — специфицировать, специфицировать, а потом отдать исполнителю. Именно так родился водопад, и ответом на него стал agile. 36:20

С агентами соблазн тот же, и Мартин пробовал буквально на неделе разговора. Итог называет катастрофой, причём предсказуемой: план написан, агенты бегут, и человек по ходу понимает, что предусмотрел не всё, а агенты не настолько мудры, чтобы это компенсировать. Их приходится останавливать, откатывать, переписывать план и запускать заново. 37:14

Сейчас он пробует обратное: дать агентам сделать одну-две истории, посмотреть на архитектуру, руками навести порядок, дальше ещё несколько историй. Ручной шаг разбора он пока считает неустранимым, хотя и надеется его когда-нибудь автоматизировать. 37:51

Дальше идёт его старая лекционная аналогия. Представьте, что любое изменение дома стоит доллар, включая фундамент и крышу. Наймёте ли вы архитектора за тысячи, чтобы он выдал идеальный проект, который подрядчик реализует за доллар? Или подойдёте к подрядчику и скажете: фундамент сюда, нет, вот такой формы, кухню туда, а теперь поменяйте местами, лестницу сдвиньте — по доллару за шаг? 40:06

Стоимость изменения, говорит Мартин, рухнула настолько близко к нулю, насколько это вообще достижимо. Раз так, дорогое планирование впереди теряет смысл: дешевле подкручивать, пока не получится нужное. 41:22

Спецификации у него эфемерны: он их не хранит и не возвращается к ним. Прежней роли исходного кода как окончательной спецификации больше нет — код всё ещё есть, но пишут его не люди, и многим этой опоры не хватает. 42:47

Отдельно оба отмечают асимметрию, которую видит каждый, кто работает с агентами: спецификацию, отправленную агенту, он прочитает целиком, а человек из большого документа усвоит процентов пять. Обратная сторона в том, что написанное агентами люди не читают вовсе, хотя те явно на это рассчитывают. 44:44

Мэтт формулирует проблему через различение Аустерхаута: тактическое программирование — это сержант в бою, стратегическое — генерал, который ведёт войну. Агенты сильны в тактике и слабы в стратегии, но именно тактика была школой, через которую люди приходили к стратегии. 45:56

Готового ответа у Мартина нет, и он это признаёт. Его версия начинается с очевидного: год или сколько-то писать код руками, чтобы понимать, с чем вообще имеют дело агенты. 47:05

Отдельно Мартин настаивает, что код нельзя терять из виду совсем. Десять лет назад он советовал провести выходные за ассемблером, чтобы понять, что происходит под капотом, иначе живёшь в выдуманном мире. Совет он считает актуальным: путь идёт от двоичного кода через ассемблер и C к языкам вроде Python, и только потом — к работе с агентами и детерминированными инструментами. 48:28

Мэтт задаёт неудобный вопрос: зачем компании платить человеку за тактическую работу, если рой агентов сделает то же дешевле. 49:58 И добавляет наблюдение, в котором есть надежда: обратная связь по стратегическим решениям всегда приходила через месяцы, поэтому многие никогда не видели последствий своих ошибок — с агентами цикл сжался, и ошибки возвращаются быстрее. 51:00

Как Мартин сам понял в декабре, что дело плохо: сначала он просто видел плохой код, но важнее было другое — он узнал борьбу агента, потому что сам через неё проходил. Новичок этой борьбы не распознает. 51:16

Где брать это знание, кроме собственных шишек: старые книги, которые никто не читает именно потому, что они старые. Мартин называет Тома Демарко и Эда Йордона, Мэтт подсказывает «Программиста-прагматика». Архаику придётся отфильтровать — многое написано в семидесятых и восьмидесятых, но там эти уроки и были выучены. 51:43

Ответ Мартина держится на мысли, которую он приписывает Дейкстре: программное обеспечение — самая сложная вещь, за которую брались люди. Фундаментальные принципы — это способ организовать эту сложность так, чтобы её можно было охватить умом. И раз модели устроены по образу человеческого мышления, им нужно ровно то же. 53:39

Про тех, кто считает иначе, он высказывается спокойно: они научатся, и научатся трудным путём. Возможно, это займёт больше времени, чем ему кажется, потому что агенты неплохи. Но стену он уже видел и второй раз в неё врезаться не хочет. 54:21