Сповільнюйтесь, це відповідь на епоху агента

Оригінальний заголовок: Роздуми про те, як сповільнитися до біса
Оригінальний автор: Маріо Зехнер
Переклад: Пеггі, BlockBeats

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

На основі практики на передовій ця стаття пропонує тверезе відображення сучасної тенденції "агентного програмування". Автор зазначає, що агенти не вчаться на помилках так, як люди; за відсутності вузьких місць і механізмів зворотного зв'язку дрібні проблеми швидко посилюються. У складних кодових базах їхня локальна перспектива та обмежена здатність до відтворення ще більше погіршують структуру системи. Суть цих проблем полягає не в самій технології, а в тому, що люди передчасно відмовляються від судження та контролю під впливом тривоги.

Тому, замість того, щоб піддаватися тривозі з приводу того, "чи повинні ми повністю прийняти штучний інтелект", краще переглянути взаємини між людьми та інструментами: нехай агенти беруть на себе локальні, керовані завдання, тоді як проектування системи, забезпечення якості та ключові рішення залишаються в наших руках. У цьому процесі "уповільнення" стає здатністю; це означає, що ви все ще розумієте систему, можете робити компроміси та зберігати відчуття контролю над своєю роботою.

В епоху еволюції інструментів те, що дійсно є рідкістю, може бути не швидшими генеративними можливостями, а судженням про складність і твердістю у виборі між ефективністю та якістю.

Нижче наведено оригінальний текст:

Вираз на обличчі черепахи - це те, як я дивлюся на цю галузь

Приблизно рік тому з'явився справжній кодувальний агент, який міг би допомогти вам «завершити весь проект від початку до кінця». Раніше були такі інструменти, як Aider і ранній Cursor, але вони більше нагадували помічників, ніж «агентів». Нове покоління інструментів дуже привабливе, і багато людей витратили багато свого вільного часу на реалізацію всіх проектів, які вони завжди хотіли реалізувати, але ніколи не мали на це часу.

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

Під час різдвяних свят Anthropic і OpenAI також випустили деякі "безкоштовні кредити", залучаючи людей, як ігровий автомат. Для багатьох це був перший реальний досвід магії "агентного кодування". Участь зростає.

Сьогодні кодування з агентом також починає проникати в виробничі бази коду. Минуло дванадцять місяців, і ми починаємо бачити наслідки цього «прогресу». Ось мої поточні думки.

Все розвалюється

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

Я визнаю, що така ситуація існувала до появи Агента. Але зараз проблема явно прискорюється.

Ми не можемо бачити справжній стан у компаніях, але іноді виникають витоки інформації, як-от чутки про "відключення AWS через ШІ". Amazon Web Services оперативно "виправили" заяву, але потім негайно запустили 90-денний план реорганізації внутрішньо.

Сатья Наделла (генеральний директор Microsoft) також нещодавно наголосив, що все більше і більше коду в компанії пишеться за допомогою штучного інтелекту. Хоча прямих доказів немає, але є відчуття: якість Windows знижується. Навіть з деяких блогів, опублікованих самою Microsoft, здається, вони мовчки визнали це.

Компанії, які стверджують, що "100% продукту створено за допомогою штучного інтелекту", майже завжди у підсумку випускають найгірші продукти, які можна собі уявити. Не для того, щоб звинувачувати, але такі речі, як витік пам'яті на гігабайти, хаос у користувацькому інтерфейсі, відсутність функцій, часті збої... жодна з цих проблем не є тим, що вони вважали "підтвердженням якості", не кажучи вже про позитивну демонстрацію "нехай Агент зробить все за вас".

Приватне: ви все частіше будете чути від великих компаній і малих команд одне й те саме: вони потрапили в глухий кут через «агентне кодування». Без перегляду коду, передачі рішень щодо дизайну Агенту, а потім додавання безлічі непотрібних функцій — очевидно, що це не закінчиться добре.

Чому ми не повинні використовувати Агента таким чином

Ми майже повністю відмовилися від інженерної дисципліни та суб'єктивного судження, замість цього потрапивши в «залежний» спосіб роботи: є лише одна мета — генерувати якомога більше коду за найкоротший час, абсолютно не думаючи про наслідки.

Ви будуєте допоміжний шар для управління армією автоматизованих Агентів. Ви встановили Beads, але ви абсолютно не усвідомлюєте, що це по суті невидаляне «шкідливе програмне забезпечення». Ви робите це лише тому, що в інтернеті пишуть, що «усі так роблять». Якщо ви не робите це так, ви «ngmi» (не зможете досягти успіху).

Ви постійно самознищуєтесь у «петлі, як матрьошка».

Подивіться — Anthropic створив компілятор C за допомогою групи агентів, хоча зараз у нього все ще є проблеми, але модель наступного покоління обов'язково зможе це виправити, чи не так?

А тепер подивіться — Cursor створив браузер, використовуючи велику групу Агентів, хоча зараз він практично непридатний і все ще потребує періодичного ручного втручання, але модель наступного покоління, безумовно, зможе впоратися з цим, чи не так?

"Розподілений", "Ділись і владарюй", "Автономні системи", "Фабрика чорного світла", "Шість місяців на вирішення програмної проблеми", "SaaS мертвий, моя бабуся щойно створила магазин Shopify за допомогою Claw"...

Ці наративи звучать захоплююче.

Звичайно, такий підхід дійсно може "досі працювати" для вашого майже невикористовуваного (включаючи вас самих) побічного проекту. Можливо, дійсно існує геній, який може використовувати цей метод для створення не сміттєвого, дійсно корисного програмного продукту. Якщо ви така людина, то я дійсно захоплююся вами.

Однак, принаймні в моїх колах розробників, я ще не бачив дійсно ефективного випадку використання цього методу. Звичайно, можливо, ми всі просто занадто недосвідчені.

Накопичення помилок у навчанні, відсутність вузьких місць і затримка вибухів

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

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

Агенти не мають цієї здатності до навчання, принаймні, не за замовчуванням. Вони будуть повторювати одну й ту саму помилку знову і знову, і можуть навіть "створювати" чудові комбінації різних помилок на основі навчальних даних.

Звичайно, ви можете спробувати їх "навчати": написати правила в AGENTS.md, щоб вони не повторювали такі помилки; розробити складну систему пам'яті, щоб вони могли звертатися до історичних помилок і найкращих практик. Це дійсно ефективно для певних типів проблем. Але передумовою є те, що спочатку ви повинні помітити, що він зробив цю помилку.

Ключова різниця полягає в наступному: Людина є вузьким місцем; Агенти — ні.

Людина не може виплюнути двадцять тисяч рядків коду за кілька годин. Навіть із не надто низькою частотою помилок, за день можна ввести лише обмежену кількість помилок, і їх накопичення відбувається повільно. Зазвичай, коли "біль від помилок" досягає певного рівня, люди (через інстинктивну неприязнь до болю) роблять паузу, щоб виправити ситуацію. Або їх замінюють, і хтось інший їх виправляє. У будь-якому випадку, проблема вирішується.

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

Тільки одного разу, коли ви спробуєте додати нову функцію і виявите, що поточні архітектура системи (по суті, стос помилок) не може вмістити зміни, або користувачі починають люто скаржитися, тому що в останньому випуску є проблеми, або, що ще гірше, втрачені дані.

Саме в цей момент ви розумієте: Ви більше не можете довіряти цьому коду.

Навіть гірше, тисячі й тисячі модульних тестів, тестів знімків екрана, інтеграційних тестів, згенерованих Агентами, також є ненадійними. Єдиний спосіб зрозуміти, чи "система функціонує правильно" - це ручне тестування.

Вітаємо, ви загнали себе (і свою компанію) у глухий кут.

Крамниця складності

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

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

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

Це безпосередньо призводить до вищезгаданих проблем: велика кількість дублікатів коду, надмірно абстрактні структури заради абстракції, всілякі невідповідності. Ці проблеми накопичуються, у підсумку призводячи до невиправно складної системи.

Це насправді дуже схоже на код на рівні підприємства, написаний людиною. Єдина різниця полягає в тому, що цей рівень складності зазвичай є результатом багаторічного накопичення: біль розподілена між великою кількістю людей, кожен з яких не досяг порогу "необхідно виправити", сама організація має високу толерантність, тому складність і організація "співрозвиваються".

Однак у випадку поєднання людини та Агента цей процес значно прискориться. Двоє людей плюс група Агентів можуть досягти цього рівня складності за кілька тижнів.

Швидкість відкликання агентурного пошуку низька

Ви можете сподіватися, що Агенти "приберуть за вами", допоможуть вам переписати, оптимізувати та зробити систему чистішою. Але проблема полягає в тому, що вони більше не можуть цього зробити.

Тому що база коду занадто велика, а складність занадто висока, і вони можуть бачити лише частину коду. Це не просто питання недостатньо великого вікна контексту або неспроможності механізму довгого контексту перед мільйонами рядків коду. Проблема більш підступна.

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

Те, як Агент це робить, залежить від інструментів, які ви йому надаєте: це може бути Bash + ripgrep, це може бути індексований пошук у коді, служба LSP, векторна база даних...

Але незалежно від того, які інструменти використовуються, суть одна: чим більша база коду, тим нижчий рівень відкликання. А низький рівень відкликання означає: Агент не може знайти весь відповідний код і, природно, не може внести правильні зміни.

Ось чому спочатку з'являються ті незначні помилки "запаху коду": він не знайшов існуючу реалізацію, тому він винаходить велосипед заново, вводить непослідовність. Зрештою, ці проблеми будуть продовжувати поширюватися, перекриватися та переростати в надзвичайно складну "гнилу квітку".

Тож як уникнути всього цього?

Як нам співпрацювати з агентами (принаймні поки що)

Написання коду з агентами схоже на боротьбу з морським чудовиськом, з його надзвичайно швидкою швидкістю генерації коду та таким "переривчастим, але іноді приголомшливим" інтелектом, який приваблює вас. Вони часто можуть виконувати прості завдання з вражаючою швидкістю та високою якістю. Справжня проблема починається, коли у вас виникає думка: «Ця річ занадто потужна, комп'ютер, зроби роботу за мене!»

Передавання завдань самому Агенту, звичайно, не є проблемою. Зазвичай завдання для хорошого Агента мають кілька характеристик: сферу можна чітко визначити, немає необхідності розуміти всю систему; завдання замкнуте, тобто Агент може самостійно оцінити результати; результат не знаходиться на критичному шляху, це просто деякі тимчасові інструменти або програмне забезпечення для внутрішнього використання, це не вплине на реальних користувачів або дохід; або вам просто потрібна «гумова качка», щоб допомогти вам думати - по суті, взяти ваші ідеї та зіткнутися зі стисненими знаннями з Інтернету та синтетичними даними.

Якщо ці умови виконані, то це завдання, придатне для передачі Агенту, за умови, що ви, як людина, все ще залишаєтеся кінцевим контролером якості.

Наприклад, використання методу автоматичного дослідження Андреа Карпаті для оптимізації часу запуску програми? Чудово. Але вам слід розуміти, що код, який він генерує, аж ніяк не готовий до використання у виробництві. Автодослідження є ефективним, оскільки ви надали йому функцію придатності для оптимізації щодо певного показника (наприклад, часу запуску або втрат). Однак ця функція придатності охоплює лише дуже вузький вимір. Агент сміливо ігноруватиме всі показники, які не включені до функції придатності, такі як якість коду, складність системи, а в деяких випадках навіть коректність, якщо ваша функція придатності сама по собі має недоліки.

Основна ідея насправді досить проста: дозвольте Агенту виконувати нудні, непродуктивні завдання або дослідницьку роботу, яку ви ніколи не мали часу спробувати. Потім оцініть результати, виберіть дійсно розумні та правильні частини та завершіть остаточну реалізацію. Звичайно, ви також можете використовувати Агента, щоб допомогти з цим остаточним кроком.

Але те, що я дійсно хочу підкреслити: дійсно, трохи сповільніть.

Дайте собі час подумати про те, що ви робите і чому ви це робите. Дайте собі можливість сказати «ні, нам це не потрібно». Встановіть чіткий ліміт для Агента: скільки коду він може генерувати за день, кількість, яка повинна відповідати вашій фактичній можливості перегляду. Усі частини, які визначають «загальну форму» системи, такі як архітектура, API, повинні бути написані вами. Ви можете використовувати автозавершення, щоб відчути «написання коду вручну», або займатися парним програмуванням з Агентом, але головне: ви повинні бути в коді.

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

Зрештою, у вас все одно буде система, яку можна підтримувати, принаймні не гірша, ніж до появи Агента. Так, минулі системи також були недосконалими. Але ваші користувачі скажуть вам спасибі, тому що ваш продукт «працездатний», а не купа поспішно зібраного мотлоху.

У вас буде менше функцій, але вони будуть більш коректними. Навчитися говорити «ні» — це вже навичка. Ви також можете спати спокійно, тому що ви все ще знаєте, що відбувається в системі, ви все ще контролюєте ситуацію. Саме це розуміння дозволяє вам вирішувати проблему відкликання агентурного пошуку, роблячи вихід Агента більш надійним і вимагаючи менше виправлень.

Коли система виходить з ладу, ви можете забруднити руки, щоб її виправити; коли дизайн був недосконалий з самого початку, ви можете зрозуміти проблему та переробити її на кращу форму. Насправді, чи є Агент, чи ні, це не так вже й важливо.

Все це вимагає дисципліни. Все це невіддільне від людей.

[Оригінальна стаття]