Як ми змусили 4 різних АІ-агентів сперечатися заради якісного Code Review
Привіт, DOU!
Всі ми знаємо, що звичайний ChatGPT або Claude непогано пише код, але коли справа доходить до рев’ю великих Pull Requests він починає плавати, пропускати баги або просто писати загальні фрази.
Ми вирішили піти іншим шляхом і створили Consensia. Це не просто обгортка над LLM, а цілий зал суду для вашого коду.
В чому фішка? Замість одного промпту ми запускаємо мультиагентну систему, де кожна модель має свою вузьку роль:
Security Sentinel — параноїк, який шукає SQLi, XSS та хардкоджені секрети.
Performance Architect — рахує Big-O, шукає витоки пам’яті та N+1 запити.
Clean Code Advocate — б’є по руках за порушення SOLID, DRY та поганий неймінг.
Edge-Case Hunter — Lead QA у душі, який намагається зламати вашу логіку через граничні значення.
Консенсус замість галюцинацій. Головна проблема АІ він погоджується сам із собою. В Consensia агенти проходять кілька раундів обговорення. Якщо один знайшов баг, а інший каже та ні, це ок, вони мають аргументувати свою позицію.
Наприкінці приходить THE JUDGE (Senior Tech Lead роль) він аналізує звіти всіх агентів і залишає фінальні інлайн-коментарі прямо у вашому GitHub PR.
Технічна частина:
- Система працює як GitHub Action, тому налаштовується за 5 хвилин, але має й веб версію у вигляді чату.
- Ми додали рівні потужності (Economy, Balanced, Max Power) від швидкого чеку до глибокого аудиту.
- Використовуємо WebSocket для стрімінгу, щоб GitHub Action не відвалювався по тайм-ауту на великих дифах.
Ми зараз на стадії релізу і нам дуже потрібен фідбек від українського ком’юніті. Чи вірите ви в АІ-рев’ю, яке реально «думає», чи вважаєте, що краще за синьйора ніхто не гляне?
Спробувати можна тут: consensia.world Наш GitHub Action: Ashixi/consensia-action
Буду радий подискутувати в коментарях! 👇
15 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівО, колеги!
Андріє, будьмо знайомі.
Я теж мейнтейню AI Code Reviewer вже рочки два як,
тільки моє рішення має трохи іншу цільову — Gito — AI Code Reviewer з відкритим кодом для роботи в ізольованих середовищах клієнтів без відправки коду в зовнішні сервіси, підтримує OpenAI-compatible API, а також Anthropic, Google.
Інтегрується з Jira/Linear для захоплення контексту задачі, працює не як повільний агент з thinking loop, а One-Shot’ом з пачки паралельних LLM запитів (швидко, дешево по інференсу).
Вміє працювати локально з cli, відповідати в коментарях github на запитання по змінам, застосовувати по запиту fix proposals з останнього code review, постити звіти в github / gitlab з автоматизованих workflow.
Написано на Python, використовується в кількох сотнях реп сьогодні.
По власним суб’єктивним враженням суттєво краще ніж Qodo / CodeRabbit / etc, якщо гоняти на opus / gpt-5.4 / gemini pro моделях — багато уваги я приділяв мінімізації сміття і води в звітах.
От консенсус я реалізував на рівніLLM-Proxy — таким чином, власне LLM консенсус агностичний і до llm inference providers / judges і до виконуваної задачі.
Стововно безкоштовних конкурентів/альтернатив з відкритим кодом... нажаль один російський навайбкоджений аналог домінує в OpenSource за рахунок активного піару на таких майданчиках як Хабр, куди зважаючи на політичну ситуацію досить гидко сунутись 😢
А комерційні альтернативи з відверто слабкими рішеннями так заспамили все своїм SEO, що до потенційної аудиторії не пробитись
Приємно зустріти колегу)
Цікаво вийшло, що ми вирішуємо ту ж саму проблему (боротьба з водою і галюцинаціями), але пішли кардинально різними шляхами.
Коротко про те, як це працює у нас:
Замість паралельних запитів ми побудували багатоетапний цикл. Агенти (Security, Performance тощо) проходять кілька раундів. Вони читають звіти одне одного з попереднього кроку, шукають протиріччя і можуть не погоджуватися з колегами. І лише після цієї так скажемо суперечки всі дані йдуть до моделі арбітра, яка формує фінальний вердикт. Це потребує більше часу та токенів, але ми пішли на це свідомо, щоб максимально зімітувати людський процес рев’ю.
Ваш проект буде способом натхнення для мене. Приємно бачити що в українському ком’юніті роблять такі класні інструменти
Був би дуже радий якось списатися (у Telegram чи LinkedIn) і просто обмінятися досвідом.
Якщо не проти поспілкуватися мій лінкедін: www.linkedin.com/.../andrii-shumko-3aa818313
Успіхів з розробкою Gito! 🤝
найбільше проблем на проектах створює сліпе слідування DRY. Коли різні речі, з точку зору бізнес логіки, поєднуються у коді, бо код для обох одинаковий. І коли приходить момент, що бізнес вимагає зміни однієї частини, то потрібно у коді роз’єднувати речі. І починається пошук винних, чому невеликі зміни вимагають такого великого бюджету. Хоча з самого початку було сказано, що це різні речі з точки зору бізнес логіки
Зі сторони сама ідея виглядає як шлях у пекло. ШІ у першу чергу повинен мати доступ до повного і детального опису бізнес логіки. У якості екперименту можна пробувати, але якщо таку річ притягнути на реальний проект, то можна зіпсувати стосунки з іншими учасниками команди. Нікому не сподобається, що хтось створює проблеми іншим заради експериментів
Додатковий момент у плані фінансової вигоди. Коли за місяць потрібно буде заплатити +1 зарплату за токени, тоді буде дуже важко аргументувати необхідність подібних речей. Враховуючи, що вартість токенів зростає з часом, це досить ймовірний сценарій
У будь якому випадку, орієнтація на правила відірвані від контексту бізнес логіки, це провальна ідея з самого початку
Дякую за розгорнутий фідбек! Щодо DRY абсолютно згоден, сліпе слідування правилам без контексту бізнес-логіки шкідливе. Саме тому Consensia це не лінтер(хоча є схожість), а система з 5 спеціалізованих агентів під наглядом «Судді». Їхня задача не сліпо вимагати DRY, а аналізувати код з різних точок зору (безпека, перформанс, архітектура).
Щодо вартості, тут ви помиляєтесь. Ціна токенів на ринку стрімко падає, а не зростає. Одне глибоке рев’ю нашого сервісу коштує як пара ковтків кави, що ніяк не порівнювано із зарплатою розробника. Наша мета зекономити час ліда, взявши на себе рутину, а не замінити його розуміння бізнес-логіки.
у меня другая проблема.
90-95% замечаний по code review от агентов это тупо false positives.
т.е. если этот слоп не фильтровать, ты постоянно будешь менять кучу кода просто потому, что сегодня другая фаза луны или после обеда дождик пошел.
У саму точку. Це головна вада базових AI-інструментів. Тому ми не видаємо користувачеві необроблену відповідь від першої-ліпшої нейронної мережі. У нас впроваджено арбітраж: агенти сперечаються між собою, перевіряють чужі зауваження, після чого головний агент відфільтровує всі false positive. Система спеціально будувалася так, щоб код не змінювався через фази місяця)
добавив к совершенно недерминированному решению еще пять таких же недерминированных фильтров и проверок, вы все равно не получите детерминированное решение )
Справедливо, детермінізм у LLM це поки що міф. Але ми й не намагаємося перетворити ймовірнісну модель на чисту функцію. Наше завдання зниження ентропії. Один агент з імовірністю X видасть нісенітницю. Коли п’ять агентів з різними ролями (і на різних сімействах моделей) проводять перехресну перевірку, ймовірність того, що вони всі однаково «галюцинують» в одній і тій же точці, математично знижується. Це не робить рішення детермінованим у строгому сенсі, але це робить його валідним для практичного застосування.
выкрути температуру в ноль и зафиксируй сид и миф станет реальностью
це як? хоча дай угадаю. Ти навмисне зробив якийсь брейкінг чендж, при цьому ніде ні в тікеті, ні в пул реквесті, ні в коментарях не написав що це навмисно і що ніхто поки цю штуку не використовує і брейкінг чейндж допустимий. Не надав АШці доступ до внутрішньої документації, до інших внутрішніх продуктів які залежать від цього проекту, не надав доступ до тікетів, не надав доступ до внутрішніх гайдлайнів, як треба робити у вас в компанії, в цьому проекті, не написав інструкцій з хоча б загальними гайдлайнами типу «повтикай історію подібних змін, і перевір чи ми нічого не упускаємо». І потім коли АІшка каже що тут у тебе брейкінг чендж, у тебе починає пригорати.
У мене таке враження, що ти навіть вбудований /review (який відносно примітивний) не використовуєш, бо важко уявити 95% false posisitves, або у нас інше розуміння false posisitves. Якісь мінорні, неважливі ремарки — так. Пропонує якесь своє бачення чи свій неймінг, яке також правильне тільки інше — так. Але це все фікситься на 90% з правильним налаштуванням і промтами (да-да, правильне ревью це не один промт і не один агент). Но щоб прям так 95% false positive — навіть 2 роки тому такого не було.
не угадал.
это когда в коде, на который делает review, есть факты, опровергающие неверные замечания.
я уже молчу о том, что агент на сгенерированный минуту назад код следом дает гору замечаний с high severity.
таке буває но рідко, може 5% від всіх коментарів, максимум 10% (залежить від складності кодобази і промта) но не 95%
Все ж, я вважаю, що подібрий контроль має бути за людиною. Цікаво, скільки часу ви витратили на написання цієї супер команди?
Згоден на всі 100%, фінальний контроль завжди має бути виключно за людиною. Ми і не позиціонуємо сервіс як заміну Senior-розробнику. Це швидше «лінтер на максималках» або прискіпливий напарник. Суть у тому, щоб зняти рутину і підсвітити сліпі зони. На власному коді перевіряв, часто агенти знаходять такі неочевидні баги, які око просто замилює і пропускає. А ви вже самі вирішуєте, приймати ці правки чи ні.
Щодо часу, то базовий кістяк оркестратора ми зібрали досить швидко. А от на що дійсно пішла (і йде досі) купа часу та спалених токенів це калібрування агентів. Змусити їх нормально сперечатися і не видавати false positives це ще той квест.
Цікаво, чому акцент не на цьому, а на «зняти рутину». Адже якщо людина пул реквест дивиться все одно (і робить це якісно) ні про яку економію часу мова насправді не йде. Але якщо агентське рев’ю допомагає знизити кількість факапів які доповзли до прода (що до речі повинно бути нескладно виміряти) — це цілком собі цінність.