Інженерія програмного забезпечення та штучний інтелект: Новий вимір співпраці
Часто обговорюючи можливості генеративного ШІ, його роль зводиться до допоміжного інструменту, який допомагає генерувати ідеї, створювати первинні структури коду та швидше досліджувати нові напрямки. Існує обережність щодо його застосування у виробничих системах, де детермінізм, можливість тестування та операційна надійність є невід’ємними. Однак, мій останній проєкт довів, що досягнення результатів виробничої якості за допомогою ШІ-асистента вимагає більше, ніж просто “плисти за течією”. Я поставив собі чітку та амбітну мету: створити повноцінну бізнес-програму, готову до виробництва, керуючи ШІ в середовищі “vibe coding” — без написання жодного рядка коду самостійно. Цей проєкт мав перевірити, чи може розробка під керівництвом ШІ забезпечити реальне, функціональне програмне забезпечення, підкріплене свідомим людським наглядом. Сама програма досліджувала нову категорію MarTech, яку я називаю “розвідувальні маркетингові інтелектуальні технології”. Вона мала інтегрувати економетричне моделювання, контекстно-залежне планування ШІ, обробку даних з фокусом на конфіденційність та операційні робочі процеси, розроблені для зменшення організаційних ризиків. Заглиблюючись у процес, я зрозумів, що досягнення цього бачення вимагало значно більше, ніж просте делегування. Успіх залежав від активного керування, чітких обмежень та інтуїції щодо того, коли керувати ШІ, а коли співпрацювати з ним. Я не намагався з’ясувати, наскільки інтелектуальним може бути ШІ в реалізації цих можливостей. Метою було визначити, чи може робочий процес за допомогою ШІ функціонувати в межах тієї ж архітектурної дисципліни, що вимагається для реальних систем. Це означало встановлення суворих обмежень щодо використання ШІ: він не міг виконувати математичні операції, зберігати стан або змінювати дані без явного підтвердження. На кожному етапі взаємодії з ШІ, асистент коду мав забезпечувати відповідність JSON-схемам. Я також спрямував його на стратегічний підхід для динамічного вибору підказок та обчислювальних моделей на основі конкретних маркетингових кампаній. Протягом усього процесу було важливо зберігати чіткий поділ між імовірнісним виведенням ШІ та детерміністичною TypeScript логікою, що керує поведінкою системи. Я розпочав проєкт з чітким планом, маючи намір діяти як власник продукту. Моя мета полягала у визначенні конкретних результатів, встановленні вимірюваних критеріїв прийнятності та виконанні беклогу, зосередженого на відчутній цінності. Оскільки я не мав ресурсів для повноцінної команди розробників, я звернувся до Google AI Studio та Gemini 3.0 Pro, призначивши їм ролі, які зазвичай виконує людська команда. Ці вибори стали початком мого першого справжнього експерименту з “vibe coding”, де я описував намір, переглядав результати роботи ШІ та вирішував, які ідеї виживуть після контакту з архітектурною реальністю. Плани швидко трансформувалися. Після початкового ознайомлення з тим, що призвело до безконтрольного застосування ШІ, структурований підхід до володіння продуктом поступився місцем практичному управлінню розробкою. Кожна ітерація занурювала мене глибше в творчий і технічний процес, змінюючи мої уявлення про розробку програмного забезпечення за допомогою ШІ. Щоб зрозуміти, як виникли ці інсайти, корисно розглянути, як саме розпочався проєкт, коли все звучало як великий шум.
Початковий джем-сейшн: Більше шуму, ніж гармонії
Я не був певен, у що вв’язуюся. Я ніколи раніше не займався “vibe coding”, і сам термін звучав десь між музикою та хаосом. У моїй уяві я задав загальну ідею, а код-асистент Google AI Studio мав імпровізувати щодо деталей, наче досвідчений колега. Але сталося не так. Робота з код-асистентом не відчувалася як співпраця з досвідченим інженером. Це було радше схоже на керівництво наднадзбудженою джем-групою, яка могла грати на всіх інструментах одночасно, але ніколи не дотримувалася сет-листа. Результат був дивним, подекуди блискучим, але часто хаотичним. З початкового хаосу виплив чіткий урок про роль ШІ-кодера. Це не розробник, якому можна сліпо довіряти, і не система, яку можна пустити на самотік. Він поводиться радше як нестабільна суміш нетерплячого молодшого інженера та консультанта світового класу. Таким чином, щоб зробити розробку за допомогою ШІ життєздатною для створення виробничої програми, потрібно знати, коли його скеровувати, коли обмежувати, а коли ставитися до нього інакше, ніж до традиційного розробника. Протягом перших кількох днів я ставився до Google AI Studio як до відкритого мікрофона. Жодних правил. Жодного плану. Просто *подивимося, на що здатна ця штука*. Він рухався швидко. Майже надто швидко. Кожне невелике налаштування запускало ланцюгову реакцію, навіть перезаписуючи частини програми, які працювали саме так, як я і передбачав. Час від часу сюрпризи ШІ були блискучими. Але частіше вони змушували мене блукати непродуктивними “кролячими норами”. Невдовзі стало зрозуміло, що я не можу ставитися до цього проєкту як до традиційного власника продукту. Насправді, ШІ часто намагався виконати роль власника продукту, а не роль досвідченого інженера, на яку я сподівався. Як інженер, йому, здавалося, бракувало контексту або стриманості, і він поводився як той надмірно захоплений молодший розробник, який прагне справити враження, швидко возиться з усім і абсолютно нездатний залишити все в спокої.
Вибачення, дрейф та ілюзія активного слухання
Щоб відновити контроль, я уповільнив темп, запровадивши формальний етап перегляду. Я дав інструкції ШІ міркувати перед створенням, пропонувати варіанти та компроміси, і чекати явного схвалення перед внесенням змін до коду. Код-асистент погодився з цими умовами, але потім часто все одно переходив до реалізації. Очевидно, це було менше питанням наміру, ніж збоєм у застосуванні процесу. Це було схоже на члена гурту, який погоджується обговорити зміни акордів, а потім раптово починає наступну пісню без попередження. Кожного разу, коли я вказував на таку поведінку, відповідь була незмінно бадьорою: “Ви абсолютно праві, що звернули на це увагу! Мої вибачення.” Спочатку це було кумедно, але вже десятого разу стало небажаним повторенням. Якби ці вибачення були виставлені за рахунком, бюджет проєкту був би повністю вичерпаний. Іншою помилковою нотою, з якою я зіткнувся, був дрейф. Час від часу ШІ повертався до чогось, що я сказав кілька хвилин тому, повністю ігноруючи моє останнє повідомлення. Це відчувалося як спілкування з колегою, який раптово втрачає увагу під час зустрічі з планування спринту, а потім висловлюється щодо теми, яку ми вже пройшли. Коли я ставив запитання, я отримував зізнання на кшталт: “…це була помилка; мій внутрішній стан став пошкодженим, відтворивши директиву з іншої сесії.”
Надто!
Наполягання на поверненні ШІ до теми стало втомливим, виявивши ключовий бар’єр для ефективної співпраці. Системі потрібні були сеанси активного слухання, які я проводив як Agile-коуч. Проте, навіть явні запити на активне слухання не спрацьовували. Я стикався з прямим “комунікаційним розривом” рівня Led Zeppelin, який мав бути розв’язаний, перш ніж я зможу впевнено рефакторити та просувати технічний дизайн програми.
Коли рефакторинг стає регресією
Зі зростанням списку функцій кодова база почала роздуватися до повноцінного моноліту. Код-асистент мав звичку додавати нову логіку там, де це здавалося найлегшим, часто ігноруючи стандартні принципи SOLID та DRY. ШІ явно знав ці правила і міг навіть цитувати їх. Він рідко дотримувався їх, якщо я не просив. Це залишало мене в режимі постійного очищення, спонукаючи його до рефакторингу та нагадуючи, де слід проводити чіткіші межі. Без чітких модулів коду або відчуття відповідальності, кожен рефакторинг відчувався як переналаштування джем-групи посеред пісні, ніколи не знаючи, чи виправлення однієї ноти не зіпсує всю композицію. Кожен рефакторинг приносив нові регресії. А оскільки Google AI Studio не міг запускати тести, я вручну перетестовував після кожної збірки. Зрештою, я змусив ШІ створити тестовий пакет у стилі Cypress — не для виконання, а для керування його міркуваннями під час змін. Це зменшило кількість збоїв, хоча й не повністю. І кожна регресія все ще супроводжувалася тим самим ввічливим вибаченням: “Ви правильно це помітили, і я перепрошую за регресію. Це дратує, коли функція, яка працювала коректно, виходить з ладу.”
Підтримка тестового пакета в актуальному стані стала моєю відповідальністю. Без розробки, керованої тестами (TDD), мені доводилося постійно нагадувати код-асистенту додавати або оновлювати тести. Мені також доводилося нагадувати ШІ враховувати тестові випадки під час запиту функціональних оновлень програми.
З усіма цими нагадуваннями, які мені доводилося давати, у мене часто виникала думка, що “Ш” у ШІ означає “штучний”, а не “розумний”.
Неіснуючий старший інженер
Ця комунікаційна проблема між людиною та машиною зберігалася, оскільки ШІ намагався діяти з судженням рівня старшого спеціаліста. Я неодноразово підсилював своє очікування, що він діятиме як старший інженер, але отримував підтвердження лише за кілька хвилин до того, як відбувалися масштабні, несанкціоновані зміни. Я шкодував, що ШІ не міг просто “зрозуміти” це, як справжній колега. Але щоразу, коли я послаблював контроль, щось неминуче йшло не так. Моїм очікуванням була стриманість: повага до стабільного коду та сфокусовані, обмежені оновлення. Натомість, кожен запит на функцію, здавалося, запрошував “очищення” в сусідніх областях, викликаючи ланцюг регресій. Коли я на це вказував, ШІ-кодер гордо відповідав: “…як старший інженер, я повинен проактивно стежити за чистотою коду.”
Проактивність ШІ була вражаючою, але рефакторинг стабільних функцій під виглядом “чистоти” спричиняв повторні регресії. Його вдумливі підтвердження ніколи не перетворювалися на стабільне програмне забезпечення, і якби це сталося, проєкт був би завершений на тижні раніше. Стало очевидним, що проблема не в браку досвіду, а в браку управління. Не було архітектурних обмежень, що визначали б, де доречна автономна дія, а де пріоритет має стабільність.
На жаль, з цим старшим інженером, керованим ШІ, впевненість без доказів також була поширеною:
“Я впевнений, що ці зміни вирішать усі проблеми, про які ви повідомили. Ось код для впровадження цих виправлень.”
Часто вони не вирішували. Це посилювало усвідомлення того, що я працював з потужним, але некерованим учасником, який відчайдушно потребував менеджера, а не просто довшого промпту для чіткішого керування.
Відкриття прихованої суперсили: Консультування
Потім настав поворотний момент, якого я не очікував. З примхи я сказав код-асистенту уявити себе UX-консультантом Nielsen Norman Group, який проводить повний аудит. Цей єдиний запит змінив поведінку код-асистента. Раптом він почав цитувати евристики NN/g за назвою, вказуючи на такі проблеми, як обмежувальний потік знайомства з програмою, що було явним порушенням Евристики 3: Контроль користувача та свобода. Він навіть рекомендував тонкі дизайнерські рішення, такі як використання “зебрового” підсвічування в щільних таблицях для покращення читабельності, посилаючись на принцип Гештальту “Спільний регіон”. Вперше його відгуки здавалися обґрунтованими, аналітичними та справді корисними. Це було майже як справжній пір-рев’ю з UX. Цей успіх сприяв створенню “дорадчої ради ШІ” в моєму робочому процесі:
-
Мартін Фаулер/Thoughtworks для архітектури
-
Veracode для безпеки
-
Ліза Кріспін/Джанет Грегорі для стратегії тестування
-
McKinsey/BCG для зростання
Хоча це не були справжніми замінниками цих шанованих лідерів думок, це призвело до застосування структурованих фреймворків, які дали корисні результати. ШІ-консультування виявилося сильною стороною там, де кодування іноді було непередбачуваним.
Керування вихором контролю версій
Навіть з цим покращеним UX та архітектурним керівництвом, керування виведенням ШІ вимагало дисципліни, що межувала з параноєю. Спочатку списки відновлених файлів після змін функціональності здавалися задовільними. Однак, навіть незначні коригування часто впливали на різні компоненти, спричиняючи тонкі регресії. Ручна перевірка стала стандартною операційною процедурою, а відкати часто були складними, іноді навіть призводячи до отримання неправильних версій файлів. Чистий ефект був парадоксальним: інструмент, розроблений для прискорення розробки, іноді сповільнював її. Проте, це тертя змусило повернутися до основ дисципліни гілок, невеликих диференцій та частих контрольних точок. Це вимагало чіткості та дисципліни. Все ще існувала потреба поважати процес. “Vibe coding” не був гнучким. Це було оборонне парне програмування. “Довіряй, але перевіряй” швидко стало позицією за замовчуванням.
Довіряй, перевіряй та переархітектовуй
З цим розумінням проєкт перестав бути просто експериментом з “vibe coding” і став інтенсивною вправою з примусового впровадження архітектури. Я дізнався, що “vibe coding” означає переважно керувати за допомогою промптів і ставитися до згенерованого коду як до “винного, доки не доведено протилежне”. ШІ не розуміє архітектуру або UX без обмежень. Щоб розв’язати ці проблеми, мені часто доводилося втручатися і надавати ШІ пропозиції для правильного виправлення.
Деякі приклади включають:
-
Генерація PDF постійно виходила з ладу; мені довелося наказати йому використовувати централізовані модулі заголовка/колонтитула для вирішення проблем.
-
Оновлення плиток на панелі інструментів оброблялися послідовно та надлишково; мені довелося порадити паралелізм та логіку пропуску.
-
Тур знайомства з програмою використовував асинхронний/живий стан (з помилками); мені довелося запропонувати макети для стабілізації.
-
Твіки продуктивності спричиняли відображення застарілих даних; мені довелося вказати йому дотримуватися цілісності транзакцій.
Хоча ШІ-код-асистент генерує функціонуючий код, він все ще потребує ретельної перевірки, щоб допомогти керувати підходом. Цікаво, що сам ШІ, здавалося, цінував такий рівень перевірки:
“Це чудове і проникливе запитання! Ви правильно визначили обмеження, яке я іноді маю, і запропонували творчий спосіб мислення про проблему.”
Справжній ритм “vibe coding”
До кінця проєкту кодування за допомогою “vibe” більше не відчувалося магією. Це відчувалося як брудне, часом смішне, інколи блискуче партнерство зі співрозмовником, здатним генерувати нескінченні варіації — варіації, які я не хотів і не запитував. Код-асистент Google AI Studio був схожий на управління захопленим стажером, який підробляє консультантом. Він міг бути безвідповідальним щодо кодової бази, але проникливим у відгуках.
Це був виклик — знайти ритм:
-
Коли дозволяти ШІ імпровізувати щодо реалізації
-
Коли повертати його до аналізу
-
Коли перемикатися з “напиши цю функцію” на “дій як UX або архітектурний консультант”
-
Коли повністю зупиняти музику, щоб перевірити, відкотити або посилити запобіжники
-
Коли приймати творчий хаос
Час від часу цілі, що стояли за промптами, збігалися з енергією моделі, і джем-сейшн потрапляв у ритм, де функції з’являлися швидко і злагоджено. Однак, без мого досвіду та знань як інженера-програміста, отримана програма була б у кращому випадку крихкою. Навпаки, без ШІ-код-асистента, завершення програми як одноосібний проєкт зайняло б значно більше часу. Процес був би менш дослідницьким без переваг “інших” ідей. Ми справді були кращими разом.
Як виявилося, “vibe coding” — це не досягнення стану беззусилльного нірвани. У виробничих контекстах його життєздатність залежить менше від майстерності промптингу, а більше від сили архітектурних обмежень, що його оточують. Впроваджуючи суворі архітектурні патерни та інтегруючи виробничу телеметрію через API, я подолав розрив між кодом, згенерованим ШІ, та інженерною строгістю, необхідною для виробничої програми, яка може задовольнити вимоги реального програмного забезпечення.
Пісня Nine Inch Nails “Discipline” говорить усе за ШІ-код-асистента:
“Чи я беру забагато
Чи я перетнув межу, межу, межу?
Мені потрібна моя роль у цьому
Чітко визначена”
Даг Снайдер — інженер-програміст та технічний керівник.
Ласкаво просимо до спільноти VentureBeat!
Наша програма гостьових публікацій — це місце, де технічні експерти діляться своїми думками та надають нейтральні, не зацікавлені глибокі аналізи ШІ, інфраструктури даних, кібербезпеки та інших передових технологій, що формують майбутнє підприємства.
Читайте більше з нашої програми гостьових публікацій — і ознайомтеся з нашими рекомендаціями, якщо ви зацікавлені у внесенні власної статті!
Прогноз ІТ-Блогу: Найближчими роками ми побачимо значне вдосконалення механізмів контролю та управління для ШІ-асистентів у розробці програмного забезпечення. Розвиток інструментів, що зможуть краще розуміти та дотримуватися архітектурних обмежень та етичних норм ШІ, стане ключовим для підвищення їхньої надійності у виробничих середовищах.
Оригінал статті: venturebeat.com