У 2026‑му штучний інтелект уже не просто допомагає писати код — у багатьох компаніях агенти фактично стали «основними розробниками». Один із найцікавіших прикладів цього тренду — Pi, мінімалістичний самозмінний AI‑кодер, створений австрійським розробником Маріо Цехнером. Pi вміє змінювати власний код на вимогу користувача й став ядром персонального асистента OpenClaw від Петера Штайнбергера. Поруч із ним — Армін Ронакер, автор популярного Python‑фреймворку Flask і один із перших активних користувачів та контриб’юторів Pi.
Попри те, що обидва глибоко залучені в побудову AI‑інструментів, їхній тон щодо нинішньої хвилі автоматизації — стриманий, а подекуди й тривожний. Вони говорять про те, що якість програмного забезпечення у все більшій кількості продуктів відчутно падає, складність росте, а інженерне судження й процеси не встигають за швидкістю, з якою компанії кидаються в обійми агентів. Армін формулює це просто: «нам усім треба, цитую, slow the F down».
Коли «код від агентів» стає червоним прапором
Сьогодні дедалі більше компаній хизуються тим, що «більшість нашого коду пишуть агенти». Для інвесторів це звучить як історія про ефективність і майбутнє. Для досвідчених інженерів — як тривожний сигнал.
Маріо жорстко формулює те, що багато хто відчуває, але не завжди озвучує: коли продукт відверто посередній, а компанія паралельно вихваляється відсотком AI‑коду, це не досягнення, а діагноз. Користувачі не читають реліз‑ноти про те, скільки рядків написав агент. Вони просто користуються продуктом — і «відчувають у кістках», що щось не так: інтерфейс незграбний, поведінка нестабільна, дрібні баги не виправляються місяцями, а нові фічі нашаровуються поверх старих, не інтегруючись у цілісну систему.
Це не випадковість, а структурний наслідок того, як працюють агенти. Вони чудово генерують код, але не мають власного відчуття якості продукту, не живуть із наслідками своїх рішень і не повертаються через пів року до того ж репозиторію, щоб розгрібати технічний борг. Там, де компанія підміняє інженерне судження метрикою «скільки зробив агент», результат закономірний: швидке зростання коду, повільне падіння якості.
Це не означає, що агенти приречені продукувати сміття. Але означає, що без сильної технічної культури, процесів і людей, які готові сказати «ні», автоматизація легко перетворюється на фабрику посередності.
Люди відчувають біль, агенти — ні: чому це критично для якості
Ключова відмінність між хорошим інженером і AI‑агентом — не в синтаксисі, а в тому, як вони переживають наслідки своїх рішень.
Досвідчений розробник, який роками підтримує складну систему, добре знає, що таке «біль від поганої абстракції». Це коли кожна нова фіча вимагає торкатися п’яти модулів, коли зміна в одному місці ламає три інші, коли онбординг новачка перетворюється на тижні пояснень, «чому тут так дивно зроблено». Цей біль — потужний стимул спрощувати, рефакторити, викидати зайве й будувати кращі моделі домену.
Агенти цього болю не відчувають. Вони не живуть у часі. Вони не повертаються в той самий код через рік, щоб розгрібати накопичену складність. Вони не отримують нічних пейджерів через падіння продакшену. Вони не сперечаються з продакт‑менеджером, пояснюючи, чому ще одна «маленька фіча» зламає архітектуру.
Маріо прямо говорить: агенти не вчаться так, як люди. Вони не мають внутрішньої мотивації виправляти власні помилки, не накопичують інтуїцію про те, що в цій конкретній кодовій базі болить найбільше. Їхня «пам’ять» — це контекст сесії, а не роки досвіду.
Звідси й фундаментальна асиметрія: люди структурно зацікавлені в зменшенні болю, тобто в зменшенні складності й підвищенні якості. Агенти — ні. Якщо не закласти цю асиметрію в процеси, системи й метрики, кодова база природно дрейфуватиме в бік все більшої складності.
«Гарні інженери часто кажуть “ні”». Агенти — майже завжди «так»
Ще одна важлива відмінність — у ставленні до нових фіч і змін. У здоровій інженерній культурі сильні розробники регулярно говорять «ні». Вони відмовляються від зайвих можливостей, ріжуть обсяг, відкладають «класні ідеї» на потім, якщо ті не вписуються в архітектуру чи не мають достатньої цінності для користувача.
Це «ні» — не прояв консерватизму, а інструмент контролю складності. Кожна нова фіча — це не лише код, а й нові стани системи, сценарії використання, гілки логіки, тестові випадки, документація, підтримка. Коли інженер каже «ні», він захищає продукт від ентропії.
Агенти ж структурно налаштовані на «так». Їхня мета — виконати запит. Якщо продакт, сейлз чи будь‑який інший користувач формулює промпт «додай ось таку фічу», агент не вступає в дискусію про пріоритети, не ставить під сумнів бізнес‑логіку, не пропонує спростити вимогу. Він генерує код.
У короткій перспективі це виглядає як магія: ідеї миттєво втілюються в прототипи, демо з’являються за години, а не тижні. У довгій — як повільна катастрофа: продукт обростає десятками напівінтегрованих можливостей, які ніхто не встиг осмислити, протестувати й вписати в загальну картину.
Саме тому Маріо й Армін так наполягають на ролі сильних інженерів із хорошим судженням. Їхнє завдання в епоху агентів — не стільки писати кожен рядок коду, скільки бути фільтром, який вирішує, які з нескінченних «так» агентів мають право потрапити в продакшен. Без цього фільтра швидкість перетворюється на хаос.
Автоматизаційне упередження: коли кілька вдалих відповідей вимикають критичне мислення
Щойно інженери отримали в руки інструменти на кшталт GitHub Copilot, стало очевидно: AI може бути надзвичайно корисним у дрібних задачах — від автодоповнення до генерації шаблонного коду. Згодом агенти навчилися більше: читати файлові системи, виконувати інструменти, змінювати код у кількох файлах одночасно. З’явилися системи на кшталт Pi, які взагалі можуть модифікувати самих себе на вимогу користувача.
На цьому тлі виникає небезпека, про яку Маріо й Армін говорять особливо різко: автоматизаційне упередження. Це психологічний ефект, коли людина починає надмірно довіряти автоматизованій системі після кількох вдалих взаємодій і поступово перестає ретельно перевіряти її результати.
У контексті AI‑коду це виглядає так: інженер кілька разів отримує від агента дуже вдале рішення, економить час, вражається «розумності» системи — і непомітно знижує планку перевірки. Рев’ю перетворюється на побіжний погляд, тести запускаються рідше, архітектурні наслідки змін не аналізуються.
Проблема в тому, що моделі не мають стабільної якості. Вони можуть видати блискуче рішення в одному контексті й небезпечну нісенітницю в іншому. Кілька вдалих відповідей нічого не гарантують щодо наступної. Але людський мозок не любить постійної настороженості: якщо інструмент «зазвичай працює», ми схильні йому довіряти.
У поєднанні з тиском на швидкість це створює ідеальний шторм. Команди, які й так поспішають, отримують інструмент, що дозволяє ще більше прискоритися, і психологічний механізм, який знижує контроль. Результат — зростання кількості великих, важких для рев’ю pull request’ів, у яких зміни агента й людини переплетені так, що розібратися складно навіть досвідченому розробнику.
Саме тому Маріо й Армін наполягають: чим потужніші агенти, тим жорсткішими мають бути процеси перевірки. Автоматизація не скасовує потребу в критичному мисленні — навпаки, робить його ще важливішим.
Коли код пишуть не інженери: нова свобода й нові ризики
Один із найрадикальніших ефектів AI‑інструментів — те, що код більше не є виключною територією інженерів. Армін відзначає, що сьогодні в багатьох компаніях у написанні коду беруть участь продакт‑менеджери, маркетинг, сейлз‑команди. Вони формулюють промпти, отримують робочі фрагменти коду, інтегрують їх у демо чи навіть у реальні системи.
З одного боку, це справді потужно. PM може швидко перевірити гіпотезу, не відволікаючи розробників. Маркетинг може зібрати інтерактивну сторінку для кампанії. Сейлз — підготувати кастомізоване демо під конкретного клієнта. Це зменшує «вузькі місця» й дозволяє експериментувати там, де раніше все впиралося в дефіцит інженерного часу.
З іншого — відкриває цілу низку нових ризиків. Армін наводить показові кейси, коли сейлз‑команди за допомогою AI будували демо‑функції, яких не існувало в основному продукті. На презентації все виглядало чудово, але за демо не стояла реальна, підтримувана інженерна реалізація. Коли ж клієнти очікували побачити ці можливості в продакшені, компанія опинялася в пастці власного «демо‑театру».
Це не просто етична проблема, а й технічна. Код, написаний людьми без інженерної підготовки, часто не враховує безпеку, масштабованість, інтеграцію з існуючою архітектурою. Навіть якщо агент генерує формально коректний фрагмент, його вбудовують у систему без належного рев’ю, тестів і документації. У результаті продукт обростає «сірою зоною» — шматками коду незрозумілого походження, за які ніхто не несе відповідальності.
Маріо й Армін не пропонують «заборонити неінженерам писати код». Навпаки, вони визнають, що ширша участь у розробці — це реальне посилення команд. Але лише за умови, що поверх цієї свободи накладені сильні процесні запобіжники: чіткі правила, що можна й не можна робити, обов’язкове рев’ю інженерами, розмежування демо й продакшену, прозорість походження коду.
Без цього AI‑демократизація програмування ризикує перетворитися на хаотичну «самодіяльність», наслідки якої доведеться розгрібати тим самим інженерам, але вже в умовах набагато більшої складності.
Pull request чи «prompt request»: як контролювати те, що створює агент
Класичний процес розробки спирається на pull request’и: конкретний набір змін у коді, який проходить рев’ю, тести й обговорення. У світі, де значна частина коду генерується агентами, цього виявляється замало. Рецензент бачить результат, але не бачить, як саме він був отриманий: які були промпти, які проміжні кроки робив агент, які компроміси приймав.
Петер Штайнбергер, творець OpenClaw, запропонував ідею «prompt request’ів» — артефактів, які фіксують не лише зміну коду, а й процес її генерації. Це дозволяє рецензенту зрозуміти, що саме було поставлено агенту як завдання, які обмеження йому задавали, як він інтерпретував контекст.
У такій моделі рев’ю перетворюється на оцінку не лише коду, а й якості постановки задачі. Це важливо, бо в епоху агентів помилка часто закладається не в реалізації, а в промпті: некоректно сформульована вимога, пропущені обмеження, невраховані частини системи. Якщо бачити лише фінальний diff, ці помилки важко виявити.
Маріо, працюючи над Pi, фактично застосовує подібний підхід на практиці. Він зізнається, що більшість pull request’ів, які генерує агент у репозиторії Pi, він просто закриває. Але це не означає, що вони марні. Навпаки, ці «наївні» реалізації служать йому базовою лінією: показують очевидний шлях, який обирає модель, висвітлюють крайні випадки, допомагають швидше побачити прості рішення. На основі цього він уже будує власні, якісніші реалізації.
Це показовий приклад того, як можна використовувати агентів без втрати контролю: не як остаточних авторів коду, а як генераторів варіантів, які сильний інженер аналізує, коригує й часто переписує. У такій конфігурації агенти посилюють людське судження, а не підміняють його.
«Повільніше» як стратегія: чому гальмувати іноді корисніше, ніж прискорюватися
На тлі загальної гонки за AI‑продуктивністю заклик Арміна «slow the F down» звучить майже єретично. Але за ним стоїть дуже прагматична логіка.
По‑перше, швидкість без контролю складності — це не прискорення, а відкладене гальмування. Кожен день, коли команда «виграє час», дозволяючи агентам безконтрольно розростати кодову базу, наближає момент, коли будь‑яка зміна стає болісною й дорогою. У якийсь момент продукт досягає стану, коли кожен новий реліз — це ризик, а не прогрес.
По‑друге, індустрія ще не виробила зрілих практик роботи з агентами. Є окремі успішні кейси, але немає усталених стандартів, як колись із CI/CD, code review чи тестуванням. У такій ситуації сліпе масштабування автоматизації — це експеримент над продакшеном користувачів.
По‑третє, якість — це не те, що можна «прикрутити потім». Якщо з перших днів AI‑інтеграції компанія не закладає процеси контролю, прозорості й відповідальності, потім їх доведеться впроваджувати в уже хаотичне середовище. Це завжди дорожче й болючіше, ніж робити правильно з початку.
Тому «сповільнитися» в інтерпретації Маріо й Арміна означає не відмовитися від агентів, а свідомо інвестувати час у:
– побудову процесів рев’ю, які враховують специфіку AI‑коду;
– визначення зон, де агенти можуть працювати автономно, і зон, де потрібен жорсткий людський контроль;
– навчання неінженерів, які тепер пишуть код, базовим принципам якості й безпеки;
– формування культури, де «я це згенерував агентом» не є виправданням, а навпаки — приводом для уважнішої перевірки.
У цьому сенсі сильні інженери з хорошим судженням стають не менш, а більш важливими. Вони — ті, хто має сміливість сказати «ні» там, де всі навколо кричать «так, ще швидше». І саме від їхньої позиції залежить, чи стане ера AI‑коду золотим віком продуктивності, чи черговим витком накопичення технічного боргу.
Висновок: AI‑код як тест на зрілість інженерної культури
Pi, OpenClaw та інші агентні системи показують, наскільки далеко просунулися інструменти розробки. Один розробник у Граці може створити самозмінний агент, який стає ядром популярного асистента. Неінженери можуть писати робочий код. Компанії можуть за лічені місяці збільшити обсяг змін у репозиторіях у рази.
Але водночас стає очевидно: технічний прогрес не скасовує базових законів інженерії. Складність залишається ворогом. Якість не виникає сама собою. Біль від поганих рішень нікуди не зникає — він лише відкладається в часі.
Маріо й Армін пропонують дивитися на AI‑агентів не як на магію, а як на потужний, але небезпечний інструмент. Він може радикально посилити сильну інженерну культуру — і так само радикально зруйнувати слабку. Різницю між цими сценаріями визначають не моделі, а люди: їхня здатність казати «ні», будувати процеси, протистояти автоматизаційному упередженню й не підміняти судження статистикою «скільки коду написав агент».
У підсумку питання звучить не «чи замінять агенти розробників», а «чи вистачить у розробників характеру й професійної гордості, щоб не дозволити агентам зруйнувати якість». І відповідь на нього, схоже, залежить від того, чи готова індустрія бодай на мить справді «slow the F down».
Джерело
Building Pi, and what makes self-modifying software so fascinating — The Pragmatic Engineer Podcast