Розмови про те, що штучний інтелект незабаром замінить програмістів, тривають уже кілька років. Водночас інша крайність — тотальний скептицизм щодо практичної цінності ШІ-інструментів — теж нікуди не зникла. Між цими двома позиціями існує прагматична середина, яку компанія E-Docs знаходила методом послідовних проб з 2024 року.
Результат: скорочення часу виконання завдань у середньому на 30%, 70–90% коду пишеться за допомогою ШІ-агентів, а щомісячні витрати на інструментарій — від 15 до 300–400 доларів на розробника. Zк це стало можливим і чому «просто використовувати ШІ» — недостатньо?
Від чат-бота до агента в середовищі розробки
Перший контакт команди зі штучним інтелектом відбувся через ChatGPT — як через звичайний чат. Розробники ставили запитання, отримували відповіді, але відчутного ефекту не було. Проблема полягала в тому, що інструмент існував окремо від середовища, в якому люди реально працювали.
Наступним кроком стало впровадження PR Agent — безкоштовного рішення з відкритим кодом від розробників корпоративної системи Qodo (раніше — Codium). Він інтегрується безпосередньо в процес code review: аналізує pull requests, знаходить потенційні проблеми, пропонує покращення. Вартість використання на кластері з 300–400 PR на місяць — не більше 15 доларів, витрачених на мовну модель.
Ефект був відчутний одразу. Якщо раніше перевірка невеликого pull request займала 15 хвилин, складного — від години до чотирьох, то після впровадження ці цифри скоротилися до 5 хвилин і 30–90 хвилин відповідно. Для тих завдань, що раніше вимагали чотирьох годин, зараз достатньо години-півтори.
Cursor: редактор, який прийшов завтра
Другий етап — впровадження Cursor як основного середовища розробки з вбудованими ШІ-агентами. Вибір відбувався серед кількох альтернатив через відкрите дослідження: кілька розробників отримали завдання протягом двох місяців вивчати різні інструменти та ділитися досвідом на регулярних сесіях.
Ключовим критерієм відбору стала швидкість впровадження. Одні рішення вимагали двох місяців налаштування, Cursor пропонував почати вже наступного дня. При цьому він зовні схожий на VS Code, яким команда користувалася раніше, — нижчий поріг адаптації.
Зручність у цьому контексті означала не лише інтерфейс, а й вирішені питання безпеки та аутентифікації. Команді не довелося будувати цей контур безпеки з нуля — питання приватності, аутентифікації та режиму роботи з кодом були частиною оцінки продукту ще до впровадження.
Три режими роботи агента і що вони дають
Cursor дозволяє використовувати агентів у трьох режимах. Спочатку — Ask: розробник досліджує кодову базу, ставить питання, розбирається в нюансах. Потім — Plan: агент складає план реалізації або виправлення. Нарешті — Agent: автономне виконання описаного плану.
Рутинні завдання, що раніше забирали час і знижували мотивацію — наприклад, додати переклади для 20 нових ключів на 5 мовах — тепер займають хвилини. Розробник описує, які ключі потрібні та які значення має кожен із них українською, агент перекладає все самостійно.
Unit-тести — окремий показовий кейс. Якщо раніше на чотириденну задачу додатково закладали цілий день для написання тестів, зараз на це йде година. Агент аналізує код, визначає, що варто тестувати, і реалізує тести самостійно.
Статистика після шести місяців використання
Cursor використовується в команді з вересня 2024 року. Перші узагальнені результати:
Середній час виконання завдань скоротився на 30%, і ця цифра продовжує зменшуватися — разом із зростанням навичок команди.
70–90% коду тепер пишеться за участю ШІ-агентів. CTO особисто — близько 90%, в середньому по команді — приблизно 70%, оскільки частина розробників ще перебуває на етапі освоєння.
Кількість помилок, що повертаються після передачі в продакшн, помітно зменшилась. PR Agent на рівні code review відсіює значну частину проблем до того, як вони потрапляють у гілку.
Ці цифри — не разова оцінка і не лабораторний бенчмарк. 30% економії часу та зменшення кількості помилок виведено з порівняння типового часу проходження задач, тривалості code review і кількості повернень після передачі в продакшн за внутрішніми трекерами та регулярними зрізами команди. Це практична операційна метрика, яка узгоджується з реальним темпом роботи, а не з умовами тестового середовища.
Важливий момент: код, створений за участі AI-агента, не має спрощеного шляху в продакшн. Він проходить той самий процес — review іншими розробниками, перевірку PR Agent, автоматизовані тести і фінальне рішення відповідального інженера. Агент прискорює підготовку рішення, але не замінює інженерну відповідальність.
Чому ШІ підвищує цінність досвідченого розробника — а не скасовує її
Найпопулярніший страх — що ШІ замінить програмістів — команда E-Docs вважає хибним. Правильніший висновок протилежний: ШІ сильніше підсилює тих, хто має системне мислення, і водночас швидко проявляє прогалини в базових інженерних навичках.
Причина проста. Щоб ефективно використовувати агента, потрібно коректно описати задачу. Щоб коректно її описати — потрібно розуміти архітектуру, шаблони проєктування, бізнес-контекст. Без цього агент напише щось — але не обов’язково те, що потрібно.
Великі enterprise-проєкти з мільйонами рядків коду не можуть бути «осягнуті» мовною моделлю цілком. Розробник повинен самостійно дослідити релевантну частину кодової бази, сформулювати чіткий контекст і лише потім ставити завдання агенту. Після виконання — перевірити результат згідно зі своїм описом.
Фактично досвідчений розробник перетворюється на оркестратора: він не пише код рядок за рядком, а управляє агентами, перевіряє архітектурні рішення, приймає кінцеві рішення. Той, хто не може самостійно реалізувати завдання, не зможе ефективно делегувати його агенту.
Як команда вчилась: внутрішні сесії замість зовнішніх консультантів
E-Docs свідомо відмовилась від залучення зовнішнього ШІ-консультанта для вибору інструментарію. Логіка: консультант запропонує рішення, яке він вже знає і рекомендує іншим. Розробник, який досліджує самостійно, обере те, що буде йому зручно в щоденній роботі.
Дослідження тривало з кінця червня по серпень 2024 року — два місяці щотижневих сесій по 1,5–2 години, де розробники ділилися тим, що знайшли. За підсумками цих зрізів і було обрано Cursor.
Після впровадження команда записала серію навчальних сесій — внутрішній курс із прикладами використання різних режимів і типових сценаріїв. Як показала практика, до цих матеріалів зверталися ті, хто не міг самостійно побудувати ефективний робочий процес з агентами.
Крива навчання виявилась нерівномірною: комусь вистачило одного дня після загального обміну досвідом, іншим знадобилось місяць-півтора. Розробники, які довго не могли зрушити з місця, як правило, або покладались на агента повністю — і отримували десяток нових помилок після реалізації, — або не вірили в корисність інструменту і використовували його формально.
Питання безпеки: що реально ризикує витекти і що ні
Питання конфіденційності коду — одне з головних серед корпоративних замовників, які розглядають ШІ-інструменти. E-Docs вирішувало його ще на етапі вибору: безпека була одним із критеріїв відбору поряд зі швидкістю впровадження.
Cursor підтримує приватний режим роботи: у Privacy Mode код не використовується для навчання моделей, а для провайдерів застосовується Zero Data Retention. Водночас команда окремо перевіряла, які технічні дані можуть оброблятися або тимчасово кешуватися для роботи інструменту. Це частина належної експертизи перед впровадженням, а не сліпа довіра до маркетингових формулювань вендора.
Повністю виключити передачу коду на зовнішні сервери неможливо — це вимога будь-якого хмарного ШІ-сервісу. Але різниця між «код передається для обробки» і «код зберігається і може бути використаний повторно» є принциповою. Вендори, що будують бізнес на ШІ-продуктах для розробки, зацікавлені саме в тому, щоб ця межа була чіткою.
Codex як наступний крок: керованість і економіка масштабу
Після етапу з Cursor команда не зупинилася на тому, що вже працює. Для нас AI-інструменти в розробці — не разове впровадження, а постійний процес оптимізації. Ринок змінюється швидко, тому інструмент, який півроку тому здавався найзручнішим, не обов’язково залишається найкращим для всіх сценаріїв сьогодні.
Останнім етапом став перехід на Codex. Це не було рішення на хвилі моди — команда розмірено порівнювала Codex із Claude Code: дивилися на якість виконання типових задач, швидкість, зручність роботи з власною кодовою базою, поведінку на великих змінах і вартість. Claude Code теж показував добрі результати, але для наших сценаріїв Codex показав краще співвідношення результату і витрат. Це принципово, бо коли інструментом користується не одна людина, а команда, навіть невелика різниця у вартості на одного розробника швидко масштабується в суттєвий бюджет.
Окремо варто зазначити: у квітні 2026 року OpenAI перейшов на token-based pricing для Codex, тому будь-які числові порівняння залежать від структури використання конкретної команди. Наша оцінка економіки відображає сценарії і профіль навантаження E-Docs, а не універсальну тезу про те, що Codex дешевший за альтернативи в усіх випадках. На іншій структурі використання співвідношення може виявитися іншим — і саме тому ми наголошуємо на власних метриках, а не на абстрактному порівнянні цін.
Ми дивилися не лише на те, чи може агент виконати задачу, а й на те, скільки коштує стабільне використання цього підходу в реальній командній роботі. Фактично команда рухається до моделі, де AI-агент стає стандартною частиною інженерного процесу. Він допомагає швидше проходити рутину, готувати зміни, писати тести, аналізувати кодову базу — але відповідальність залишається на інженері. Роль розробника стає ще більш архітектурною: правильно поставити задачу, дати контекст, перевірити рішення, зрозуміти, чи воно справді відповідає бізнес-цілі.
Окремий напрям, який зараз запущено, — пілот Codex у тестуванні. Команда перевіряє, наскільки агент може допомагати QA: генерувати тест-кейси, аналізувати acceptance criteria, покривати типові сценарії автотестами, швидше знаходити місця, де зміна може зламати існуючу логіку. Це природне продовження того ж підходу: спочатку посилили розробку, тепер дивимося, як посилити контроль якості.
Принцип залишається незмінним: AI не впроваджується заради самого AI. Кожен новий інструмент проходить через практичне питання — чи економить час, чи зменшує кількість помилок, чи робить процес прогнозованішим, чи окупається в масштабі команди. Якщо відповідь «так» — рухаємося далі. Якщо ні — навіть наймодніший інструмент не має сенсу.
Якщо Cursor був етапом масового входу AI в розробку, Codex стає наступним кроком — більш керованим, економічно оптимізованим і придатним не лише для написання коду, а й для пілотування в тестуванні. Команда вже не просто експериментує з AI-асистентами, а вчиться керувати цілою системою агентів у розробці, code review і тестуванні. Головний принцип зберігається: фінальне інженерне рішення завжди залишається за людиною.
ШІ в продукті: від інструменту для команди до функції для клієнта
Паралельно з розбудовою внутрішнього інструментарію E-Docs інтегрує ШІ-агентів у саму платформу e-Docs. Наразі реалізовано кілька напрямів: автоматична класифікація документів під час імпорту, генерація короткого резюме по відкритому документу на основі всіх прикріплених файлів, розпізнавання сторін-підписантів і контрагентів.
У розробці — інтерактивний режим, де користувач зможе звернутись до агента в межах системи з довільним запитом: наприклад, отримати список документів, пов’язаних із конкретним контрагентом, або перевірити залишок відпусток.
Окремий принцип архітектури — права доступу. Продуктові агенти працюють лише в межах прав конкретного користувача. Якщо користувач не має доступу до документа, контрагента або HR-даних у системі, агент також не повинен мати можливості їх отримати. Аудит дій, ролі й обмеження доступу застосовуються до AI так само, як до будь-якої іншої функції платформи. Це знімає одне з ключових заперечень, які виникають у замовників, коли мова заходить про ШІ всередині корпоративної системи: агент не створює окремого контуру привілеїв і не обходить наявну модель безпеки.
Де ШІ-автоматизація недоцільна
Одна з ключових думок із досвіду E-Docs — не варто автоматизувати заради факту автоматизації. Перед впровадженням потрібно відповісти на три запитання: скільки ресурсів витрачається на процес сьогодні; скільки коштуватиме автоматизація та її підтримка; який реальний ефект у перерахунку на час і гроші.
Якщо витрати на підтримку автоматизованого процесу перевищують витрати на ручну роботу — автоматизація збиткова. Якщо процес, який планується автоматизувати, займає п’ять хвилин на тиждень, а впровадження коштує сотні тисяч — це теж не окупиться.
Практичний висновок: ШІ ефективний там, де є масштаб, де помилка людини коштує дорого, або де рутинна робота відволікає фахівця від завдань, які вимагають мислення. Там, де масштабу немає, або де процес і без ШІ займає секунди, — автоматизація лише ускладнює систему.
Підсумок
ШІ-інструменти в розробці — це не магія і не загроза. Це інфраструктура, яка сильніше підсилює тих, хто має системне мислення, і водночас швидко проявляє прогалини в базових інженерних навичках. Досвід E-Docs показує: 30% економії часу команди і 70–90% коду, написаного за допомогою агентів, — досяжні результати за реальних витрат у кілька сотень доларів на місяць. Але лише за умови, що команда розуміє, що вона робить, і не покладається на агента більше, ніж на власне судження.