Вибух API є реальним – і кодування настроєнь підпалює вогонь

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

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

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

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

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

Поява “кодування настроєнь”

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

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

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

Патчеві API та криза власності

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

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

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

1. Видимість

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

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

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

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

2. Встановлення організаційних стандартів інженерії промпту та інструментів

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

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

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