У 2026 році будь-хто з ідеєю і платіжною карткою може до обіду отримати щось, схоже на робочий застосунок. Моделі складуть Next.js-магазин. Напишуть пристойний бекенд на Django. Якщо попросити — навіть накидають конвеєр розгортання і схему Postgres. Артефакт на виході реальний, його можна запустити, він справляє враження.
Чим він майже ніколи не є — це продуктом промислової якості. Розрив між «це працює на моєму ноутбуці перед прихильною аудиторією» і «це працює об 11-й вечора в суботу, коли реальний користувач із нестандартним кодуванням у поштовій адресі намагається зайти» лишається величезним. AI звузив багато частин інженерії софту. Цю частину — найменше.
Останній рік ми беремо AI-згенеровані кодові бази і vibecoded MVP клієнтів і доводимо їх до продакшну. Список того, що щоразу потрібно полагодити перед запуском, майже однаковий. Це той список — і пояснення, чому ми досі робимо цю роботу руками.
1. Автентифікація, яка справді безпечна
Модель видасть вам робочу форму входу. Скоріш за все, використає авторитетну бібліотеку. Імовірно, навіть правильно зробить хешування паролів. Чого вона майже ніколи не робить правильно з першого разу:
- Інвалідація сесій при зміні пароля.
- Обмеження частоти запитів на вхід і відновлення пароля з правильною семантикою fail-open vs fail-closed.
- Захист від перерахування поштових адрес на реєстрації й скиданні пароля.
- CSRF-токени, прив'язані до правильних операцій.
- Послідовна модель прав замість випадкових перевірок на кожному маршруті.
- Ізоляція між тенантами, що забезпечується на рівні бази даних, а не в коді застосунку.
Кожне з цього — пошук одного рядка в OWASP і кілька днів виправлень у реальній кодовій базі. AI закриває їх по одному, коли просять, але сам про них не сигналізує.
2. Схема бази, яка переживе другу функцію
Найстабільніший спосіб AI-зібраних систем зламатися: схеми, які виглядають розумно під три сценарії прототипу і стають непридатними тієї миті, коли з'являється четвертий.
Що ми зазвичай перебудовуємо:
- Зовнішні ключі замість «зджойнимо в коді застосунку».
- Справжні обмеження —
NOT NULL,CHECK,UNIQUE— замість надії на здоровий глузд. - Індекси, спроєктовані під реальні шаблони запитів, а не під здогадку моделі про те, що колись хтось запитає.
- Міграції, які чисто проходять уперед і назад, зокрема міграції даних.
- Чесний облік того, що зберігають колонки JSON, і план, як їх розвивати.
Зробити схему правильно перед запуском — це приблизно інженерний тиждень. Зробити її неправильно — це півроку поступового болю після перших ста клієнтів.
3. Спостережуваність, з якою можна налагоджувати о 2-й ночі
Прототип налагоджують додаванням print() і перезапуском локально. Промислова система налагоджується читанням дашбордів з телефона серед ночі.
Майже жодна AI-згенерована кодова база не їде у продакшн з:
- Структурованими логами з ідентифікатором запиту, що проходить наскрізь.
- Метриками на тому, що справді важливо: p95/p99 затримки, частота помилок на ендпоінт, глибина черги, повільні запити.
- Розподіленим трасуванням, яке пов'язує помилку 500 у користувача з конкретним запитом до бази, що її спричинив.
- Алертами, заведеними в канал, який людина реально читатиме.
Ми робимо це за замовчуванням. Робота негламурна, забирає приблизно тиждень — і це найбільш окупна інвестиція в готовність до продакшну, яку взагалі можна зробити.
4. Розгортання, які рутинні й оборотні
AI-згенерований Dockerfile, найімовірніше, запуститься. Чого він вам не розкаже:
- Як відкотитися за дві хвилини, коли наступний реліз ламається.
- Як зробити міграцію бази безпечною для розгортання на кількох інстансах.
- Як працювати з секретами, не закомітивши їх.
- Як тримати dev, staging і продакшн узгодженими настільки, щоб слова «працює на стейджі» взагалі щось означали.
- Як поводитись із п'ятничним релізом, коли є бажання розгорнутись, але у вашому регіоні AWS офіційне свято.
Розрив між «контейнер стартував» і «ми розгортаємось у продакшн у вівторок після обіду, ніхто не затримує дихання» — це шість місяців операційної зрілості. Ми стискаємо його приблизно у два тижні сфокусованої роботи.
5. Справжній захист для самих AI-функцій
У застосунках з AI є додатковий шар ризику, який сам AI рідко виносить на поверхню: AI-функції самі стають частиною площі атаки.
- Ін'єкція промптів через документи, що завантажує користувач.
- Витік даних між тенантами через спільні ембединги.
- Відмова в обслуговуванні через вартість — необмежені запити, які з'їдають бюджет.
- Галюцинації, упевнено неправильні на критичних для безпеки темах.
- Відсутність журналу аудиту: що зробив агент і чому.
Це не граничні випадки. Промислові AI-функції потребують простежуваності, обмеження області, поведінки відмови, оцінювання і стелі витрат — нічого з цього в прототипі зазвичай немає.
6. Бюджети продуктивності — і дисципліна їх тримати
Прототип швидкий, бо ним ніхто не користується. Промислова система, яка не міряє p95-затримку, плани запитів і Core Web Vitals, тихо деградуватиме, аж поки користувачі не почнуть іти.
Реальні виправлення у успадкованих AI-системах, які ми бачили:
- Заміна запитів
SELECT *на явний перелік колонок. - Додавання індексів, яких прототипу не бракувало, бо в таблиці було десять рядків.
- Винесення шаблонів N+1 у ORM з гарячих шляхів.
- Додавання нормального HTTP-кешування для здебільшого читальних ендпоінтів.
- Попередній рендер контенту, який не мусить бути динамічним.
Нічого з цього не складне інтелектуально. Все це потребує стабільної уваги і базової культури вимірювання. AI за замовчуванням не дає ні того, ні іншого.
Що ми робимо насправді
Коли клієнт приходить з AI-зібраною або vibecoded кодовою базою, що має стати реальним продуктом, проєкт виглядає приблизно так:
Тиждень 1 — аудит. Читаємо код, запускаємо, міряємо. Складаємо перелік прогалин за категоріями вище і ранжуємо їх за ризиком.
Тижні 2–6 — закриваємо найнебезпечніші прогалини. Автентифікація, схема бази, спостережуваність, розгортання. Робота, яку ніхто не продає в рекламі, але всі потребують.
Тижні 6 і далі — робота над функціями паралельно з фундаментом. Продукт уже може рости, не гниючи знизу. Ми продовжуємо випускати функції на повній швидкості, поки фундамент поступово міцнішає.
Завжди — обслуговування є опцією, а не податком. Більшість клієнтів обирає місячний ретейнер на рік після запуску. Використовуємо його на постійні покращення, роботу над продуктивністю та чергування. Система з часом стає кращою, а не гіршою.
Що ми не стверджуємо
Ми не стверджуємо, що AI-згенерований код поганий. Навпаки: він уже досить хороший, щоб вузьке місце перейшло з «чи зможе хтось написати цей код узагалі» на «чи зможе хтось зробити так, щоб цей код вижив у продакшні». Друге питання — це і є цікаве питання сьогодні.
Ми не стверджуємо, що наша робота гламурна. Вона не гламурна. Це читання звітів аудиту, акуратні міграції, додавання індексів, написання інструкцій реагування. Причина, з якої ми робимо її із задоволенням, проста: це саме та робота, яку AI не витіснив — і, ймовірно, не витіснить доти, доки промислові системи потребують людей на чергуванні, коли ламаються.
Ми не стверджуємо, що через це треба проходити кожному проєкту. Якщо ваш AI-згенерований прототип обслуговуватиме тридцять користувачів у внутрішньому інструменті — йому не потрібне те саме ставлення, що й платформі для зовнішніх клієнтів. Розмір інженерії має відповідати меті.
Ми стверджуємо ось що: легка частина побудови софту стала драматично легшою. Складна частина лишилась рівно настільки ж складною — і розрив між ними розширився. Закрити його — робота для досвідченої команди. Ми — та команда. Якщо ваш AI-зібраний застосунок починає тріщати — саме тут заходимо ми.