На конференції Craft 2026 у Будапешті автор блогу The Pragmatic Engineer Ґерґей Орош поділився рідкісним зрізом того, як великі AI‑лаби й продуктові компанії уже перебудували щоденну розробку навколо кодових агентів. На відміну від теоретичних прогнозів, це історії з перших рук: внутрішні метрики, робочі практики OpenAI, Anthropic, Cursor, Google, Uber й інших гравців — і дуже конкретні цифри, що показують, наскільки більше коду сьогодні реально пише AI.
Вибух продуктивності: коли кодові агенти множать обсяг коду
Одне з найяскравіших спостережень стосується команд, які інтегрували AI‑агентів у свій щоденний процес розробки. За внутрішніми даними Linear, які компанія поділилася вперше, команди, що користуються агентами, зараз «шиплять» приблизно у п’ять разів більше коду, ніж ті, що працюють без них. Це не віддалений прогноз, а вже наявний ефект: «by now the teams that are using agents are shipping five times as more code… this is massive 5x increase».
Орош окремо наголошує: це зміна масштабу, яку галузь не бачила десятиліттями. Подібне зростання продуктивності зазвичай розтягується на 10–20 років еволюції інструментів і практик. Тепер же, за його словами, п’ятикратний приріст обсягу коду стався менш ніж за два роки.
Що це означає на рівні окремого розробника, добре видно на прикладі Cursor — одного з найбільш «агентно-орієнтованих» IDE на ринку.
Cursor: вдвічі більше рядків і втричі більші PR за рік
Команда Cursor поділилася з Орошем статистикою щодо того, як змінився випускний «темп» розробників, які активно працюють у цьому середовищі. За рік середня кількість рядків коду, які деви генерують за допомогою Cursor, «майже у два з половиною рази» зросла: «from 3 up 4,000 lines of code to more than 8,000 lines of code just on cursor».
Змінився не лише обсяг, а й структура змін. «The size of PRs also from cursor is up by 3x… if you combine those two that’s six times as much code», — каже Орош. Тобто окремі pull request стають у три рази більшими, а сумарний обсяг коду, який проходить через них, зростає приблизно вшестеро.
Cursor також бачить ще одну помітну тенденцію: різко зростає частка розробників, які приймають зміни від AI без ручного редагування. Після виходу нових моделей на кшталт Opus 4.7 та GPT 5.5 «the percentage of devs using cursor who are accepting changes from the AI without any manual review is massively up». Це означає, що для значної кількості користувачів AI уже не просто інструмент підказок, а фактичне джерело фінального коду.
Орош одразу застерігає: така експоненціальна крива обсягу коду тягне за собою й очевидний наслідок — зростання кількості багів. Він прямо артикулює те, про що посміхаючись думає зал: «we know that there’s six times as many bugs… we’ll again, we’re going to get there». Питання якості він розкриває окремо, але саме на прикладі Cursor добре видно базову динаміку: AI швидко перетворюється на основний «двигун» потоку змін, а не допоміжний інструмент.
Anthropic: 5 агентів на ноутбуці й 70–90% коду, написаного AI
Як виглядає «життя з агентами» всередині AI‑лабу, Орош демонструє на прикладі Anthropic та його продукту Claude Code. Він розповідає про розмову з Борисом Черні, який очолює команду Claude Code й одночасно залишається дуже hands‑on‑інженером.
«Boris specifically runs five parallel agents on his laptop all the time. He ships 20 to 30 pull requests a day», — описує Орош. П’ять паралельних агентів постійно працюють поруч із людиною, яка водночас керує великим продуктом і щодня відправляє десятки PR. Це наочна демонстрація того, наскільки щільно агентні воркфлови можуть бути вплетені в роботу навіть топових техлідів.
Всередині Anthropic Claude Code вже давно став не просто продуктом для клієнтів, а базовим інструментом розробки самої компанії. Орош наводить їхні внутрішні оцінки: «Today 100% of cloud code is generated by cloud code… inside Entrophic is not 100% but it’s closer to 70 to 90%». Тобто:
- весь код самого Claude Code повністю згенерований Claude Code
- у ширшому кодовому базисі Anthropic AI‑генерація становить приблизно 70–90% залежно від команд та контексту
Принципово важливо, що таке проникнення AI в їхній дев‑процес не є формальною ціллю: «there’s no target. This is just people using it again». Люди просто віддають перевагу інструменту, який працює швидше й звичніше за ручний ввід.
Окремий акцент — на тому, що класичні артефакти на кшталт PRD‑документів для планування фіч у Anthropic фактично «мертві». Черні, за словами Ороша, вважає їх застарілими, а компанія масово переходить на прототипування, де агенти допомагають швидко збирати робочі прототипи замість довго писати специфікації.
OpenAI: кнопка «fix it» і компанія, де «більшість людей більше не пише код»
Якщо в Anthropic Claude Code став внутрішнім «двигуном коду», то в OpenAI роль грає Codex і внутрішня версія ChatGPT. Орош описує те, як виглядає їхня розробка сьогодні.
Всередині компанії існує модифікований застосунок ChatGPT із вбудованою функцією «fix it». «Inside of OpenAI… they have fix it button. You can literally just take a screenshot and say fix this bug and it goes to codeex. It generates a pull request and an engineer can merge it», — пояснює Орош.
Алгоритм роботи простий і показовий:
- Інженер або навіть неінженер робить скріншот проблеми в інтерфейсі чи системі.
- В інтерфейсі ChatGPT він натискає кнопку «fix this bug».
- Запит іде у Codex, який генерує код‑фікс та створює pull request.
- Людина переглядає PR і за потреби зливає його.
Для некритичних змін у OpenAI запроваджені багаторівневі safety‑механізми: частина коду може йти в продакшен після лише AI‑рев’ю, для критичних шляхів обов’язковий людський перегляд. Але те, що навіть неінженери можуть фактично запускати повний цикл «знайшов баг — отримав PR», показує, наскільки глибоко Codex обгортає рутини розробки.
Орош описує й повсякденну «агентну» культуру компанії. Більшість девів, за його словами, запускають «several agents» одночасно. Він наводить історію, як під час відеоінтерв’ю запитав одного з інженерів, чи той тримав агента увімкненим під час розмови. Відповідь була показовою: «I didn’t have an agent running. I had five».
Далі — ще більш радикальний зсув: «most people don’t really write code inside of OpenAI… this has changed in October… it’s just slowly going away». Якщо раніше було типовим співвідношенням, коли деви писали приблизно 30% коду руками й 70% — через AI, то нині навіть ця «людська третина» поступово зникає. Команда Codex, за його словами, «obviously writes it all with Codex».
Фокус зміщується до іншої компетенції: «taste, knowing what to build is becoming pretty important». Вартість не стільки в тому, щоб написати код, скільки в тому, щоб правильно сформулювати, що саме має бути побудовано, як це інтегрується в систему й яку проблему вирішує.
Цю логіку OpenAI застосовує навіть до власних інструментів. Codex, за словами Ороша, «improves itself» — вночі він проганяє тести, шукає можливі покращення, а зранку команда отримує пропозиції змін і вже вирішує, що приймати. Під час дебаг-сесій інженери надсилають голосові нотатки в Codex, який паралельно аналізує їх і повертає результати вже до кінця зустрічі.
Google і обмеження власної моделі
Всередині Google картина менш однозначна. Компанія історично побудувала величезний стек внутрішніх інструментів: власний IDE Cider, монорепозиторій Piper, Borg замість Kubernetes, Monarch як внутрішній аналог Datadog, Code Search, Critique для code review тощо. За словами Ороша, «AI is integrated into all of these things and it’s all integrated together really really nicely so inside it’s a really good experience».
Втім, ключова проблема — якість самої моделі Gemini. Орош формулює це дуже прямо: «Gemini is just not as good as Opus or GPT 5.5». У результаті там, де інженери мають можливість користуватися Claude Code, вони це роблять, але «only inside the Gemini org», де є офіційний дозвіл. Обмеження на використання зовнішніх моделей означає, що загальне впровадження AI у Google, попри вражаючий внутрішній стек, відстає від компаній, які можуть безперешкодно брати кращі моделі ззовні.
Uber та «новий стандарт» внутрішніх AI‑платформ
Uber з’являється в розповіді Ороша як показовий приклад того, як навіть відносно «традиційна» продуктова компанія з кількома тисячами інженерів відбудовує свій дев‑стек навколо агентів. Він підкреслює, що в Uber близько 3 000 розробників, а окрема команда developer experience фактично перетворилася на «AI experience‑команду» з приблизно 20 людей.
Ця невелика група побудувала цілу екосистему внутрішнього AI‑інструментарію:
- внутрішній MCP‑gateway для реєстрації й відкриття сервісів
- конструктор агентів Uber Agent Builder і візуальну Agent Studio для нетехнічних співробітників
- реєстр агентів, яким користуються близько 20 000 людей поза інженерним штатом
- AI‑CLI, яке Орош описує як «the cloud code for Uber»
- Uber Minion — фонова система агентів, інтегрована в монорепозиторій і платформу експериментів Morpheus
- Code Inbox, що фільтрує AI‑рев’ю коду й підсвічує, де потрібна увага людини
- Smart Assignments і UReview для пріоритизації та маршрутизації рев’ю
Орош порівнює Uber Minion із режимом фонового виконання агентів у Cursor, але підкреслює, що внутрішнє рішення працює «краще і швидше» завдяки глибокій інтеграції з їхньою інфраструктурою. Наприклад, Minion сам аналізує промпт, пропонує варіанти, як отримати «results faster cheaper», і тому деви воліють користуватися ним, навіть маючи доступ до Claude Code.
Ця частина розповіді у виступі Ороша тісно пов’язана з іншим його спостереженням: великі компанії на кшталт Stripe, Shopify, Airbnb так само інвестують у власні MCP‑шлюзи, агентні студії, CLI та внутрішні рантайми — але це детальніше він виносить в окремий блок, який уже виходить за межі теми чисто «кодового вибуху».
Де закінчується хайп і починається практика
Усі ці приклади разом малюють чіткий тренд: агенти перестають бути додатковою опцією в IDE і стають базовим шаром розробки — від AI‑лабораторій до великих продуктових компаній.
Ключові практичні маркери цього переходу, які фіксує Орош у своїх розмовах і даних:
По-перше, різке зростання обсягу коду. П’ятиразовий приріст у командах з агентами за даними Linear, дво‑з‑половиною кратне зростання рядків на девелопера в Cursor, триразове збільшення розміру PR і до шестиразового сукупного приросту коду — це вже не експерименти окремих ентузіастів.
По-друге, глибина інтеграції у внутрішні процеси. В Anthropic 70–90% коду компанії створюється Claude Code, а сам Claude Code на 100% написаний собою. В OpenAI існує кнопка «fix it», яка перетворює скріншот у pull request, і «most people don’t really write code» у класичному сенсі. Uber будує цілий ланцюжок платформ для агентів, покликаний зробити AI доступним не лише девам, а й десяткам тисяч бізнес‑користувачів.
По-третє, зміна ролі розробника. Там, де агенти беруть на себе більшу частину «рутинного» набору коду, зростає цінність смаку й продуктового мислення — «knowing what to build». У кодових лабах AI не скільки замінює інженера, скільки вимагає від нього іншого профілю — архітектора, куратора агентів, людини, що формулює задачу правильно й контролює результат.
По-четверте, розмивання межі між інженерами й «неінженерами» у частині взаємодії з кодом. Функції на кшталт OpenAI‑шної «fix it» дозволяють людям без сильного дев‑бекграунду ініціювати кодові зміни, покладаючись на автоматизований пайплайн генерації та рев’ю.
Орош не ідеалізує ці процеси: далі у виступі він детально розбирає проблеми якості, перевантаження кодової бази, вигоряння рев’юерів і бюджетний шок від AI‑інференсу. Але саме в частині агентів і обсягу коду картинка вже досить чітка: хайп навколо «AI, що пише код», перетворився на стрімко мінливий, але дуже конкретний робочий стандарт у значній частині індустрії.
Висновки
Історії Anthropic, OpenAI, Cursor, Google й Uber у викладі Ґерґея Ороша показують, що дискусія про «AI‑агентів у деві» змістилася з площини «чи це спрацює» у площину «які наслідки матиме такий темп для якості, культури й ролі розробника». Команди, які вже живуть у цій реальності, бачать п’ятикратні й більші прирости обсягу коду, масову генерацію PR‑ів агентами й дедалі менший обсяг коду, написаного людиною «від руки».
Попереду — робота з відновлення балансу між швидкістю й довірою до коду, але факт залишається фактом: агентні системи вже сьогодні радикально переписують те, як створюється програмне забезпечення у провідних технологічних компаніях.
Джерело
Slow down to speed up: AI and software engineering — The Pragmatic Engineer