«Право на помилку для AI» vs «AI пише — людина перевіряє»
Ми звикли, що людині (особливо джуну чи новій команді) треба давати право на помилку. Це єдиний спосіб навчитися. Ми створюємо для цього безпечне середовище: тестові контури, пісочниці, менторство.
Але зараз, коли ми все більше делегуємо задачі AI, я зловив себе на такій думці.
Сьогодні типовий флоу виглядає так: AI генерує код чи рішення, а людині залишається правильно поставити задачу і зробити рев’ю. Наче все логічно.
Але очевидно, що в такій системі людина стала вузьким горлечком.
Швидкість, з якою AI може генерувати рішення, вже космічна. А пропускна здатність нашого мозку для перевірки цих рішень залишилась такою ж, як і була. Ми фізично не можемо рев’ювити все.
Якщо ми хочемо дійсно нового рівня ефективності, нам потрібен інший спосіб покращувати якість рішень від AI. Без ручного контролю кожного рядка.
І тут виникає головний парадокс.
Щоб AI ставав кращим автономно, йому потрібно дати те саме «право на помилку». Йому треба дати можливість приймати рішення, імплементувати їх, отримувати фідбек від реального світу і самонавчатися на цьому.
Але як це зробити, не поклавши при цьому прод? 😅
Як побудувати систему, де AI зможе безпечно помилятися на реальних задачах, сам бачити, що метрики впали, сам відкочувати зміни і робити правильні висновки — без того, щоб за кожним його кроком стояв сіньйор із червоною ручкою?
Я щиро не знаю відповідей. Здається, нам потрібна якась зовсім інша інженерна культура і архітектура процесів. Бо парадигма «AI пише — людина перевіряє» вже скоро вичерпає свій ліміт масштабування.
Хтось вже думав у цей бік? Як ви бачите еволюцію цього процесу?
36 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівТобто ШІ що умітимуть у логіку будуть ну дууууже повільні. Додавання логіки знизить швидкість виконання. Або ні якщо буде гарна архітектура взаємодії логічних та не дуже логічних ШІ.
Це абсолютно непов’язані речі. На відміну від NN, людина навчається на досить обмеженому датасеті. Тому один приклад може навчити джуна, а не навчить нічого NN, йому треба тисячі. Більше того впливу на компанії, які навчають NN особливо немає.
Як це вирішується, наприклад, в авіації, де права на помилки немає навіть у розробника? Читаємо стандарт DO-178C, рівень A (Catastrophic), загроза життю або катастрофа: формальна верифікація, математичний доказ коректності. Тобто, потрібний фідбек може дати формальна верифікація, тоді помилка може бути лише в специфікації.
Ми дійсно мало впливаємо на компанії, що тренують базові моделі. Тому більш життєздатним виглядає фокус на локальних AI-агентах, які збирають контекст власних помилок на конкретному проєкті. Щодо DO-178C: формальна верифікація чудово підходить для авіації, але в продуктовому IT з частими релізами вона критично уповільнить time-to-market. Нам потрібні автономні рішення, адаптовані для звичайного CI/CD.
Виглядає так, що ми не можемо повпливати на виробників літаків, будемо робити власний...
Ну... в теорії може закритися тими ж агентами, питання не у часі, а в токенах. Але знову, Rust виключає певний клас помилок. Робити анотації + SMT може позакривати щось... Це не так й складно та взагалі корисно. Про звичайне CI/CD теж можна казати, що це уповільнення time-ti-market, але...
З мого спілкування з ChatGPT:
Тобто перевірка логічності відповіді ШІ є дуже дорогою операцією з точки зору використання ресурсів.
Я вже про це писав але повторюсь. Ревью ШІ кода це не те саме що ревью людського коду.
У випадку людського коду, 80% часу йде на переключення контексту, на розуміння задачі яку намагаються вирішення, на читання спек і на ознайомлення з кодобазою в яку ти залазиш раз в місяць чи навіть раз в пів року і яка вже вилетіла з твого контексту. У випадку ШІ цього немає, тому можна сказати що ревью ШІ коду мінімум в 5 раз швидше. Взагалі це швидше парне програмування а не ревью.
Хіба що річ йде про автономних агентів які підбирають задачі і генерують пул реквести. Там да, ревью буде включати всі ті ж кроки що і людського пул реквеста. А вот вайбкодинг — немає там ревью в традиційному розумінні ревью.
Думаю залежить від того що називати вайбкодінгом. Якщо давати робити великі правки і змін багато, то імхо нічим не буде відрізнятись від класичного ревью. А от якщо ставити задачі покроково з гарною ізоляцієй, то сприймається це ніби ти сам пишеш код, тільки без рук...
Дякую! Так в тому і справа, що ми якраз будуємо автономного агента. Тому це саме той другий випадок: агент приносить готовий PR, а людині треба з нуля вʼїжджати в контекст. Моі роздуми якраз про те, як архітектурно позбутися цього ручного апруву і дати агенту автономно фейлитись і навчити вчитись)
Архітектурно це модульний, слабозв’язаний, ізольований код. Чіткі границі між різними модулями системи і підмодулями в модулях. Ну і хай будують/мейнтейнять агенти ці модулі, можна не ревьювити, аби модуль задовольняв інтерфейсу і тести проходили.
А вот якісь глобальні рефакторинги, зміна цих границь між модулями, пул реквести які зачіпають кілька модулів — тут доведеться ревьювити.
В будь якому разі це не маштабується. Тим більше для інших рев’юверів PR
Тестувати на nonProd?
я думав навпаки — людина ставить і уточнює задачу .. а ші залишається генерувати код... 🤔
Так, звісно) Ви маєте рацію, черговість в топіку порушена) Сформулювати задачу -> згенерувати згенерувати код. Саме це мав на увазі)
«ШІ» не вчиться, коли ми користуємося інференсом моделей. Він використовує контекст, але це не те саме, що навчання людини, коли ми порівнюємо помилку «ШІ» з помилкою джуніора, який на цій помилці може як раз навчитися.
Це дуже важлива різниця.Вона фактично вказує на те, що таке порівняння є некоректним, а тому й не можна казати про таке саме «право на помилку», яке є ефективним інструментом для людини.
Так, ви абсолютно праві) Я й не намагаюся вдихнути в машину душу чи наділити її свідомістю. Моя головна мета підсвітити іншу проблему. Ситуація, де людина має стояти з «червоною ручкою» між кодогенерацією та деплоєм, вручну перевіряючи кожен чих це точно не те майбутнє розробки, якого особисто я хочу)
много лет назад в одной компании сео убедил заказчиков, что баги это нормально и без них не бывает, самое главное что мы их починим асап, главное сообщите. если его концепцию использовать с генерацией кода, то человек не будет стоять с красной ручкой, он просто не будет нужен
Це про те, що людина має віддати таку перевірку машині? Чи про те, що людина має залишити собі роботу зі створення коду/софту, а не лише перевіряти результат машин?
Це про делегування перевірки машині. Повертатися до виключно ручного написання коду — точно ні. Як на мене більш перспективний підхід: людина проектує архітектуру та пайплайни, а AI-агенти писали код, проганяли його через CI/CD, аналізували логи і самі фіксили баги до успішного релізу без нашого мікроменеджменту.
Мені цей дискурс невловимо нагадує XY problem.
Нескладно навести дуже багато прикладів коли неякісні рішення або діри в софті обертались для бізнесу колосальними збитками (не паперовими, типу тимчасового дампу стоків, а цілком реальними) або взагалі припиненням існування (таких меньше, але вони є). А хтось може навести приклади, щоб компанія реально а не гіпотетично на папері понесла якісь збитки через те, що не могла продукувати код достатньо швидко? Я щось навіть натяків на щось таке не чув.
Тож яку саме проблему ми намагаємось вирішити?
Історія Netscape, яка програла браузерну війну Майкрософту рахується?
А нетскейп точно-точно програв через брак якихось фіч, а не через дистрібуцію та platform power вінди? :)
Я ж тому і спитав. Звідки мені відомо, що вкладається в поняття «не могла продукувати код достатньо швидко»? Я взагалі не побачив в цьому визначенні зрозумілого сенсу. Хіба хтось пише код заради коду?
Так я приблизно це й питаю вище, хіба що іншими словами :) Бо тема зводиться до «давайте приберемо man in the loop щоб не заважати агентам писати більше коду». Писати більше коду щоб що?
В топіку йдеться про швидкість «генерування рішень», а це аж ніяк не те саме що генерування коду. Виглядає так, що ви свідомо чи несвідомо підмінили поняття. В вашій формуліровці процес дійсно виглядає трохи безсенсовним, а в формуліровці автора топіка — ні.
В топіку йдеться про
і автор жодним чином не пояснює різниці, якщо вона є. Для мене це означає, що для автора в контексті статті це синоніми. Більше того, фрази на кшталт
є додатковим підтвердженням що моє розуміння коректне, бо думати категоріями «швидко відкочувати зміни» це привілей саме нашої сфери діяльності (і то не скрізь, в якомусь медтеху з їх «два релізи на рік бо півроку триває аудит та формальності» ще піди швидко відкоти), за межами розробки софту це ненаукова фантастика.
А що, це дійсно так складно, що прямо треба пояснювати різницю? До цієї хвилини я був впевнений, що будь-кому, хто пропрацював в розробці ПЗ хоча б пару років, різниця має бути очевидною. Я був неправий?
Я так розумію ви пропонуєте від обговорення початкового питання перейти до змагань зі схоластики?
Ні, я просто намагався звернути вашу увагу на те, що ви не зовсім вірно зрозуміли сенс топіку. Але, якщо вам ця розмова не цікава, це — ваше право. :)
Доволі цікава заява від людини, яка не є автором топіку. Якщо це свідомий маневр — знімаю капелюха, пан знається на маніпулятивних техніках.
Якщо ні, єдине що маємо це дві інтерпретації. Свою інтерпретацію я пояснити можу — текст містить декілька маркерів, які однозначно прив’язують контекст саме до розробки софту, наприклад:
Це не про SDLC? А про що, вишивання хрестиком чи може лікування апендициту?
Я не маю нічого проти розмови в більш широкому контексті, але на мою думку стаття на це жодним чином не претендує.
Тисячі компаній, хто був недостатньо швидкий, не вклався в строки або бюджети і хто закрився ще на етапі стартапу.
Мені особисто здається, що все йде к тому, що людина буде контролювати дві речі:
1. Вимоги.
2. Архітектуру.
Контроль за всім іншим, в тому числі і за якістю рішення, буде поступово переміщуватися на бік агентів. Через зациклення. Аж до перевірки end-to-end сценаріїв.
І мені так само здається)
Ба більше — вже починаємо експерементувати в цю сторону
Яким чином контролювати? Писати реквести «перевір архитектуру»? ))
Це довга розмова. В два кліка не поясниш. Я нещодавно статтю на цю тему написав: dou.ua/forums/topic/58459 Там навіть посилання на живий приклад є. Він не дуже так щоб сильно досконалий, але, мені здається ідею зрозуміти можна, якщо дуже цікаво.
Писати не реквести, а правила гри. Архітектура задається через базові шаблони проєкту, налаштовані статичні аналізатори та локальний RAG-контекст. Людина формує цю екосистему, а агент використовує її для імплементації фіч. Якщо згенерований код відхиляється від патернів або тягне неправильні залежності — система автоматично реджектить коміт. Агент аналізує причину відмови і робить нову спробу. Ми делегуємо рутину генерації, але утримуємо концептуальний контроль.
Хто саме?
Мабудь кастомер та його найближчі... ні... навіть не менеджери, а технічні друзі?
Да нічого ви не утримуєте і не делегуєте.
Делегує овнер.
Безпосередньо на робітників.
Однак поки що були потрібні додаткові поверхи у вигляді технічних манагерів, лідів, хедів.
Але кількість необхідних робітників зменьшується. І надібніть в технічних менеджерах, хедах і лідах теж поступово зменьшується.