Эксперимент 10×

У меня есть признание, слегка неудобное для инженера, который завёл блог об AI: я не вполне доверяю AI-агентам.

Я видел, как они пропускают очевидное, уверенно решают соседнюю задачу и пишут код, который выглядит прилично ровно до тех пор, пока кто-нибудь не спросит, что случится во вторник, когда база данных тормозит, а пользователь дважды нажал Back. Поэтому, когда агент заканчивает работу, мой первый порыв — открыть diff и проверить, чего этот маленький засранец там натворил.

Не лучшая основа для делегирования.

Но зато честная. И она привела команду к вопросу поинтереснее, чем «какая модель лучше?». Мы решили поставить эксперимент: можем ли мы настолько перестроить инженерную работу вокруг AI, чтобы ускорить delivery не на оптимистичные двадцать процентов, а в несколько раз — возможно, когда-нибудь в десять — и при этом не превратить ускорение в баги, переделки и операционный геморрой?

Иными словами: можно ли ускорить всю систему, а не только набор текста?

Десять агентов — не инженер 10×

Соблазн понятен. Открой десять потоков. Дай каждому задачу. Выгляди до ужаса футуристично, пока ноутбук звучит так, будто готовится к взлёту.

Это работает — до определённого предела. Один из нас уже гоняет около десяти агентов параллельно и сжигает недельный лимит за день. Другой заменил Instagram Reels наблюдением за работой агентов — то ли профессиональное развитие, то ли просто более дорогая зависимость. Результат реален: сделать в три-четыре раза больше примерно теми же личными усилиями — не фантазия.

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

AI не убирает узкое место. Он показывает, где оно было на самом деле.

Иногда это код. Гораздо чаще — отсутствующий контекст, нерешённый продуктовый вопрос, внешняя система, которую нельзя протестировать, или архитектура, которую никто толком не продумал. Когда реализация становится дешёвой, неопределённость становится дорогой.

Работа сдвигается влево

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

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

Вот здесь «AI-native engineering» перестаёт звучать как вебинар вендора и становится неприятно реальным. Навык теперь не в том, чтобы произвести код по тикету, а в том, чтобы построить контекст, в котором неправильный код написать трудно.

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

Сделать мир тестируемым

Возражение возникло сразу: что делать с процессами, которые агент физически не может пройти? Проверка личности, подписи, сторонние виджеты, селфи и все места, где софт просит человека посмотреть в камеру и доказать, что он не три енота в плаще.

Ответ — не отказываться от end-to-end тестов, а построить мир, которым агент способен управлять: реалистичные моки внешних границ с тем же API-контрактом и представительным UI. Сами границы тщательно сверять с реальностью, а агентам позволить гонять десятки внутренних сценариев, не заставляя человека повторять один ритуал десять раз в день.

Это не будет метафизически идеальный E2E-тест. Но большую часть уверенности можно получить за малую часть постоянной стоимости. Остаток закрывается меньшим числом реальных happy-path проверок. Инженерия всегда была искусством покупать правильный уровень уверенности, а не всю возможную уверенность.

Качеству нужна собственная машина

Больше кода означает больше возможностей для дефектов. Делать вид, что это не так, — лучший способ превратить эксперимент по производительности в очень эффективную фабрику багов.

Наша рабочая модель состоит из трёх циклов:

1. Хорошо решить. Люди и агенты создают и критикуют спецификацию до начала реализации.
2. Автоматически доставить. Агенты реализуют, тестируют, ревьюят и готовят изменение по явному процессу.
3. Непрерывно чинить. Другие агенты ищут регрессии, сравнивают ожидаемое с фактическим и отправляют воспроизводимые ошибки в параллельные циклы исправления.

Третий цикл важен, потому что баги необычно удобны для агентов: есть ожидаемый результат, фактический результат и разница между ними. Это намного легче делегировать, чем «придумай правильный продукт». Цель не в том, чтобы объявить ноль дефектов, а в том, чтобы система находила и устраняла их быстрее, чем растущий output создаёт новые.

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

Человеческая работа не исчезает

Во время обсуждения я задал неудобный вопрос: если агенты пишут код и ревьюят код, то мы тут вообще зачем?

Мой ответ такой: решать, что достойно существования; выбирать компромиссы там, где нет заранее правильного ответа; и отвечать за результат.

Агент способен отразить ваши рассуждения с огромной широтой. Но он не всегда понимает, что задача с ярлыком «архитектура» на самом деле является неразрешённым бизнес-правилом. Другой человек иногда понимает — особенно когда задаёт раздражающий вопрос, который перестраивает всю картину. Команды будут меньше спорить об именах и больше — о поведении продукта, границах системы, риске и деньгах. Честно говоря, это похоже на улучшение.

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

Наш эксперимент — без bullshit

Первую фазу мы намеренно делаем достаточно маленькой, чтобы её можно было наблюдать:

• Вести несколько независимых потоков параллельно, а не бесконечно полировать один разговор с агентом.
• Требовать согласованную спецификацию с явными решениями по данным, безопасности, архитектуре и проверке.
• Делать заблокированные внешние процессы тестируемыми через контролируемые моки.
• Использовать несколько раундов независимого агентного ревью, но останавливаться, когда поздние раунды дают в основном шум.
• Оставлять человеческое ревью там, где последствия требуют человеческого суждения.
• Раз в неделю пересматривать процесс и улучшать harness, а не только промпты.

Измерять будем результаты, а не произведённые артефакты: время от идеи до проверенного поведения, завершённые бизнес-возможности, дефекты в production, переделки, человеческое внимание на изменение и операционную нагрузку. Строки кода проигнорируем с тем уважением, которого они заслуживают.

Десять раз — не обещание, а верхняя граница гипотезы. Даже три раза при том же или лучшем качестве уже изменят всё. Десять раз больше pull request'ов и десять раз больше уборки — лишь новый способ работать по выходным.

На что мы действительно ставим

Ставка не в том, что модели станут идеальными. Не станут. Люди тоже не идеальны, хотя мы построили впечатляющее количество встреч, чтобы скрыть этот факт.

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

Пока правило эксперимента предельно простое:

Если я делаю что-то вручную, я обязан спросить, какой возможности не хватает системе.

Автоматизировать нужно не всё. Но «я всегда делал именно так» больше не достаточная причина продолжать.

Это эксперимент 001. Я напишу, что будет дальше, — включая провалы, потому что заявление про 10× без рассказа об обломках есть маркетинг с чуть лучшей типографикой.