Дядько Боб не робить рев’ю ШІ-коду. Натомість він влаштовує йому смугу перешкод
Натрапив на свіжий тред від Роберта Мартіна (або ж, як його іноді називають — Дядька Боба, який написав «Сlean Code» і подарував світу принципи SOLID). У своєму X він сказав, що взагалі не читає код, який пишуть його ШІ-агенти.
Але не все так просто, як може здатися на перший погляд.
«Я значно старший за вас. Я почав програмувати наприкінці60-х. Моя нинішня стратегія — не читати жодного рядка коду, написаного моїми агентами. Це єдиний спосіб скористатися перевагами їхньої продуктивності. Натомість я оточую агентів екстремальними обмеженнями».
Чому читати дифи більше не має сенсу
Мартін пояснює свою філософію дуже просто. Якщо ви змушені читати та рев’ювити кожен рядок за агентом, то ваша загальна пропускна здатність впирається у вашу ж швидкість читання. У такому разі весь сенс делегування завдань ШІ просто зникає, адже ви витрачаєте стільки ж часу на перевірку, скільки витратили б на написання чи дебаг вручну.
Тому він вирішив перенести точку людського контролю на рівень вище. Замість колупання в самій реалізації він пропонує фокусуватися на специфікації та правильній поведінці системи.
Як влаштовані його процеси
За логікою Роберта весь робочий процес ділиться на чіткі зони відповідальності залежно від того, навіщо потрібен конкретний артефакт.
«Мої агенти пишуть юніт-тести. Я їх не перевіряю. Вони також пишуть приймальні тести на Gherkin та процедури QA. Їх я перевіряю. Іноді ретельно, а іноді — вибірково, залежно від критичності. Також я періодично проводжу фінальне ручне тестування».
Тут можна виділити три основні рівні нагляду:
- Сам код реалізації та юніт-тести повністю віддаються агентам. Людина туди взагалі не лізе, бо це низькорівневі деталі, які ШІ здатний контролювати від початку до кінця і перевірка яких дає мінімум користі.
- Приймальні тести на Gherkin та процедури QA пише агент, але рев’ювить Мартін. Саме в цих артефактах зашито розуміння того, що взагалі є правильною роботою з точки зору бізнесу. Їх він перевіряє або дуже ретельно, або вибірково, залежно від критичності фічі.
- Фінальне ручне тестування проводиться особисто розробником, але лише періодично.
Чому обмеження важливіші за прибирання постфактум
Коли Мартіна запитали, чому б просто не давати агентам писати що завгодно, а потім змушувати їх прибирати за собою, він відповів, що брудний код дуже сильно сповільнює самих агентів. Він спостерігав, як нейронки починають борсатися у власних милицях і застрягають у нескінченних циклах самовиправлення, не в змозі знайти вихід. У результаті йому доводилося втручатися й розплутувати ці спагеті вручну.
«Я думаю, це досі має значення, і значення величезне. Брудний код сповільнює моїх агентів. Я бачив, як вони борсаються у власному безладі, не в змозі його вирішити. Зрештою мені доводилося втручатися й розплутувати їхню ж плутанину. Тому я не дозволяю їм створювати ці клубки. Я жорстко обмежую розмір та складність функцій».
Тому його головне правило — жорсткі архітектурні обмеження на самому старті. Мартін налаштовує лінтери, метрики аналізу та інструменти контролю покриття так, щоб агент технічно не міг створити функцію на п’ятсот рядків чи з якимось оверіжирінгом.
Що думаєте про такий підхід? Завжди перевіряєте ШІ-код перед відправкою чи іноді грішите? І що вам легше дається: писати код самостійно чи рев’ювати його?
44 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарівЯкщо чесно, це виглядає як AI-сміття, де АІ просто бере твіт на 100 символів і розтягує його зміст на цілу сторінку, не додаючи жодної нової цінності.
все правильно делает, прислали пулл реквест из спагетти, который видно что тупо написан бестолковыми LLM, взял и закрыл.
Раньше были быдлокодеры, теперь они в руки получили легкий инструмент, который высирает спагетти любой глубины и сложности и слопами закрывают таски. На сложной бизнес-логике LLM генерирует лютое говно, потому что не знает как правильно надо делать и ему плевать на побочные сайд-эффекты
Я не маю якогось важливого досвіду в розробці з ШІ, без ШІ, рев’ю тощо, але не розумію, чому такі «негативні» коментарі. Як на мене, у статті просто стисло розповідається про підхід і сказано, що за належного контролю самого ШІ деякі речі можна не перевіряти.
Для мене, як для людини без досвіду, це виглядає так: якщо вам дають задачу і кажуть, що має бути, ви маєте все це додати. Якщо у вас не виходить, вам можуть підказати, як це зробити, і ви стаєте на правильний шлях. У його випадку ці підказки даються одразу як сама вимога.
ШІ хоч і тупить, але часто виконує все так, як йому кажуть. Тупити він починає тоді, коли йому кажеш: «зроби метод для відправки повідомлень», не вказуючи спосіб реалізації. Гадаю, проблема більшості коментаторів пов’язана із замалим контекстом, і Мартін саме про це каже. ШІ, як-не-як, просто помічник для написання простого, повторюваного коду. Unit-тести він віддає агентам повністю, а ось приймальні тести, QA-процедури та фінальне ручне тестування залишає під своїм контролем.
Хоча, скоріше, у великих проєктах виникнуть проблеми, але, думаю, його думка цілком адекватна. Ба більше, я повністю згоден з підходом до виправлення помилок. Я робив навчальний проєкт із ШІ, у нас часто виникали помилки, і чим більше ми намагалися їх полагодити, тим гірше ставало. Я багато тестував вручну, тому, коли знаходив помилку, відкривав той шматок коду і казав, що саме потрібно виправити. Тоді помилка зникала.
Я не знаю, наскільки це вдале рішення, але цілком погоджуюся з його думкою. Наскільки я зрозумів, він не пропонує сліпо вайбкодити, а говорить про правильне формування контексту та контроль результату. Якщо ні, то буду радий почитати, у чому помиляюся.
То есть он пишет о том, что плохой код негативно влияет на дальнейшую работу AI и при этом он рекомендует не читать код и полагаться на линтеры?
Что мешало такой же подход использовать с людьми? Типа ставишь линтеры, не делаешь код-ревью и всю нагрузку кидаешь на тестировщиков, что бы те искали баги...
Боб шарит, но в этом конкретном случае подход выглядит странно.
AI можно использовать не вместо тебя, а в дополнение, он шикарно справляется с поиском расхождений, подготовкой тест кейсов, копированием реализации между платформами (iOS/Android/Web), ну и да, частенько пишет рабочий код, а еще чаще плохой код выдает за хороший — вот для этого и нужно ревью, особенно если мы говорим про критический функционал которым пользуются миллионы пользователей, а не пет-проект.
«выдаёт плохой код за хороший» — это как Вы определяете? ИИ как раз пишет «визуально» хороший код, главное коварство в том, что ИИ не чувствует приоритеты и ошибается в реализации именно в том, на чём нужно было заострить внимание. А касательно использования паттернов, SOLID и прочего ИИ почти не ошибается. Сеньоры ошибаются гораздо чаще в этом, просто потому, что они люди.
Я скорей не про визуал кода, а его значимость) ИИ любит насыпать лишнего, сделать из элегантного решения сложное, написать тесты которые и не нужны вовсе потому что ничего нового не тестят, и тд.
Это всё можно регулировать скилами, но даже в этом случае срабатывает теория разбитого окна — стоит один раз написать чушь, и ИИ охотно подхватит это за новую норму. И да, разработчики любого уровня тоже склонны писать чушь, именно по этому и был придуман процесс код-ревью. Так что выбросить код-ревью из процесса разработки для меня звучит странно, и не важно с ИИ мы пишем код или с синьорами-помидорами.
По тестам кстати говоря — намного лучге чем человек делает, если изначально правильный и формализованный промпт. ИИ инструмент опеатора, а не полностью автоматическая машина (когда будет достигнуто второе, профессия программиста действительно исчезнет, хотя это будет уже вселенная из Terminator 2).
По тестам я для себя определил, что с ИИ нужно юзать TDD и заставлять писать тесты до реализации, это значительно сокращает количество ненужных тестов + лучше пишет реализацию (чисто что бы покрыть тесты)
в таком случае он начинает придумывать кейсы, которые не могут быть, что в итоге потом ведёт как раз именно к ненужному усложнению кода :)
ну, здесь соглашусь. Оверкомпликейт для кода это тоже из серии «не чувствует».
Потому что только мы, как разрабы, можем чувствовать, куда в будущем код может развиваться и соответственно, где какие решения/паттерны лучше применить, а где они излишни
а вообще мне тоже код-ревью выкинуть не заходит. Я чувствую какую-то неуверенность в этом и не могу это сделать. Может, пока что.
Человек пока эффективнее потому что у нас есть страх плохо сделанной работы, и каждого можно уволить.
Как результат — у нас есть что терять, а ИИ просто скажет «извини, ты был прав», мне лично такой уровень ответственности не подходит 😅
в целом, ИИ тоже неплохо ревьювит, но даже ревью с помощью ИИ (и даже ревью самого ревью) меня не удовлетворяет, пока я не пробегусь глазами по коду. И не нужно меня тут подгонять (как часто любят)
боб спробував завантажити всі свої монографії в контекст, але не допомогло
there must be a way...
а что этот дедушка в маразме пишет? трекер финансов для своей бабушки?
давайте его потуги зальем на прод, так, чтобы от работы этого дела зависел бы оборот компании ну хотя бы в несколько миллионов долларов в месяц.
только что закончил изучать продукты жизнедеятельности таких вот любителей новых революционных подходов. агенты нагенерили 360 килобайт юнит тестов, которые вообще ничего не тестируют.
Ну сорян, наши колеги из Индии и не только, тоже самое делали к тому же и писали специально кучу кода, ктотрый после реверс инжинеринга оказывалось просто бенчмарком для памяти и процессора. Я реально бывало выкидывал вызов на странные «поделки» в3-4 тысячы строк кода в легаси проектах, которые не несли вообще никакой смысловой нагрузки. Оказалось индийцам в свое время их вендоры платили за количество написанных операторов и они туда писали бенчмарки, причем бангалорскими паттернами — чтобы по больше заработать. Впрочем и нам давали заработать через лет так 8-10 уже, когда клиент платил за оптимизацию.
Кстати сейчас ИИ умеет реально рефакторить спагетти гомнокод, если его попросить правильно. Реверс инженеринг тех миллилнов строк кода, который удавлось сделать индусам введу ИТ менеджерского провала в США в эпоху доткомов и после, отнимал очень много ментальных усилий.
я бы слегка скептически воспринимал тейки о том, как пишет код73-летний лидер мнений, у которого внезапно тейки совпадают тейками маркетинга вендоров токенов
спасибо редакции доу за прекрасную статью!
Виглядає що всім нам так прийдеться трансформуватись. Хоча це і забирає фан з професії.
фан також трансформується
чим більше юзавємо АІ, тим більше починаємо цінувати якісну документацію
ще додати до Gherkin сценаріїв приорітизацію по must/should/nice to have щоб АІ-шка не займалась фігнею і не шукала якісь edge-case або сценарії які нафіг нікому не потрібні, буде топчик
а то якщо запитати АІ-шку про тестування або імлементацію і не дати нормальних обмежень, то там кожна сторя має 10 AC і кожна фіча має весь функціонал на світі одразу
Я вот зараз ревьювлю пул реквест сінйора-principle, який поки скептично відноситься до ШІ і використовує його по мінімуму. Пул реквест пройшов кілька ревью одного сінйора, який любить ШІ і по-любому поганяв пул реквест через ШІ ревью.
Но я, вже 4 рази його завернув, так як мій ревью агент продовжує знаходити доволі серйозні баги і доволі реальні ейдж кейси, які через пару місяців — рік по-любому вилізуть. Сам би я без ШІ з першого чи другого разу запрувив.
Висновки:
1. ШІ код ревью маст хев, ніякий сінйор з ним не зрівняється в плані багів, регресії, перфоманса.
2. Не всі ШІ based ревью скіли/агенти одинакові — якщо гівняний скіл отримаєш гівняне ревью з придирками до стилю но без знайдених багів
3. Якби оригінальний автор використовував ШІ, не тратив би мій час і час інших сінйорів на ревью
Чому просто не додати в CI ревю від агента? Тоді таких проблем не виникне.
Тільки бажано мати різні моделі під роботу і під ревью. Помітив, що модель яка писала код — легко може прогавити свої баги на ревью. Навіть якщо ревью це окремий контекст, окремий діалог
Як ти це собі уявляєш? Claude пише код, а Codex перевіряє?
Як приклад: Antropic Opus пише, Kimi або Gemini перевіряє. Не розумію здивування (модель і інструмент це різні речі, якщо що. codex — інструмент, opus, kimi — моделі)
Мені на роботі не проплачують за різні підписки. Тому і здивування.
норм підхід, я використовував Cursor Bot, який використовував кілька моделей і писав рев’ю відразу в PR.
зазвичай в підписку входить декілька моделів. Як мінімум, одного виробника (наприклад Anthropic Opus і Sonnet). Бажано взагалі від різних виробників брати, але навіть так краще, ніж одною й той самою і писати, і рев’ювіти (хоча і тут можна погратися і мати непоганий успіх)
Дивна ідея, мені не подобається.
Не бачу такої великої різниці в ревю однієї моделі іншою. Ну в межах особливості конкретних моделей, але не більше.
Без людини яка буде апрувити результати рев’ю агента це може бути проблемою.
ЛЛМки та агенти, як їх похідне, часто не вміють зупинятися і люблять додавати і додавати.
Ваш продукт може бути розрахованим на 1000 клієнтів максимум одночасно, а агент заверне пул-реквест чергової фічі із коментарем «це не витримає навантаження в 100 000 клієнтів», а така переробка може потягнути рефакторинг всієї архітектури, але вам це не потрібно бо навряд ви досягнете цього.
Приклад надуманий і пальцем в небо, але, сподіваюсь, ідея зрозуміла.
Можете заперечити, що подібні умови можна прописати в системних інструкціях до агента, але, по-перше, всі подібні кейси передбачити майже неможливо, а по-друге продукти розвиваються і треба буде оновлювати такі інструкції кожного спринта або навіть частіше.
Я про те, що таке ревью це просто додатковий крок пайплайну.
Не треба відміняти стандартний ревью процес, його треба доповнювати.
І нормально воно там знаходить помилки, головне щоб знайдені пункти були класифіковані по впевненості та важливості.
Для цього не треба промпти міняти кожен тиждень. Наразі моделі досить потужні, щоб знаходити багато чого навіть без додаткової бази знань по проекту/технології.
А якщо ще є додаткова специфічна база знань яка постійно поповнюється то взагалі цукерка.
Так, як крок для пайплайну по відлову дурних помилок — погоджуюсь, має сенс.
Інша справа, що якщо кожен дев кодить із агентом, який пише 90%+ коду, то таких помилок майже ніколи і не виникне, і все, що нам треба робити — це перевіряти на рев’ю, аби АІ не відхилився від наміченої архітектури і досягнення потрібних нам бізнес-задач, а не досягнення чогось свого.
це прописується в реквайременти ШІ-аналізатора (або підкидується йому з constitution того ж SpecKit) і ця проблема вирішена
це єдиний спосіб розробки, який має майбутнє. Але доки не зʼявились IDE вищого рівня, які дозволяють легко і зручно оперувати специфікаціями, архітектурою і тестами прийомки, треба мати сувору дисципліну щодо описаного процесу. Будь який крок в сторону, і ти опиняєшся серед проблем описаних в решті коментарів до цього посту.
Я одного разу теж так зробив в робочому проєкті. Виставив Treat warnings as errors= true, підключив купу аналізаторів. Агент 5 годин довбався і спалив майже всі токени .
Два харнеса цьому пану! ))))
зате Альтман і Даріо аплодують стоячи)
А ще Карпати та Черний! :))
Воно то та, але питання а хто буде за це все платити. Якщо агента занесло чи специфікація змінилась, це буде дуже дорого змінити
В тіхаря посадять кодомеса ревьювати оці тонни спек та ПР-ів, але тік ні кому не кажіть, у нас тут ШІ автоматизація і ШІ всих замінв ))))
Я тільки вчора закінчив виправляти помилки після людини яка не читає свій код. У файлах локалізації було сумарно близько 22 000 помилок. Рев’ю результатів після агента — це Must have. Особливо, якщо людина не зовсім розуміє що вона робить. С або Агент пише код на такому рівні, який не є базовим, зрозумілим для оператора.
youtube.com/...nAwSA?si=yabl2X2fq4D5kqlp
Як це стільки вийшло, кошмар. А рев’ю інший ШІ-агент допомагав робити?
та яке там рев’ью)
з того що там було:
— мікс ключів з мобільного додатку з дашбордом у рендомній послідовності.
— ключі типу «просто фраза якась» — що як би каже про те, що зміни перед коммітом навіть не перевірялись)
— ключі з «Å, Ä» і так далі.
— ключі тільки у baseline мові
— практично усе було з fallback value у коді, тому типу працювало)
за допомогою AIшки переписав старий варіант, який перевіряв тільки формат тексту (параметри для підстановки значень у рантаймі) та що б ключі були однакові по кількості у всіх мовах по групам.
Тепер аналізує статично код проекту кожного, шукає де юзалось, робить fix автоматом. Я 100% не перевіряв, ще треба дивитись що там до чого у фіналі вийшло, але так на перший погляд навіть ключі типу somedata.+enum.value вміє розпізнавати і навіть по стеку іде вгору, якщо у функцію передали ключ у якості параметра.
Проблема з зими висіла, у мене депресія була коли я намагався охопити весь об’єм безладу.
PS ~22к помилок — це сумарно по усім мовам, унікальних було може пару тисяч. Зате тепер жорстка валідація на пр.
Нажаль погана ідея не дивлячись, що Дядько Боб один із співавторів XP взагалі і автоматизованного тестування, зокрема дідуся сучасних фреймверків — Fitnesse. Мені після ревью доводиться робити суттєво поправок в промти, та додаткові уточнюючі промпти, щоб отримати те — що я хочу в кінцевому на низькому рівні.
А от, що дійсно цікаво — нормально працює ситуація коли ШІ робить сам ревью.
І що більш цікаво, люди часто займаються політикою на код ревью, бо це засіб спілкування, а ви маєте справу із гомінідом породи хомо сапієнс, який на 75% керується гормонами інстинктами та швідкісною системою прийняття рішень. В половині випадків ревью перетворюється на Holly wars, де під низом політика.
ШІ робить ревью якісно інакше, ближче до розширеного статичного аналізу, підсвічує антипатерни, не ефективні та наївні алгоритми, прогалини в безпеці і т д.. Хоча разом з тим, ще генерує і слоп сміття та fakse positive.
Тому, якраз саме ревью, дуже класно автоматизується, і вже можна робити ревью з гори ревью виявляючи False- positive.