Повідомлення про обмеження інструментів програмування з ШІ у Goldman Sachs легко прочитати як розчарування великого бізнесу у «вайб-кодингу». Такий висновок приваблює своєю простотою: спочатку всі повірили, що програмувати зможе кожен, потім зіткнулися з реальністю. Проте ця історія заслуговує на уважніший розгляд. Вона порушує питання, з яким доведеться працювати багатьом компаніям: як перетворити доступність створення коду на керовану розробку програмного забезпечення.
За публікаціями від 2 листопада 2026 року, які посилаються на Bloomberg, Goldman Sachs у жовтні звузив доступ банкірів і трейдерів до окремих інструментів програмування з ШІ. Доступ зберегли інженери, а також кількісні стратеги, чия робота поєднує фінансове моделювання та розробку. Йдеться про повідомлення щодо внутрішніх правил банку; формулювання про «офіційну відмову від вайб-кодингу» виходить за межі наведених фактів. State of AI: обмеження інструментів ШІ у Goldman Sachs, 2 листопада 2026 року.
Водночас сам Goldman Sachs прямо включає використання Claude Code, GitHub Copilot та інших агентів до обов’язків інженерів у своїх вакансіях. Разом із цим він вимагає критично оцінювати створений код, підтримувати його якість і забезпечувати придатність до промислової експлуатації. Банк продовжує розглядати ШІ як інструмент професійної розробки. Goldman Sachs: вакансія Software Engineer, Global Banking & Markets, AI/ML Technology.
Для української ІТ-індустрії тут важливий зв’язок між можливістю створити програму та здатністю відповідати за її роботу.
Під вайб-кодингом зазвичай розуміють підхід, коли людина описує бажану поведінку природною мовою, а ШІ отримує значну свободу у створенні програми. Людина оцінює результат, уточнює завдання, повторює спробу. Такий спосіб може бути корисним для прототипів і перевірки ідей. Але видимий результат показує лише частину властивостей системи. Працюючий інтерфейс ще не дає відповіді, як програма поводиться з некоректними даними, хто має доступ до інформації та що станеться після зміни зовнішнього сервісу.
Уявімо фінансового аналітика, який за допомогою ШІ створив інструмент для звіряння платежів. На тестовому файлі все працює. Колеги починають користуватися програмою щодня, а згодом її результати потрапляють до управлінської звітності. Проте ніхто окремо не перевірив часткові платежі, дублікати операцій або різні правила округлення. Це умовний приклад, але він добре показує момент, коли особиста автоматизація стає частиною бізнес-процесу. Саме на цьому переході мають з’явитися перевірка, відповідальний за супровід і зрозумілі межі застосування.
Наслідки помилки визначають необхідний рівень контролю. Британський Національний центр кібербезпеки — NCSC — прямо розрізняє прототипи з обмеженим ризиком і системи, які обробляють чутливі дані, керують автентифікацією чи працюють із секретами доступу. Для останніх потрібні розуміння коду, перевірка вразливостей і підтвердження очікуваної поведінки. NCSC: рівні контролю у розробці з ШІ, 2026.
Звідси випливає важливе управлінське уточнення: сама посада інженера не гарантує безпечного результату. Досвідчений розробник також може прийняти помилкове рішення або надмірно довіритися агенту. Значення мають компетентність, організація перевірки та повноваження інструмента. Обмеження за ролями може бути зручним адміністративним рішенням, але воно потребує доповнення правилами роботи з конкретними системами й даними.
Другий аспект — економіка. Вартість програмного забезпечення включає аналіз вимог, інтеграцію, перевірку, експлуатацію, оновлення та усунення інцидентів. Якщо генерація коду прискорилася, а обсяг перевірки й перероблення зріс, загальна економія потребує окремого вимірювання.
Показовою є історія досліджень METR. В експерименті, оприлюдненому в липні 2025 року, 16 досвідчених розробників виконували 246 завдань у знайомих їм відкритих проєктах. Із доступом до тодішніх інструментів ШІ вони витрачали в середньому на 19% більше часу, хоча суб’єктивно вважали, що працювали швидше. Цей результат стосувався конкретних інструментів, учасників і завдань. METR: вплив інструментів ШІ початку 2025 року на продуктивність досвідчених розробників.
У лютому 2026 року METR опублікувала оновлення: дослідники вже вважали ймовірним зростання користі від новіших інструментів, проте попередили, що особливості відбору учасників і завдань заважають надійно оцінити величину ефекту. Частина розробників не хотіла працювати без ШІ навіть заради експерименту. Ця послідовність добре демонструє, наскільки обережно слід переносити окрему цифру на всю індустрію. METR: оновлення дослідження продуктивності та обмеження методики, лютий 2026 року.
Для керівника практичний висновок полягає у виборі показників. Варто вимірювати час до прийнятого й перевіреного результату, обсяг повторної роботи, дефекти після випуску та витрати на супровід. Кількість згенерованих рядків або активованих ліцензій показує використання інструмента, але слабко пояснює його економічну цінність.
Дослідження DORA 2025 року також пов’язує результати використання ШІ з організаційними умовами. Серед важливих чинників — зрозуміла політика, якісні внутрішні дані, контроль версій, невеликі порції змін і орієнтація на потреби користувача. Це дає підстави розглядати впровадження ШІ як зміну процесу розробки, що потребує більше роботи, ніж придбання підписок. DORA AI Capabilities Model: організаційні умови ефективної розробки з ШІ, 2025.
Для компанії доцільно передбачити кілька рівнів самостійності. Експеримент із синтетичними даними може мати простий порядок запуску. Внутрішній інструмент, на який регулярно покладаються колеги, вже потребує визначеного власника та перевірки. Зміни у платіжній системі або сервісі з персональними даними мають проходити відповідні інженерні процедури незалежно від того, хто написав першу версію коду.
Важливо також залишити бізнес-фахівцям можливість пропонувати й перевіряти ідеї. Аналітик, бухгалтер чи логіст часто краще за розробника знає винятки у своєму процесі. Створений ним прототип може зробити вимоги конкретними й прискорити взаєморозуміння. Компанії потрібен доступний шлях від такого прототипу до підтримуваного рішення: з описом призначення, перевіркою припущень і передаванням на супровід.
ШІ може допомагати і з перевіркою, однак додаткова автоматична оцінка не гарантує правильності. GitHub у документації до своїх агентів попереджає про пропущені проблеми, хибні зауваження та потенційно небезпечні пропозиції коду. Рекомендації передбачають людський перегляд і тестування результатів. GitHub Docs: можливості, обмеження та відповідальне використання агентів Copilot.
Тому критерії приймання варто визначати ще до генерації. Для розрахунків потрібні приклади з відомою правильною відповіддю. Для доступу до даних — перевірки того, що користувач не може виконати заборонену дію. Для інтеграцій — сценарії відмови й відновлення. Такий підхід допомагає перевіряти відповідність бізнес-вимогам, включно з тими, які модель могла неправильно зрозуміти.
Для українських продуктових і сервісних компаній це створює конкретну можливість. Пропозиція замовнику може включати весь шлях: від швидкого прототипу до інтегрованої, перевіреної системи з визначеною підтримкою. Цінність такої роботи легше пояснити через результат для клієнта, надійність і вартість експлуатації.
Замовникам, своєю чергою, варто уточнювати, хто перевіряє критичні зміни, які дані доступні агентам, як фіксуються їхні дії та хто підтримуватиме рішення після запуску. Відповіді мають бути конкретними: відповідальна команда, критерії приймання, правила доступу, порядок відновлення. Формальне запевнення про використання «найсучаснішого ШІ» цих питань не закриває.
Окремого перегляду потребує навчання молодших спеціалістів. Коли ШІ виконує частину початкових завдань, компанії мають цілеспрямовано навчати читати чужий код, знаходити помилки, перевіряти припущення та пояснювати рішення. Доступ до сильного інструмента дає більше можливостей практикуватися, але розвиток професійного судження потребує наставництва й зворотного зв’язку.
Історія Goldman Sachs залишає українському ІТ корисне питання: чи готові наші процеси до того, що створювати програмні рішення може значно більше людей? Відповідь має включати і свободу експерименту, і спосіб перетворити успішний експеримент на надійний продукт.
Доступ до генерації коду стає масовим. Відповідальність за програмне забезпечення має залишатися конкретною.
Діяльність Асоціації у цьому напрямі: Комісія з AI Software Ukraine.