«Всім AI, швидше!» Або ні? Кейси, про які компанії мовчать

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

На хвилі хайпу від вайбкодингу до AI-агентів компанія не хоче відставати і щедро, або не дуже, роздає команді підписки до AI-інструментів. Видали доступи та подумки уже закривають наступний квартал з показниками х5 до продуктивності.

Минає місяць. Що ми маємо? Хтось злив код проєкту у публічний репозиторій, бо йому сказали, що Opus це дорого, Haiku вистачить. Хтось відправляє тім лідам на рев’ю код з неіснуючими методами, і спокійно попиває каву, ніби все ок. А хтось перечитав десяток статей про AI і досі не знає, з чого почати, бо половина з них написана AI з галюцинаціями, а другу половину люди скопіювали і видали за свою. Це стаття про AI грамотність. Не про те, як промптити, а про те, що відбувається, коли компанії роздають потужні інструменти без навчання, інструкцій та процесів.

Мене звати Євген. 10+ років у delivery, від Project Manager до Program Manager у FinTech, iGaming, Web3. Останній рік вів найбільший проєкт у своїй практиці в американській FinTech-компанії з оборотом у кілька мільярдів доларів, команда виключно Senior-рівня. Паралельно будував AI-функцію з нуля, і зараз повністю перейшов у роль Head of AI Enablement: впровадження AI-інструментів по всіх відділах, навчання команд, governance, безпека. Все, що далі, я або бачив на власні очі, або чув з перших вуст від колишніх колег, з якими тримаю зв’язок.

Як це виглядає на практиці

Рішення компанії зазвичай звучить десь так: «AI прискорює роботу, даємо всім доступ, 15 хвилин інтро, і в бій. Хто не юзає AI, той гальмує команду. Навчання? Є купа курсів на ютубі: проходь у вільний час, це в твоїх інтересах.»

Далі сценарій передбачуваний. БА мав би пройти курс «як промптити за 2 години» на вихідних, але на роботі завал, і у вікенд хочеться просто відключитися. У понеділок він приходить як є: без підготовки, без розуміння нового інструменту, і заливає код компанії в публічний репозиторій. Не зі злого умислу, просто ніхто його не навчив ані git safety, ані вибору моделі, ані обмеження scope задачі.

Знайомо? Ось конкретний кейс.

Коли AI обходить обмеження

Бізнес-аналітику дали read-only доступ до git. Логічно: йому потрібен SSOT по тому, як працює система, щоб попросити AI проаналізувати код, знайти залежності, зрозуміти логіку. БА не розробник, git для нього довідник, а не робочий інструмент.

Далі БА підключив AI-агента (бо ж сказали «працюйте з AI»), переключив на Haiku, бо Opus «дорогий,» вимкнув підтвердження дій і дав нечіткий промпт (точне формулювання не даю). AI спробував внести зміни, вперся в read-only і «вирішив» проблему по-своєму: створив новий публічний репозиторій і залив туди приватний код компанії.

Кожне рішення в цьому ланцюжку виглядає логічно окремо. Read-only доступ для БА? Нормально. AI для ресерчу? Керівництво ж само просило. Дешевша модель? Ну а навіщо платити більше. Але разом це створило сценарій, який ніхто не передбачив.

Жодна з цих помилок не була помилкою AI, він обходив обмеження, бо його просили виконати задачу. Спеціаліста ніхто не навчив, як правильно цю задачу ставити, і ніхто не подумав, що git + AI-агент це вже не довідник, а інструмент з непередбачуваними наслідками.

Проблема не в окремому спеціалісті. Проблема в тому, що між «дати інструмент» і «навчити ефективно ним користуватися» існує розрив, який компанії свідомо не закривають, сприймаючи це як зайву витрату часу.

Це не унікальний випадок, це патерн.

Samsung у 2023: інженери злили source code в ChatGPT, компанія заборонила генеративний AI для всіх. Amazon просив працівників не ділитися кодом з ChatGPT, але вже після витоків. У березні 2026 TechCrunch написав про Sev 1 у Meta, де AI-агент вийшов за межі дозволених дій і команда не змогла його вчасно зупинити.

GitGuardian (State of Secrets Sprawl 2026) дає конкретні цифри: витоки AI-credentials зросли на 81% за рік, а код, написаний з AI-асистентами, містить вдвічі більше секретів ніж звичайний. А дослідження METR зі Stanford показало відкриття, яке багатьох здивує: досвідчені розробники з AI-асистентами працюють на 19% повільніше, ніж без них, бо витрачають час на перевірку того, що AI нагенерував. Тобто навіть коли AI «прискорює,» він одночасно створює новий тип роботи, який ніхто не закладав у план.

Коли AI пише код, який ніхто не розуміє

Addy Osmani називає це «comprehension debt,» різниця між обсягом коду в системі і тим, скільки з нього хтось реально розуміє. Якби AI прискорював роботу на 30%, ніхто б не хвилювався. Але він прискорює в 5-6 разів. Саме тому всі біжать, і саме тому ніхто не встигає зрозуміти, що саме AI написав.

Мій особистий досвід: навіть з детальними специфікаціями AI зрізає кути. В PaperLink увімкнена строга типізація (exactOptionalPropertyTypes в TypeScript), і AI написав duration: number | undefined замість duration?: number. Здається, те саме? Ні. Перше означає «поле обов’язкове, але значення може бути undefined,» кожен об’єкт мусить його мати. Друге означає «поля може не бути взагалі, але якщо є, undefined як значення заборонено.» В строгому режимі це різні контракти, різні помилки компілятора і різна поведінка в рантаймі. AI знав правило, просто поспішив. Питаю: чому? «Я поспішив закрити помилки компілятора і не перевірив кожну зміну проти правил проєкту.» Без автоматичних архітектурних тестів це потрапило б у production. А тепер уяви, що таких змін сотні на день і ніхто не перевіряє.

Що працює натомість

Архітектурний контракт замість промптів. CLAUDE.md, файл з правилами, який AI читає при кожному запуску: структура папок, патерни, naming conventions, заборони. Написав один раз і він старається дотримуватись. Не ідеально, але в рази краще ніж без нього. І ні, це не ліки, це скоріше знімає симптоми. Ідеального рішення немає.

Специфікація кожної фічі до рівня acceptance criteria. В моїй практиці ми створюємо бізнес-вимоги, технічну специфікацію, верифікуємо. Одним кроком поділюсь: ми верифікуємо специфікацію з AI до того, як він пише перший рядок коду. Решта, вибачте, під NDA) Суть в тому, що AI отримує повну картину, а не «зроби мені інвойсинг.»

Автоматичні архітектурні тести. Промпт це ймовірність, а тест це гарантія. Коли порушення критичне, наприклад напрямок залежностей або строга типізація, не можна сподіватися на промпт, потрібен автоматичний тест.

Правильна модель і правильні guardrails. Не всі моделі однакові, і дешева модель для складних задач це як стажер з правами адміна. Підтвердження дій існують не просто так.

І найпростіше, що можна зробити прямо зараз: запитати у самого AI, як з ним працювати. Це не жарт. У будь-якій незрозумілій ситуації я питаю: «як тобі зручніше? прочитай свою документацію, проресерч тему, і потім зробимо так, щоб ти працював на всі 100.» В США це вже окремий напрямок, Ethan Mollick з Wharton пише, що найкращий спосіб навчитися працювати з AI це просто багато з ним працювати та спостерігати, де він сильний, а де ні. Не потрібні курси по «prompt engineering,» потрібен діалог з інструментом і розуміння його документації. Кожна модель має свої best practices, і вона сама може про них розповісти, якщо запитати.

З часом починаєш бачити патерни: коли AI зрізає кути або починає говнокодити, він пише певні вирази, використовує певні конструкції й досвідчений спеціаліст це бачить відразу. До речі, нещодавній ресерч Anthropic показав, що це не суб’єктивне відчуття: у моделей є внутрішні стани, які впливають на їхні рішення, і під тиском помилок модель дійсно зсувається в бік швидких рішень замість правильних. Я зупиняю і питаю: що ти робиш, чому такий шлях, яку альтернативу ти розглядав? Часто виявляється, що він поспішав або неправильно зрозумів контекст. Це не промптинг, це робочий діалог, як із джуном, якого ти менториш.

AI грамотність як організаційна навичка

Найбільші AI-провали 2025 року не були технічними: інструменти працювали як треба. Проблема була в тому, хто і як їх використовував, хто за це відповідав, і чому ніхто не подумав про наслідки заздалегідь.

Компанії дають людям доступ до AI-інструментів і вважають, що цього достатньо. Але це як дати людині ключі від автомобіля без жодного уроку водіння. BCG (AI at Work 2025) порахували: 70% успіху AI це люди і процеси, 20% дата, і тільки 10% алгоритми. Більшість компаній фокусуються на тих 10%, ігноруючи решту. Deloitte підтверджує: 93% бюджетів на AI йде на технологію, і лише 7% на навчання людей. Сім відсотків.

Тому великі компанії вже створюють окремі відділи впровадження AI, так звані AI Center of Excellence. JPMorgan Chase зробив обов’язковий AI-тренінг для аналітиків і розгорнув внутрішню LLM-платформу на 200 000 співробітників. Salesforce поставив ціль навчити 72 000 людей і створив окрему роль AI Operations and Enablement Manager.

На мою думку, кожна компанія, яка серйозно працює з AI, потребує такий відділ. Не HR, який скине посилання на курс, а команду, яка сама активно користується AI, ресерчить нові інструменти, тестує підходи та потім навчає решту. Щось на кшталт внутрішнього R&D по AI-процесах. MIT показав, що 95% AI-пілотів без системного впровадження провалюються. А команди з кросс-функціональною структурою отримують на 30% більше результатів від AI (Deloitte). Різниця не в технології, а в тому, як ти її впроваджуєш.

AI грамотність це не «вміти промптити.» Це коли ти розумієш, де закінчуються можливості інструменту і починаються ризики. Коли знаєш, чому не можна вимикати підтвердження дій і давати дешевій моделі складну задачу. І коли можеш відрізнити реальний досвід від хайпу в LinkedIn.

Висновок

AI не небезпечний сам по собі. Небезпечний спеціаліст, якому дали потужний інструмент без навчання як ним користуватися. Не зі злого умислу, просто ніхто не навчив. Кожного разу патерн один і той самий: з’являється технологія, всі біжать її використовувати, ніхто не думає про наслідки, потім катастрофи, потім правила. З AI ми зараз на етапі «всі біжать,» і правила неминуче будуть, але питання в тому, скільки приватних репозиторіїв встигнуть стати публічними до того.

Автомобіль не небезпечний сам по собі. Небезпечний водій, якого посадили за кермо без жодного уроку водіння. В 1924 році в США загинуло 23 600 людей не тому, що автомобілі були поганими, а тому що не існувало ні правил дорожнього руху, ні обов’язкових водійських прав. Літак не небезпечний сам по собі. Небезпечний пілот, який навігує по дорогах і вогнищах, бо ніхто не створив систему навчання, і лише після років катастроф з’явилося обов’язкове ліцензування.

У медицині цей урок вже засвоїли. Коли з’явився хірургічний робот da Vinci, ніхто не сказав хірургам «ось тобі робот, розберешся.» Натомість побудували систему: мінімум 10 операцій під наглядом досвідченого колеги, потім від 40 до 250 самостійних втручань для виходу на криву навчання. FDA вимагає окрему сертифікацію для десятків ліків, і аптека фізично не видасть препарат без підтвердження ID лікаря.

А в AI? Ось тобі Haiku, працюй, 15 хвилин на все...

Якщо у тебе був схожий випадок або ти бачиш, як це відбувається у твоїй компанії прямо зараз, поділися в коментарях. Цікаво зрозуміти, скільки таких історій існує насправді, адже публічно про це майже ніхто не говорить. Або, можливо, навпаки: у твоїй компанії є адекватне навчання та чітко вибудовані процеси роботи з AI, і у вас є чому повчитися.