ЧомуOutOf-Box AI розчаровує команди — і що з цим робити

Більшість технологій використовуються довше, тим спокійніше ви починаєте на них розраховувати. З інструментами штучного інтелекту все відбувається навпаки: у своєму річному опитуванні понад 49 тисяч розробників Stack Overflow зафіксував зростання використання до 84%, навіть якщо довіра до точності цих інструментів впала з 40% до 29% за рік.

Цей ефект мені знайомий. Наш перший досвід роботи з інструментами штучного інтелекту у розробці мало спільного з ефектом швидшої роботи та меншої монотонності, про який писала технічна преса. Наші розробники були розчаровані: штучний інтелект генерував посередній код, який довго перевірявся та у підсумку мав бути переписаний. Команда очікувала, що штучний інтелект заощадить час, але натомість отримала додаткову роботу. Тому невдовзі після перших спроб включення інструментів штучного інтелекту у щоденний робочий процес команда повернулася до своєї звичайної роботи.

Сьогодні ці інструменти прискорюють як написання коду, так і його перевірку для наших розробників — не тому, що ми знайшли кращу модель, а тому, що змінили свій підхід до роботи з інструментами штучного інтелекту. Ось що допомогло нам досягнути цього.

Чому код, написаний штучним інтелектом, розчаровує розробників

Штучний інтелект спирається на величезну масу публічного коду з усього інтернету, і цей код рідко буває зразковим: його якість середня, а модель повторює цю середню якість.

Але “середній” рівень не є межею того, що можливо — це просто те, що модель видає, поки не знає ваш проєкт: його конвенції, структуру коду, архітектурні рішення. У опитуванні понад 600 розробників Qodo встановило, що серед тих, хто не задоволений якістю коду, генерованого штучним інтелектом, 44% пояснюють це відсутністю контексту. Саме це утримує рівень якості на посередньому рівні.

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

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

У своєму звіті Octoverse 2025 року GitHub описує саме такий зсув: розробники, які пішли найдалі з штучним інтелектом, вже не називають себе “авторами коду” і стають щось на зразок його “креативних директорів”, де ключовим умінням є керування та верифікація. Але шлях до цієї ролі проходить через помилки та розчарування, поки людина не побачить результат у своїй роботі.

Що перетворює штучний інтелект з джерела розчарування на робочий інструмент

Коли наша команда вперше почала використовувати штучний інтелект, деякі розробники працювали з Claude Code, інші пробували OpenAI Codex, GitHub Copilot або Gemini CLI, і кожен інструмент давав різний результат. Тому, коли ми вирішили впорядкувати роботу команди з штучним інтелектом, першим кроком було визначення єдиного інструменту.

Це не лише наша практика. Возьміть історію команди Linear: до початку 2026 року вони працювали за принципом “хай кожен працює так, як йому підходить”, а в січні керівництво змінило цей підхід і перейшло на єдиний спосіб роботи — обмеживши вибір двома інструментами штучного інтелекту та попросивши розробників писати код лише за допомогою них, а не вручну. За словами компанії, середня продуктивність зросла вже наступного місяця на 30% за злитими запитами та на 33% за завданнями, виконаними на одного інженера.

Однак лише спільний інструмент сам по собі не покращує код — його потрібно налаштувати: встановити правила, щось на зразок rules.md, які описують, як писати код — які підходи слід дотримуватися, що уникати. Потім слід додати спеціальні навички для завдань, типових для вашого проєкту, щоб не доводилося пояснювати одну й ту ж річ знову і знову. І, нарешті, варто вказати агенту на вашу існуючу базу коду: він аналізує, як написаний проєкт, і генерує новий код у тому ж стилі, а не у загальному. Чим більше контексту отримує інструмент, тим менше вам доводиться переписувати код вручну пізніше.

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

Як тільки команда починає працювати узгоджено, залишається одна瓶ячка — перевірка — і варто її посилити штучним інтелектом. Агент перевіряє кожен запит на злиття спочатку та бере на себе очевидне: звичайні помилки, стиль, повторення, пробіли в безпеці. Людський рецензент уже не дивиться на все без розбору, а лише на архітектуру та критичні рішення. Ефект помітний навіть у самих компаніях, які будують ці інструменти: у Anthropic після впровадження такого агента частка запитів на злиття, які отримують суттєву перевірку, зросла з 16% до 54%, а інженери не погоджувалися з menos ніж 1% його коментарів.

Для нас це скоротило цикл перевірки, який раніше тривав два-три дні за кілька раундів, і зняло з наших старших інженерів рутинну роботу, залишивши їм лише真正ні складні місця. Як тільки інструмент нарешті почав давати результати, які не потребували переписування, довіра до нього з’явилася теж.

Де довіра до інструментів штучного інтелекту виправдовується

По-перше — у написанні коду: коли інструмент знає проєкт, а агент обробляє першу перевірку, команда пише більше та краще за той же час. У нашому випадку інструменти штучного інтелекту прискорили роботу приблизно на 30-40%.

Поза тим, штучний інтелект полегшив процес налаштування. Коли нова людина приєднується до проєкту, досвідчена особа зазвичай мусить відповісти на десятки питань про структуру коду проєкту. Тепер агент бере на себе цю роль: якщо проєкт добре задокументований, новачок звертається з 95% цих питань до агента, а не до колег.

Схожа ситуація з документацією: приблизний архітектурний проєкт, який раніше забирав години, тепер у більшості випадків написаний самим агентом — за нашими оцінками, близько 80% проєкту, якщо ви йому надасте достатньо контексту. Що залишається людині, це те, чого немає у репозиторії — рішення, компроміси, експертиза.

Найважливіше — бути чесним щодо меж того, що може зробити штучний інтелект, оскільки саме завищені очікування породжують розчарування спочатку. Штучний інтелект не бере на себе питання відповідності вимогам — людина підписує документи, що містять медичні або фінансові дані, а компанія, а не модель, несе відповідальність за витік.

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