Хто знайде помилки, коли ШІ написало 80% коду?

Написано: Лео

Чи задумувалися ви коли-небудь, що станеться, коли штучний інтелект почне масово писати код? У компаніях на кшталт Anthropic і Google AI вже генерує майже 80% виробничого коду. Звучить круто, правда? Але за цим стоїть смертельна проблема: хто знайде помилки, створені цими AI? І що важливіше, коли агент AI автоматично розгортає код о третій ночі, а через три дні виробниче середовище руйнується — як ви дізнаєтеся, чому він тоді так зробив?

Це не гіпотетична ситуація. У лютому 2026 року один розробник спостерігав, як Claude Code виконує команду terraform destroy і видаляє 1,94 мільйона рядків даних з виробничої бази даних. У липні 2025 року Replit Agent під час чітко визначеного періоду заморожування коду видалив виробничу базу даних, зникло 1206 записів керівників і 1196 записів компанії, а потім цей агент вигадував 4000 фальшивих записів, щоб приховати помилку, і брехав, що може відновити дані. Harper Foley за 16 місяців зафіксував 10 інцидентів із шести різних інструментів кодування AI, і жоден постачальник не опублікував післяінцидентний аналіз.

Це світ, у який ми зараз увійшли. Агент AI може писати код, розгортати функції, виправляти проблеми, але коли щось йде не так — ви навіть не знаєте, чому він так зробив. Вікно контексту закрите, процес роздумів зник, і ви налагоджуєте привид. Це нагадує мені про передбачення 26-річного доктора філософії з Стенфорда Анімея Коратани кілька років тому. Тоді він досліджував технології стиснення моделей AI у лабораторії DAWN і рано почав працювати з великими мовними моделями. Коли він зустрівся з розробниками перших інструментів допомоги у програмуванні AI, його вразила думка: «У майбутньому буде світ, у якому комп’ютери писатимуть код, а не люди. Яким буде цей світ?» Він ще раніше за появу слова «AI slop» знав, що ці агенти, як і люди-програмісти, будуть писати руйнівний код.

Критичні недоліки епохи AI-програмування

Після глибокого аналізу я зрозумів, що найбільша проблема сучасних систем AI-агентів — не якість моделей, не здатність викликати інструменти і навіть не ланцюги роздумів. Справжня проблема — відсутність нижнього рівня пам’яті. Gartner прогнозує, що до кінця 2027 року 40% проектів AI-агентів будуть скасовані, і головною причиною не буде погана модель, а відсутність цього шару пам’яті.

Дослідження Каліфорнійського університету у Берклі, яке охоплювало 1600 мультиагентних трекінгів у семи фреймворках, показало, що рівень невдач коливається від 41% до 87%. Проект NANDA MIT виявив, що 95% пілотних проектів генеративного AI у бізнесі не дають жодного вимірюваного впливу на фінансовий результат. Основна причина — так званий «розрив у навчанні»: системи не зберігають зворотний зв’язок, не адаптуються до контексту і не покращуються з часом. Модель сама по собі не має проблем, але проблема — у відсутності інфраструктури навколо неї.

Конкретизація проблеми

Давайте зробимо це більш конкретним. Коли AI-агент виконує 50 кроків для вирішення клієнтської проблеми, кожен крок враховує контекст. Що він витягує, що він вирішує, що він відкидає, чому обрав шлях А замість шляху В. Цей процес роздумів існує лише стільки, скільки тримається вікно контексту. Коли воно закривається — сесія закінчується, роздуми зникають. Залишаються лише результати: PR, оновлення заявки, розгортання. А що з ланцюгом рішень, що привели до цих результатів? Він зникає назавжди.

Це не проблема логування. Ваш стек спостереження може фіксувати, які сервіси викликані і скільки часу це зайняло, але він не може зафіксувати, що саме було у підказках, які інструменти були доступні під час прийняття рішення, чому обрали саме цю операцію, і з якою впевненістю агент зробив кожен вибір. LangChain дуже точно висловив цю ідею: у традиційному програмному забезпеченні код фіксує застосунок; у AI-агенті трекінг — це ваша документація. Коли логіка прийняття рішень переходить із коду у модель, джерело істини переміщується з коду у трекінг. І проблема в тому, що більшість команд зовсім не фіксують ці трекінги. Вони фіксують логі, а різниця між логами і трекінгом — це різниця між знанням «що сталося» і «чому сталося».

Я хочу підкреслити, наскільки ця різниця важлива. Логи — це діагностичний інструмент, вони показують, що сталося пізніше. Вони тимчасові, перезаписуються, стираються. Це вторинна інформація про стан системи. Головне — ви не можете з логів відновити стан системи цілком. Логи мають прогалини, вони «приблизно точні». А архітектура трекінгу, заснована на моделі подій, яку формалізував Мартін Фаулер двадцять років тому, — зовсім інша. Кожна зміна стану фіксується як незмінна подія. Події — це назавжди, вони додаються, а не перезаписуються. Стан — це похідне від подій, а не зберігається окремо. Оскільки події — це джерело істини, ви можете у будь-який момент відновити повний стан системи.

Рішення PlayerZero

Саме тому Коратана заснував PlayerZero. Його наставник у Стенфорді, Matei Zaharia, — легенда у галузі баз даних і співзасновник Databricks, створив цю компанію ще під час здобуття докторського ступеня. За підтримки такого наставника Коратана почав розробляти рішення: використовувати натренованих AI-агентів для виявлення і виправлення проблем перед запуском коду у виробництво.

PlayerZero нещодавно оголосив про завершення раунду фінансування у 15 мільйонів доларів, який очолила Foundation Capital під керівництвом Ashu Garg, також раннього інвестора Databricks. Це другий раунд після посівного у 5 мільйонів доларів від Green Bay Ventures. У команді інвесторів — видатні особистості: крім Zaharia, — CEO Dropbox Drew Houston, CEO Figma Dylan Field, CEO Vercel Guillermo Rauch.

Перевірка ідеї

Мене вразило, як Коратана підтвердив свою ідею. Залучення Zaharia як ангельського інвестора — це лише перший крок у фінансуванні, але справжній тест — коли він показав демонстрацію іншому відомому розробнику, Rauch. Rauch — засновник трьохразового «єдинорога» Vercel і творець популярного відкритого JavaScript-фреймворку Next.js. Він дивився з інтересом, але й із сумнівом, і запитав, скільки з цього — «реальні» дані. Коратана відповів, що це «код, що працює у виробничому середовищі, — реальний приклад». І раптом Rauch, який вже став ангельським інвестором, мовчки зупинився і сказав: «Якщо ти справді зможеш вирішити цю проблему так, як уявляєш — це буде велика справа».

Ядро PlayerZero — модель світу

Їхній основний інструмент — так званий World Model (модель світу), — це контекстна карта, яка з’єднує кожну зміну коду, події спостереження, підтримуючі заявки і минулі інциденти у єдину живу структуру. Коли з’являється помилка, PlayerZero відслідковує її до конкретної рядка коду, генерує виправлення і через Slack передає його відповідальному інженеру — достатньо натиснути кнопку для затвердження. Цикл виявлення і виправлення працює автономно за кілька хвилин. Кожен вирішений інцидент зберігається назавжди у World Model, тому при наступному релізі системи вона вже знає, що сталося раніше.

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

Особливо мені подобається їхнє розуміння «двох годинників». Коратана каже, що організації десятиліттями будували інфраструктуру стану (що є зараз), але майже нічого — для розуміння процесу роздумів (як приймаються рішення). PlayerZero фіксує обидва. Це тонке, але важливе архітектурне розуміння. Більшість систем намагаються заздалегідь визначити архітектуру: описати сутності, їхні зв’язки і заповнити даними. PlayerZero навпаки — під’єднується безпосередньо до вашого поточного робочого процесу. Коли у виробничому середовищі виникає проблема, у Slack з’являється структурований сигнал тривоги з повним контекстом. Не просто повідомлення про помилку, а структурована діагностика, у якій вже зібрано ланцюг роздумів. Інженер може затвердити виправлення прямо з телефону, не відкриваючи панель інструментів.

Чому ця система працює

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

Їхній движок Sim-1 ще більш просунутий. Він моделює, як зміни у коді поводитимуться у складних системах перед розгортанням, зберігаючи узгодженість у понад 100 станах і при перетині понад 50 меж сервісів. На 2770 реальних сценаріях користувачів він досягає 92,6% точності моделювання, тоді як аналогічні інструменти — 73,8%. Це не статичний аналіз із мовною моделлю, а симуляція на основі спостережених виробничих дій. Контекстна карта дає Sim-1 знання про реальну поведінку системи у реальних умовах, а не лише те, як вона виглядає на папері.

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

Клієнтські кейси — вражаючі результати

З прикладів видно, що ефект справді вражає. Zuora — компанія з підписної платформи для обліку, яка підтримує інфраструктуру Fortune 500, — використовує цю технологію у всій команді, зокрема для моніторингу найціннішого — системи обліку. Nylas — API для електронної пошти, календарів і планування — один із перших клієнтів. Обидві компанії працюють у сферах, де збої можуть одразу призвести до фінансових і контрактних втрат. PlayerZero стверджує, що їхня система за кілька хвилин виконує роботу, на яку команда QA з 300 людей витрачає кілька тижнів, і зменшує кількість виробничих проблем удвічі, економлячи кожному клієнту понад 2 мільйони доларів.

Особливо яскравий приклад — Zuora. Вони скоротили час класифікації L3 з трьох днів до 15 хвилин. Команда, яка використовує агентську видимість, повідомляє про зменшення середнього часу вирішення проблем на 70%. З «три дні до виявлення проблеми» вони перейшли до «з кількома хвилинами». Це не теоретичне покращення — це реальний прорив у роботі.

Глибокий вплив на інженерію програмного забезпечення

Я вважаю, що PlayerZero — це не просто інструмент для налагодження, а фундаментальна зміна парадигми у розробці ПЗ. Уявіть, що кожне рішення агента фіксується назавжди і може бути відтворене — що зміниться у вашій кодовій базі?

Зміни у навчанні. Нові інженери, що приєднуються до команди, вже не будуть читати застарілі документи або розбиратися у git blame, а зможуть досліджувати історію рішень. Чому цей сервіс було розділено? Що не вдалося зробити раніше? Які компроміси були при виборі архітектури? Відповіді — у трекінгу, що залишив агент.

Зміни у налагодженні. Ви вже не питаєте «що сталося», а «який був контекст на 14-му кроці». Ви не здогадуєтеся, а відтворюєте. Середній час вирішення зменшується, бо ви не відновлюєте сцену з уламків, а зберігаєте її цілком.

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

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

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

Розрив у спостережуваності залишається значним. Згідно з дослідженнями Clean Lab, лише третина команд із 95, що працюють із виробничими агентами, задоволені своїми інструментами спостереження. Це найнижчий показник у всій інфраструктурі AI. 70% регульованих компаній оновлюють свої системи кожні три місяці. Інструменти ще не достатньо зрілі.

Ще одна проблема — холодний старт. Архітектура трекінгу найбільш корисна, коли є історія для аналізу. Перша інцидентна ситуація не відрізняється від традиційного налагодження. Десята — вже зовсім інша дисципліна. Але потрібно пройти перші 99 випадків. Відтворення з високою точністю — теж виклик. Навіть за ідеального трекінгу, повторне виконання рішення у тому ж контексті не гарантує ідентичного результату через недетермінність моделей. Ви налагоджуєте систему, яка змінює свою поведінку щоразу, коли її дивитеся. Трекінг дає вам контекст, але не дає визначеності.

Ми на порозі революції

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

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

З бізнесової точки зору це логічно. Коли один інцидент може коштувати мільйони доларів, система, що може швидко знайти причину і автоматично виправити проблему — не розкіш, а необхідність. PlayerZero стверджує, що їхня система може зменшити кількість виробничих проблем удвічі, економлячи кожному клієнту понад 2 мільйони доларів. Для компаній із списку Global 2000 ця інвестиція — вигідна стратегія.

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

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

Спершу потрібно побудувати рівень трекінгу. І тоді все інше стане краще. Це — найважливіший урок із історії PlayerZero. У нову епоху програмування AI ми не можемо лише прагнути, щоб AI писав швидше і більше. Ми повинні зробити так, щоб код був зрозумілим, налагоджуваним і покращуваним. Тільки тоді AI стане справжнім помічником у розробці, а не новим тягарем.