«Якщо код пише ШІ, чи не вийде програма гіршою?» Це перше, про що нас запитують клієнти, і запитання слушне. Чесна відповідь: усе залежить від того, хто тримає інструмент. У руках досвідченого інженера ШІ збільшує обсяг зробленого й не знижує планку.
Нещодавно ми писали про те, як завдяки ШІ індивідуальна автоматизація стала доступною для малого бізнесу. Дешевизна має сенс лише тоді, коли результат працює, тож тут пояснимо, чому він працює і звідки насправді береться швидкість.
Вирішує інженер, друкує ШІ
Якість програмного забезпечення здебільшого визначається ще до першого рядка коду. Які дані куди йдуть, що станеться, коли платіж не пройде, хто має право бачити який запис, як система поводиться, коли інший сервіс лежить. Усе це рішення, які потребують досвіду, і ухвалює їх інженер.
ШІ пришвидшує наступний крок: перетворення цих рішень на код. Раніше ця частина забирала більшість годин, але проєкти ніколи не ламалися саме на ній. Вони ламаються на поганих рішеннях, а рішень ШІ за вас не ухвалить.
Досвід — це фільтр
ШІ помиляється, причому переконливо: код запускається, але не враховує крайній випадок; запит за певних умов розкриває чужі дані; виклик звертається до функції, якої не існує. Людина без інженерного досвіду приймає такий результат, бо він ніби працює. Досвідчений інженер помічає, що щось не так.
ШІ — це множник. Він множить майстерність того, хто ним користується, а заразом і прогалини в ній.
Так само редактор працює з перевіркою правопису. Інструмент швидко знаходить друкарські помилки, а редактор — речення, написане без жодної помилки, яке все одно каже не те. Приберіть редактора, і текст з’являтиметься швидше, але кращим не стане.
Перевірки подешевшали, тому їх нарешті роблять
Ось що дивує людей: на практиці якість часто зростає. До ШІ, коли наближався дедлайн, першим під ніж ішло все непоказне: тести, валідація введення, обробка помилок, документація. Усі знали, що це важливо, просто бракувало часу.
Тепер ґрунтовний набір тестів або зрозумілу інструкцію на випадок збоїв можна написати за хвилини, а не за дні, тож хороший інженер додає їх як щось само собою зрозуміле. Робота над надійністю, яка раніше була розкішшю, стає нормою.
Запобіжникам байдуже, хто написав рядок
Рев’ю коду, автоматичні тести, тестові середовища, невеликі релізи, які можна відкотити, стабільні й добре вивчені технології: ніщо з цього не залежить від того, хто надрукував код, людина чи модель. Перевіряється поведінка, а не авторство. Команди, які вже так працюють (про свої звички ми розповідали в статті «Як релізити регулярно й нічого не ламати»), можуть узяти ШІ, не змінюючи того, як вони захищають продакшн.
І за результат усе ще хтось відповідає. Інженер схвалює зміну й бере слухавку, якщо щось зламається. Саме ця відповідальність тримає стандарти, і на інструмент вона не переходить.
Звідки береться додатковий обсяг
Якщо якість тримається, чому результат настільки зростає? Бо значна частина будь-якого проєкту — це рутина, з якою ШІ справляється добре:
- Типові будівельні блоки. Форми, адмін-панелі, списки з фільтрами, сторінки налаштувань. Потрібні в кожному проєкті, рідко складні, завжди забирають час.
- Інтеграції. З’єднати API однієї системи з іншою й зіставити поля між ними раніше означало години з відкритою документацією. Тепер інженер починає з робочої чернетки й перевіряє її.
- Менше часу на пошуки. Кожна нова бібліотека чи сервіс раніше вимагали часу на вивчення. ШІ скорочує його до хвилин.
- Дешеві експерименти. Зробити дві версії рішення, щоб їх порівняти, раніше було задорого. Тепер це швидко, тому кращі варіанти знаходяться на початку, а не після запуску.
Зніміть з інженера всю цю рутину, і залишиться те, що може зробити тільки він: зрозуміти бізнес, розібратися зі складною логікою й зробити продукт приємним у користуванні. Більше його робочого тижня йде на важливе, і більша частина проєкту доходить до кінця.
Швидко й без перевірки — це вже інша історія
Усе це не означає, що будь-який застосунок, зібраний із ШІ, безпечний. Інструмент, швидко зроблений людиною без інженерного досвіду, може місяцями добре працювати, а потім зламатися від реального навантаження, реальних даних або реального зловмисника. Швидкість та сама, а фільтра немає.
Якщо це схоже на щось, на що ваш бізнес уже покладається, це не привід його викидати. Це привід для техогляду: інженер перевіряє зроблене, виправляє ризиковане й залишає вам те, що зможе рости.
ШІ не змінив того, що потрібно хорошому програмному забезпеченню. Він змінив те, скільки такого програмного забезпечення досвідчений інженер може випустити за тиждень. На такий обмін варто погодитися, і саме так ми працюємо. Якщо маєте на думці якийсь робочий процес, розкажіть, як він працює сьогодні.