Оригінальна назва: Думки про те, щоб трохи сповільнитися
Оригінальний автор: Mario Zechner
Переклад: Peggy, BlockBeats
Редакторська примітка: У часи, коли генеративний ШІ активно входить у програмну інженерію, настрій у галузі змінюється з “вражаючої здатності” на “тривогу щодо ефективності”. Писати недостатньо швидко, використовувати недостатньо часто, автоматизувати недостатньо повно — все це, здається, викликає тиск на викидання. Але коли кодувальні агенти справді входять у виробниче середовище, починають з’являтися більш реальні проблеми: помилки посилюються, складність виходить з-під контролю, системи поступово стають незрозумілими, а підвищення ефективності не перетворюється в пропорційне підвищення якості.
Ця стаття, заснована на практиці з перших уст, пропонує спокійні роздуми про цю хвилю “агентного кодування”. Автор зазначає, що агенти не навчаються на помилках, як це роблять люди, і в умовах відсутності вузьких місць і механізмів зворотного зв’язку дрібні проблеми швидко посилюються; а в складних кодових базах їх локальна перспектива та обмежені можливості відгуку ще більше підсилюють хаос у структурі системи. Суть цих проблем не в самій технології, а в тому, що люди, керуючись тривогою, надто рано передають судження та контроль.
Таким чином, замість того щоб потрапляти в тривогу “чи потрібно повністю прийняти ШІ”, краще переналаштувати відносини між людиною та інструментами: дати агентам виконувати часткові, контрольовані завдання, а системний дизайн, якість контролю та ключові рішення тримати у своїх руках. У цьому процесі “сповільнитися” стає навичкою, що означає, що ви все ще розумієте систему, можете робити вибір і все ще маєте відчуття контролю над роботою.
В епоху постійної еволюції інструментів справжнім дефіцитом, можливо, є не швидші можливості генерації, а здатність судити про складність і стійкість у виборі між ефективністю та якістю.
Нижче наведено оригінал:
Обличчя черепахи — це вираз, з яким я дивлюсь на цю галузь
Приблизно рік тому з’явилися кодувальні агенти, які справді можуть допомогти вам “зробити повний проект з початку до кінця”. Раніше були такі інструменти, як Aider, ранній Cursor, але вони більше нагадували помічників, а не “агентів”. Нове покоління інструментів надзвичайно привабливе, багато людей витратили чимало свого вільного часу, щоб реалізувати проекти, які вони завжди хотіли зробити, але не мали часу.
Я вважаю, що в цьому немає нічого поганого. Займатися чимось у вільний час — це завжди приємно, і зазвичай не потрібно так вже й турбуватися про якість коду та зручність його обслуговування. Це також дає вам шлях для навчання новій технологічній стека.
Під час різдвяних свят Anthropic і OpenAI також випустили деякі “безкоштовні кредити”, які привабили людей, як ігрові автомати. Для багатьох це був перший справжній досвід “Агенти пишуть код”. Кількість учасників зростала.
Сьогодні кодувальні агенти також починають входити до виробничих кодових баз. Минуло 12 місяців, і ми починаємо бачити наслідки цього “прогресу”. Ось мої думки на даний момент.
Все пішло шкереберть
Хоча більшість із цього є лише досвідом, сучасне програмне забезпечення дійсно справляє враження “може зламатися в будь-який момент”. 98% доступності стає нормою, навіть великі сервіси не є винятком. Інтерфейси користувача переповнені різноманітними абсурдними помилками, які QA-команда змогла б виявити з легкістю.
Я визнаю, що ця ситуація існувала ще до появи агентів. Але тепер проблема явно прискорюється.
Ми не бачимо реальної ситуації в компаніях, але іноді з’являється деяка інформація, що просочилася, наприклад, чутки про “вимкнення AWS через ШІ”. Amazon Web Services потім швидко “виправили” цю заяву, але незабаром після цього розпочали внутрішній 90-денний план реструктуризації.
Satya Nadella (генеральний директор Microsoft) нещодавно також постійно підкреслює, що в компанії все більше коду пишеться ШІ. Хоча немає прямих доказів, дійсно є відчуття, що якість Windows погіршується. Навіть з деяких блогів, опублікованих самою Microsoft, здається, що вони також підтверджують це.
Ті компанії, які стверджують, що “продукт на 100% створено ШІ”, зазвичай випускають найгірші продукти, які можна собі уявити. Не маючи на увазі конкретних людей, але постійні витоки пам’яті на рівні ГБ, плутанина в UI, неповноцінні функції, часті збої… все це абсолютно не є “якісним підтвердженням”, і тим більше, не є позитивним прикладом “дозволити агенту робити все за вас”.
На приватному рівні ви все частіше чуєте, що як великі компанії, так і малі команди кажуть одне: вони вже зазнали краху через “кодування агентами”. Без кодової перевірки, передавши дизайнерські рішення агенту, і наваливши купу непотрібних функцій — результат, природно, не буде хорошим.
Чому ми не повинні так використовувати агентів
Ми майже відмовилися від усіх інженерних дисциплін і суб’єктивних суджень, замість цього потрапивши в “аддиктивний” робочий стиль: єдина мета — згенерувати максимальну кількість коду за найкоротший час, а наслідки повністю ігноруються.
Ви створюєте шар оркестрації, щоб керувати армією автоматизованих агентів. Ви встановили Beads, але абсолютно не знаєте, що це по суті майже “незнищуване шкідливе програмне забезпечення”. Лише тому, що в інтернеті сказали, що “всі так роблять”. Якщо ви цього не зробите, “ви програєте” (ngmi).
Ви постійно “вичерпуєте себе в циклі”.
Дивіться — Anthropic створили компілятор C за допомогою групи агентів, хоча зараз є ще проблеми, але наступне покоління моделей точно зможе це виправити, вірно?
Подивіться ще раз — Cursor створили браузер за допомогою великої кількості агентів, хоча зараз він в основному непрацює і потребує періодичного ручного втручання, але наступне покоління моделей точно впорається, вірно?
“Розподілені”, “діліть і володарюйте”, “автономні системи”, “чорні фабрики”, “проблеми програмного забезпечення вирішуються за шість місяців”, “SaaS мертві, моя бабуся щойно створила Shopify за допомогою Claw”…
Ці наративи звучать чудово.
Звичайно, цей підхід може спрацювати для вашого проекту, яким майже ніхто не користується (включаючи вас самих). Можливо, дійсно існує якийсь геній, який може створити непогане програмне забезпечення, що дійсно використовується людьми. Якщо ви це робите, я щиро вас поважаю.
Але, принаймні в колі розробників, які я знаю, я ще не бачив справжніх успішних прикладів використання цього методу. Звісно, може бути, що ми всі просто недостатньо досвідчені.
Помилки накопичуються в умовах відсутності навчання, вузьких місць і затримок
Проблема агентів полягає в тому, що вони можуть помилятися. Це саме по собі не є нічим поганим, адже й люди помиляються. Це можуть бути просто деякі помилки правильності, які легко виявити й виправити, а потім ще й додати регресійні тести для стабільності. Це також можуть бути деякі “аромати” коду, які не вловлює лінтер: тут зайвий метод, там нерозумний тип, а також повторюваний код тощо. Ці окремі проблеми не є фатальними, люди-розробники також можуть робити такі дрібні помилки.
Але “машини” не є людьми. Люди після кількох повторних помилок зазвичай вчаться не повторювати їх — або їх виховують, або вони змінюються в процесі навчання.
А агенти не мають такої навчальної здатності, принаймні, за замовчуванням не мають. Вони постійно повторюють одні й ті ж помилки, і навіть можуть “створити” різні помилки на основі навчальних даних.
Звісно, ви можете намагатися “тренувати” їх: написати правила в AGENTS.md, щоб вони більше не допускали таких помилок; розробити складну систему пам’яті, щоб вони могли звертатися до історичних помилок і кращих практик. Це дійсно працює для деяких специфічних типів проблем. Але передумова полягає в тому, що ви спочатку повинні зафіксувати, що агент допустив цю помилку.
Ключова різниця полягає в тому, що люди є вузьким місцем, а агенти — ні.
Люди не можуть за кілька годин написати двадцять тисяч рядків коду. Навіть якщо частота помилок не низька, за день можна внести лише обмежену кількість помилок, а накопичення цих помилок відбувається повільно. Зазвичай, коли “болі від помилок” накопичуються до певного рівня, люди (керуючись інстинктивним відразою до болю) зупиняються, щоб виправити їх. Або ж людина замінюється, і хтось інший виправляє. В будь-якому випадку, проблема буде вирішена.
Але коли ви використовуєте цілу оркестровану “армію” агентів, немає вузьких місць, і немає “відчуття болю”. Ці спочатку незначні помилки накопичуються з неприпустимою швидкістю. Ви вже вийшли з циклу, і навіть не знаєте, що ці на перший погляд безневинні дрібниці перетворилися на величезну проблему. Коли ви зрештою відчуваєте біль, зазвичай вже занадто пізно.
Одного дня ви хочете додати нову функцію, але виявляєте, що поточна архітектура системи (по суті, вже є нагромадженням помилок) не може підтримувати зміни; або користувачі починають скаржитися, тому що останній реліз виявився проблемним, навіть призвів до втрати даних.
Тоді ви усвідомлюєте: ви вже не можете довіряти цьому коду.
Ще гірше, тисячі юніт-тестів, тестів знімків, тестів “кінцевої точки”, згенерованих вашим агентом, також більше не є надійними. Єдиний спосіб перевірити, чи “система працює нормально”, залишився — ручне тестування.
Вітаємо, ви завели себе (і компанію) в глухий кут.
Торговець складності
Ви повністю не знаєте, що відбувається в системі, адже передали контроль агентам. А агенти, по суті, “торгують складністю”. Вони бачили безліч поганих архітектурних рішень у навчальних даних і постійно підсилюють ці моделі в процесі навчання з підкріпленням. Ви просите їх спроектувати систему, і результат, зрозуміло, не може бути добрим.
В результаті ви отримуєте: цілу набір надзвичайно складних систем, переплетених із різними “найкращими практиками галузі”, які погано імітуються, і до того ж ви не наклали жодних обмежень до того, як ситуація вийшла з-під контролю.
Але проблема на цьому не закінчується. Ваші агенти не діляться між собою виконанням процесів і не бачать повної кодової бази, не розуміють рішень, прийнятих вами чи іншими агентами. Отже, їхні рішення завжди є “локальними”.
Це безпосередньо призводить до тих проблем, про які ми згадували раніше: величезна кількість повторюваного коду, структури, створені лише для абстракції, різні невідповідності. Ці проблеми постійно накопичуються, в результаті утворюючи незворотну складну систему.
Це насправді схоже на корпоративні кодові бази, написані людьми. Лише ця складність зазвичай є результатом багаторічного накопичення: біль розподіляється серед багатьох людей, кожен з яких не досягає критичної точки “необхідності виправлення”, а терпимість самої організації досить висока, отже, складність “співіснує” з організацією.
Але в комбінації людини та агента цей процес значно прискорюється. Двоє людей і купа агентів можуть досягти такої складності всього за кілька тижнів.
Агентний пошук має низький коефіцієнт відгуку
Ви можете сподіватися на агентів, щоб “прибрати безлад”, допомогти вам з рефакторингом, оптимізацією, зробити систему чистою. Але проблема в тому, що вони вже не можуть цього зробити.
Оскільки кодова база надто велика, а складність занадто висока, і вони завжди можуть бачити тільки локальні частини. Це не просто питання недостатньої контекстної вікна або вичерпання довгих контекстних механізмів перед мільйонами рядків коду. Проблема є більш прихованою.
Перед тим, як агенти намагатимуться виправити систему, вони спочатку повинні знайти весь код, який потрібно змінити, і вже наявні реалізації, які можна повторно використовувати. Цей етап ми називаємо агентним пошуком.
Як агенти виконують це завдання, залежить від інструментів, які ви їм надаєте: це може бути Bash + ripgrep, запитуваний кодовий індекс, LSP-сервіс, векторна база даних…
Але незалежно від того, які інструменти використовуються, суть залишається такою ж: чим більша кодова база, тим нижчий коефіцієнт відгуку. А низький коефіцієнт відгуку означає, що агенти не можуть знайти весь відповідний код, отже, не можуть внести правильні зміни.
Це також пояснює, чому спочатку виникають ті “аромати” коду: вони не знайшли вже існуючу реалізацію, тому й повторно винайшли колесо, що призводить до невідповідностей. Врешті-решт, ці проблеми постійно поширюються, накопичуються, утворюючи надзвичайно складну “погану квітку”.
Отже, як ми можемо уникнути всього цього?
Як ми повинні співпрацювати з агентами (принаймні наразі)
Кодувальні агенти схожі на сирен, притягуючи вас своєю надзвичайною швидкістю генерації коду та “переривчастим, але часом вражаючим” інтелектом. Вони часто можуть виконувати деякі прості завдання з вражаючою швидкістю і якістю. Справжні проблеми починають виникати, коли у вас виникає думка — “цей інструмент настільки потужний, комп’ютере, зроби це за мене!”
Доручати завдання агентам саме по собі не є проблемою. Хороші завдання для агента зазвичай мають кілька характеристик: обсяг можна чітко визначити, не потрібно розуміти всю систему; завдання має бути замкнутим, тобто агент може оцінити результати самостійно; вихід не є критичним для основних процесів, а лише тимчасовими інструментами або програмами для внутрішнього використання, які не впливають на реальних користувачів або дохід; або ж ви просто потребуєте “гуся” для допомоги в роздумах — по суті, це ваші ідеї, які потребують зіткнення з узагальненими знаннями та синтетичними даними з інтернету.
Якщо ці умови виконуються, тоді це завдання, яке підходить для передачі агенту, за умови, що ви, як людина, все ще є фінальним контролером якості.
Наприклад, використання методу авто-дослідження, запропонованого Андреєм Карпатієм, щоб оптимізувати час запуску програми? Чудово. Але передумова в тому, що ви розумієте, що код, який він згенерує, абсолютно не має виробничої придатності. Авто-дослідження є ефективним, оскільки ви надали йому функцію оцінки, яка дозволяє йому оптимізувати навколо певного показника (наприклад, часу запуску або втрат). Але ця функція оцінки охоплює лише дуже вузьку область. Агент буде з упевненістю ігнорувати всі показники, які не входять до функції оцінки, такі як якість коду, складність системи, навіть у деяких випадках може ігнорувати правильність — якщо ваша функція оцінки сама по собі має проблеми.
Основна думка насправді дуже проста: дайте агентам виконувати ті нудні, без навчання новим речам завдання, або ті дослідницькі роботи, на які у вас просто не було часу спробувати. А потім ви оцінюєте результати, вибираєте дійсно раціональні й вірні частини, а потім завершуєте остаточну реалізацію. Звісно, останній етап ви також можете виконати за допомогою агентів.
Але я хочу підкреслити: дійсно, настав час сповільнитися.
Дайте собі час поміркувати, що саме ви робите і чому. Дайте собі можливість сказати “ні”: “ні, це нам не потрібно”. Встановіть агенту чітку межу: скільки коду йому дозволено генерувати щодня, ця кількість повинна відповідати вашій реальній можливості перевіряти. Усі рішення, що визначають “загальну форму системи”, такі як архітектура, API тощо, повинні бути написані вами особисто. Ви можете використовувати автоматичне доповнення, щоб відчути “смак ручного коду”, або працювати в парі з агентом, але ключове: ви повинні бути в коді.
Адже особисте написання коду або спостереження за його поетапним створенням приносить певний “тертя”. Саме це тертя допомагає вам краще усвідомити, що ви хочете зробити, як працює система, і як виглядає загальний “досвід”. Це те місце, де досвід і “смак” грають роль, а це те, чого нинішні найсучасніші моделі ще не можуть замінити. Сповільнитися, витримати трохи тертя — це ваш спосіб навчання та розвитку.
В кінцевому підсумку ви отримаєте систему, яка все ще є легкою у обслуговуванні — принаймні, не гіршою, ніж до появи агентів. Так, минулі системи теж не були досконалими. Але ваші користувачі будуть вдячні вам, тому що ваш продукт “зручний у використанні”, а не купа безглуздого сміття.
Ваша функціональність буде меншою, але більш правильною. Навчитися говорити “ні” — це вже навичка. Ви також зможете спокійно спати, адже принаймні ви знаєте, що відбувається в системі, і все ще контролюєте ситуацію. Саме це розуміння дозволяє вам компенсувати проблеми з відгуком агентного пошуку, роблячи вихід агента більш надійним і потребуючим менше виправлень.
Коли система має проблеми, ви можете особисто втрутитися; коли дизайн спочатку був неналежним, ви також зможете зрозуміти, у чому проблема, і перетворити його на кращу форму. Щодо наявності агентів, це насправді не так важливо.
Усе це потребує дисципліни. Усе це не обходиться без людей.
[Посилання на оригінал]
Натисніть, щоб дізнатися, що BlockBeats шукає вакансії
Ласкаво просимо приєднатися до офіційної спільноти BlockBeats:
Telegram підписка: https://t.me/theblockbeats
Telegram група: https://t.me/BlockBeats_App
Twitter офіційний аккаунт: https://twitter.com/BlockBeatsAsia
