AI-разработка в феврале 2026: от агента к среде

Семь релизов, одна траектория

Февраль 2026 года дал редкий набор релизов, которые удобно рассматривать вместе. OpenAI выпустила Codex App и GPT‑5.3‑Codex. Anthropic представила Claude Opus 4.6 и Sonnet 4.6. Cursor показал Long-running Agents, упаковал Rules, Skills, Subagents, MCP и Hooks в Plugins, а затем дал Cloud Agents доступ к Computer Use.

По отдельности это записи в changelog разных продуктов. В одной временной линии виден архитектурный сдвиг: coding agent перестаёт быть функцией редактора и становится средой, в которой можно поставить задачу, выбрать исполнителя, дать ему инструменты, дождаться результата и получить доказательства проверки.

2 февраля   Codex App        → workspace
5 февраля   новые модели     → task-level work
12 февраля  Long-running     → long horizon
17 февраля  Sonnet + Plugins → routing + agent stack
24 февраля  Computer Use     → verification

Для меня это главный итог месяца. Индустрия соревновалась уже не за лучший autocomplete. Компании собирали недостающие части автономного engineering loop.

Единица делегирования выросла до задачи

Autocomplete получал несколько символов контекста и предлагал продолжение. Чат работал с методом, тестом или SQL-запросом. Coding agent получает цель: «добавь аудит изменения пользователя» или «найди причину 401 после refresh token».

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

«Напиши AuditService»
        ↓
реализация готового решения

«Добавь аудит пользователей»
        ↓
исследование → решение → код → проверка

Релиз GPT‑5.3‑Codex хорошо зафиксировал эту границу. OpenAI описала модель как рассчитанную на long-running задачи с research, tool use и complex execution. Требование к модели изменилось: держать цель через серию действий стало ценнее, чем безупречно дописать один класс.

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

Пока агент помогает в текущем файле, ему достаточно панели в IDE. Когда четыре независимых агента занимаются bugfix, feature, тестами и review, разработчику нужен другой интерфейс: список задач, отдельные контексты, worktrees, статусы и очередь результатов.

Именно поэтому Codex App интересен как «command center», а не как ещё один клиент для чата. Он делает видимой новую единицу управления — agent thread. Человек переключается между работами, а не переносит один разговор из файла в файл.

                 Developer
                     │
          ┌──────────┼──────────┐
          ▼          ▼          ▼
       BUG-142    FEATURE-38  REVIEW-12
          │          │          │
       Agent A    Agent B    Agent C

Это и есть простейшая orchestration. Сложная цепочка Planner → Implementer → Reviewer необязательна. Достаточно уметь разделить backlog на независимые задачи, не столкнуть агентов в одни файлы и вовремя проверить их выводы.

Название модели больше не описывает агента

Одновременный выход GPT‑5.3‑Codex и Claude Opus 4.6 сделал старое сравнение «Claude против GPT» слишком грубым. В реальном проекте разработчик взаимодействует с Codex, Claude Code или Cursor, а не с изолированной LLM.

Model
+ Tools
+ Context
+ Instructions
+ Sandbox
+ Execution loop
+ Permissions
= Coding Agent

Модель может правильно решить, что нужно воспроизвести failing test. Harness определяет, есть ли shell, видит ли агент repository, умеет ли прочитать stack trace и повторить цикл после исправления. Сильная модель с бедным поиском и без test loop легко проиграет менее дорогой модели в хорошо собранной среде.

Поэтому практический benchmark coding agents должен измерять весь путь: исследование, размер diff, лишние изменения, самостоятельное исправление failures и качество отчёта. Красивый PHP-класс — слишком маленький критерий.

Длинный горизонт потребовал Task Engineering

Long-running Agents добавили к автономности время. Cursor приводит примеры работ на 25, 30 и 36 часов и отдельно описывает planning-first harness: агент предлагает план, ждёт согласования, а во время исполнения несколько агентов сверяют работу с ним.

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

Обычного «сделай X» становится мало. Нужна mini-spec:

Goal — какое поведение требуется получить;
Scope — какие компоненты разрешено менять;
Constraints — что должно остаться совместимым;
Definition of Done — чем доказать завершение;
Stop Conditions — когда вернуть BLOCKED вместо догадок.

Я бы называл это Task Engineering. Проектируется уже не формулировка промпта, а безопасная траектория работы виртуального исполнителя.

Модель стала маршрутизируемым ресурсом

Sonnet 4.6 добавила к выбору экономический аргумент. Anthropic оставила цену на уровне $3 за миллион входных и $15 за миллион выходных токенов и приблизила Sonnet к задачам, для которых раньше чаще выбирали Opus. При этом сама компания сохранила Opus 4.6 как вариант для глубокого codebase refactoring, multi-agent coordination и работ с высокой ценой ошибки.

Отсюда возникает model routing. CRUD, DTO и обычные tests можно начинать на быстрой модели. Неясный legacy bug — эскалировать после первой диагностики. Архитектуру или security-sensitive изменение отдать сильной модели сразу либо использовать её для независимого review.

Task
  ↓
complexity + uncertainty + risk + cost + latency
  ↓
model for this stage

Особенно рациональна схема Opus → Sonnet → Opus: сильная модель исследует и утверждает архитектуру, более доступная реализует ясный план, сильная независимо проверяет результат. Покупать максимум reasoning для каждого чтения файла нет смысла.

Вокруг агента сформировался development stack

Cursor Plugins собрали в один пакет пять разных механизмов. Rules задают постоянную policy. Skills хранят повторяемую процедуру. Subagents получают отдельную ответственность. MCP подключает внешние системы. Hooks механически запускают обязательные действия.

Это уже похоже на developer tooling. Команда версионирует рядом с кодом архитектурные ограничения, процедуру создания миграции, reviewer для API-контракта и проверку PHPStan перед завершением. Prompt становится короче, потому что повторяющееся знание переехало в environment.

Computer Use замкнул feedback loop

Релиз Cursor от 24 февраля закрыл слабое место автономной реализации. Cursor Cloud Agents с Computer Use получили возможность запустить приложение в изолированной VM, пройти интерфейс мышью и клавиатурой, а затем приложить к PR screenshots, video и logs.

До этого агент чаще доказывал корректность через кодовые проверки. PHPUnit и PHPStan могут быть зелёными, пока кнопка в Filament не сохраняет форму или Stimulus controller падает в browser console. Теперь feedback loop охватывает наблюдаемое поведение продукта.

IMPLEMENT
   ↓
TEST
   ↓
RUN → OBSERVE → FIX
   ↑             ↓
   └──── VERIFY ─┘

Сдвиг здесь от output к outcome. Агент возвращает не утверждение «feature implemented», а evidence: тесты прошли, пользовательский flow выполнен, console чиста, ограничения перечислены. Human review по-прежнему нужен, но начинается с доказательств, а не с проверки обещания.

Как этот stack выглядит в PHP-проекте

Для Laravel 13 и Filament 5 мне не нужна футуристическая система из двенадцати агентов. Достаточно связать уже знакомые инструменты в один управляемый процесс.

Issue
  ↓
Research → Plan → Human approval
  ↓
Laravel implementation
  ↓
PHPUnit + Pint + PHPStan
  ↓
Filament browser flow + logs
  ↓
Diff review → Human decision

Project Rules фиксируют структуру Filament Resource и запрет business logic в controller. Skill описывает создание миграции. Hook запускает tests. Отдельный reviewer проверяет mass assignment, N+1 и escaping. Browser verification проходит acceptance criteria. Внешний issue tracker подключается только на чтение, пока агенту не требуется менять статус задачи.

Такой pipeline уже снимает механическую работу и сохраняет понятные границы ответственности. Multi-agent orchestration стоит добавлять позже — когда независимых задач действительно больше, чем человек успевает вести последовательно.

Разработчик перемещается к границам системы

Автономность не превращает инженера в автора билетов. Она переносит его внимание с каждой строки на решения, которые дороже исправлять: постановку проблемы, границы bounded context, совместимость API, риск миграции и достаточность evidence.

Для проверки плана нужно понимать архитектуру. Для Definition of Done — продукт. Для permission policy — безопасность. Для оценки тестов — реальные failure modes. Ручного набора кода может стать меньше, но инженерная компетенция никуда не девается.

К привычным навыкам добавляются новые:

декомпозиция задач без конфликтующих изменений;
context engineering и отбор проектных знаний;
model routing по неопределённости и риску;
verification design и evidence для acceptance criteria;
permission design для автономных действий.

Это не менеджмент вместо разработки. Это разработка на другом уровне управления.

Начинать стоит с минимального замкнутого процесса

Февральские релизы легко провоцируют собрать всё сразу. Я бы начал значительно проще:

Добавить короткие Project Rules с проверяемыми ограничениями.
Разделить research, plan и implementation для задач дороже часа.
Вынести одну повторяемую процедуру в Skill.
Автоматизировать обязательные PHPUnit, Pint и PHPStan.
Для UI-задач требовать browser flow и screenshot.
Подключить независимый review только для рискованных изменений.

Уже этот набор превращает «prompt → code» в управляемый цикл. Orchestrator, десятки subagents и автоматический model router понадобятся лишь после появления реальной нагрузки, а не ради красивой схемы.

Следующий вопрос — граница доверия

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

read repository     auto
edit isolated branch auto
run tests           auto
create migration    policy
merge               human gate
production deploy   explicit authority

Чем ближе действие к необратимому изменению, данным пользователей и production, тем сильнее должен быть контроль. Скриншот работающей формы не доказывает корректность permission model. Зелёный test suite не даёт права на автоматический deploy.

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

Февраль собрал автономную среду по частям

Codex App дал агентам workspace. Новые модели увеличили масштаб и длину задачи. Long-running harness потребовал Task Engineering. Sonnet 4.6 сделал model routing практичным. Plugins оформили agent stack. Computer Use добавил наблюдение за продуктом и evidence.

Вместе это уже не «AI внутри IDE». Перед нами отдельный слой разработки, у которого есть исполнители, контекст, инструменты, разрешения, автоматические проверки и собственный feedback loop.

Главная развилка теперь проходит между implemented и trusted. Агент всё чаще способен дойти до первого состояния сам. Задача разработчика — спроектировать путь ко второму: задать границы, потребовать доказательства и оставить человеческий контроль там, где цена ошибки выше скорости.

От coding agent к автономной среде разработки: что показали релизы февраля 2026Как workspace, long-running harness, model routing, Plugins и Computer Use складываются в новый engineering workflow.