От вайб-кодинга к агентной инженерии: как меняется роль разработчика в 2026 году

4 февраля 2026 года Андрей Карпатый — сооснователь OpenAI и автор термина «вайб-кодинг» — написал в X пост к годовщине своего прошлогоднего твита. Среди прочего он предложил новый термин для того, как выглядит работа разработчика сегодня.

Agentic — потому что теперь по умолчанию ты 99% времени не пишешь код напрямую. Ты оркестрируешь агентов, которые пишут его, а сам осуществляешь контроль. Engineering — чтобы подчеркнуть, что в этом есть и искусство, и наука, и профессиональная экспертиза. Этому можно учиться и со временем становиться лучше — у этой практики своя, особая глубина.

Андрей Карпатый, сооснователь OpenAI

Сам Карпатый позже назвал этот твит «спонтанной мыслью в душе, которую просто выложил» — но формулировка зацепила индустрию: 580 тысяч просмотров, 10 тысяч лайков, сотни цитирований за сутки. Термин стал общепринятым не потому, что его кто-то навязал, а потому что точно описал то, что уже происходило.

Именно вокруг этой идеи мы построили концепцию хакатона Dev-to-Dev: Agentic Engineering Challenge.

Почему не вайб-кодинг

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

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

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

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

Агенты на каждом этапе: что уже работает

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

Анализ и исследование

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

Anthropic встроила этот подход в исследовательский модуль Claude. Ведущий агент координирует процесс и делегирует подзадачи специализированным субагентам, которые работают параллельно: один анализирует документацию, другой ищет аналоги в open-source, третий проверяет баг-трекер. Результат — структурированный отчёт с контекстом, а не набор ссылок.

Что делают агенты:

• Анализируют существующий код, документацию и историю задач.
• Исследуют аналогичные решения, сравнивают подходы.
• Формируют отчёт о технических рисках, зависимостях и ограничениях.
• Собирают требования из разрозненных источников: чатов, тикетов, документов.

Проектирование и архитектура

Агенты не заменяют архитектора. Они позволяют быстрее перебрать варианты, оценить их по заданным критериям и зафиксировать обоснование решения.

Дэйв Норрис, Developer Advocate в Salesforce с 30+ сертификациями и статусом Certified Technical Architect, описал свой подход: инженер формулирует требования и ограничения, а модель генерирует варианты решений, сравнивает их по критериям (производительность, масштабируемость, стоимость поддержки) и формирует структурированный документ с обоснованием. Финальное решение остаётся за человеком — AI ускоряет исследование вариантов, но не снимает ответственности.

Что делают агенты:

• Генерируют варианты архитектуры на основе требований и ограничений.
• Проводят анализ совместимости с существующей системой.
• Создают диаграммы взаимодействия компонентов и потоков данных.
• Оценивают каждый вариант по заданным критериям.
• Формируют спецификации для передачи на этап разработки.

Разработка

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

Борис Черный, руководитель направления Claude Code в Anthropic, рассказал, что его команда создала Cowork — инструмент для автоматизации рабочих задач — примерно за полторы недели. Практически весь код написан AI-агентами. Основное время инженеров ушло на формулировку требований, архитектурные ограничения и ревью. Черный отмечает, что уже более двух месяцев не пишет код вручную, параллельно управляя 5–10 агентами.

Это впечатляющий результат, но стоит учитывать контекст: команда Anthropic работает с собственными моделями и инструментами, имеет глубокую экспертизу в промпт-инженерии, и Cowork — относительно ограниченный по скоупу продукт. Экстраполировать этот опыт на произвольный enterprise-проект напрямую нельзя.

Что делают агенты:

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

Тестирование и контроль качества

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

Команда DriveOS в NVIDIA разработала агентную платформу Hephaestus (HEPH) для автоматической генерации тестов. Система анализирует документацию и примеры кода с помощью LLM, затем генерирует тесты, компилирует, запускает и анализирует покрытие, используя результаты для уточнения следующих итераций. В пилотных проектах команды-участники сэкономили до 10 недель работы — хотя это верхняя граница для конкретных пилотов, а не средний показатель.

Что делают агенты:

• Генерируют тест-кейсы на основе спецификаций, в том числе негативные сценарии.
• Запускают тесты, анализируют результаты и предлагают исправления.
• Проводят аудит безопасности: ищут уязвимости и небезопасные паттерны.
• Профилируют производительность и выявляют узкие места.

Публикация и деплой

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

Postman, платформа для работы с API, демонстрирует подход, при котором агент встроен в релизный контур: при изменении OpenAPI-спецификации в pull request запускается автоматическая генерация тестов безопасности, результаты добавляются к PR. Postman также предоставляет MCP-сервер, через который AI-агенты могут управлять коллекциями, запускать тесты и работать с окружениями через естественный язык.

Что делают агенты:

• Формируют changelog и release notes из истории задач.
• Запускают и контролируют этапы CI/CD.
• Проводят поэтапный релиз и инициируют откат при аномалиях.
• Обновляют документацию, API-спецификации и миграционные инструкции.
• Уведомляют команду о статусе релиза.

Мониторинг и реагирование

После деплоя агенты помогают поддерживать устойчивость сервиса и быстро реагировать на инциденты.

В Microsoft Research разработана система TRIANGLE — мультиагентная платформа для триажа (классификации и маршрутизации) инцидентов. При появлении инцидента один агент анализирует описание и сопоставляет с историческими данными, затем несколько специализированных агентов обмениваются аргументами и определяют ответственную команду. Система обрабатывает ~600 млн логов в день и улучшает точность триажа более чем на 20% по сравнению с предыдущими методами.

Важно: TRIANGLE — система именно триажа, а не мониторинга. Она классифицирует и маршрутизирует инциденты, а не обнаруживает их. Для полного цикла нужны дополнительные инструменты наблюдаемости.

Что делают агенты на этом этапе:

• Классифицируют инциденты и маршрутизируют к ответственным командам.
• Сопоставляют сбои с конкретными релизами и изменениями в коде.
• Обнаруживают аномалии и признаки деградации.
• Анализируют влияние релизов на продуктовые метрики.

Техническая поддержка и обратная связь

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

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

Прецеденты: агентный подход до Карпатого

Хотя термин «агентная инженерия» появился в феврале 2026, сам подход развивался раньше. В апреле 2025 года IT_ONE совместно с SK FinTech Hub провели IT_ONE Cup. ML Challenge на платформе Codenrock. Один из треков — разработка AI-системы, которая восстанавливает структуру UI из готовых веб-приложений без исходников и вносит изменения на основе текстовых описаний.

Задача участников — восстановить структуру интерфейса из работающего веб-приложения, проанализировать HTML, CSS и JavaScript, включая минифицированные бандлы, и на основе текстового описания сгенерировать обновлённый макет с новой функциональностью. Решение требовало многоэтапной системы, где модель выполняет разные роли на разных стадиях: анализ, восстановление структуры, проектирование изменений, генерация и проверка результата. Фактически — агентный пайплайн, собранный участниками хакатона за ограниченное время.

MCP: инфраструктура для агентов

Model Context Protocol (MCP) — открытый стандарт от Anthropic, который позволяет AI-агентам подключаться к внешним инструментам, базам данных, API и сервисам через единый интерфейс. Если агенты — это операторы, то MCP-серверы — точки подключения к реальному миру.

MCP быстро стал де-факто стандартом: Microsoft встроила поддержку в Visual Studio 2026, SDK доступны на всех основных языках, а количество активных MCP-серверов в индустрии исчисляется тысячами.

Хороший пример системного внедрения — Shopify. По словам Фархана Тавара, вице-президента и руководителя инженерного департамента компании (1000+ инженеров), Shopify создала около дюжины MCP-серверов для внутренних систем: Slack, G Suite, Salesforce и других. Стратегия — «MCP everything»: сделать каждый внутренний источник данных доступным для агентов через единый протокол.

Что делает MCP-сервер хорошим:

• Решает конкретную боль — рутинную задачу, с которой разработчики сталкиваются ежедневно.
• Даёт агенту полный контекст — не голые API-методы, а семантически богатый интерфейс с описаниями, примерами и ограничениями.
• Вписывается в цепочку — может быть использован как часть агентного пайплайна, а не изолированно.
• Спроектирован как продукт — с документацией, тестами и понятным API.

Ограничения и что стоит учитывать

Агентная инженерия — мощный подход, но не серебряная пуля. Вот что стоит держать в голове:

• Галлюцинации. LLM генерируют правдоподобный, но некорректный код. Без тестов и ревью агентная система — генератор технического долга.
• Стоимость. Каждый вызов агента — это API-запрос. При масштабировании затраты растут быстро, особенно при мультиагентных пайплайнах с итерациями.
• Безопасность. Агент с доступом к продакшен-данным, деплою и внутренним API — это поверхность атаки. Принцип наименьших привилегий обязателен.
• Зависимость от моделей. Смена провайдера или деградация модели может сломать весь пайплайн. Нужны абстракции и фоллбэки.
• Потеря экспертизы. Если команда перестаёт читать и понимать код, который генерируют агенты, она теряет способность отлаживать и развивать систему.

Эти ограничения не отменяют ценности подхода — но определяют границы его применимости.

Задача хакатона: MCP-сервер для разработчиков

На Dev-to-Dev: Agentic Engineering Challenge участники создадут MCP-сервер с полезными инструментами для разработчиков. Формат Dev-to-Dev означает: вы решаете свою собственную боль — рутину, переключения между инструментами, повторяющиеся действия, которые давно просят автоматизации.

Примеры направлений:

• Инспектор зависимостей и лицензий.
• Парсер CI-логов с диагностикой ошибок.
• Поисковик TODO/FIXME и техдолга с приоритизацией.
• Генератор release notes из git-лога.
• Анализатор покрытия тестами с рекомендациями.
• Аудитор Dockerfile и docker-compose конфигураций.

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

Рекомендуемый подход

Этап 1: исследование. Определите конкретную рутинную задачу, которую решаете. Изучите существующие MCP-серверы и решения в этой области. Сформулируйте ценностное предложение: что делает ваш сервер, для кого, какой эффект даёт.

Этап 2: архитектура. Спроектируйте API: какие инструменты, ресурсы и промпты предоставляет сервер. Продумайте, как он встраивается в рабочий процесс разработчика. Зафиксируйте спецификацию — это контракт между вашим сервером и агентами.

Этап 3: разработка. Используйте AI-агентов для генерации кода — но по вашей спецификации. Контролируйте, тестируйте, корректируйте. Документация — параллельно с кодом, не после.

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

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

Вместо заключения

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

Освоить её можно только на практике. Dev-to-Dev — хорошая точка входа.