LIVE: Uncle Bob on Software Fundamentals in the Age of AI

19 авг. 2026 г.

Read: ~5m · You save: 52 min

Дядя Боб о фундаментальных основах ПО в эпоху ИИ

Дядя Боб Мартин о влиянии ИИ на разработку ПО. Узнайте, почему чистый код, основы и структурированный дизайн по-прежнему важны. Погрузитесь в генерацию кода с помощью И

Роберт С. Мартин, широко известный как "Дядюшка Боб", ветеран программирования с более чем полувековым опытом, обсудил меняющийся ландшафт разработки программного обеспечения в эпоху искусственного интеллекта. Мартин, автор влиятельной книги "Чистый код", поделился своим видением того, как ИИ-агенты влияют на практики программирования и непреходящее значение фундаментальных принципов разработки программного обеспечения.

Ранняя карьера Мартина началась в 1964 году в возрасте 12 лет с программируемой модели компьютера. Он продолжал развивать свои навыки программирования путем самообучения и профессиональной деятельности, начав свою первую работу в 16 лет, а полную карьеру программиста — в 18 лет. Его книга "Чистый код: Руководство по гибкому мастерству разработки программного обеспечения" стала краеугольным камнем для разработчиков, стремящихся писать высококачественное, поддерживаемое программное обеспечение.

Влияние ИИ-агентов на разработку

Мартин описал свой первоначальный скептицизм по отношению к ИИ-агентам, включая ранние версии Grok и ChatGPT. Он обнаружил, что, хотя эти агенты могли генерировать код, они часто давали "грязные" результаты, требующие значительной доработки. Это привело его к осознанию: ИИ-агенты быстры и могут выполнять утомительные задачи, которые люди считают обременительными.

Это наблюдение побудило Мартина пересмотреть более ранние, непрактичные инновации в разработке программного обеспечения. Он вспомнил "CRAP" (Code Realization Analysis Process), метрику, объединяющую покрытие кода и цикломатическую сложность для выявления "плохих" функций, и мутационное тестирование, которое включает систематическое изменение кода для обеспечения сбоев наборов тестов. Оба метода были слишком трудоемкими для ежедневного использования разработчиками.

Теперь Мартин использует ИИ-агентов для автоматического запуска этих инструментов. Его текущий принцип заключается в том, чтобы агенты выполняли эти анализы и процессы очистки, стремясь минимизировать его прямое взаимодействие с сгенерированным кодом. Он проверяет качество с помощью таких метрик, как оценки CRAP и выборочные проверки, полагаясь на агентов в генерации кода и первоначальной проверке качества.

Необходимость чистого кода и структуры

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

Мартин противопоставил два подхода к управлению ИИ-агентами: "рулевое управление", которое включает предоставление подробных инструкций и правил, и "детерминированные инструменты", которые представляют собой автоматизированные проверки, обеспечивающие стандарты качества. Он обнаружил, что модели ИИ часто рассматривают подробные инструкции как простые рекомендации, что он объяснил эффектом "потерянного в середине" в их контекстных окнах, где информация в начале и конце запроса имеет приоритет над серединой.

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

Многоагентные системы и проектирование рабочих процессов

Мартин исследует многоагентные системы, где специализированные агенты обрабатывают различные этапы процесса разработки. Этот подход предлагает преимущества в параллельной обработке и управлении контекстным окном. Его предлагаемый рабочий процесс включает:

Агент-спецификатор: Преобразует требования, написанные человеком, в приемочные тесты Gherkin (Given-When-Then) и процедуры контроля качества.
Агент-кодер: Пишет модульные тесты и производственный код для реализации указанной истории, обеспечивая прохождение тестов Gherkin.
Агент-очиститель: Выполняет анализ CRAP и общие проверки кода для устранения беспорядка, оставленного агентом-кодером.
Агент-укрепитель: Выполняет мутационное тестирование для выявления и исправления выживших мутантов, обеспечивая полное покрытие тестами.
Агент контроля качества: Преобразует процедуры контроля качества в исполняемые скрипты для проверки функциональности системы с детерминированными результатами.

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

Стратегическое против тактического программирования и обучения

Мартин различал тактическое программирование (выполнение конкретных задач) и стратегическое программирование (определение общего курса). Он считает, что ИИ-агенты преуспевают в тактических задачах, но испытывают трудности со стратегическим планированием. Для начинающих разработчиков он рекомендует строгий путь обучения:

Пишите код: Уделяйте значительное время написанию кода, чтобы понять основы и проблемы, с которыми сталкиваются ИИ-агенты.
Относитесь как к агенту: Новым разработчикам в средах с интенсивным использованием ИИ следует поручать задачи, аналогичные тем, что даются агентам, использовать детерминированные инструменты и ожидать первоначальной непродуктивности во время обучения.
Поймите основы: Глубоко изучите низкоуровневые концепции, такие как язык ассемблера, чтобы понять, что происходит «за кулисами».
Изучите основополагающую литературу: Читайте классические книги по разработке программного обеспечения от таких авторов, как Том ДеМарко и Эд Йордон, чтобы развить чувство стратегического мышления, отсеивая устаревшие элементы.

Мартин подчеркнул, что основы программного обеспечения остаются критически важными, поскольку они предоставляют средства для организации присущей сложности программного обеспечения, сложности, которой даже моделям ИИ необходимо управлять. Он считает, что те, кто пренебрегает основами, в конечном итоге познают их важность трудным путем.

Непреходящая актуальность основ

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

Он заявил, что программное обеспечение, возможно, является самым сложным начинанием, предпринятым человеком. Следовательно, основы необходимы для организации этой сложности таким образом, чтобы она была понятна как людям, так и моделям ИИ, которые, в конце концов, смоделированы по образцу человеческого познания. Мартин предсказывает, что те, кто пренебрежет этими основами, в конечном итоге столкнутся с ограничениями, так же как он наблюдал, как агенты ИИ упираются в "стену".

Путь Дяди Боба в программировании

Дядя Боб представляется, рассказывая о своем долгом пути программиста, начавшемся в 1964 году в возрасте 12 лет. Он вспоминает свой первый опыт программирования на модельных компьютерах и изучение таких языков, как Фортран и Кобол, написание программ на бумаге. Он начал свою профессиональную карьеру в 16 лет и занимается программированием более 50 лет.

Роберт С. Мартин (Дядя Боб) программирует более полувека.
Он начал программировать в 1964 году в возрасте 12 лет.
Его первая программа была написана на модельном компьютере с использованием штырьков и трубок.
Он изучал языки программирования, такие как Фортран и Кобол, читая книги.
Он писал программы на бумаге и выполнял их мысленно.
Начал профессионально кодить в 16 лет и с тех пор является программистом.

Введение в ИИ и ранний опыт

Дядя Боб обсуждает свою влиятельную книгу «Чистый код» и ее влияние. Затем он делится своим первоначальным удивлением и исследованием инструментов ИИ, таких как ChatGPT и Grok, примерно в конце прошлого года. Он описывает свой ранний опыт использования ИИ-агентов для кодирования, отмечая, что они были быстрыми, но часто производили беспорядочный код («собачья роса»), который требовал значительной очистки, что делало его медленнее.

«Чистый код» — очень влиятельная и часто цитируемая книга в области разработки программного обеспечения.
Дядя Боб начал экспериментировать с инструментами ИИ, такими как ChatGPT и Grok, примерно на Рождество прошлого года.
Первые попытки кодирования с использованием ИИ были быстрыми, но генерировали беспорядочный код («собачья роса»).
Использование ИИ-агентов для кодирования изначально замедляло его из-за необходимости очистки.
Он обнаружил, что ИИ-агенты были быстрыми, но разочаровывающими из-за создаваемого ими беспорядка.

Ранние инновации: CRAP и мутационное тестирование

Дядя Боб размышляет о двух ранних, непрактичных программных инновациях: CRAP (покрытие кода, цикломатическая сложность) и мутационном тестировании. Он объясняет, как CRAP оценивает качество кода на основе покрытия и сложности, а мутационное тестирование включает изменение кода для проверки отказа тестов. Признавая их ценность, он счел их слишком трудоемкими для практического использования в начале 2000-х годов.

CRAP (покрытие кода, цикломатическая сложность) был ранним показателем качества кода.
Мутационное тестирование включает изменение кода (например, изменение знаков) для проверки эффективности набора тестов.
И CRAP, и мутационное тестирование считались отличными идеями, но непрактичными из-за временных ограничений в начале 2000-х годов.
Запуск этих инструментов на больших проектах занимал чрезмерное время (например, ночь для мутационного тестирования).
Эти инструменты были отложены из-за их непрактичности в то время.

ИИ делает старые инструменты практически применимыми

Дядя Боб объясняет, как скорость и готовность ИИ выполнять утомительные задачи вновь делают ранее непрактичные инструменты (CRAP, мутационное тестирование) жизнеспособными. Теперь он использует ИИ-агентов для автоматического выполнения этих проверок, очистки кода и обеспечения тестового покрытия. Его текущий принцип — позволить агентам выполнять утомительную работу, чтобы он мог сосредоточиться на задачах более высокого уровня и проверке.

Скорость и готовность ИИ-агентов выполнять скучную работу делают CRAP и мутационное тестирование практичными.
ИИ-агенты теперь могут автоматически запускать эти инструменты, очищая код и обеспечивая тестовое покрытие.
Текущий принцип дяди Боба: пусть агенты выполняют утомительные задачи, сосредоточьтесь на проверке.
Он стремится достичь состояния, когда ему не придется напрямую смотреть на сгенерированный код.
Проверка включает в себя проверку оценок CRAP, выборочную проверку кода и запуск других тестов.

Почему плохой код по-прежнему имеет значение при работе с ИИ

Обсуждается, почему «плохой код» (собачья роса) имеет значение даже при быстрой работе ИИ. Дядя Боб объясняет, что ИИ-агенты, как и люди, могут быть перегружены беспорядочным кодом, что приводит к циклической логике, ошибкам и, в конечном итоге, к сбою или отказу. Это требует автоматизированных проверок, а не простого «управления» ИИ с помощью инструкций, поскольку инструкции могут быть потеряны в контекстном окне ИИ.

Беспорядочный код («собачья роса») может перегрузить ИИ-агентов, заставляя их замедляться, совершать ошибки или давать сбой.
ИИ-агенты могут застревать в циклах, непреднамеренно ломая код при попытке его исправить.
Для ИИ существует порог беспорядочного кода, аналогичный человеческому.
Детерминированные инструменты (такие как CRAP, мутационное тестирование) предпочтительнее инструкций по «управлению».
Инструкции могут быть потеряны в контекстном окне ИИ (явление «потери в середине»).

Управление против автоматических проверок: проблема «потерянного в середине»

Дядя Боб противопоставляет «управление» ИИ автоматическим проверкам. Он обнаружил, что ИИ-агенты относятся к подробным инструкциям как к «рекомендациям» (метафора из «Пиратов Карибского моря») и могут терять информацию из длинных подсказок из-за явления «потерянного в середине» в их контекстном окне. Детерминированные инструменты, однако, остаются надежными и применяются после того, как ИИ генерирует код.

ИИ-агенты относятся к подробным инструкциям как к «рекомендациям», а не как к строгим правилам.
Явление «потерянного в середине» влияет на контекстные окна ИИ; информация в начале/конце имеет приоритет.
Длинные документы с подсказками игнорируются ИИ в средней части.
Детерминированные инструменты (автоматические проверки) не страдают от проблемы «потерянного в середине».
Стратегия заключается в минимизации начальных подсказок и опоре на автоматические проверки после генерации.

Многоагентные системы: Баланс скорости и качества

Обсуждение рассматривает компромисс между производительностью и качеством при использовании автоматизированных проверок. Хотя эти проверки замедляют работу ИИ-агентов, они обеспечивают более высокое качество. Дядя Боб стремится поддерживать запас производительности (в 2-4 раза быстрее человека), одновременно повышая качество. Он описывает многоагентную систему, где спецификаторы, кодеры, очистители, упрочнители и агенты по обеспечению качества работают последовательно, жертвуя некоторой скоростью ради значительно лучших результатов.

Автоматизированные проверки жертвуют производительностью ИИ ради более высокого качества кода.
Цель — поддерживать запас производительности (например, в 2-4 раза) при одновременном повышении качества.
Многоагентная система включает последовательные роли: спецификатор, кодер, очиститель, упрочнитель, QA.
Этот конвейер занимает около часа для задачи, которую один агент может выполнить за 5 минут с сомнительными результатами.
Многоагентный подход предлагает значительное улучшение производительности и качества по сравнению с разработчиками-людьми.

Подробный конвейер многоагентной системы

Дядя Боб обсуждает преимущества многоагентных систем: параллельная обработка и лучшее управление контекстным окном путем фокусировки агентов на отдельных задачах. Недостатки включают время запуска. Он описывает свой конкретный конвейер: спецификатор создает документы Gherkin/QA, кодер пишет модульные тесты и код, очиститель выполняет анализ CRAP, закалитель проводит мутационное тестирование, а агент QA выполняет тесты.

Многоагентные системы позволяют параллельное выполнение и лучший контроль контекстного окна.
Недостатки включают время запуска агента и повторную инициализацию контекста.
Спецификатор: Создает документы Gherkin (Given-When-Then) и процедуры QA.
Кодер: Пишет модульные тесты и код реализации, гарантируя прохождение тестов Gherkin.
Очиститель: Выполняет анализ CRAP и общий обзор кода.
Закалитель: Тщательно выполняет мутационное тестирование.
Агент QA: Преобразует процедуры QA в исполняемые скрипты.

Траектория ИИ и динамика контекстного окна

Обсуждается концепция 'траектории' в контекстных окнах ИИ, где первоначальные инструкции влияют на последующее поведение ИИ. Дядя Боб соглашается, отмечая, что ИИ может запутаться из-за посторонних тем, попадающих в контекст. Он подчеркивает необходимость сохранения четкого и последовательного направления для ИИ. Разговор также затрагивает 'умную зону' и 'глупую зону' контекстных окон, где ранние токены имеют большее влияние.

На 'траекторию' поведения ИИ влияют первоначальные инструкции и контекст.
Посторонние темы, попадающие в контекстное окно, могут запутать ИИ.
Поддержание четкого и последовательного направления для ИИ имеет решающее значение.
'Умная зона' (ранний контекст) и 'глупая зона' (средний контекст) влияют на внимание ИИ.
Детерминированные инструменты помогают поддерживать траекторию и избегать путаницы ИИ.

Важность проектирования модулей для ИИ

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

Хорошо спроектированные модули с четкими интерфейсами необходимы для понимания ИИ.
Компартментализация помогает ИИ сосредоточиться на конкретных задачах, избегая путаницы.
Глубокие модули (маленький интерфейс, скрытая сложность) полезны для ИИ.
Модели ИИ обращают внимание на имена интерфейсов и структуру кода.
Модели ИИ читают тесты, чтобы понять функциональность кода.

Адаптация принципов чистого кода для ИИ

Касательно изменений в своих принципах 'Чистого кода' дядя Боб отмечает, что ИИ-агенты могут справляться с более высокими порогами сложности, чем люди. Он корректирует оценки CRAP (например, с 4 до 6 или 8), чтобы разрешить использование более крупных функций. Он также утверждает, что человеческие дисциплины, такие как разработка через тестирование (TDD), не следует строго применять к ИИ, поскольку ИИ ведет себя иначе; для них более естественно позволить ИИ сначала написать функцию, а затем ее тест.

ИИ-агенты могут справляться с более высокими порогами сложности, чем люди.
Пороги оценки CRAP могут быть повышены для ИИ (например, с 4 до 6 или 8).
Человеческие дисциплины, такие как TDD, не обязательно оптимальны для ИИ.
ИИ-агенты естественным образом склонны сначала писать функцию, а затем соответствующий ей тест.
Неразумно навязывать ИИ человеческие дисциплины; сосредоточьтесь на человеческих ценностях и скорректированных порогах.

Гибкая разработка против разработки на основе спецификаций с ИИ

Дядя Боб отвергает тщательное предварительное планирование ('разработка на основе спецификаций') с использованием ИИ, сравнивая его с неудачной каскадной моделью. Он обнаружил, что ИИ-агенты с трудом следуют жестким, обширным планам, что приводит к постоянным пересмотрам. Он выступает за гибкий подход: разработать несколько историй, просмотреть архитектуру, а затем продолжить итеративно, признавая, что некоторая ручная организация все еще может потребоваться.

Тщательное предварительное планирование ('разработка на основе спецификаций') с использованием ИИ склонно к неудаче, подобно каскадной модели.
ИИ-агенты с трудом придерживаются жестких, подробных планов.
Гибкий подход (итеративная разработка с обратной связью) более подходит для ИИ.
Разработайте несколько историй, просмотрите архитектуру, затем итерируйте.
Ручная организация все еще может потребоваться в конце циклов разработки.

Непреходящая важность основ разработки программного обеспечения

Дядя Боб утверждает, что основы разработки программного обеспечения остаются критически важными, поскольку программное обеспечение по своей сути сложно. Основы обеспечивают структуру для управления этой сложностью как для людей, так и для ИИ-моделей. Он отвергает идею о том, что основы устарели из-за ИИ, заявляя, что те, кто их игнорирует, в конечном итоге узнают об их важности трудным путем.

Программное обеспечение — самое сложное, что пытаются сделать люди.
Основы организуют сложность, делая ее понятной для людей и ИИ.
Модели ИИ по-прежнему моделируются по человеческому познанию, поэтому основы применимы.
Вера в то, что основы не имеют значения при наличии ИИ, ошибочна.
Те, кто игнорирует основы, в конечном итоге столкнутся с последствиями.

Изучение программирования в эпоху ИИ

Разговор проводит параллели между ИИ и предыдущими уровнями абстракции (компиляторами, ассемблером). Каждое новшество первоначально вызывало опасения устаревания, но основы сохранялись. Дядя Боб советует начинающим программистам глубоко разбираться, написав код, начиная с основ (двоичный код, ассемблер) и до инструментов ИИ, и предлагает относиться к новым разработчикам поначалу как к агентам, чтобы изучить процесс.

ИИ представляет собой последний уровень абстракции в вычислениях, подобно компиляторам или языку ассемблера.
Прошлые уровни абстракции первоначально вызывали опасения потери рабочих мест и обесценивания навыков.
Основы остаются актуальными на разных уровнях абстракции.
Начинающие программисты должны учиться, написав код, начиная с низкоуровневых концепций.
К новым разработчикам в средах с интенсивным использованием ИИ поначалу следует относиться как к агентам, выполняющим тактические задачи.

Развитие навыков стратегического программирования

Дядя Боб считает, что изучение стратегического программирования требует глубокого понимания, полученного благодаря практическому опыту. Он предлагает, чтобы новые программисты проводили время, написав код, а затем относились к ним как к агентам, выполняющим тактические задачи под наблюдением. Этот подход «испытаний», хотя и непродуктивен на начальном этапе, формирует критически важное понимание. Он рекомендует изучать старые книги по принципам программной инженерии для получения фундаментальных знаний.

Стратегическое программирование требует глубокого понимания, которое лучше всего достигается на практике.
Новые программисты должны много писать код и выполнять тактические задачи, как агенты.
Этот опыт «испытаний», хотя и медленный, формирует необходимые навыки.
Старые книги (например, Тома ДеМарко, Эда Йордона) предлагают ценные фундаментальные знания.
Обучение включает как теоретическое изучение, так и практический опыт.

Основы остаются решающими, несмотря на ИИ

Дядя Боб утверждает, что основы разработки программного обеспечения необходимы для организации сложности. Он отвергает утверждения о том, что они устарели из-за ИИ, заявляя, что те, кто их игнорирует, узнают об их важности трудным путем. Он сравнивает ИИ с предыдущими уровнями абстракции, где опасения по поводу устаревания оказались необоснованными, а основные принципы остались жизненно важными.

Основы разработки программного обеспечения являются ключом к управлению сложностью в разработке программного обеспечения.
ИИ не отменяет необходимость этих основ.
Игнорирование основ приведет к негативным последствиям, хотя и с возможной задержкой благодаря возможностям ИИ.
Существуют исторические параллели с предыдущими технологическими достижениями (например, компиляторами, ассемблером).
Основные принципы остаются актуальными независимо от используемых инструментов или уровней абстракции.