Пробуем паттерн Software Factory: эксперимент Уилла Ларсона в Imprint

· 1 мин чтения
ai-agents management ai-coding orchestration workflow
Пробуем паттерн Software Factory: эксперимент Уилла Ларсона в Imprint

Одна из самых интересных проблем AI-экосистемы в 2026 году состоит в том, что новые эффективные паттерны работы появляются быстрее, чем их успеваешь внедрять. Только найдёшь несколько стоящих подходов, вернёшься к текущим задачам — и через месяц обнаружишь, что пропустил ещё четыре-пять. Именно об этом размышляет Уилл Ларсон (Will Larson), CTO компании Imprint и автор известных книг по инженерному менеджменту, в свежей заметке про паттерн «программная фабрика» (software factory).

Эта статья — отчёт о практическом эксперименте: как зрелая продуктовая компания шаг за шагом дошла от «посадим всех инженеров на Claude Code» до агента, который сам ведёт проект по кругу: от аудита целей до pull request и пост-релизного мониторинга.

Год эволюции: пять волн внедрения

Ларсон начинает с краткой истории того, как в Imprint менялся подход к работе с AI-агентами. Ценность этой хронологии не в конкретных названиях инструментов, а в том, как быстро узкие места смещаются с одного уровня на другой:

  1. Январь. Посадить каждого инженера на Claude Code, чтобы тот использовался каждый день.
  2. Март. Подключить к ежедневной работе с Claude Code или Claude Cowork и всех остальных сотрудников, не только инженеров.
  3. Апрель. Обнаружилось, что локальная разработка упирается в модель checkout и worktree. Решение: создать около десяти локальных рабочих пространств (workspaces), в каждом из которых — независимый checkout всех репозиториев. Оперировать теперь нужно на уровне workspace, а не отдельного репозитория: только так агент способен генерировать кросс-репозиториевые pull request'ы, затрагивающие сразу frontend-, backend-, infrastructure- и data-монорепозитории.
  4. Июнь. Выяснилось, что агентная разработка жёстко ограничена отсутствием общей системы управления задачами — с большей прозрачностью и меньшей сложностью прав, чем Jira. Компания целиком мигрировала на Linear и жёстко остановила использование Jira.
  5. Июль. Прозрачность по тикетам появилась, но многие из них оказались тривиальными, а управление ими через локальную разработку перестало масштабироваться. Ответ — оркестрированный харнесс, внутри получивший имя Agent Fleet, по образцу Stripe'овских Minions (one-shot end-to-end кодинг-агентов).

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

Что такое паттерн software factory

Термин software factory в AI-контексте attribution--wise запутан — Ларсон честно признаёт, что после небольшого исследования склонен приписывать его Джастину Маккарти (Justin McCarthy) и его февральской работе 2026 года Software Factories And The Agentic Moment.

Суть паттерна проста, если отделить её от маркетинговой оболочки:

  • Классический режим работы с агентом: вы даёте задачу, агент её выполняет, вы проверяете результат, даёте следующую задачу. Цикл замыкается на человеке.
  • Паттерн software factory: вы задаёте широкую цель (broad goal), а дальше харнесс сам циклически двигается к этой цели — аудит, планирование, выполнение, измерение, снова аудит.

Человек определяет, что считается успехом и как он измеряется; агент организует всю исполнительную петлю вокруг этого определения.

Первый вариант: скилл /linear-project-loop

Реализация в Imprint пока довольно базовая. Это агентский скилл /linear-project-loop, который работает так:

  1. Аудит определения цели. Скилл читает Linear-проект и проверяет, что определение цели проекта состоятельно по двум измерениям:

    • в Notion существует RFC, описывающий цели проекта, то, как эти цели измеряются, и общий подход;
    • существует Datadog-дашборд или Snowflake-запросы, которые меряют прогресс относительно этих целей.

    Если чего-то из этого не хватает — или Linear-проекта нет вообще — скилл итерирует с вами, чтобы создать недостающие артефакты.

  2. Сверка состояния. Далее он просматривает актуальное состояние метрик и задач проекта. Если видна новая работа — добавляет задачи в проект. Если состояние задач изменилось — обновляет его.

  3. Выполнение. Скилл берётся за неблокированные задачи согласно текущему состоянию проекта. На практике это чаще всего: написать pull request, обновить существующий PR, пингануть ревьюеров, задать уточняющий вопрос.

  4. Зацикливание. Когда задача завершена, скилл смотрит на свежесть описания проекта. Если оно актуально — берёт следующую задачу. Если давно не обновлялось — перезапускает цикл с первого шага, начиная с аудита цели.

Сейчас Ларсон запускает этот цикл локально, в локальном харнессе, но работает он уже достаточно хорошо, чтобы в ближайшее время перенести это поведение в тот же оркестрированный харнесс (Agent Fleet), через который компания раздаёт разовые задачи агентам.

Что в этом по-настоящему ценно

Самое интересное в заметке — не механика скилла, а два наблюдения Ларсона о том, почему паттерн «встал» так хорошо.

Первое: фабрика вынуждает перестать прятать состояние. Этот паттерн очень близко параллелит то, как Ларсон и раньше работал локально, но при этом заставляет честно признать места, где он незаметно для себя монополизировал часть состояния о целях проекта. Он и прежде просил агентов итерировать по конкретным Linear-проектам — но у агентов не было возможности оценить, движутся ли они в правильном направлении, или не хватает ли каких-то задач. Теперь есть. Это тонкий, но важный сдвиг: делегирование исполнения без делегирования контекста цели — это полу-делегирование, которое ограничивает потолок автономии.

Второе: пост-релизный мониторинг. Фабрика оказалась крайне полезной для проверки проектов после релиза. Ларсон приводит пример: он выпустил реализацию passkeys в начале года, но месяцы проходили без того, чтобы он возвращался к вопросу «как она, вообще, идёт». Если бы adoption внезапно вырос или начали расти error rate'ы — он бы этого пропустил. А запуская фабрику в более редком, «пост-релизном» режиме, такие вещи ловятся сразу.

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

Паттерны компаундируются только вместе

Финальная мысль Ларсона, пожалуй, самая важная для тех, кто планирует повторить путь: все эти кусочки дают мультипликативный эффект ровно в той мере, в какой у вас есть остальные кусочки.

Фабричный паттерн зависит:

  • от наличия Datadog MCP и доступа к Snowflake — иначе агент не может сам мерить прогресс к цели;
  • от того, что Linear — единственный источник состояния (single source of state) для всей работы компании;
  • от оркестрированного харнесса, способного выполнять работу независимо от вашего ноутбука.

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

Именно поэтому Ларсон завершает заметку наблюдением об индустрии в целом: успевать за таким количеством миграций — инструментов, рабочих моделей, процессов, инфраструктуры — это «fascinating industry moment». Внедрение AI-агентов в 2026-м — это не разовая настройка, а непрерывная череда организационных изменений, где каждый следующий паттерн требует фундамента из предыдущих.

Выводы для команд, которые хотят попробовать

Если извлекать из эксперимента Imprint практический чек-лист, он выглядит так:

  1. Начните с определения цели, а не с агента. Прежде чем запускать автономный цикл, убедитесь, что по проекту есть: письменное описание целей и подхода (RFC), измеримые индикаторы прогресса и единое место со списком задач.
  2. Дайте агенту доступ к метрикам. MCP-интеграции с системами мониторинга и аналитики (Datadog, Snowflake) — это то, что превращает «агента-кодера» в «агента, который понимает, помогает ли его код цели».
  3. Унифицируйте систему задач. Один трекер с прозрачными правами резко упрощает агентную работу; раздробленное состояние — главный тормоз.
  4. Планируйте переход от ноутбука к харнессу. Локальный запуск — нормальный первый шаг, но настоящая отдача появляется, когда цикл исполняется независимо от вас.
  5. Не забывайте пост-релизный режим. Автономный цикл, работающий в фоновом режиме над наблюдением за метриками выпущенных фич, — дешёвый способ не упускать деградацию и неожиданный рост adoption.

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

Источник: https://lethain.com/software-factory-experiment/