Агент-ориентированная разработка

Как перестроить инженерную организацию вокруг AI-агентов как основных исполнителей, а не вокруг инженеров — и почему это отличает 1x-разработчиков от 100x-разработчиков.

Это AI-перевод статьи, сделанный каналом Про AI: Лучшие Статьи и Исследования.

Агент-ориентированная разработка

Agent-Native Engineering Автор: Andrew Pignanelli Оригинальный текст:

На передовой появился новый способ создания софта. В модных стартапах Сан-Франциско, за четырьмя уровнями безопасности в лабораториях, или у парня с ноутбуком в кафе Вильямсбурга с кофе по 9 долларов за чашку.

Это называется agent-native engineering (агент-ориентированная разработка), и именно это на самом деле отличает 1x-инженеров от 100x-инженеров. Вы видите людей, которые хвастаются двенадцатью терминалами Claude Code, запущенными одновременно, но возможно ли это на практике? Как это вообще работает? Что такое agent-native engineering?

Проще говоря, agent-native engineering означает реструктуризацию организации, где агенты выступают индивидуальными контрибьюторами вместо инженеров. Давайте разберёмся, что это значит на практике.

Фоновые агенты изменили всё

Сдвиг начался с Devin от Cognition AI. Летом 2024 года это был первый асинхронный coding-агент (агент для написания кода). Это означало, что вы могли назначить ему задачу, уйти и вернуться к новому коду, закоммиченному в вашу кодовую базу в виде PR. Агент, который мог работать в фоновом режиме без прямого управления.

Лето 2024 было ранним этапом для агентов — Devin был отстойным. Но модели улучшились, и Devin тоже. Практически каждый знакомый мне стартап использовал Devin в 2025 году. Однако я понял, что сам Devin на самом деле не очень хороший coding-агент. Мы использовали его внутри General Intelligence и отказались от него в октябре.

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

Это значительно сокращает простои и позволяет достичь более высокого уровня полировки на выходе. Можно итерировать быстрее, выпуская V1 чего-либо синхронно, а затем делегируя мелкие баг-фиксы и доработки асинхронному агенту.

Как на самом деле работают фоновые агенты?

Фоновым агентам нужно несколько вещей:

• Песочница, где они могут писать и запускать код
• Доступ к GitHub для пуша кода через PR
• Сам coding-агент, размещённый где-то для асинхронной работы
• Возможность итерировать на основе обратной связи — через комментарии в GitHub или через Slack/чат

Devin был первым, кто объединил всё это, но сейчас появилось множество аналогов: Tembo, Factory, Cursor Cloud Agents и Claude Code в песочнице. И теперь Linear интегрируется со всеми ними — пользователи могут запускать их прямо из тикетов Linear. Сформировался довольно сложный, но высокоэффективный рабочий процесс для фоновых агентов.

Рабочий процесс с фоновыми агентами:

• У кого-то появляется идея новой фичи с достаточно узким скоупом
• Создаётся тикет в Linear
• Тикет назначается человеку и coding-агенту, потому что кто-то всё равно должен отвечать за тикет
• Coding-агент работает над тикетом в фоне и в итоге создаёт pull request
• Coding-агент итерирует по CI/тестам, пока они не пройдут, и проверяет конфликты слияния
• Назначенный инженер ревьюит код, иногда запуская ветку локально
• [опционально] Назначенный инженер оставляет комментарии к PR или тикету Linear
• Coding-агент автоматически отрабатывает обратную связь и делает новые коммиты
• Инженер апрувит и мержит код

Это освобождает инженеру время на другие вещи, подобно тому, как PM назначает работу. Работу всё ещё нужно ревьюить, но нагрузка синхронной работы снимается.

Дать инженерам coding-агентов — это ещё не agent-native engineering

Agent-native engineering — это система управления командой вокруг этого рабочего процесса синхронной+асинхронной работы. Она влияет на то, как работает команда. Вы можете называть свой отдел agent-native только если он построен вокруг агентов, а не людей.

Как это сделать?

Нужно начать думать о задачах на трёх уровнях в зависимости от того, как над ними могут работать агенты:

• Простые (aka one-shottable): Хорошо написанный промпт для задачи будет закодирован агентом и легко смержен. Обычно для мелочей вроде «изменить радиус скругления этой кнопки»
• Легко управляемые: Фоновый агент с несколькими циклами обратной связи может решить задачу и смержить код
• Сложные: Задача, которой напрямую управляет инженер, используя синхронные coding-агенты. Полный флоу, интенсивный дизайн или что-то подобное

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

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

Даже самые сложные задачи просто разрываются этими моделями. Всё кардинально изменилось по сравнению с полугодом назад.

При этом ваши менеджеры становятся staff-инженерами, а ваши инженеры становятся техлидами. И со временем процент простых и управляемых задач растёт, а процент сложных задач падает.

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

Агентность растёт (каламбур)

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

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

Вы должны отменить требование ревью двумя инженерами

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

Если вы управляете инженерной организацией, одна из ваших задач — оптимизировать этот процесс. Несколько идей: используйте агентные пентестинговые компании, добавьте агентов для code review вроде Cursor Bugbot или Greptile, добавьте AI SRE в ваше staging-окружение. Но делайте всё возможное, чтобы убрать требование ревью двумя инженерами.

«но безопасность» «но code review» — вы мыслите по-старому. В этом новом мире вы будете жить и умирать по количеству итераций, которые можете завершить за определённое время. Вам нужно реструктурировать инженерную организацию так, чтобы влияние каждого нового релиза модели ощущалось. Иначе такие люди, как я, будут отгружать больше вас.

Подумайте с точки зрения инженера. Инженер, который может выкатывать десятки PR в день и дрифтовать на 12 инстансах Claude Code, будет строить и итерировать продукт очень быстро, и если вы помешаете ему это делать, он уйдёт туда, где не будут.

А как насчёт слопа в коде?

Code slop (слоп, мусорный код) — вполне реальная проблема, но её можно предотвратить с помощью надёжных правил и тестов. Можно создать файлы claude.md или .cursorrules (или любой другой стандарт) для обеспечения стиля и качества. Эффективное управление agent-native организацией означает работу над вашими наборами правил. Внутри компании у нас разные правила для фронтенд-кодовой базы, бэкенда, общей архитектуры, гайдлайнов по стилю кода и гайдлайнов по стилю компонентов.

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

Тесты тоже крайне важны. Вашим агентам нужен reward signal (сигнал вознаграждения) — что-то, что говорит им, сработало ли то, что они сделали, или нет. Тесты — это этот сигнал. Если правильные тесты реализованы и их прохождение требуется перед мержем, агент будет итерировать, пока тесты не пройдут.

Мы также используем линтеры вроде ESLint и форматтеры вроде Python Black. Это обеспечивает консистентный стиль и значительно улучшает слоп на низком уровне.

Комбинация умных правил с надёжным набором тестов и линтеров значительно сокращает code slop. И с улучшением моделей каждые несколько месяцев code slop будет дополнительно сокращаться сам по себе с каждой итерацией.

Наконец, боты для code review стали очень хорошими. Мы используем Cursor Bugbot. Он ловит баги с очень высоким показателем и способствует лучшему качеству кодовой базы в целом.

Как agent-native engineering влияет на организацию

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

В результате время на управление системой тикетов становится большей частью рабочего процесса. Ревью кода становится гораздо большей частью рабочего процесса. Люди тратят время на размышления о том, что делать, а не как это делать. По сути, все становятся PM и тимлидами для проекта, над которым работают.

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

Тесные циклы коллаборации становятся очень важными, и вы живёте и умираете по количеству действий в минуту. Поэтому я предпочитаю политику работы в офисе каждый день — это снижает трение для идей и увеличивает скорость генерации новых идей.

Говоря о генерации идей — это новая проблема. До 2026 года инженеры тратили время, используя свой высокий интеллект для решения относительно узких, хорошо определённых проблем. Теперь большинство этих проблем — простые или управляемые фоновыми агентами. Новая работа ваших инженеров — находить больше проблем для решения. Поэтому многие говорят, что это золотой век человека с идеями — так и есть. Если вы можете узко определить проблему и передать её инженеру, вы с тем же успехом можете передать её фоновому агенту.

Вам, вероятно, нужно больше дизайнеров и продуктовых людей

Поскольку все тратят больше времени на идеи, эти идеи должны быть переведены в удобный (и красивый) продукт. Инженеры справляются с этим нормально. Они могут создать лучшую производительную систему, и в их понимании она будет функциональной. Ваши пользователи могут не согласиться. Часто она будет функциональной, но будет ощущаться неуклюжей и выглядеть отстойно. Это не вина инженера — он, вероятно, год назад решал задачи с LeetCode, чтобы получить работу по написанию юнит-тестов в Google (и был в этом действительно хорош).

Правда в том, что инженерам, выкатывающим PR, нужна поддержка дизайна от PM или дизайнеров. В идеале — от обоих. И у большинства организаций эта функция налажена неплохо, с хорошим соотношением дизайнеров к инженерам. И инжиниринг обычно отстаёт от дизайна, поскольку сложность разработки продукта гораздо выше, чем его проектирования. Это всё ещё верно, но с agent-native соотношение меняется. Если ваше соотношение было 1:20, как довольно типично для таких организаций, теперь оно слишком низкое. Вам нужно больше людей, которые могут рассуждать об опыте, продукте и дизайне, чем раньше, потому что новые фичи будут материализовываться со скоростью мысли.

Это то, что мы узнали в General Intelligence. Мы значительно ускорили инжиниринг в декабре, а в январе сильно отстали по дизайну/UX из-за этого.

Не бойтесь расхода токенов ваших инженеров

Мы не ограничиваем расход токенов наших инженеров. Нет — я имею в виду буквально не ограничиваем. Вообще. В январе 2026 года мы тратили в среднем 4000 долларов на инженера в месяц на токены Opus. Это огромная сумма денег на токены.

Почему? При 4 тысячах это солидный процент от общей зарплаты инженера. Это немного безумно. Да. Однако в январе 2026 года наши инженеры также отгружали в среднем 20 PR в день, иногда сотни коммитов ежедневно. Мы тратим примерно на 20% больше на инженерный интеллект, чтобы увеличить выход в 3-4 раза. Это невероятный компромисс. Я оцениваю, что наш расход токенов как процент от инженерного бюджета продолжит расти в течение года, пока мы не достигнем некого плато, связанного с тем, как быстро мы можем превратить расходы в выручку, но нет причин не превысить 100%.

Будущее agent-native engineering

Подведём итог, текущее состояние дел таково:

• Синхронные агенты для сложной работы
• Делегирование асинхронным агентам для управляемых и простых задач
• Боты для code review и системы управления задачами

Что изменится: IDE в привычном виде уйдут. Code review людьми уйдёт. К концу 2026 года люди будут ревьюить только изменения в продуктах и крупной инфраструктуре — по сути превращая всех инженеров в продакт-менеджеров и всех продакт-менеджеров в инженеров.

Будущее выглядит так:

• Высокоспособные фоновые агенты как команды, с делегированием в первую очередь
• Продвинутые UI режима планирования, похожие на PRD прошлого, для сложных наборов фич
• Красивый (не художественный) фронтенд-код в основном автоматизирован, включая анимацию, создавая функциональный красивый UI за несколько нажатий клавиш
• Вся инфраструктура становится кодом, и всё, что не infra-as-code, начинает уходить
• Команды становятся меньше и способнее
• Дизайнеры или те, кто умеет проектировать, становятся важнее, а инженеры, которые не являются продуктовыми мыслителями, становятся менее важными

Каждая организация должна стать agent-native, или она перестанет существовать. К счастью, это означает более эффективные и продуктивные компании. Если это вас пугает, вы не в том месте для будущего.

Подпишитесь на канал и каждый день читайте лучшие материалы про AI переведенные на русский!

Нашли интересную статью для перевода? Пришлите нашему боту: @ailongreadsbot