Factory AI: обзор ИИ-агентов Droids, тарифы и ограничения

Что такое Factory AI?

Factory — платформа для разработки ПО. Её агенты, Droids, умеют изучать репозиторий, предлагать план, менять файлы, запускать проверки и готовить пул-реквест — набор изменений, который можно проверить перед включением в кодовую базу. Работать с ними можно через терминал, интегрированную среду разработки (IDE), десктопное приложение или веб-интерфейс Factory. Под «разработкой с опорой на агентов» здесь понимается постановка задачи через нужный результат с последующей проверкой работы, а не запрос каждой отдельной правки. Продукт объединяет модели и инструменты разработки; это не новый язык программирования и не модель, которую нужно обучать самостоятельно. Именно так его возможности описаны на странице продукта Factory.

Данные проверены 21 октября 2026 года по действующим тарифам и документации Factory. Обзор основан на документации, примерах рабочих сценариев и расчётах стоимости. Тестирование на задачах программирования и практическое испытание продукта не проводились.

Кому подойдёт Factory, а кому лучше оставить привычного агента?

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

Ближайшие альтернативы — Claude Code, агент для разработки от Anthropic; Codex, агент для программирования от OpenAI; и Cursor, редактор и платформа агентов. Сравнивать их полезнее по тому, как покупка каждого продукта изменит повседневную работу.

Это ориентиры для выбора продукта, а не рейтинг по бенчмаркам. Claude Code, Codex и Cursor уже давно не ограничиваются одним чатом или терминалом. Само по себе наличие нескольких интерфейсов не даёт Factory преимущества.

Factory AI или Claude Code: что выбрать?

Factory стоит рассмотреть, если модели Claude должны быть одним из вариантов в более широком рабочем процессе. Claude Code проще выбрать там, где для него уже подготовлены полезные инструкции, интеграции и правила ревью. Запуск модели Claude внутри Droid не превращает его в Claude Code: набор инструментов, отбор контекста и поведение при выполнении задач определяет сам агентный продукт.

Например, руководитель команды, где бэкенд-разработчики работают в JetBrains, а фронтенд-разработчики — в Cursor, может внедрить Factory для общей очереди задач по сопровождению. Это понятная причина добавить новый инструмент. Впечатляющая демонстрация другой модели сама по себе не оправдывает перевод всей команды.

Отложите внедрение Factory, если главные проблемы — расплывчатые требования, ненадёжные тесты или очередь пул-реквестов, которые никто не проверяет. Эти же проблемы ограничат и Droids. Продолжайте работать с Claude Code, Codex или Cursor, пока делаете результат задач проще для проверки. Более узкому выбору посвящено сравнение Codex и Claude Code, а весь круг альтернатив разбирается в подборке ИИ-агентов для программирования.

Далее оценим Factory по четырём критериям: качество контекста, контроль над выполнением, возможность продолжать работу в разных интерфейсах и затраты на доведение изменения до принятия.

Factory AI Droid: привычный редактор и чётко поставленная задача

Factory Droid работает внутри уже используемого редактора, поэтому небольшой пилот можно провести без переезда в новую IDE. В VS Code, Cursor и Windsurf интеграция передаёт агенту активный файл, выделенный текст, открытые файлы и диагностику — сообщения редактора об ошибках и предупреждениях. Также доступен встроенный просмотр изменений. Запустите droid во встроенном терминале, затем проверьте подключение командой /ide. Настройка описана в документации Factory по интеграциям с IDE.

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

Такое описание задаёт агенту рамки, а проверяющему — основания отклонить результат. Большой объём изменений сам по себе не доказывает, что миграция выполнена правильно.

Как Factory AI работает с планом задачи?

Spec Mode в Factory отделяет изучение задачи и планирование от реализации. Агент читает нужный контекст и предлагает план, после чего запрашивает одобрение. В CLI сочетание Shift+Tab переключает режимы Normal и Spec. Уровень автономности настраивается отдельно: он определяет, какие действия разрешены без дополнительного подтверждения. В документации режима это различие оговорено явно.

Для миграции проверки прав начните со Spec Mode. Потребуйте, чтобы план перечислял затрагиваемые файлы, допущения о совместимости и этапы проверки. Отклоните план, который предлагает менять правила доступа, но не объясняет, как сохранится существующее поведение. Одобряйте реализацию, когда эти решения станут понятны.

На практике порядок такой:

1. Попросите Droid найти точки входа в проверку прав доступа и соответствующие тесты.
2. Запросите план, который сохраняет текущее поведение и отмечает все неясные требования.
3. Проверьте план и выберите уровень автономности, соответствующий разрешённой работе.
4. Изучите изменения и результаты тестов перед созданием или принятием пул-реквеста.

Преимущество — возможность проверить замысел до того, как агент напишет много кода. Ограничение — даже убедительный план может оказаться ошибочным. Критерии приёмки должны описывать поведение системы, а не только требовать наличия тестов.

Есть и оговорка для конкретного редактора: согласно документации Factory, интеграция с JetBrains не передаёт автоматически открытые файлы, выделения и диагностику, а также не предоставляет встроенный просмотр изменений Droid. При внедрении в команде с разными редакторами это нужно учитывать: опыт работы в VS Code нельзя переносить на все IDE.

Как менять модели без перестройки рабочего процесса

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

В актуальном каталоге моделей Factory среди прочих указаны:

• Anthropic Claude Opus 5.5 и Claude Sonnet 5.5.
• OpenAI GPT-6.1 Sol и GPT-6 Astra.
• Google Gemini 3.1 Pro и xAI Grok 4.7.
• Открытые модели, включая Mistral Large 4, Kimi K3 и DeepSeek V4.1 Flash.

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

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

Для корректного сравнения задача и среда должны оставаться одинаковыми. Если одновременно менять модель, инструкции репозитория и уровень автономности, интерпретировать результат невозможно. В каталоге Factory есть разные коэффициенты расхода лимитов и настройки рассуждений, поэтому «одинаковое число запросов» не даёт надёжного сравнения потребления.

Bring your own key (BYOK) — подключение собственных учётных данных поставщика модели или совместимой конечной точки API. Factory поддерживает персональные пользовательские модели, в том числе локальные конфигурации. Однако в документации BYOK указано существенное ограничение: такие модели доступны в CLI и десктопном приложении, но не в размещённых у Factory веб- и мобильном интерфейсах.

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

Проверка результата в десктопном приложении и браузере

Десктопное приложение Factory полезно, когда результат нужно рассматривать рядом с перепиской. На странице продукта перечислены доступные для предпросмотра изменения кода, документы, презентации, электронные таблицы, PDF и работающие сайты. Комментарии можно привязывать к строкам кода или выбранным элементам. Приложение доступно для macOS и Windows. Также Factory Desktop позволяет продолжать сессии в десктопном приложении, веб- и мобильном интерфейсах и CLI.

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

При делегировании это различие существенно. Интерфейс и поведение приложения могут проверять разные люди. Требуйте и видимого изменения, и подтверждения того, что лежащая под ним логика работает. Убедительный предпросмотр не должен быть единственным критерием готовности.

Factory также предлагает подключения к GitHub, Linear, Slack, Sentry и другим инструментам. Они могут дать агенту контекст, доступ к которому разрешён, но подключение трекера не сделает расплывчатую задачу точной. У неё всё равно должны быть ответственный, границы и понятный результат.

При удалённом выполнении появляется ещё одно важное различие: интерфейс, в котором вы проверяете работу, и компьютер, который её выполняет, — не одно и то же. Управляемые Factory Droid Computers — постоянные среды, где между сессиями сохраняются файлы, установленные пакеты, службы и конфигурация. Для компьютера, которым вы уже управляете сами, Factory описывает отдельный вариант — Remote Control. Оба подхода разобраны в документации Droid Computers.

Сохранение состояния удобно, когда подготовка среды обходится дорого. Но тогда за её состояние кто-то должен отвечать. Factory прямо указывает: пересборка Environment не обновляет Droid Computer, ранее созданный из снимка этой среды. Поэтому руководителю платформенной команды стоит проверить состояние машины, прежде чем считать успешный запуск воспроизводимым в другом окружении.

Автоматизация разработки с ИИ начинается с одной повторяемой задачи

Factory становится интереснее, когда Droid обрабатывает определённую очередь задач, а разработчику не приходится вручную начинать каждый диалог. Droid Exec — режим без интерактивного интерфейса: команда выполняет задачу и возвращает результат скрипту или системе непрерывной интеграции (CI). По умолчанию разрешено только чтение; правки и более широкий набор команд требуют явной настройки автономности. В документации Exec описаны форматы вывода, рабочие каталоги и изолированные рабочие деревья Git.

Хороший первый сценарий — анализ репозитория с выводами, которые сможет проверить его сопровождающий. Установите Droid, пройдите авторизацию и запустите из каталога репозитория:

droid exec --output-format json \
  "Identify exported functions without direct test coverage. Return file paths, the evidence for each gap, and suggested test cases. Do not edit files."

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

Следующий шаг — поручить Droid согласованное, ограниченное изменение тестов в отдельной ветке или рабочем дереве, а затем запустить проверки репозитория. Проверка приёмки должна существовать отдельно от отчёта самого агента. Готовность определяют результат CI и решение проверяющего.

В автоматизации легко упустить тонкое ограничение: если действующая политика команды выдаёт ask, одобрение потребуется даже при уровне автономности High, а однократный неинтерактивный запуск не может запросить его у пользователя. Поэтому повышение автономности не обязательно разблокирует автоматическую задачу. Factory описывает команду droid rules check, позволяющую заранее проверить решения политики. Это вопрос настройки, который нужно решить осознанно, а не повод отключать все проверки разрешений.

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

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

Тарифы Factory AI: сколько стоит нужный вам рабочий процесс

Factory Teams — понятный выбор для небольшой команды, которой нужна централизованная оплата. Business стоит обсуждать, если требуются общий объём использования по договору, управление идентификацией или административные политики. Переход с индивидуального тарифа на Teams сам по себе не даёт этих возможностей.

Ниже — ежемесячные условия с действующей страницы тарифов Factory, проверенные 21 октября 2026 года:

На странице тарифов не указаны квоты в токенах. Объём использования описан только относительно Pro. Эти множители не гарантируют определённого числа задач, и надёжно пересчитать их в принятые пул-реквесты нельзя. В документации тарифов для организаций уточняется: каждый пользователь Teams получает лимиты Pro, а на Business и Enterprise общий объём использования регулируется договором.

Пять пользователей Teams обойдутся в $260 в месяц: $60 + 5 × $40. Десять — в $460. Если предположить, что команда из пяти пользователей за месяц приняла 20 пул-реквестов Droid, на подписку пришлось бы $13 за принятый пул-реквест. Это арифметика, а не прогноз производительности. Перед сравнением полной стоимости нужно добавить расходы на дополнительное использование, вычислительные ресурсы и время проверяющих.

Частая проблема — тариф не покрывает требования рабочего процесса. Pro не даёт средств корпоративного управления, перечисленных у Business. Для Teams не заявлен объём использования Plus на каждого пользователя. Кроме того, в документации индивидуальных тарифов управляемые Droid Computers указаны в Pro, а на коммерческой странице тарифов они появляются в Plus. При планировании бюджета опирайтесь на страницу тарифов и подтвердите фактическое право доступа, прежде чем рассчитывать на управляемые вычислительные ресурсы.

Какие ограничения могут помешать внедрению

Самые существенные ограничения Factory связаны с различиями между интерфейсами и тарифами. Они способны остановить внедрение даже после удачной отдельной сессии программирования.

Поддержка редактора не означает одинакового набора функций. В JetBrains нет автоматической передачи файлов, выделений и диагностики, описанной для редакторов семейства VS Code. Agent Panel в Zed не восстанавливает предыдущие сессии Factory Droid. Даже если команда стандартизирует работу на Droids, ей понадобятся отдельные инструкции для каждого редактора и способ восстановления контекста. Factory описывает эти различия в документации.

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

Множители объёма использования не гарантируют производительность. Документация индивидуальных тарифов описывает независимые скользящие периоды длительностью 5 часов, 7 дней и 30 дней. Более дорогая подписка не превращает эти ограничения в опубликованную квоту токенов или гарантию завершения задачи. Если срок сдачи работы клиенту зависит от выполнения без участия человека, обсуждайте гарантированный договором объём ресурсов, а не экстраполируйте результаты короткого пилота. В правилах индивидуального использования Factory также сказано, что Missions приостанавливаются при достижении лимита.

Доступность управляемых вычислительных ресурсов нужно подтвердить. Расхождение между Pro и Plus существенно для основателя, который рассчитывает запускать задачи вне своего ноутбука. Таблица тарифов в этом обзоре основана на действующей странице цен; противоречащая ей документация не доказывает наличие бесплатного расширения возможностей. Условия предоставления вычислительных ресурсов тоже проверяйте отдельно от использования моделей: формулировка «облачные агенты» не означает, что вся нужная инфраструктура включена.

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

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

Обзор Factory AI: по какому критерию принимать решение

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

Добавьте его рядом с нынешним агентом, если у вас пока нет подходящего решения для общей очереди задач по сопровождению, работы в разных редакторах или осмысленного сравнения моделей. Заменяйте привычный инструмент для этого класса задач только после того, как сопоставимая работа покажет сокращение усилий на ревью или полной стоимости без ослабления приёмочных проверок. Откажитесь от внедрения, если Factory дублирует процесс, с которым Claude Code, Codex или Cursor уже хорошо справляется.

На ближайший понедельник запланируйте небольшую оценку с руководителем, отвечающим за результат:

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

Частые вопросы

Получите AI Business Workflow Audit Checklist через рассылку, чтобы определить задачу, разрешения, ответственного за ревью и эксплуатационные расходы до расширения внедрения агентов.