Писати код стало значно швидше. Ціна помилки не змінилася. Саме тому справжній зсув останніх років не в тому, що ШІ пише за нас, а в тому, що перевірка, тестування й контроль тепер забирають істотно більше зусиль . Нижче — як я працюю з ШІ на Odoo-проєктах і чому 100 % покриття доопрацювань тестами перестало бути приємним бонусом і стало умовою роботи.
Що насправді змінилося
Раніше вузьким місцем було написання коду: розробник писав повільно, а потім швидко перевіряв те, що сам щойно продумав. Тепер навпаки — код зʼявляється швидше, ніж людина встигає його осмислити . Центр ваги перемістився з написання на перевірку.
Це не аргумент проти ШІ. Це аргумент за зміну процесу: інструмент, який прискорює одну частину роботи вдесятеро, автоматично робить вузьким місцем усі інші.
Головний ризик: виправив одне — зламав інше
Найнеприємніша властивість роботи з ШІ в автоматичному режимі — готовність правити сусідній код. Ви просите змінити один розрахунок, а разом із ним «про всяк випадок» підправляється сигнатура методу, що викликає, змінюється залежність обчислюваного поля, а перевірка, яка здавалася зайвою, тихо зникає.
У звичайному застосунку це помітно одразу. В Odoo — ні, бо наслідок зазвичай не помилка, а тихо неправильне число : не та собівартість, не той податок, не той залишок. Нічого не падає й ні на що не скаржиться — воно просто накопичується до закриття періоду.
Другий типовий сценарій — архітектурний дрейф : кожна ітерація локально розумна, а через двадцять ітерацій у проєкті три різні способи робити те саме, і жоден не задокументований.
Тести: 100 % покриття доопрацювань
Це вимога, яка змінилася найсильніше. Раніше можна було жити з тестами на «критичних місцях». Тепер, коли код правиться швидко й почасти автоматично, уся кастомна логіка має бути покрита тестами — бо саме тест фіксує намір: ось так система має поводитися, і будь-яка зміна, що це ламає, має падати одразу.
Що на Odoo-проєкті покривається завжди:
- обчислювані поля та їхні залежності — найчастіше джерело тихих помилок і перше, що ШІ схильний «оптимізувати»;
- облікова логіка : проводки, собівартість, податки, зіставлення платежів — там, де помилка найдорожча;
- переходи станів документів — підтвердження, скасування, повернення;
- розбір відповідей зовнішніх API — на збережених зразках відповідей, без мережевих викликів, щоб тести лишалися швидкими й стабільними;
- граничні випадки : нуль, відʼємні значення, інша валюта, порожня відповідь, повторний виклик;
- права доступу — те, що вручну ніхто не перевіряє, поки не станеться неприємність.
Практична деталь: тест має перевіряти бізнес-результат , а не факт виклику методу. «Після підтвердження замовлення на складі на три одиниці менше й існує проводка собівартості» — корисний тест. «_compute викликався один раз» — ні.
Робочий цикл: рішення → тест → код → рецензія
Порядок важливіший за інструмент. Той самий ШІ дає протилежний результат залежно від того, у який крок його ввімкнено.
- Архітектурне рішення ухвалює людина. Де це живе, як лягає в механіку Odoo, що буде при оновленні. До коду, а не після.
- Спершу тест, потім код. Тест описує очікувану поведінку бізнесовою мовою і водночас слугує технічним завданням для генерації.
- Генерація коду. Саме тут ШІ економить найбільше часу — і це нормально.
- Рецензія людиною, яка знає Odoo. Не «чи працює», а «чи так це має бути побудовано».
- Прогін усього набору тестів , а не лише нових. Саме він ловить зламаного сусіда.
Приберіть крок 2 — і крок 5 перетворюється на ворожіння. Приберіть крок 1 — і отримаєте той самий архітектурний дрейф, тільки швидше.
Що ШІ робить добре, а що погано саме в Odoo
Добре: рутинні моделі та представлення, скрипти міграції, розбір форматів відповідей, тести, написані з опису поведінки, рефакторинг за чіткою інструкцією, документація до вже наявного коду.
Погано: усе, що вимагає знання наслідків. Залежності обчислюваних полів і їхній вплив на продуктивність, порядок операцій в обліку, взаємодія зі стандартними модулями, мультикомпанійність і права доступу. Тут згенерований варіант часто виглядає правильним, не будучи ним.
Окремо: ШІ схильний писати «власну» логіку замість того, щоб скористатися вбудованим механізмом Odoo. Формально воно працює, а потім не переживає оновлення, не потрапляє у стандартні звіти й ламається на першій же нетиповій операції.
На що дивитися в згенерованому коді
- чи зʼявився ще один метод, який робить те, що вже робив наявний;
- чи обходиться ORM там, де можна було лишитися всередині фреймворку;
- чи не змінилися «мимохідь» залежності обчислюваних полів;
- чи не додано поля й моделі, які нікому не потрібні — завтра це мертвий код;
- чи не зникли перевірки, які здавалися зайвими;
- чи буде через півроку зрозуміло, навіщо це взагалі написано.
Найпростіший фільтр: якщо розробник не може пояснити фрагмент своїми словами, цей фрагмент ще не є частиною проєкту, хоч би як акуратно він лежав у репозиторії.
Регресії: чому без CI це не працює
Тести окупаються лише тоді, коли запускаються автоматично. Мінімальний робочий набір: повний прогін на кожну зміну, окрема staging-база з копією реальних даних і заборона деплою в продакшен із тестами, що падають. Складної інфраструктури це не потребує — на Odoo.sh воно вбудоване, а на власному сервері налаштовується один раз.
Що це означає, якщо ви замовник
Три практичні висновки, якщо ви замовляєте розробку:
- Швидше не означає дешевше загалом. Економія на етапі написання легко зʼїдається місяцями розплутування наслідків.
- Тести — не опція. «Чи покриті доопрацювання тестами?» — тепер важливіше питання, ніж «скільки це годин?».
- ШІ не замінює кваліфікацію. Він її підсилює — в обидва боки. Хороший розробник із ШІ працює швидше; слабкий швидше виробляє те, що потім доведеться переписувати.
Як перевірити це в потенційного підрядника — окремо: як обрати виконавця для впровадження Odoo . А якщо код уже є і ніхто не знає, що в ньому — технічний аудит проєкту.
Часті питання
Чи використовуєте ви ШІ на клієнтських проєктах?
Так, як прискорювач. Архітектурні рішення й рецензія лишаються за мною, а кастомна логіка покрита тестами.
Чи робить це розробку дешевшою?
Частково — рутина справді швидша. Але частина зекономленого часу переходить у тестування й контроль, і це правильний обмін.
Чому 100 % покриття, якщо раніше вистачало вибіркового?
Раніше код змінювався невеликими шматками і людиною. Тепер зміни часто ширші за очікувані, і лише повний набір тестів показує, що зачепило деінде.
Чи можна покрити тестами наявний проєкт?
Так, і зазвичай починають з облікової логіки та інтеграцій — там помилка коштує найдорожче. Повне покриття добудовується поетапно.
Скільки часу забирають тести?
Помітно менше, ніж здається, — і в рази менше, ніж пошук облікової розбіжності через три місяці після релізу.
Як програмувати з ШІ: чому тести стали важливішими за швидкість