Взрыв API стал реальностью – и “Vibe Coding” зажигает фитиль

Бум искусственного интеллекта принес нам многое: повышение производительности, новые творческие рабочие процессы и, более недавно, лавину API. Если вам кажется, что количество внутренних и внешних API в вашей компании удвоилось за одну ночь, вы не представляете себе это. Мы живем в эпоху взрыва API, и генеративный ИИ является основным ускорителем.

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

Теперь? Инструменты разработки, работающие на ИИ, сожгли эту瓶頸.

Агенты GenAI могут потреблять огромные объемы контекстных данных и генерировать изменения кода по hundreds файлов за секунды. Это демократизировало возможность создания API – не только для инженеров, но и для неквалифицированных ролей (ужасный ужас) как менеджеров продукта и команд поддержки, которые могут теперь чувствовать себя уполномоченными отправлять эксперименты прямо в производство.

Это огромный сдвиг в том, кто обладает властью в процессе разработки программного обеспечения. И это не обязательно плохая вещь, особенно в бизнес-среде, которая отдает приоритет скорости и итерации. Но результатом является лесной пожар быстро развернутых API: многие запущены как “экспериментальные” или скрыты за флагами функций, но быстро становятся важной инфраструктурой, поскольку меняются бизнес-потребности. То, что начинается как быстрый прототип, становится ключевым интеграционным компонентом. И теперь уже слишком поздно, чтобы его развернуть.

Рост “Vibe Coding”

Этот новый тип API, сгенерированный ИИ, часто появляется с небольшим количеством архитектуры, документации или тестирования. Мы называем это явление “vibe coding” – написание программного обеспечения на основе грубой интуиции, свободной подсказки и общего представления о том, что “должно работать”, а не глубокого понимания систем или моделей проектирования.

К сожалению, API, созданные таким образом, часто следуют не последовательным соглашениям, не имеют надежной проверки и часто игнорируют внутренние стандарты. Хуже того, они могут ввести серьезные проблемы безопасности или регулирования, особенно при подключении к чувствительным данным или внешним конечным точкам. ИИ не знает модели управления вашей компании – или ваших требований соответствия. Если ему не указать явно, он не будет писать с учетом этих требований.

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

Патч-ап API и кризис собственности

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

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

Некоторые практические шаги

1. Видимость

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

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

Инструменты, которые отслеживают API – как во время выполнения, так и в коде – становятся необходимыми. Как только вы сможете отобразить свою реальную карту API, вы сможете оценить риск, выявить дублирование и начать строить надежное управление на основе этого.

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

2. Настройка стандартизации инженерии подсказок и инструментов на уровне организации

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

Более мощным является согласование на конкретных файлах типа rules.md которые вы требуете от AI-кодеров, чтобы предоставить контекст своему агенту. Чем более сложен кодовый базис, тем более полезно, чтобы все инженеры работали с одним и тем же набором правил, предоставляя контекст ИИ-агенту о том, как правильно генерировать код, который работает лучше всего с существующими структурами.

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