Playwright та TypeScript без знання TypeScript: інженер, шар ШІ та чотири контрольні точки.

Репозиторій, який можна клонувати, що містить функції Skills та Rules, а також Playwright, керований MCP, який самостійно аналізує додаток, легко обіцяти, але важко реалізувати. Цей проект вже існує у вигляді функціонального проекту: клонуйте його, виконайте одну команду, і тести будуть працювати на живому сайті. Історія його створення почалася зі старої системи тестування та запитання щодо використання різних мов програмування.

Міграція, яка так і не отримала схвалення

Команда з тестування протягом чотирьох років намагалася розвивати стару систему тестування на основі Selenium, а деякі колеги, які згодом перейшли у відділ розробки, знали про неї ще довше. Її основою були тисячі тестів інтерфейсу на C#, накопичених протягом років авторами, які переважно вже покинули компанію. Перехід на Playwright давно був у списку бажань — він швидший, стабільніший та зручніший у використанні, але цей перехід так і не відбувся.

Причина була звичайною. У нікого не було сотні зайвих годин інженерної роботи, які можна було б витратити на переписування коду, яке не мало жодної комерційної цінності, а менеджер не може схвалити проект лише через те, що „новий інструмент працює краще“. Технічні аргументи завжди є, проте чим більша система, тим дорожчим стає її міграція, а користь від неї здається ще меншою. Переписування коду потрібно оплачувати заздалегідь та повністю. Його ефективність ніколи не відображається у цифрах у звітах: вона проявляється у меншій кількості невдалих тестів та швидшому виправленні проблем протягом кількох років. Тому ця ідея залишилась нереалізованою. Playwright та TypeScript постійно з’являлися у все більшій кількості оголошень про роботу, а бездіяльність ставала все дорожчою як для проекту, так і для особи.

Потім інша команда розпочала щось нове, починаючи з чистого аркуша: без спадщини, без купи тестів, які не можна порушувати, та без необхідності міграції. Пропозиція створити автоматизацію інтерфейсу користувача та API нарешті привела до використання Playwright та TypeScript у щоденній роботі. Це також виявило неприємний факт: Java та C# були знайомі, і за ними стояло десять років коду тестів, але це були тести, а не розробка, що вимагає іншої глибини знань. JavaScript, TypeScript та сам Playwright були новими. Виникло питання, яке два роки тому звучало б риторично: наскільки незнання мови може стримувати когось у 2026 році, коли існує штучний інтелект?

Звідки виник експеримент

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

Дві речі сприяли цьому в одному напрямку.

Один з спроб був здійснений ботом для торгівлі криптовалютами, написаним на Python за допомогою Claude Code людиною, яка не знала Python. Робота розпочалася з емоцій від першого успіху, але закінчилася крахом, коли код став незрозумілим для всіх, і ніхто не міг пояснити, чому провалюються тести чи як їх виправити. Урок полягав у різниці між створенням коду та побудовою системи: бот працював, проте його не можна було підтримувати. Не існувало жодної карти проекту, виправлення призводили до нових проблем, а токени зникали під час безкінечних описів симптомів замість пошуку причин.

Ще один поштовх надійшов зі щоденної роботи, де ШІ почав проникати у процедури тестування. Експерименти стосувалися цілого ланцюжка від завдання до завершеного тесту, формулювання правил, щоб модель слідувала їм до останньої літери, та забезпечення того, щоб весь процес був повторюваним та контрольованим. Колеги використовували ШІ як розумну пошукову строку чи машину для генерації коду. Майже ніхто не створював систему, яка б зробила його прогнозованим, що здавалося марною можливістю, адже саме систематична частина має цінність.

Ці два напрямки призвели до проекту Playwright, сформульованого як гіпотеза: наскільки далеко може зайти інженер із міцними основами, коли ШІ виконує набір тексту, і чи можливий повноцінний фреймворк тестування без написання жодної рядка мовою, яку інженер не може вільно читати?

Чому TypeScript, а не C# чи Java

Перша перевірка була очевидною. Playwright також існує для C# та Java, тож, можливо, зміна мови була зайвою. Виявилося, що різниця полягає не у керуванні браузером. Ця частина однакова всюди: там та сама API, ті самі селектори та ті самі браузери. Різниця полягає у тому, як організовані та виконуються тести.

У JavaScript та TypeScript Playwright постачається з вбудованим засобом виконання тестів, який підтримує паралельну обробку, фіксати, звіти та автоматичний трекінг. Для C# та Java такого засобу немає. Команди використовують те, що вже є в їхній екосистемі — чи то xUnit, NUnit, JUnit чи TestNG, — а Playwright лише надає для них базові класи, тож організація роботи та паралелізм створюються вручну. Саме це є справжньою обмеженням: не дивна синтаксис чи відсутній метод, а необхідність заново створювати все — включаючи паралелізм, ізоляцію даних за потоками, інфраструктуру та звітність, — проблеми, які вже були вирішені та краще уникати. Поруч із цим існувала опція, яка була готова до використання, але написана мовою, яку ніхто не знав. Playwright розвивався разом із JavaScript, тому це є його вбудованою частиною, а не стороннім інструментом.

Що насправді означає „створено без знань“

Називати цей проект створеним без належних знань — це не просто неточно. Це буде відверта брехня. За цим стоять десять років досвіду у тестуванні: розробка процесів з нуля та тестування систем усіх типів — від веб-додатків та API до мобільних додатків. Саме цей досвід допоміг уникнути ситуації, коли робота була б поглинута морем створеного коду. Синтаксис TypeScript та Playwright завжди залишався непередбачуваним фактором.

Кілька курсів допомогли. Як під час попередніх експериментів, так і під час цього проекту, кілька курсів Anthropic присвятовувалися розробці агентів, поєднанню навичок та сформулюванню завдань для ШІ. Вони доповнювали досвід, але не замінювали його. Важливим був підхід. Проект виник не внаслідок ідеї програміста, який просив провести тести, а завдяки інженеру, який визначив для моделі правила, архітектурні обмеження та те, що потрібно перевірити, а потім дозволив їй діяти в межах цих рамок, що перетворило хаотичний обмін на організований процес.

Каркас із двома застереженнями

Перед описом структури та її рішень потрібно зазначити два моменти.

По-перше, цей проект є лише скелетом, а не готовим продуктом, який можна взяти, адаптувати чи змінити. Він поділяється для демонстрації підходу, а не для ствердження досконалості. Ті, хто шукає готовий інструмент, будуть розчаровані, тоді як ті, хто шукає модель для створення системи на основі ШІ, знайдуть її. У командах є власні обмеження, вимоги до безпеки та інтеграції, і дизайн, придатний для публічної демонстрації, може потребувати суттєвої переробки в умовах корпоративних механізмів SSO, MFA, спеціальних правил для тестових даних та системи керування тестами. Тож логіка, яка лежить в основі коду, є тією частиною, яку можна перенести.

По-друге, набір інструментів був мінімальним. Він складався з Claude Code за базною щомісячною підпискою в двадцять доларів, Visual Studio Code як редактора, налаштованого сервера MCP для Playwright, який дозволяє моделі самостійно досліджувати додаток, та, мабуть, найважливіше — свіжого розуму та трохи вільного часу. Не було жодних дорогих корпоративних рішень, складної інфраструктури чи розподілених засобів для тестування. Усе працює на звичайному ноутбуці, що є частиною суті: для початку роботи не потрібно нічого надприродного — лише розуміння того, що будується, та бажання це зробити.

Що охоплює проект та як він структурований

Метою є Toolshop — публічний демо-інтернет-магазин, створений для практики автоматизації. Вибір має значення: це не закрита система, немає бізнес-контексту, тож будь-хто може скопіювати репозиторій, встановити залежності за одним командним запитом та запустити тести на живому сайті, без необхідності створювати облікові записи чи шукати документацію.

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

config/
 env.ts // The only place where environment variables are read
 timeouts.ts // Timeouts, also in one place
core/
 run-user.ts // The user registered by this specific run
 global-setup.ts // Register → UI login → data snapshot → download OpenAPI spec
 global-teardown.ts // Cleanup after the run: remove favorites and the user
 allure-labels.ts // Parses [Section / Subsection] from the test name into report structure
 allure-categories.ts // Buckets for triaging failures in the report
api/
 generated/schema.d.ts // Types generated from OpenAPI, never touched by hand
 types.ts // Domain types derived from the schema
 client.ts // openapi-fetch, paths and params checked by the compiler
 contract.ts // Runtime validation of API responses against the schema
 auth.api.ts // Typed clients on top of api/client.ts
pages/
 base.page.ts // Base page class
 components/ // Elements present on every page (site header)
 auth/ // Page Objects for authorization pages
 account/ // Account area: account, profile, favorites
 shop/ // Catalog, product page, checkout
fixtures/
 base.fixture.ts // All dependency injection, test/expect only imported from here
data/ // Strings and routes, so they don’t live inside tests
utils/ // Logger, reference data snapshot
tests/
 auth/ // Everything auth-related in one folder
   auth.api.spec.ts // API: login, token lifetime
   registration.api.spec.ts
   login.ui.spec.ts // UI: login form, errors, logout
 catalog/
   products.api.spec.ts
   catalog.ui.spec.ts
 cart/
   cart.ui.spec.ts
 favorites/
   favorites.api.spec.ts
   favorites.hybrid.spec.ts // Hybrid: state via API, verification via UI
 profile/
   profile.hybrid.spec.ts
 contract/
   contract.api.spec.ts // Matching live API responses against the spec
 demo/ // Tests tagged @demo that fail on purpose
docs/ // Feature maps, checklists, test cases, plans
.claude/ // AI layer: rules, skills, agents, hooks```

Рішення щодо структури, які дозволяють масштабування

• Спочатку функції, потім шари. Одне рішення спочатку може здатися дивним, але саме воно визначає, наскільки добре все буде масштабуватися: тести групуються за функціями, а шар є суфіксом імені файлу, як у login.ui.spec.ts, auth.api.spec.ts та checkout.hybrid.spec.ts. Розробник, який змінює логіку авторизації, знаходить усі відповідні тести під tests/auth/ та не повинен переглядати три папки. При тридцяти тестах це ніхто не помічає, а структура за принципом шарів виглядає охайною. При трьохстах тестах tests/ui/ перетворюється на купу з шістдесяти файлів, оскільки зміна функції впливає на кожен тест, який до неї належить, незалежно від шару. Розкидані тести перетворюють аналіз на пошук.
• Коли навіть папки з функціями заповнюються до краю. Завдяки тисячам тестів папка з функцією може розростися до сотень файлів. Наступним кроком є створення підпапок за підфункціями чи сценаріями, таких як tests/auth/login/, tests/auth/registration/ та tests/auth/password-reset/, що продовжує ідею зберігання контексту поруч із кодом. Так само сотні тестів не повинні знаходитися в одному файлі, адже це створює нерозбірливий та неможливий до перегляду „монстр“.
• Гібридний підхід як відправна точка. Демонстраційний приклад поділяється на тести API, інтерфейсу та гібридні тести, але справжній проект не обов’язково має відповідати цій структурі чи мати три шари для кожної функції. Може не існувати окремого API, який варто було б тестувати, або тести інтерфейсу вже можуть бути гібридними, з попередніми умовами, встановленими через API чи базу даних, причому перевіряється лише та частина, що стосується інтерфейсу, у браузері. Це є прийнятним, адже розділення заради самого розділення — це помилка. Складання гібридних тестів інтерфейсу з самого початку дозволяє уникнути чистих тестів інтерфейсу, які передають стан через браузер та займають багато часу. Структура є засобом, і кожна додаткова абстракція потребує додаткового обслуговування.

Чотири рішення, які пояснюють решту

У репозиторії описано чотирнадцять архітектурних рішень у файлі .claude/rules/architecture.md, причому кожне з них відповідає на запитання «чому саме так», а не «що це». Чотири з них описані тут, оскільки решту краще залишити у репозиторії, ніж переказувати їх знову.

Кожен запуск реєструє власного користувача

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

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

Той самий логічний підхід дає retries: 0. Повторна спроба виконання слугує лише засобом приховування проблем, а не страхуванням: вона приховує справжню ситуацію конкуренції та відкладає наслідки до моменту, коли це завдасть найбільшої шкоди. Тест, який потребує повторної спроби, не є ненадійним, але фіксує проблему із ізоляцією, і такий звіт потребує розгляду. Витрати чітко вказані: у демо-версії реєстрація користувача вимагає одного запиту та завжди успішна, тоді як в інших випадках механізм буде відрізнятися.

Типи походять із специфікації, а тест контракту перевіряє цю специфікацію

Це два різні види перевірок, які постійно плутають.

• Перша — це перевірка на етапі компіляції. API має документ OpenAPI, з якого генеруються типи, тож поле, на яке посилається код, але якого немає у специфікації, заважає проекту скомпілюватися. Це займає дві секунди та не вимагає запитів до сервера.

Другий тест перевіряє, чи справді сервер відповідає власним специфікаціям. Генерований тип не може цього довести, адже він підтверджує лише відповідність документу. Тести за контрактом взаємодіють із реальним API та порівнюють справжні відповіді зі схемою. Вже під час першого запуску вони виявили розбіжність у шляху: у документі було зазначено products/{productId}, тоді як у коді використовувався products/{id}. Іншого разу вони показали, що фільтр каталогу викликав функцію by_category_slug, параметр, якого взагалі немає у специфікаціях. Сервер його приймає, і тести проходять успішно, тож усе „функціонує“. Але параметр, що не входить до контракту, не може відхилятися від нього — він може просто зникнути без сліду одного дня.

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

Токен, який діє триста секунд

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

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

Дані зі знімка стану — один раз, а змінний стан — ніколи

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

Очищення також діє за цією ж логікою. Воно виконується по порядку: спочатку об’єкти, а потім їхні власники, і ніколи не зазнає невдачі; обмежені права лише викликають попередження. Невдале завершення процесу перетворює один червоний тест на червоний запуск із неправильним поясненням — це найгірший вид червоного статусу.

Шар ШІ

Розгляньмо, що відбувається, коли Claude Code відкривається у папці проекту та отримує запит «написати тести для кошика». У моделі є лише цей запит. Вона не знає, що спільні облікові записи заборонені, що локатори мають походити з підтвердженої карти, або що використання глобального лічильника у паралельному наборі тестів є пасткою. Вона припускає, і робить це досить добре, тож код виглядає пристойно та, ймовірно, працює. Більшість людей зупиняються на цьому етапі та називають це роботою з ШІ.

Шар ШІ перефразовує проблему. Питання більше не полягає у тому, що припустить модель, а у тому, що вона повинна знати та що вона, можливо, ніколи не зробить. Його складають п’ять компонентів, кожен з яких виконує свою функцію.

• CLAUDE.md, завжди завантажується. Це файл у корені проекту, який завантажується на початку кожної сесії. Він виконує функцію ознайомлення з проектом для нового співробітника, у цьому випадку — моделі, інформація представлена на двох екранах: що таке проект, де знаходяться елементи, п’ять найважливіших моментів та що категорично заборонено. Слово „завжди“ визначає обмеження, адже кожна розмова оплачує завантаження файлу в контексті цієї розмови. У файл включається лише те, що потрібне щоразу. Сорок стилістичних правил знаходяться у окремому файлі, на який він посилається.

правила/, причини, а не команди. Ці файли містять архітектурні рішення, конвенції кодування та процедури браузерів. Інструкція говорить про те, що не слід поміщати токен у змінну. Правило пояснює, що токен існує триста секунд, тож той, який піднімається на вершину, гине під час виконання та спричиняє помилку 401 у найповільнішому тесті. Маючи причину, моделі не потрібен конкретний заборонний наказ: вона розуміє категорію проблеми та виявляє її в незнайомому середовищі.

навички/, процедури з контрольним етапом. Навичка — це посібник для виконання однієї задачі: кроки, опис, фрази-тригери, визначена модель та список дозволених інструментів. Список інструментів є справжньою обмеженням, а не документацією. Навичка, яка створює тестові випадки, не може виконувати команди, тому не може почати тестування просто на випадок, як би вона не прагнула цього.

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

хуки/ — примусові та не запам’ятовуються. Правило у прозовій формі діє стільки, скільки хтось його пам’ятає, тому найбільш суворі заборони перетворюються на хуки: невеликі скрипти, які запускаються перед дією та можуть її заблокувати. Створені типи та файл .env є незмінними. Команди git push --force, --no-verify та --amend автоматично відхиляються. Хук не переконує та не пояснює нічого після цього. Дія не відбувається, а у відповіді вказується причина та правильний шлях.

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

Той самий рівень у живому замовленні

Абстракції мають сенс лише тоді, коли через них проходить реальне завдання. Візьмемо PROJ-431 — «оплата замовлення карткою». Звичайний порядок виконання робіт не має нічого спільного з ШІ: хтось тестує функцію вручну, хтось складає чек-лист, хтось перетворює його на окремі випадки, хтось автоматизує їх. Одна людина може виконати всі чотири кроки, або їх можуть розділити між трьома людьми. Для конвеєра не має значення, хто це робить, і саме в цьому суть, адже конвеєр додається до існуючого процесу, а не замінює його. Номер завдання є тією ниткою, яка проходить крізь усе; його використовують замість назв функцій чи гілок, тому що він залишається незмінним під час перейменувань та перерозподілу обов’язків.

Перший крок: чек-лист

Інженер з перевірки якості активує навичку та передає їй номер. Оскільки MCP підключений до Jira, навичка безпосередньо читає тикет, включаючи опис, критерії прийняття та, що часто є найкориснішим, коментарі, де розробник пояснив половину функціоналу, не оновлюючи опису. Якщо MCP відсутній або тикет порожній, інженер описує функцію у запиті. Пайплайн потребує вхідних даних та не звертає уваги на те, звідки вони походять.

Потім починається етап, для якого все було створено. Ця функція не формує список перевірок на основі тексту заявки; вона запускає агента для дослідження, який входить у додаток у локальному чи тестовому середовищі, відвідує сторінки функції, натискає на елементи, читає актуальний DOM, самостійно викликає API та порівнює отримані відповіді з технічними вимогами. Лише після цього складається список перевірок на основі того, що насправді існує, а не на основі того, що обіцялося у заявці. Критерії прийняття є вхідними даними, а не істиною, і половина їхніх неузгоджень із реальністю є першими багами завдання, які виявляються ще до створення будь-якого коду.

У результаті створюються два файли, і найважливішим уроком тут є їх розділення. Перший — це чек-лист: сценарії бізнес-операцій у форматі команди, а не перевірки елементів. Червона рамка навколо поля не є сценарієм; але користувач, у якого блокується картка іншої особи з поясненням причини, є сценарієм. Другий файл — це карта функцій, яка містить перевірені місцезнаходження, поля API, правила верифікації та проблеми, виявлені під час роботи. Чек-лист є прямим результатом виконання завдання, а карта слугує основою для подальших кроків. Інженер з тестування читає чек-лист, видаляє непотрібне, додає те, що знає лише він, і цей огляд є контрольним етапом: ніщо не може перейти далі без схвалення.

Другий крок: тест-кейси

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

• Правила, які застосовує сервер, стають тестами API.
• Елементи, які бачить користувач, стають тестами UI.
• Перевірка, яка вимагає п’ятнадцяти клацань для налаштування однієї твердження, стає гібридною — стан створюється через API, а лише видима частина перевіряється вручну.

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

Третій крок: автоматизація

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

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

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

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

Заборони тут є окремими та не підлягають обговоренню:

• Не вимикайте неуспішний тест, щоб запуск став «зеленим».
• Не збільшуйте кількість спроб.
• Не таємно послаблюйте перевірки, щоб вони відповідали спостережуваній поведінці.

Якщо додаток поводиться неправильно, правильним результатом є червоний тест.

Четвертий крок: перегляд та затвердження

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

Коли весь процес завершується, PROJ-431 містить повну інформацію: що було досліджено, що обрано для перевірки, що автоматизується, що залишається вручну та що не буде автоматизовано та чому. Причина цього — не любов до документації. Через шість місяців під час аналізу результатів хтось запитає, чому певний сценарій не було розглянуто, і на це запитання має бути відповідь.

Що залишається після завершення завдання

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

• Правила залишаються в силі протягом усього проекту та змінюються лише разом із кодом.
• Карта функцій існує роками та належить до функції, а не до замовлення. Її розширюють додаванням розділів із датами, нових сторінок та нових проблем, проте її ніколи не перебудовують для кожного окремого завдання.
• Чек-листи, кейси та плани належать до одного завдання та стають частиною історії після його закриття.

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

Жоден з цих підходів не є універсальним рецептом. Чотири кроки у процесі обробки даних, п’ять компонентів шару ШІ, ворота та терміни життя артефактів — це лише одна з можливих комбінацій. Команди відрізняються за кількістю співробітників, продуктом та інструментами, тому половина деталей буде реалізовуватися по-різному. Деякі рішення спрацюють, деякі потребуватимуть коригувань, а деякі не спрацюють, і це є прийнятним.

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

Чи все ще потрібні старші спеціалісти?

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

Раніше інженерів цінували за написання коду, знання синтаксису та швидке виконання завдань, що мало сенс, оскільки код був основним продуктом. З появою ШІ ця цінність змінилася в кілька разів, а не лише на кілька відсотків. Машина пише код, а людина вирішує, що писати, чому, в яких межах та як перевірити, що результат є правдивим.

Уявіть двох спеціалістів. Перший відкриває Claude Code та просить написати тест на входження. Тест пишеться та проходить, і спеціаліст відчуває себе продуктивним, що справді так і є сьогодні. Через місяць тест перестає працювати, причина залишається загадкою, патчі вносяться випадково, токени витрачаються, і зрештою все переписується або тест видаляється та забувається.

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

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

Чи означає це, що необхідно вивчати мову програмування?

Так, але не для написання коду. Потрібна мова, щоб зрозуміти те, що створила ШІ, виявити помилки в генерованому коді, переглянути запити на інтеграцію та вирішити, що потрапить до основної гілки. Синтаксис — це інструмент. Складна структура, заснована на пам’яті, є недосяжною для тестувальника у незнайомій сфері, але архітектура — це відома територія: як має виглядати система, як тести залишаються ізольованими, як організовані пайплайни та що має міститися у хорошому звіті. Саме ця основа зробила проект Playwright можливим.

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

Компанії не потребують людей, які лише натискають кнопки та пишуть запити в Claude Code чи Cursor. Таких людей багато, і їх буде ще більше; ринок переповнений програмістами, які вважають, що знайшли скарб, але це триває лише короткий час. Потрібні люди, які розуміють, чому ШІ зробив щось певне, помічають, коли він помиляється, сформулюють завдання так, щоб модель повертала функціональне рішення, а не відшліфовану помилку, та створюють системи замість того, щоб постійно вводити токени у безкінечні цикли „спробуй знову, не так“.

Досвід у обробці даних, автоматизації та створенні потоків роботи — це не щось архівне. Це основа ефективної роботи з ШІ та те, що відрізняє людину, яка створює хаос, від тієї, хто будує систему. Раніше знання допомагали виконувати завдання вручну. Тепер вони слугують для постановки завдань для ШІ та перевірки результатів. Роль змінилась, але цінність експертизи залишилась незмінною. Це, мабуть, легше побачити, адже поруч із ШІ стає зрозуміло, хто просто генерує, а хто розуміє, що було створено та чому.

Що показує експеримент

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

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

Штучний інтелект не замінює інженера. Він стає найшвидшим та найслухнянішим „молодшим співробітником“, якого тільки можна собі уявити — невтомним, який ніколи не сперечається та завжди готовим до нової спроби. У нього є одна особливість: він пропонує як правильне рішення, так і повну нісенітницю з однаковою впевненістю, і лише той, хто розуміє суть роботи, може їх розрізнити. Тож інженер мусить залишатися керманичем — тим, хто знає пункт призначення та шлях, а не просто тим, хто тримає кермо.

Пов’язані матеріали

• MAF 1.0, LangGraph чи CrewAI? Вибір фреймворку агента у 2026 році — Порівняння Microsoft Agent Framework 1.0, LangGraph та CrewAI за рівнем функціоналу, пам’яті, можливостями відлову помилок, протоколами, шляхами в Azure та витратами, із коротким алгоритмом прийняття рішення та схемою впровадження.

Інженерія циклів: чотири вкладені цикли для самовдосконалюваних AI-агентів — Як чотири вкладені контрольні цикли (ReAct, повторна спроба, черга, підйом по схилу) разом із механізмом оцінки, індикатором бюджету та перевіркою на зміни роблять агента надійним, на прикладі процесу схвалення страхових полісів.