Фабрика программного обеспечения — это повторяемый цикл вокруг разработки ПО. Если вы строите такую фабрику, код, достаточно хороший для релиза, всё равно требует человеческого вкуса и ответственности. Мы обсудим это, в том числе, нужна ли вам вообще фабрика прямо сейчас.
Если да:
- Скорее всего, вам потребуются люди в цикле на начальном этапе для определения цели продукта, проектирования системы (если это важно) и вашей планки качества.
- Проверяйте код (фабрика с «включенным светом»), но делайте это осознанно там, где это нужнее всего. Я заметил, что стоит следить за тем, где ломается автоматическая обратная связь. Или где нужно принимать компромиссы по поддерживаемости.
- Стремитесь к тому, чтобы проверки качества происходили как можно раньше и непрерывно. Не все из них обязательны, но это включает системы типов, автоматические тесты, мутационное тестирование, сканеры безопасности и линтинг для архитектурных правил.
- Количество проверок не равно качеству. Вам, вероятно, придется экспериментировать, чтобы понять, какие проверки дают наилучшее соотношение сигнала к шуму. Будьте готовы осознанно ужесточать или ослаблять ограничения.
Вы хотите построить свою фабрику так, чтобы некоторые аспекты человеческого вкуса были закодированы в среде, агент предоставлял доказательства правильности своей работы, а человек всё еще «владел» тем, что попадает в продакшен.
Действительно ли вам нужна фабрика ПО?
По моему опыту, можно зайти удивительно далеко, используя стандартную среду разработки! Например, Claude Code или Codex, несколько сессий, хорошие спецификации со встроенной верификацией и ограничениями. Можно даже закинуть в них пачку задач из GitHub с критериями реализации и участия человека. Руттины Claude Code и облачные агенты Copilot/Codex уже предоставляют вам запланированный или событийно-ориентированный цикл без кастомной инфраструктуры.
Фабрика имеет смысл, когда вам нужны повторяемые стабильные запуски, передача работы между агентами, предотвращение одновременной работы двух сессий над одной задачей, сохранение доказательств и остановка производства, когда ревью отстают.
Итак, я начал с того, что фабрика ПО — это повторяемый цикл вокруг разработки ПО. Мы можем взглянуть на промпт, демонстрирующий очень маленький цикл фабрики:
Прочитай GitHub issue #123 и инструкции репозитория перед изменением кода.
Реализуй только указанные критерии приемки. Не изменяй аутентификацию, биллинг, миграции или существующие тестовые утверждения. Работай в ветке и сохраняй diff обозримым для ревью.
Запусти npm run lint, npm test и npm run build. Если обязательная проверка не может быть выполнена, остановись и объясни почему. Открой черновик pull request с выполненными проверками, оставшимися рисками и любым решением, которое еще должен принять человек. Не сливай.
Цель может поддерживать этот процесс до тех пор, пока проверки не пройдут, и мы можем опрашивать GitHub issues на предмет определенных меток или просматривать открытые pull request каждое утро. Защита веток может обеспечить границу слияния, а человек может оставаться в цикле, выбирая, что готово, проверяя и принимая окончательные решения о слиянии и т.д.
Добавьте фабрику ПО, когда вам нужна событийно-ориентированная очередь задач (например, триггеры Slack, GitHub issues, Linear, бэклог) для выполнения в изолированном облачном окружении с целью обработки триажа, реализации и тестирования с некоторым явным контролем со стороны человека. Некоторые заканчивают свой цикл агентом-монитором, который следит за продакшеном и создает задачи, которые снова проходят триаж.
По моему опыту, фабрика становится полезной, когда сложная часть заключается в том, чтобы сделать различные запуски согласованными, передавать работу между агентами и избегать ситуаций, когда разные сессии претендуют на одну и ту же задачу, сохранять доказательства и останавливать производство, когда человеческое ревью отстает.
То, что решает эту проблему, может звучать немного скучно. Например, Warp упоминают триаж каждой входящей задачи в одно из четырех состояний: ready-to-implement, ready-to-spec, needs-info, wait-to-implement — и метка запускает следующего агента.
Эта метка выполняет несколько задач одновременно: это и очередь, и блокировка, и, поскольку сессия подхватывает только то, что помечено как готовое, это место, где человек может припарковать задачу, не говоря «нет» навсегда.
С точки зрения рабочего процесса, есть несколько сходств и различий с простым использованием Claude/Codex:
- Направление (Steering): агенту нужна коррекция курса, вы можете дать указание и перенаправить его
- Уведомления (Notifications): как фабрика сообщает, что она заблокирована. Это может быть из-за неоднозначности требования, начала рискованного действия или необходимости ввода данных человеком (направление)
- Передача (Handoff): перемещение задачи, ее состояния и контекста между облачной фабрикой/другим агентом/человеком-ревьюером. Хорошие передачи будут отслеживать, что произошло, что осталось сделать и почему передача необходима.
В хорошей фабрике человек не ограничивается только проверкой и утверждением конечного diff в самом конце. Он может формировать работу на раннем этапе, направлять ее во время реализации, проводить ее через передачу или остановить ее отправку в продакшен.
Верификация — это то, на что ответственная фабрика тратит много времени. Мы рассмотрим это подробнее позже.
Если вы решите, что вам действительно нужна фабрика ПО, ее создание — не единственный вариант. Развертывание инфраструктуры для масштабирования фабрики может быть большой работой, и вам стоит рассмотреть вариант покупки против создания. Factory.ai, Devin, Warp и HumanLayer — все продают часть этого цикла.
На что я на самом деле трачу свое внимание
Мой повседневный опыт разработки ПО сильно изменился за последний год. Я много говорю о том, что все чаще выполняю параллельную работу с агентами, двигаясь к созданию фабрики ПО с «включенным светом». И многие люди спрашивают меня: что все это на самом деле значит? Что ты строишь? Какие проекты ты для этого используешь? В основном это:
Итак, в самый обычный день у меня есть более простая фабрика ПО с «включенным светом». У меня могут быть задачи, выполняющиеся в облаке. Половина этих задач может быть связана с работой над продакшен-клиентскими приложениями для небольших компаний, с которыми я сотрудничаю. У них будут реальные пользователи. У них будет настоящая аутентификация, платежи, подписки, реальные серьезные риски, с которыми нужно быть осторожным. Нельзя просто сказать: «О, агент, иди и сделай это» без тестов, ограничений и проверок качества.
Я могу работать над своими open source проектами. Могу создавать сайты-компаньоны для своих книг. Могу работать над инструментами. Могу создавать свои собственные приложения. И это все очень, очень разные типы приложений, над которыми я работаю. И иногда единственное, что их объединяет, — это инструмент, который я использую для работы, верно? Возможно, я работаю над миграцией. В других случаях я могу заниматься реальной серьезной работой над функциями. И радиус поражения работы также может быть очень, очень разным.
Поэтому, когда вы начинаете думать о том, как прийти к состоянию, когда мы все чаще выполняем параллельную работу, пытаемся повысить скорость, продуктивность и автономность (что означает приведение системы к состоянию, когда мы ей больше доверяем), вам действительно нужно подумать о том, какие места абсолютно требуют человеческого ревью кода и человеческого ввода.
И многое из этого потребуется на начальном этапе, верно? Когда вы определяете спецификацию, требования, как будет выглядеть дизайн продукта? Каковы будут намерения продукта? И затем, как вы проверяете, что агенты действительно правильно выполнили работу? Как вы проверяете, что они не сломали существующую систему? Как вы убеждаетесь, что это соответствует вашей планке качества?
Итак, генерация кода — это не обязательно та часть, о которой нужно беспокоиться больше всего. Имея достаточный контекст, агенты могут написать реализацию, запустить тесты, проанализировать сбои и исправить код за нас. Нам нужно прийти к состоянию, когда мы чувствуем, что в среде закодировано достаточно человеческого вкуса, чтобы мы могли доверять тому, что создается, и чтобы наше человеческое внимание было сосредоточено на местах, где оно нужнее всего.
Конечно, есть критика со стороны людей, которые говорят: «Я не верю, что можно просто автоматизировать большую часть этого». Дело не в том, что мы автоматизируем всё, верно? Но учитывая объем генерируемого кода, я не думаю, что реалистично ожидать, что люди будут читать его весь, особенно когда мы большую часть времени не строим ракеты, верно? Мы строим UI, мы строим full-stack приложения.
Наше суждение, наш вкус лучше всего направить на те места, где они нужнее всего. Например, какие части системы наиболее рискованны? Где нам нужно применить человеческий вкус? Это может быть во фронтенде. Это может быть в том, как работает система. Это не должно быть 100% кода.
Моя когнитивная пропускная способность не масштабируется вместе с агентами
Реальность такова, что да, теперь мы можем запустить десятки, сотни, тысячи агентов параллельно, но ваша собственная когнитивная пропускная способность не масштабируется таким же образом. Это может привести к когнитивному долгу или долгу понимания, о котором я говорил ранее.
Если вы вспомните всего пять-десять лет назад, в инженерном сообществе было много дискуссий о переключении контекста и его цене. Мы говорили о том, как люди ненавидят, когда коллега или кто-то подходит к вашему столу, когда вы находитесь в середине задачи. Затем вам требовалось много времени, чтобы вернуться в состояние потока, потому что нужно было наверстать упущенное: где я был? Что я делал? Даже если у вас оставался небольшой остаточный контекст, это все равно отнимало время.
Сейчас мы переключаем контекст еще чаще, чем раньше. В любой день, если я работаю вне фабрики ПО, я могу одновременно работать над пятью или десятью различными проектами с агентами, или над пятью или десятью различными функциями в одном проекте. У меня может быть пять или десять разных сессий, можно так сказать.
Это означает, что я должен быть в состоянии отслеживать хотя бы некоторые из них. Возможно, я смогу повысить автономность некоторых задач, если буду уверен, что достаточно хорошо определил задачу, определил результат и то, как будет проверено, что она выполнена достаточно хорошо. Но будут задачи, где я, возможно, не буду чувствовать себя так уверенно, и где будет больше риска или нюансов. За ними придется следить.
Подумайте об оптимизации фабрики ПО для вашего ревьюера. Учитывая, что каждый из этих подходов по-прежнему направляет свой результат на внимание одного человека, вы должны спросить себя, насколько фабрика облегчает принятие решений, которые вам все еще приходится принимать.
Ошибка «не тот проект»
Я помню, когда я работал над несколькими параллельными проектами со своими агентами, и были случаи, когда я случайно делал такие вещи, как, возможно, я работал над веб-приложением, в которое хотел добавить темную тему, и у меня в голове было: «Окей, вот как это должно выглядеть». Но я случайно зашел в сессию для другого проекта и начал вводить тот же самый промпт.
Так я начал внедрять темную тему для чего-то, что абсолютно в ней не нуждалось. И я могу совершить такую ошибку. Я не хочу, чтобы моя фабрика ПО совершала такие ошибки.
Вам нужно думать об этом как о системе. Вы, по сути, пытаетесь закодировать культуру разработки ПО, командную культуру, в систему, чтобы она имела такое же поведение, чтобы у нее была ответственность, закрепленная за кем-то, чтобы кто-то все еще отвечал за происходящее, и вы были очень явны в том, как вы думаете об этих вещах.
Когда зеленый цвет вводит в заблуждение
Даже в таких системах нужно быть очень осторожным, верно? Многие из нас видели, что когда вы просите ИИ помочь пройти тест, например, модульный тест, он может изменить модульный тест, чтобы удовлетворить условие, или изменить логику кода, чтобы пройти это условие. Это не значит, что он на самом деле следовал вашему намерению согласовать как функциональное поведение, так и то, что тест должен был проверять, верно?
То, что фабрика ПО показывает, что всё зелено, не значит, что это действительно зелено, особенно в начале, когда вы все настраиваете. Вам нужно уделять много внимания, чтобы убедиться, что ваши проверки, ваши верификации — все они настроены правильно. Они делают то, что вы от них ожидаете. Вы не хотите, чтобы они вводили в заблуждение.
Вы не хотите оказаться в ситуации, когда у вас были тесты, которые говорят: «Эй, я пошел и изменил поддерживаемые провайдеры аутентификации. Вы попросили меня добавить GitHub, например, в качестве провайдера аутентификации, но в моем UI было место только для трех, поэтому я пошел и убрал один из других. И, кстати, это оказался тот, который был нужен вашим клиентам». Поэтому вам просто нужно быть очень явным в том, как вы хотите, чтобы эти системы работали.
Кстати, безопасность тоже очень важна, и если ваша фабрика читает недоверенный ввод, такой как GitHub issue или сообщение Slack, он может быть враждебным и содержать такие проблемы, как атаки на цепочку поставок. Некоторые продукты, связанные с фабриками ПО, такие как Vercel Sandbox/AI ADK Factory, запускают своих агентов в изолированных песочницах, содержащих только те секреты, которые нужны для задачи. Таким образом, скомпрометированный запуск не может получить доступ к тому, что не нужно для работы. Ваша защита в итоге оказывается многоуровневой.
Какие старые проекты заслуживают второй жизни?
Я также думаю, что большая часть того, как мы работаем сегодня, заключается в решении, что должно существовать. Если вы вспомните много лет назад, до появления ИИ, было так много заброшенных проектов по разработке ПО, так много заброшенных проектов выходного дня, личных проектов, которые просто не были запущены, потому что у нас не было времени их закончить. У нас не было возможности расставить приоритеты и выпустить их, потому что они были не так важны для нас, или мы не могли найти время.
Теперь для нас довольно тривиально завершить эти проекты, но возникает тот же вопрос человеческого суждения. Заслуживают ли эти проекты существования? Стоит ли их запускать? Потому что вы выпускаете их в мир, и даже если у них всего пять пользователей, возможно, вам придется их поддерживать. Возможно, теперь у вас есть планка качества, которую вы хотите поддерживать.
Я знаю, что у меня было так много проектов на GitHub за эти годы, что теперь, когда у меня есть агент, первое, что я делаю, — это заставляю проект собираться. Потому что, конечно, вы клонируете его, и теперь он не собирается, потому что все зависимости изменились. Половина вещей устарела или имеет уязвимости в безопасности, поэтому вам нужно их обновить.
Затем вам нужно добавить тесты, если их не было, чтобы знать, что поведение, по крайней мере, сохранится, если вы будете обновлять проект каким-либо образом, или если вы переносите его на более современный язык или фреймворк.
Затем вы начинаете спрашивать себя: «Ну, возможно, глупый пример, но, возможно, я использовал Twitter Bootstrap в прошлом для этого, но теперь все используют Tailwind и shadcn, поэтому мне нужно переделать UI». И вы заметите, что внезапно это отнимает у вас больше времени, верно? Да, агент может сделать большую часть этого быстрее, но теперь вам приходится учитывать продуктовое чутье, вкус и все эти вещи.
Вы все еще задаетесь вопросом: «Для кого это? Есть ли у этого рынок? Это для меня? Это для других? Если я выпущу это в мир, будет ли это по-прежнему так же интересно, учитывая, что теперь любой может создать такое же быстро?»
Поэтому я думаю, что человеческий вопрос о том, заслуживают ли эти вещи существования, как мы учитываем наш вкус и суждение, — я чувствую, что эти вещи продолжают быть чрезвычайно важными. Именно здесь по-прежнему проявляется этот дефицитный ресурс человеческого внимания. Раньше у нас было только конечное количество часов в сутках. У нас были встречи. Нам нужно было выделять время на дизайн, кодирование и так далее.
Теперь, когда у нас есть агенты, которые нам помогают, я думаю, что вы должны быть очень явными в том, на что и почему вы тратите свое время.
Что произошло, когда я построил образец
Итак, я расскажу о 82-минутном запуске фабрики. Люди довольно долго спрашивали меня: «Как построить фабрику ПО?» или «Я привык использовать Claude Code или Codex. Как мне развить свою настройку до использования фабрики ПО?»
Поэтому первое, что я говорил: «Возможно, у вас все в порядке. Ваша работа может быть вполне нормальной и без фабрики». Но я хотел дать людям эталонную настройку, которую они могут проверить. Итак, я собрал репозиторий под названием Factory, который вы можете посмотреть. Я также собрал демонстрационное приложение и воркшоп.
В последние пару лет моим любимым демонстрационным приложением для многих вещей было приложение для фильмов. Я большой любитель фильмов. Я люблю смотреть фильмы. Я смотрю фильмы постоянно, и у меня есть демонстрационное приложение, которое начинается как очень простое приложение для фильмов. И я хочу, чтобы фабрика могла реализовать ряд функций. Есть несколько разных функций. Я хочу функцию избранного. Я хочу, чтобы она могла, возможно, выполнять поиск, а также, возможно, иметь темную тему и тому подобное.
Итак, моя фабрика начинает работать с этими вещами. Вы можете посмотреть реализацию. Одним из преимуществ было то, что она выявляла реальные проблемы. Эти проблемы могли быть не тем, что я бы заметил, если бы просто попросил ее сделать одноразовую реализацию.
Где-то на 60-й минуте я почувствовал: «Ого, это идет необычно медленно». Я спросил свою среду, используя фабрику: «Почему все идет медленно?» Она ответила: «На самом деле все в порядке. Все верификаторы все еще работают».
Вы могли ожидать, что отдельные задачи займут 10, 15, 20 минут, но они могут занять в два-четыре раза больше времени, как только вы начнете включать верификацию, повторные попытки, проверки в браузере, человеческое ревью и любые другие дополнительные задержки.
Я думаю, что это может привести к лучшему качеству и большему доверию к системе. С точки зрения измерения, вы можете смотреть на такие метрики, как стоимость одного слитого PR и срок жизни кода как метрики долга понимания.
Вам также нужно подумать о том, что является полезной задержкой, а что — накладными расходами фабрики. В моем случае верификаторы выявили некоторые реальные проблемы. Немного времени было потрачено на создание доказательств, которые я хотел. Часть была накладными расходами на работу фабрики. Я не тратил время на ее оптимизацию, но фабрика, которая просто выполняет множество проверок, которые вы не находите ценными, не означает, что она высокого качества.
Вы хотите изучить, для любых повторяющихся проверок: неактуальны ли они? Шумны ли они? Действительно ли они делают систему безопаснее?
У верификации должен быть бюджет
То, как я думаю о бюджете на верификацию, — это, по сути, то, о чем мы говорим. Мы говорим о бюджете верификации. Я думаю об этом так же, как исторически думал о бюджетах производительности.
Будут определенные виды проверок, которые можно запускать на ранних этапах жизненного цикла разработки ПО, и будут некоторые вещи, настолько тяжелые, но предлагающие так много ценности, что вы захотите запускать их позже. Есть некоторые виды быстрых проверок, например, линтинг, проверка типов. Это относительно быстрые проверки, которые можно запускать на раннем этапе.
Наш полный набор тестов может быть запущен ближе к моменту перед созданием черновика PR или после него. Это может включать мутационное тестирование, тестирование в браузере, проверки безопасности и тому подобное.
Я думаю, что не обязательно заменять их просто сводками. Вам нужны реальные тесты, но нужно просто убедиться, что вы выделяете на них бюджет в правильных местах, потому что вы не хотите замедлять свой цикл разработки. Я certainly никогда не хочу замедлять свой цикл разработки. Быстрый итерационный цикл важен для меня, но я также хочу сохранить эти сдержки и противовесы.
Когда запуск не доходит до релиза
Многое из того, что я написал выше, касается проверок.
В своей фабрике ПО Vercel маркирует каждый запуск агента как «успех», «с изъяном», «заблокирован» или «вручную», и только «успех» отправляется в продакшен. Остальные возвращаются в систему. Я думал о запусках в аналогичных терминах.
«С изъяном» здесь означает, что была реализована неправильная вещь или, возможно, не было полного контекста, поэтому это нужно исправить. «Заблокирован» означает, что в среде, возможно, не хватало учетных данных, поэтому их нужно предоставить. «Вручную» — это граница, которую фабрике, возможно, еще не разрешено пересекать.
Две из трех вещей здесь могут иметь механические исправления, а последняя связана с доверием.
Хотя это отличная сортировка, она не показывает вам стоимость. Возвращаясь к моей реализации фабрики с приложением TMDB: быстрый поиск без отклонений занял 7 минут. Избранное с двумя отклонениями и человеческим решением посередине заняло 56 минут. Та же фабрика. Поэтому я бы дополнил таксономию таймингом по этапам, иначе вы знаете, что запуск вернулся с изъяном, но не знаете, во сколько вам обошлось это выяснение. Другая вещь, которую я бы исправил, — это передача на границе: моя образцовая фабрика остановила первую задачу и переместила ее в factory:needs-info, что было правильно, но я не знал, куда поместить свой ответ. Ручной запуск заканчивается не тогда, когда фабрика останавливается, а когда человек знает, что делать дальше.
Автономность — это не одна настройка
Пару недель назад я написал статью об агентной автономности и о том, как думать об автономности, потому что автономность не будет единой настройкой для каждого проекта.
Верификация покупает вам доверие и возможность предоставить больше автономности вашим агентам. Так, если, например, я работаю над нетривиальным изменением, но у меня есть ряд проверок, все верифицируется правильно, и, возможно, я сам проверил это вручную. В следующий раз, когда я буду выполнять подобную задачу в том же проекте, возможно, я буду чувствовать себя комфортно, предоставив агенту немного больше автономности.
Вот о чем вы думаете, когда строите эти фабрики ПО. Ваша верификация будет меняться в зависимости от риска. Ваша цель — наилучшее соотношение сигнала к шуму. Вы не хотите просто иметь какой-то большой контрольный список, который вы выполняете.
Функция, которую мне пришлось переучивать
Была одна функция, которую я откладывал в день, когда использовал несколько сессий с Claude, и я работал над несколькими разными проектами одновременно, над несколькими разными функциями в каждом проекте. Итак, Claude реализовал функцию, над которой я работал. Тесты, казалось, проходили. Я не уделил много внимания верификации, но тесты прошли, и я подумал, что все работает. Я слил изменения.
Это была функция избранного. Я думал, что все довольно хорошо. Я попытался проверить это в браузере. Казалось, все в порядке, но через пару дней я вернулся к коду, потому что хотел внести некоторые изменения.
Я не хотел просто просить своего агента внести изменения, потому что это был едва заметный нюанс в работе. Нажимаешь на иконку, а нужного эффекта при нажатии не происходит, и мне хотелось просто это подправить. Я хотел понять, как это работает, чтобы правильно направлять своего агента.
Я вернулся к коду, но не мог объяснить, как работает эта функция. Ведь репозиторий был моим, верно? Я утвердил изменения. Я понимал, как работает большая часть кода, большая часть репозитория, но моё понимание не поспевало за всем тем кодом, который накапливался.
Чего я не усвоил — это как именно работает добавленная функция, как устроен интерфейс, как работает эффект. Мне пришлось переделывать эту функцию и буквально шаг за шагом разбираться: «Как это работает? Как мне это понять?»
Что параллельная работа делает с пониманием
Когда вы занимаетесь параллельной работой, это усугубляет общую проблему, и она становится ещё более острой в условиях программной фабрики. Когда вы ведёте пять или десять сессий, они создают не просто проблему объёма проверок. Они порождают несколько ментальных моделей, которые могут сильно «остыть», пока вы работаете над другими задачами.
Раньше мы говорили о сложностях переключения контекста, и как только чат сжимается, вы отвергаете одни подходы, пробуете другие, работаете в паре с агентом — вам будет трудно запомнить всё, что происходило в вашей сессии.
Вы можете прокрутить вверх, но из-за сжатия там будет не всё, и вы не сможете удержать это в голове. Код часто сохраняет принятое решение, но не причину, по которой оно было принято.
Это то, что, как мне кажется, может быть для вас полезным уроком: важно попросить агента сохранять информацию о своей траектории или интересные выводы о том, как он подходил к решению задачи, чтобы вы могли вернуться к этому позже.
Это может быть или не быть тем, что вы решите закоммитить в репозиторий. Вы можете оставить это локально, если хотите, или поделиться с командой, но это будет то, к чему можно обратиться впоследствии. Вместо того чтобы полагаться на то, что это, возможно, осталось в сессии, или что вы, возможно, вспомните об этом позже.
Что же она на самом деле производит?
@threepointone и @bentlegen опубликовали мнения о программных фабриках, с которыми я полностью согласен:
Легко увлечься механизмами работы, оптимизировать их и забыть, что они должны были производить. Если ваша фабрика в основном производит лучшую фабрику, вы построили программное обеспечение, продуктом которого является оно само.
Я считаю, что инвестиции в цикл — это нормально, и они дают накопительный эффект. Провал наступает, когда цикл замыкается, когда всё, что производит фабрика, потребляется самой фабрикой, и никто снаружи не заметит, если её выключить. Тест, который я бы применил, — это «вытягивание». Что-то извне должно запрашивать улучшение. Если вы не можете назвать того, кто «вытягивает», вы просто полируете.
Ответственность никуда не исчезает
Под всем этим лежит более широкий принцип.
Процент кода, физически напечатанного человеком, может резко упасть. Я не думаю, что ответственность человека должна упасть вместе с ним.
- Кто-то всё ещё выбирает проблему.
- Кто-то всё ещё выбирает архитектуру.
- Кто-то всё ещё устанавливает планку качества.
- Кто-то решает, каким сигналам верификации можно доверять.
- Кто-то решает, когда доказательств достаточно для релиза.
И когда полученная система даёт сбой, фраза «это написал агент» не работает. Вот почему я не думаю, что будущее разработки ПО лучше всего описывается как выход человека из цикла. Вместо этого человеческое суждение перемещается.
Мы должны убрать людей из тех частей цикла, где машины могут выдавать более сильные, быстрые и детерминированные сигналы. В то же время мы должны сосредоточить людей в тех местах, где наиболее важны контекст, вкус, риск и долгосрочная ответственность.
Лучшие программные фабрики будут определяться не тем, насколько полно они устраняют участие человека.
Они будут определяться тем, насколько разумно они его размещают.
Держите человеческое суждение на этапе определения намерения, формы системы и планки качества. Проверяйте код там, где автоматическая обратная связь становится слабой или последствия становятся субъективными. Продвигайте каждый детерминированный сигнал как можно раньше и непрерывно в цикл. Сознательно ужесточайте и ослабляйте ограничения по мере того, как система заслуживает или теряет доверие.
Человек всё ещё должен нести ответственность за то, какой код в итоге попадает в релиз. Код, достаточно хороший для релиза, всё ещё начинается с того, кому не всё равно, должен ли он существовать.
