У вересневому випуску Макс Березанський, Tech Lead у Keiki, розбирає, як Anthropic бачить AI Native розробку, навіщо Shopify стискає системні промпти, та як Google намагається зменшити кількість хибних AI-знахідок у security. А ще — кейс Vercel, яка на практиці перевірила, наскільки системні інструкції допомагають AI краще дотримуватися дизайну бренду та чому Cursor будує для coding agents інфраструктуру за логікою CI/CD.
Anthropic представила AI-native модель SDLC
Anthropic опублікувала AI Native SDLC Playbook — своє бачення того, як має змінитися цикл розробки з поширенням AI-агентів. Головна теза: написання коду поступово перестає бути найдовшою частиною процесу, а bottleneck зміщується в планування, рев’ю, тестування, безпеку та деплой.
На практиці це вже помітно. Код тепер можна написати значно швидше, але правильно сформулювати вимоги, ухвалити архітектурні рішення та проконтролювати результат усе ще має людина. Через це змінюється й навантаження: менше часу йде безпосередньо на написання коду, але більше уваги потребують рішення, контроль і перевірка того, що зробив агент.
Anthropic пропонує перебудувати під це весь SDLC. Замість лінійної послідовності
Plan → Design → Build → Test → Deploy → Maintain
компанія описує безперервний цикл, у якому AI підключається на кожному етапі. Результат одного етапу стає вхідними даними для наступного:
intent.md → spec.md → plan.md → код і тести → результати рев’ю → дані про інциденти → новий intent.md.
При цьому ключові рішення залишаються за людьми. Інженер, наприклад, перевіряє план ще до генерації коду, а результат роботи агента має підтверджуватися тестами, збірками, evals і security checks. Якщо вже у production виникає проблема, інформація про неї повертається на початок циклу й стає основою для наступної зміни.
Vercel скоротила помилки AI у вебдизайні на 57%
Vercel побудувала систему, у якій інструкції для AI-агентів постійно тестують, оновлюють на основі фідбеку та повторно перевіряють на помилки. Тобто фактично застосовуючи до них звичний цикл розробки ПЗ.
Для цього компанія створила design.md — файл з інструкціями, який допомагає AI-агентам генерувати вебсторінки у стилі бренду навіть без доступу до внутрішньої кодової бази. Під час його розробки Vercel провела понад 200 запусків агентів і з’ясувала, що самого промпту недостатньо: суб’єктивні дизайнерські правила різні моделі трактують по-різному.
Тому design.md доповнили таблицею стилів (stylesheet), яка задає конкретні параметри верстки, зокрема відступи та розташування елементів, і циклом автоматизованих перевірок (eval loop). Він допомагає знаходити повторювані помилки, перетворювати фідбек на нові інструкції та після кожної зміни перевіряти, чи не виникли нові проблеми.
У фінальному тесті Codex із GPT-5.5 створював сторінки з design.md і без нього. За результатами автоматичних перевірок, з design.md кількість відомих помилок скоротилася на 57%: 39 випадків проти 91.
Для фронтенд-команд такий підхід може бути цікавим способом зробити AI-згенеровані сторінки ближчими до дизайну конкретного бренду. Водночас Vercel поки не відмовляється від перевірки результату людиною: у кожній із шести сторінок фінального тесту залишалася щонайменше одна помилка, яку потрібно було виправити перед релізом.
Shopify стиснула системний промпт LLM у чотири рази
Shopify представила Gisting — спосіб стискати великі системні промпти LLM у коротший набір спеціально навчених токенів. Ідея доволі проста: якщо модель щоразу отримує кілька тисяч токенів з однаковими інструкціями, це збільшує час обробки й витрати. Gisting дозволяє замінити цей великий шматок контексту значно коротшим.
У Shopify так стиснули системний промпт GraphQL-агента Sidekick приблизно з 6000 до 1500 токенів. При цьому агент продовжив працювати з тією самою якістю, але став швидшим: повний час відповіді скоротився з 6,8 до 4,2 секунди, а система змогла обробляти більше запитів одночасно. Завдяки цьому Shopify також змогла зменшити кількість GPU.
Важливий момент: Gisting не просто переказує промпт коротшими словами. Модель спочатку працює з повною версією інструкції, а потім для неї навчають спеціальні gist-токени, які мають відтворювати ту саму поведінку вже без усього початкового тексту. Після навчання gist-токени додаються до моделі як спеціальні токени, тому для їх використання не потрібна окрема схема обробки запитів.
Особливо корисним такий підхід може бути для систем із великими системними промптами та високим навантаженням на моделі. Там скорочення контексту може помітно впливати і на швидкість відповідей, і на вартість інфраструктури.
Google відкрила Mantis для пошуку вразливостей у коді
Google представила Mantis — open-source систему з AI-агентами, яка шукає вразливості в коді, перевіряє їх, намагається відтворити в безпечному середовищі та може запропонувати виправлення. Один із головних акцентів Mantis — зменшити кількість хибних спрацювань, які залишаються проблемою для AI-сканування коду.
Замість того щоб просто шукати підозрілі фрагменти, Mantis спочатку намагається зрозуміти сам проєкт. Система аналізує структуру та архітектуру репозиторію, його історію, попередні security-фікси, моделі загроз і залежності. Після цього окремі агенти досліджують конкретні ділянки коду, простежують потоки даних і логіку виконання.
Такий контекст потрібен, щоб відрізнити потенційну проблему від вразливості, яку справді можна використати. Наприклад, небезпечні дані можуть проходити валідацію раніше в іншій частині системи або код із вразливою функцією взагалі не використовуватися. Тому Mantis не зупиняється на висновку LLM: підозрілу вразливість система намагається відтворити в sandbox-середовищі, щоб отримати практичне підтвердження.
Додатково результати перевіряють окремі critic- і reviewer-агенти, які допомагають відсіювати хибні знахідки та визначати пріоритет реальних проблем. Google пояснює такий підхід тим, що в неякісно побудованих AI-сканерах частка справжніх знахідок може бути нижчою за 7%. Тобто знайти підозрілий код недостатньо, важливо ще довести, що проблема реальна.
Для різних етапів Mantis можна використовувати різні моделі: простіші — для класифікації знахідок, потужніші — для відтворення вразливостей і створення патчів. На практиці особливо цікавий сам підхід до перевірки: Mantis враховує контекст системи, щоб не позначати як реальну вразливість код, який, наприклад, захищений валідацією або взагалі не використовується.
Cursor переносить роботу AI-агентів на інфраструктуру компаній
Cursor розширила можливості self-hosted Cloud Agents. Тепер компанії можуть запускати робочу частину coding agents на власних серверах і керувати не окремими машинами, а цілими пулами workers, які автоматично розподіляють між собою завдання.
Тут важливо розібратися, що саме переноситься. Сам AI-агент повністю з хмари Cursor не зникає: там залишаються inference, планування та agent loop. Але все, що агент безпосередньо робить із середовищем — редагує файли, запускає команди в терміналі, працює з репозиторієм, браузером або локальними MCP-серверами, — може виконуватися вже на інфраструктурі компанії.
Це схоже на те, як давно працює CI/CD з self-hosted runners. Команда може створити різні пули машин під конкретні задачі: наприклад, Mac для iOS-розробки або GPU-машини для навантажень, яким потрібні прискорювачі. Коли запитів стає більше, контролер може підняти додаткові workers, а коли машина простоює — її можна перевести в hibernation і відновити для наступної сесії. Cursor також додала готові варіанти розгортання для Kubernetes і Google Cloud Run.
У результаті coding agent уже не обов’язково прив’язаний до IDE або ноутбука конкретного розробника. Він може працювати у фоні на спільній інфраструктурі команди, отримувати задачі через GitHub, Slack чи Linear і використовувати ті самі внутрішні ресурси, до яких має доступ середовище компанії.
Для команд, які вже користуються Cursor, це особливо цікаво: агентам можна дати доступ до внутрішніх сервісів, приватних репозиторіїв, build-середовищ або специфічного hardware, не переносячи виконання цих операцій у managed VM Cursor. Водночас це не повністю локальне рішення: результати виконаних команд повертаються в Cursor, оскільки inference та керування агентом залишаються в його хмарі.
По суті, тут цікаве ширше зрушення: coding agents поступово стають окремим типом інфраструктурного workload. Для них уже потрібні свої workers, маршрутизація задач, autoscaling, ізоляція середовищ і правила доступу — приблизно так само, як свого часу це стало нормою для CI/CD.
