AI изменил разработку. Инструменты — нет.

За последний год роль сильного инженера изменилась сильнее, чем за предыдущее десятилетие. Мы больше не пишем код вручную — мы отлаживаем его на естественном языке, копируя ошибки тестов в чат с агентом. Но инструменты, которыми мы пользуемся каждый день — IDE, GitHub, Jira, Confluence — проектировались для совершенно другого способа работы. Ран Исенберг в своём посте разбирает этот разрыв по пяти ключевым направлениям: IDE, ревью спецификаций, спринты, межрепозиторный контекст и управление навыками.

Профессия изменилась — инструменты должны последовать

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

Если именно эти навыки теперь важны, то и инструменты должны строиться вокруг них. А большинство — нет.

Почему IDE больше не подходит для агентной разработки

Классическая IDE построена вокруг помощи человеку в написании и чтении кода: отладчик, автодополнение, инструменты рефакторинга. В агентном процессе всё иначе. Агент сам пишет код, сам анализирует ошибки и рефакторит по описанию на естественном языке. Большая часть классического инструментария просто простаивает.

В AI-управляемом SDLC spec-driven разработка означает написание структурированной спецификации в .md-файлах до начала кодирования. Спецификация становится тем, что направляет агента. Каждый этап производит свои артефакты: memory bank проектного контекста, файлы спецификаций. Именно их агент читает, чтобы понять, что строить.

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

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

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

Почему GitHub не умеет ревьюить Markdown-спецификации

Spec-driven разработка — это не только для разработчиков. Product owner может написать спецификацию с помощью фреймворка вроде BMAD и прогнать её через навык ревью, который оспаривает дизайн так, как это сделал бы жёсткий senior-инженер. Это ставит два вопроса.

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

Второй — ревью Markdown-файлов — просто плохой опыт, что на GitHub, что в IDE. GitHub создан для ревью диффов кода и делает это отлично. Но длинный Markdown-документ с дизайном — это не дифф. Читать спецификацию с плюсами и минусами, разбросанными по абзацам — miserable experience.

Что делают команды? Копируют спецификацию из репозитория в Confluence (обычно целиком) и в Jira-тикет (обычно фрагмент), собирают комментарии там, а затем кто-то вручную вносит изменения обратно в Markdown. Спецификация живёт в двух-трёх местах одновременно, версии расходятся, и единственный источник правды перестаёт быть таковым. Команды уже строят внутренние инструменты для автоматизации этого процесса — явный признак того, что проблема не маленькая.

Что происходит со спринтами, когда эпик делается за день?

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

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

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

Межрепозиторный контекст: spec-репозиторий

Реальный сервис редко живёт в одном репозитории. База данных, бэкенд, фронтенд — каждый в своём репозитории, принадлежит разным людям и развивается по своему графику. Когда агент получает задачу построить фичу, затрагивающую все три, у него нет способа понять, как они связаны, куда должно попасть изменение схемы, какой API-контракт нужно изменить и как фронтенд его потребляет.

Подход, который выглядит перспективным — выделенный spec-репозиторий, сидящий над остальными. Вместо кода приложения он содержит спецификации, архитектуру и, главное, связи между каждым репозиторием в системе. Специализированный агент или навык может закартировать brownfield-реальность — как репозитории связаны друг с другом: бэкенд читает из конкретной таблицы в database-репо и отдаёт эндпоинт, который вызывает фронтенд-репо.

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

Проблема AI-навыков: каталогизация, шаринг, тестирование

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

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

Это начинает меняться. Port недавно представил каталог навыков, который относится к навыкам как к сущностям первого класса в developer portal: команда публикует навык один раз, контролирует доступ, и он автоматически появляется в AI-клиенте разработчика, будь то Cursor или Claude Code. Port также выпустил CLI, синхронизирующий навыки в локального агента.

Microsoft движется с другой стороны с Agent Package Manager (APM) — аналогом npm или pip для настройки агентов: декларируешь навыки, плагины и MCP-серверы в манифесте и воспроизводишь конфигурацию одной командой на любом клиенте.

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

Волна самодельных AI-инструментов

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

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

Способ, которым мы создаём код, изменился. Теперь инструменты должны догнать.