Keyd's Personal Blog

/home

/hbr

/tech

/finops

/tags

/english

/spanish

Keyd's Personal Blog > tech > Software Fundamentals Matter More Than Ever

Software Fundamentals Matter More Than Ever

LLM анализ статьи

Развёрнутая аннотация

Доклад Matt Pocock “It Ain’t Broke: Why Software Fundamentals Matter More Than Ever” — это короткое, практическое выступление о том, почему AI coding не отменяет классическую software engineering-дисциплину, а делает её важнее. Публичное описание сессии формулирует тезис так: AI-инструменты одновременно «overhyped and powerful», а разницу между хорошим и плохим результатом создаёт не сам инструмент, а процесс; среди принципов названы ubiquitous language, vertical slices, TDD и deep modules. (ai.engineer)

Pocock начинает с критики подхода specs-to-code: написать спецификацию, сгенерировать код, не смотреть в кодовую базу, а при проблемах менять только spec и снова запускать генерацию. По его опыту, такой цикл быстро производит всё более плохой код. Центральная мысль: code is not cheap; особенно дорог плохой код, потому что он делает систему трудной для изменения и тем самым снижает отдачу от AI. Далее доклад переводит старые идеи из книг John Ousterhout, The Pragmatic Programmer, Frederick P. Brooks, DDD и Kent Beck в набор практик для работы с AI-агентами: добиваться общего design concept, строить shared language, использовать TDD и feedback loops, проектировать deep modules, тестировать по интерфейсам и делегировать AI реализацию внутри хорошо очерченных границ. Финальный вывод: AI — сильный тактический программист, но стратегическое проектирование остаётся задачей человека.

Введение и контекст

  • Название: “It Ain’t Broke: Why Software Fundamentals Matter More Than Ever”.
  • Спикер: Matt Pocock, AI Hero.
  • Событие: AI Engineer Europe 2026; в программе доклад указан как keynote 2026-04-09, 17:20–17:40, Keynote stage. (ai.engineer)
  • Дата публикации YouTube: 2026-04-23; внешний индекс Tech Talks Weekly указывает длительность 00h 18m 26s. (DEV Community)
  • Хронометраж по приложенному VTT: примерно 00:18:26; содержательная речь — примерно с 00:00:14 до 00:18:08.
  • Канал/контекст публикации: AI Engineer Europe / AI Engineer; спикер — Matt Pocock, AI Hero.
  • Целевая аудитория: software engineers и AI engineers, которые уже используют или собираются использовать Claude Code, Codex, Cursor-подобные агенты и другие AI coding tools в реальных кодовых базах.
  • Заявленная проблема: многие считают, что AI сделал старые правила разработки устаревшими; Pocock спорит с этим и утверждает, что именно классические fundamentals позволяют получать качественный результат от AI.
  • Контекст из описания сессии: после 18 months обучения разработчиков работе с AI agents Pocock наблюдает повторяющийся паттерн: успешны не те, кто «делегирует всё» или «не делегирует ничего», а те, кто опирается на engineering fundamentals. В описании также названы ubiquitous language, vertical slices, TDD и deep modules; в самом приложенном транскрипте vertical slices отдельно не разворачиваются. (ai.engineer)
  • Источник содержания для анализа: приложенные английский и русский VTT-транскрипты. Экранные кадры/видеофайл отдельно не были приложены, поэтому отдельный OCR экранного текста выполнить нельзя; названия слайдов/skills учтены там, где они попали в транскрипт.

Рекомендации и ключевые заметки

  • Главное правило доклада: “code is not cheap”; плохой код сейчас особенно дорог, потому что AI хорошо работает только в хорошей, понятной и изменяемой кодовой базе.

  • Критика specs-to-code: не надо строить процесс так, будто код можно игнорировать. Pocock описывает цикл “spec → AI-generated code → проблема → изменить spec → снова сгенерировать код” как “vibe coding by another name”.

  • Tip number one: сначала достичь shared design concept, а не быстро создавать план или PRD.

    • Инструмент: Grill Me.
    • Ключевая формулировка skill: “Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree… resolving dependencies between decisions one by one.”

  • Tip number two: создать shared language with the AI.

    • Инструмент: ubiquitous language skill.
    • Идея: термины в разговорах, коде и документации должны происходить из одной domain model.

  • Skill number three: TDD.

    • Причина: TDD заставляет LLM двигаться маленькими шагами — сначала тест, затем прохождение теста, затем refactor.

  • Неявный следующий практический блок: улучшать архитектуру через deep modules, а не плодить shallow modules.

    • В транскрипте номер “tip number four” явно не прозвучал; содержательно эту роль выполняет skill Improve codebase architecture.

  • Tip number five: Design the interface, delegate the implementation.

    • Смысл: человек проектирует интерфейс и тестируемую границу; AI может реализовывать внутренности модуля.
    • Ограничение: Pocock прямо оговаривает, что так нельзя бездумно делать для критичных частей вроде finance.

  • Финальный принцип Kent Beck: “Invest in the design of the system every day.”

  • Роль человека: AI — “tactical programmer”, “sergeant on the ground”; человек должен думать на strategic level.

Ключевые выводы и результаты

  • Pocock не приводит benchmark-таблиц, eval-метрик, точных процентов улучшения, стоимости или latency-измерений. В видео не заявлено количественное сравнение качества AI coding до/после предложенных практик.

  • Конкретные количественные данные из речи:

    • Репозиторий со skill Grill Me, по словам Pocock, имел “like 13,000 stars or something”.
    • Grill Me может заставить AI задать “like 40 questions, 60 questions”; Pocock видел случаи, где AI задавал 100 questions, пока не считал, что достигнуто shared understanding.
    • В финале Pocock говорит, что нужные software fundamentals используются уже 20 years, for longer.

  • Конкретные заявленные эффекты:

    • Specs-to-code в его опыте приводил к тому, что после повторных запусков код становился “worse code” и в итоге превращался в “garbage”.
    • Ubiquitous language, по наблюдению Pocock, улучшает planning, делает reasoning AI менее verbose и выравнивает implementation с изначальным планом.
    • TDD ограничивает скорость AI и заставляет работать маленькими deliberate steps.
    • Deep modules делают кодовую базу проще для AI exploration, для тестирования и для человеческого понимания.
    • Gray-box подход снижает когнитивную нагрузку: человек не обязан читать каждую внутреннюю деталь, если интерфейс, purpose и внешние тесты хорошо спроектированы.

  • Главный результат доклада: хорошие кодовые базы теперь важнее, а не менее важны, потому что именно они позволяют извлечь реальную пользу из AI coding tools.

Методы и фреймворки

  • Specs-to-code movement:

    • Написать спецификацию.
    • Попросить AI превратить её в код.
    • При проблеме не смотреть в код, а менять спецификацию.
    • Снова запускать генерацию.
    • Pocock отвергает этот цикл как источник деградации качества.

  • John Ousterhout / A Philosophy of Software Design:

    • Complexity: всё в структуре software system, что затрудняет понимание и изменение системы.
    • Плохая кодовая база — та, которую трудно менять без багов.
    • Хорошая кодовая база — та, которую легко менять.

  • The Pragmatic Programmer / software entropy:

    • Если при каждом изменении думать только о локальной задаче, а не о дизайне системы, кодовая база становится всё хуже.
    • AI ускоряет этот процесс, если не управлять архитектурой.

  • Frederick P. Brooks / design concept:

    • Design concept — невидимая, разделяемая теория того, что строится.
    • Это не markdown-файл и не отдельный артефакт; это shared understanding между участниками проектирования.

  • Grill Me skill:

    • AI превращается в “adversary”, который задаёт вопросы и проходит по design tree.
    • Результат разговора можно превратить в PRD, issues или вход для AFK agent.

  • DDD / ubiquitous language:

    • Общий словарь терминов связывает domain experts, developers, code и AI.
    • Pocock описывает markdown-файл с таблицами терминов, который AI может читать и использовать при planning/implementation.

  • Feedback loops:

    • Static types.
    • TypeScript для TypeScript/front-end контекста.
    • Доступ LLM к browser при front-end разработке.
    • Automated tests.

  • The Pragmatic Programmer / outrunning your headlights:

    • “The rate of feedback is your speed limit.”
    • AI по умолчанию делает слишком много за раз, поэтому его надо ограничивать короткими циклами обратной связи.

  • TDD:

    • Написать тест.
    • Сделать тест зелёным.
    • Refactor с учётом дизайна.

  • Deep modules vs shallow modules:

    • Deep module: много функциональности скрыто за простым интерфейсом.
    • Shallow module: мало функциональности и сложный интерфейс.
    • Deep modules помогают и человеку, и AI не держать всю систему в голове.

  • Improve codebase architecture skill:

    • Исследовать кодовую базу.
    • Найти связанные куски кода.
    • Обернуть их в deep module.
    • Тестировать через простой interface boundary.

  • Gray-box modules:

    • Человек проектирует интерфейс и внешнюю проверку.
    • AI может реализовать внутреннюю часть.
    • Подход применим не везде: критичные области требуют большего human review.

Ключевые идеи и концепции

  • AI не отменяет дизайн; AI увеличивает цену плохого дизайна. Если код трудно менять, AI не раскрывает потенциал, а ускоряет накопление технического долга.
  • Кодовая база — не disposable artifact. Specs-to-code ошибочно предполагает, что код можно не читать и не проектировать. Pocock считает это отказом от системного дизайна.
  • Communication barrier — первая проблема AI coding. Если человек и AI не разделяют design concept, AI может построить “что-то другое”, даже если формально prompt звучал разумно.
  • Shared language снижает шум. Когда AI, человек и код используют одни и те же доменные термины, AI меньше распыляется и лучше попадает в intent.
  • Feedback loops важнее скорости генерации. AI может писать код быстрее, чем успевает проверять. Поэтому ограничения через types, tests, browser feedback и TDD становятся “speed limit”.
  • Testability — свойство архитектуры, а не только тестов. Хорошая кодовая база легче тестируется; значит, она даёт AI более качественную обратную связь.
  • Deep modules уменьшают cognitive load. И AI, и человек выигрывают от меньшего числа крупных, хорошо очерченных модулей с простыми интерфейсами.
  • Стратегия остаётся за человеком. AI может быть сильным исполнителем, но Pocock прямо отделяет tactical programming от strategic system design.
  • Инвестировать в дизайн нужно ежедневно. Финальная критика specs-to-code состоит в том, что он не инвестирует в дизайн системы, а “divests” — выводит из него внимание и ответственность.

Практические выводы и шаги

  • Перед кодированием не отдавать AI сырой prompt; сначала заставить его уточнять требования до shared understanding.
  • Для сложных задач использовать Grill Me-подход: AI должен задавать вопросы, проходить ветви design tree и выявлять зависимости решений.
  • После уточняющего диалога превращать результат в PRD, issues или задачи для AFK agent.
  • Завести и поддерживать ubiquitous language: список терминов, значений и доменных сущностей, которыми пользуются человек, AI и код.
  • Давать AI этот словарь при planning и implementation.
  • Не позволять AI делать огромные пачки изменений без проверки.
  • Давать AI feedback loops: types, tests, browser access для front-end, автоматизированные проверки.
  • Использовать TDD как способ заставить агента идти маленькими шагами.
  • Рефакторить архитектуру в сторону deep modules.
  • Тестировать модули через внешние интерфейсы.
  • В менее критичных частях системы можно проектировать interface boundary и делегировать AI внутреннюю реализацию.
  • В критичных доменах, например finance, не полагаться только на gray-box делегирование.
  • В PRD явно указывать module changes, interfaces и то, как меняются границы модулей.
  • Постоянно инвестировать в дизайн системы, а не только в генерацию новых строк кода.

Ссылки/таймкоды

  • 00:00:14 — приветствие и установка: доклад должен поддержать инженеров, которые сомневаются в ценности своих навыков.
  • 00:00:33 — главный тезис: software fundamentals сейчас важнее, чем когда-либо.
  • 00:00:42 — Pocock упоминает курс Claude Code for Real Engineers; в транскрипте английский ASR ошибочно даёт “Clojure Code”.
  • 00:01:08 — объяснение specs-to-code movement.
  • 00:01:42 — личный опыт: повторная генерация давала всё более плохой код.
  • 00:02:06 — вывод: игнорировать код и позволять ему “manage itself” не работает.
  • 00:02:45 — Ousterhout: complexity как причина трудности понимания и изменения системы.
  • 00:03:10 — The Pragmatic Programmer и software entropy.
  • 00:03:43 — критика идеи “code is cheap”.
  • 00:04:15 — формулировка thesis: good codebases и fundamentals важнее, чем раньше.
  • 00:04:36 — failure mode 1: AI didn’t do what I wanted.
  • 00:05:14 — Frederick P. Brooks и design concept.
  • 00:05:51 — Grill Me skill и его ключевая формулировка.
  • 00:06:10 — количественные детали Grill Me: около 13,000 stars; 40, 60, иногда 100 questions.
  • 00:07:18 — tip number one: сначала shared design concept.
  • 00:07:21 — failure mode 2: AI слишком verbose.
  • 00:08:14 — DDD как источник решения.
  • 00:08:25 — ubiquitous language.
  • 00:08:57 — ubiquitous language skill: сканирует codebase и создаёт markdown-таблицы терминов.
  • 00:09:41 — tip number two: create a shared language with the AI.
  • 00:09:45 — failure mode: AI построил “правильную” вещь, но она не работает.
  • 00:10:01 — feedback loops: static types, TypeScript, browser access, automated tests.
  • 00:10:50 — “outrunning your headlights”; rate of feedback as speed limit.
  • 00:11:11 — skill number three: TDD.
  • 00:11:32 — почему testing hard: размер unit, mocks, behaviors.
  • 00:12:15 — хорошие codebases легче тестировать.
  • 00:12:42 — Ousterhout и deep modules.
  • 00:12:59 — deep modules vs shallow modules.
  • 00:13:18 — shallow modules как препятствие для AI exploration.
  • 00:14:20 — Improve codebase architecture skill.
  • 00:14:50 — testable codebase: тестировать и верифицировать через interface.
  • 00:15:04 — failure mode: shipped more code, but brain can’t keep up.
  • 00:15:42 — deep modules как gray boxes.
  • 00:15:50 — design interface, не ревьюить каждую деталь implementation.
  • 00:15:57 — ограничение: не применять бездумно к критичным частям вроде finance.
  • 00:16:26 — tip number five: design the interface, delegate the implementation.
  • 00:16:47 — PRD должен явно учитывать module changes и interfaces.
  • 00:16:58 — Kent Beck: invest in the design of the system every day.
  • 00:17:18 — финальный тезис: code is not cheap.
  • 00:17:23 — AI как tactical programmer; человек отвечает за strategic level.
  • 00:17:46 — ссылка на GitHub repo mattpocock/skills; публичный README репозитория подтверждает quickstart через npx skills@latest add mattpocock/skills. (github.com)