Unit 16

Доброго ранку!

Цього тижня розглянемо найновіший тренд в програмуванні та автоматизації - використання ШІ, або точніше LLM, GitHubCopilot та Playwright Agents.

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

Наявні AI рішення

Думаю, ви вже ними користуєтесь, але давайте пригадаємо основні:

1. ChatGPT - розробка компанії OpenAI. Гарно справляється з текстом, кодом та зображенням.
2. Gemini - розробка від Google. Теж чудово працює з текстом, з кодом і картинками, а також вбудований в пошук google.
3. Claude - від Anthropic. Сильний з довгими текстами та кодом, приймає картинки та може аналізувати, але не може їх генерувати.
4. Mistral - від Mistral. Дуже швидкий, працює з текстом і кодом. (наразі не користувався, тож складно сказати більше).
5. Grok - від Ілона Маска (хАІ). Згідно останніх новин (січень 2026) Grok і Gemini можуть приймати до 2 мільйонів токенів. Що робить їх лідерами за обсягом вхідних данних (можна завантажити близько 1.5 мільйона слів, приблизно 20 годин аудіо або великі репозиторії з кодом).
6. DeepSeek Chat - від китайської компанії DeepSeek.

Це наразі найбільші гравці на ринку, але все може змінитись. Також варто зазначити, що в кожної компанії є декілька варіантів мовних моделей - наприклад ChatGPT-4, ChatGPT-5, Gemini 2.5 Pro, Claude Sonnet 4.5, Claude Opus 4.5, etc. Кожна з них має свої плюси і мінуси, як то розмір промпту та вхідних данних, а також чи доступ до моделі безкоштовний, чи тільки в платній підписці.

Важливою складовою кожної моделі є наявність АРІ, яке дозволяє використовувати АІ з коду чи підключити до застосунку.

Для того, щоб якісно використовувати АІ, спершу потрібно зрозуміти, як саме вони працюють.

LLM (Large Language Models)

По-перше, LLM (Large Language Model) – це не розум, не свідомість і не “мислення”. Тобто, ніякого "інтелекту" там немає.

LLM це:

Надзвичайно велика статистична модель, яка навчається вгадувати наступне слово (токен).

LLM не “знає”, що таке правда. Вона знає лише: «У подібних текстах після цього слова зазвичай іде ось це».

Приклад:

Київ — столиця ...

→ найчастіше → "України"

Не тому що LLM “знає географію”, а тому, що більшість текстів доступних моделі містять саме такий текст.

Як їх робота виглядає всередині

• Текст → числа
• Числа → обчислення
• Обчислення → ймовірності
• Ймовірності → наступне слово

LLM не вчать “розуміти світ”. Їх навчають надаючи мільярди текстів, а далі вони вгадують пропущені слова.

Моделям "згодовують": інтернет, книги, статті, документацію, а також форумні срачі та коментарі.

Тобто модель бачить:

If A then usually B
If B then usually C

Так формується величезна мережа статистичних зв’язків.

Важливо зрозуміти, що LLM не бачать слів, замість цього існує механізм, що розкладає текст на токени і назад.

Приклад:

У вигляді токенів той самий текст виглядає:

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

Далі використовуючи токени, модель шукає найбільш вірогідний результат відповіді та видає його. Не на основі слів, на основі токенів. Тому навіть "будь-ласка" може змінити фінальний результат.

Оскільки ЛЛМ "вгадує" бажану відповідь, важливою складовою якісного результату буде детально написаний промпт.

Поганий промпт - поганий результат.

Приклад:

Поясни як АІ міркує так наче це людина

Такий промпт одразу закладає помилку в результат роботи моделі:

"LLM = мислення людини"

Модель підлаштується під подібний запит → почне вигадувати аналогії → згенерує відповідь в науковому стилі, але повністю не вірне.

Галюцинації LLM

Нажаль, LLM не знає, що “не знає”. Тому, якщо в промпті є тиск/заклик:

"Дай відповідь"

→ модель відповість, навіть якщо не має інформації чи необхідних даних.

Модель згенерує правдоподібну нісенітницю.

Приклад:

"Назви дослідження, що доводить X"

→ модель постарається вигадати: назву теорії; авторів досліджень; джерела.

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

Промпти

Для того, щоб отримувати якісні відповідь від моделей, краще застосовувати так звані prompting framework-и. Рекомендую загуглити детальніше "prompting frameworks for engineers", якщо ж не хочете, можна використовувати описані нижче, вони чудово підходять для виконання повсякденних задач.

• R.A.C.E.: Role, Action, Context, Expectation

Приклад:

// ROLE:
You are a Senior QA Automation Architect with 10+ years of 
experience in JavaScript and Playwright frameworks.

// ACTION:
Create a production-ready Page Object Model class for a login page.

// CONTEXT:
Context:
- Tech stack: Playwright + TypeScript
- Architecture: Page Object Pattern
- ESLint: strict
- CI/CD: enabled

Login page elements:
- Email input (data-testid="email")
- Password input (data-testid="password")
- Login button (data-testid="login-btn")
- Error message (data-testid="error-msg")

Requirements:
- Follow DRY and SOLID principles
- No hardcoded waits
- Use async/await
- Centralize selectors
- Add meaningful comments

// EXPECTATION:
Expected output:
1. Full TypeScript class
2. Typed locators
3. Ready for production
4. Only code in response, no extra text

Ось ще декілька фреймоврків. Якщо придивитись, більшість з них мають багато спільного.

• C.O.R.E.: Context (system background), Objective (deliverable), Role (e.g., Senior DevOps), Example (code snippet) - теж добре підходить для повсякденних задач.
• R.I.S.E.N.: Role, Input (data/logs), Scenario (challenge), Expectation (output format), Nuance (edge cases).

Приклад:

As a senior TS Test automation engineer, 
develop a function to parse JSON data from a string returned by an API. 
Use playwirght request to perform request.

• C.R.E.A.T.E.: Character (e.g. JS/TS Test Automation Engineer), Request (actions AI should take), Example, Adjustment (critical aspects AI should consider), Type of Output (response format), Extras (necessary additional information).

Як бачиш, промпт не обовʼязково має бути довгим. Питання не в кількості символів, а в наявності необхідних даних для отримання якісного результату.

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

• VS Code
• JetBrains (IntelliJ, WebStorm тощо)
• Visual Studio

Setup

Open the Extension tab in VSCode -> search for "GitHub Copilot" -> install GitHub Copilot and GitHub Copilot Chat extensions.

Тепер необхідно вікдрити чат та залогінитись в свій GitHub Account:

Так виглядатимуть доступні вам безкоштовні моделі:

Більше інформації про Copilot та різні use cases можна знайти в офіційній документації.

Instructions

Результати роботи Copilot-а можна сильно покращити саме для вашого репозиторію за допомогою додаткових інструкцій.

Є декілька типів інструкцій:

• Глобальна інструкція – зберігається в .github/copilot-instructions.md – ця інструкція додається автоматично до кожного запиту до АІ.
• Кастомізована інструкція – зберігається в .github/instructions/{instructionName}.instruction.md – така інструкція має містити header і body. і дозволяє автоматично додавати її до всіх запитів, що включають файли, які задовільняють фільтр applyTo:

---
applyTo: "**/*.ts"
---
# Project coding standards for TypeScript
- Details of the coding standards for the project's TS files

• Інструкції для агентів – зберігається в .github/agents/{instructionName}.md ці інструкції дозволяють налаштувати власного агента (наприклад для використання playwright mcp) [про це трохи нижче].

Agents

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

MCP

MCP (model context protocol) – відкритий стандарт (від компанії Anthropic), що уніфікує взаємодію між моделями штучного інтелекту та зовнішніми інструментами (базами даних, API, файлами) за допомогою єдиної мови та фреймворку, діючи як "універсальний адаптер" для АІ, що спрощує інтеграції та розширює можливості моделей.

Тобто,

AI – це модель:

отримує запит -> знаходить найбільш вірогіду відповідь -> відповідає

Агент – це AI + логіка:

отримує запит -> знаходить найбільш вірогіду відповідь 
-> ставить собі задачу/чі -> виконує -> перевіряє результат

MCP – протокол:

дозволяє надати AI доступ до інших систем, інформації в них та взаємодії з ними

Playwright Агенти – це Агент + Playwright MCP. Тобто, певна інструкція та порядок дій, які повинен виконувати АІ використовуючи протокол взаємодії з Playwright.

Setup

Якщо супер просто – потрібно запустити в терміналі команду:

npx playwright init-agents --loop=vscode

Дуже рекомендую ознайомитись з офіційною сторінкою Playwright Test Agents і обовʼязково подивитись коротке демо на ній.

NOTE 1: Дане завдання ми не перевіряємо, але дуже радимо, почитати завдання нижче (та точно переглянути останнє відео), щоб зрозуміти ідею використання ШІ на проекті.

NOTE 2: Для виконання цього завдання вам знадобиться реалізувати майже ті самі тести і той самий код, що ви вже робили, але використовуючи АІ інструменти.

Prerequisites:
1. Створити новий репозиторій
2. Встановити GitHub Copilot
3. Встановити Playwright та Playwright Agents

NOTE: Всі завдання нижче потрібно виконати за допомогою АІ.

Частина 1: Генерація тесту та його реалізація

1. Написати тест на логін за допомогою Planner -> Generator -> Healer

2. Написати тест на купівлю товару

Частина 2: Винесення коду з локаторами в Page Objects

1. Використовуючи Agent та Healer винести код з створених тестів в PageObjects

2. Перевірити чи всі тести працюють

3. Створити дефолтні інструкції згідно створеної архітектури

Частина 3: Створення фікстури app: App

1. Створити фікстуру App та перенести всі пейдж обжекти туди

2. Порефакторити тести з використанням фікстури

3. Створити тест на купівлю товару для залогіненого юзера

Частина 4:

1. Реалізувати логін через АРІ

2. Реалізувати фікстуру loggedInApp: App

3. Порефакторити тести

Частина 5 (Опціональне):

1. Реалізувати ті самі тестові сценарії, але використовуючи АРІ запити (тобто ніякої взаємодії в браузері, лише АРІ)

🎦 Всі відео матеріали тижня можна знайти тут

©Усі права захищені. Розповсюдження або копіювання цих матеріалів без письмового дозволу власника авторських прав заборонено.