Вибух API реальний – і Vibe Coding запалює запобіжник

Бум штучного інтелекту приніс нам багато чого: підвищення продуктивності, нові творчі робочі процеси та, нещодавно, лавину API. Якщо вам здається, що кількість внутрішніх та зовнішніх API у вашій компанії подвоїлася за одну ніч, ви цього не уявляєте. Ми переживаємо вибух API, і генеративний ШІ є основним прискорювачем цього.

Лише кілька років тому створення нової кінцевої точки API у зрілій кодовій базі було досить складним завданням. Потрібно було впоратися з володінням кількома доменами коду, отримати схвалення від ненадійних архітекторів та провести перевірки, які іноді затягувалися на тижні або місяці. Тертя було болісним, але воно гарантувало, що кожен новий API мав певний рівень ретельної перевірки та інституційну пам'ять.

А тепер? Інструменти розробки на базі штучного інтелекту усунули це вузьке місце.

Агенти GenAI можуть споживати величезні обсяги контекстних даних та змінювати код у сотнях файлів за лічені секунди. Це демократизувало можливість створювати API – не лише для інженерів, але й для нетехнічних професій (шок і жах), таких як менеджери продуктів та команди підтримки, які тепер можуть відчувати себе уповноваженими відправляти експерименти безпосередньо у виробництво.

Це масштабний зсув у тому, хто має владу в процесі розробки програмного забезпечення. І це не обов'язково погано, особливо в бізнес-середовищі, яке надає пріоритет швидкості та ітерації. Але результатом є лісова пожежа швидко розгортаних API: багато з них були запущені як «експериментальні» або приховані за прапорцями функцій, але швидко стають важливою інфраструктурою, оскільки потреби бізнесу розвиваються. Те, що починається як швидкий прототип, перетворюється на ключову інтеграцію. І тепер вже пізно розкручувати це.

Зростання «вібраційного кодування»

Це нове покоління API, створених штучним інтелектом, часто постає з мінімальним обсягом архітектури, документації чи тестування. Ми називаємо це явище «вібраційним кодуванням» – написання програмного забезпечення на основі грубої інтуїції, вільних підказок та загального відчуття того, що «має працювати», а не глибокого розуміння систем чи шаблонів проектування.

На жаль, API, створені таким чином, як правило, дотримуються суперечливих конвенцій, не мають надійної валідації та часто ігнорують встановлені внутрішні стандарти. Гірше того, вони можуть створювати серйозні ризики для безпеки або нормативних актів, особливо коли вони підключені до конфіденційних даних або зовнішніх кінцевих точок. Штучний інтелект не знає моделі управління вашою компанією – або ваших вимог до відповідності. Якщо про це прямо не вказано, він не писатиме з урахуванням цих вимог.

І проблеми швидко посилюються. Штучний інтелект також все частіше використовується для створення тестів. Але коли зламаний код тестується за допомогою валідацій, згенерованих ШІ, тести лише підтверджують неправильну поведінку. Розробники неохоче пишуть тести для коду, який вони не створили, не кажучи вже про код, згенерований машинами, тому ШІ бере на себе цю відповідальність. Результат? Рекурсивний цикл зворотного зв'язку низькоякісного коду, протестованого та «валідованого» за допомогою такої ж хиткої структури.

Patchwork API та криза власності

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

Інструменти штучного інтелекту надають пріоритет корисності та швидкості. Якщо їх не контролювати, вони створять найкоротший шлях до реалізації, незалежно від того, чи відповідає він вашому архітектурному баченню. З часом тягар цього технічного боргу може зупинити прогрес.

Деякі практичні кроки, які слід зробити.

1. Видимість

Відповідь не в тому, щоб уповільнювати все чи забороняти штучний інтелект. Це нереально, і це залишить величезну цінність без уваги. Натомість ми повинні еволюціонувати підходи до управління програмним забезпеченням в епоху генеративного розвитку.

Перший фундаментальний крок – це видимість. Неможливо керувати тим, чого не видно. Організаціям потрібне постійне виявлення API, а не статична документація, яка застаріває з моменту публікації.

Інструменти, що моніторять API — під час виконання та в коді — стають важливими. Щойно ви зробите карту реального ландшафту API, ви зможете оцінити ризики, виявити дублювання та розпочати створення надійного управління зверху.

За іронією долі, сам ШІ може допомогти в цьому процесі. Використання моделей ШІ з підказками для аналізу та аудиту карт API допомагає виявляти аномалії, ризиковані впливи та можливості консолідації. Це допомагає ШІ не створювати більше, а очищати те, що у нас вже є.

2. Встановлення загальноорганізаційної стандартизації оперативного проектування та оснащення

Кращий контроль як над виводом, так і над вводом даних інструментів штучного інтелекту значною мірою сприяє збереженню певного рівня контролю над згенерованим кодом. Такі прості кроки, як узгодження середовищ розробки на базі штучного інтелекту та моделей, схвалених для використання в організації, допоможуть із варіаціями. Це також має перевагу в тому, що спрощує впровадження нових моделей і підвищує ймовірність відтворення підказок на всіх робочих станціях інженерів.

Ще потужнішим є узгодження на основі конкретних правила.md файли типів, які потрібно надати ШІ-кодерам як контекст для свого агента. Чим складніша кодова база, тим корисніше для всіх інженерів працювати з одним і тим самим набором правил, надаючи ШІ-агенту контекст щодо того, як правильно генерувати код, який найкраще працює з існуючими структурами.

Ми не збираємося повертати генеративного джина назад у пляшку. Але ми можемо направляти його, стримувати радіус вибуху та використовувати його для підживлення відповідальних інновацій. Ця робота починається не з коду, а з ясності.