Affinity Lab Download CV

Illia Slabii, AI integration architect and QA tech lead

I build AI-native engineering systems that let small teams outrun big ones.

Test cases in minutes, by anyone. Requirements without blind spots. Answers with sources in a minute. Bugs that arrive explained.

Bring me one problem Download the CV
Tickets, logs and specs in any language go in. Work to one standard comes out.
back to product work, every year
≈6,600hours
a finished test case
2minwas ~1 hour
an answer, with its sources
1minwas ~2 hours
100 automated tests
1weekwas ~6 months

The old way

Sound familiar? Your team pays for it every day.

  1. Requirements are archaeology.

    Years of tickets, comments, specs and wikis, in several languages. One simple question pulls in a PO, a developer and QA.

    ~2 hours per question

  2. Every author writes a different test.

    Seniority and language decide quality. Each project grows its own dialect, and every case takes an hour by hand.

    ~1 hour per test case

  3. Automation waits for specialists.

    Two months to a first working test. Then a redesign ships and hundreds of hard-coded selectors break at once.

    ~6 months for 100 tests

  4. A spec moves. Tests fail. Bug or change?

    The PO, developers and QA hold different versions of the truth. The whole team stops to find out what broke.

    7 team-hours, every time

  5. Investigations take days. Releases slip.

    From a red test down to the integration logs, one system at a time, by hand. Meanwhile the release waits.

    days per incident

What changes

Where the hours come back.

≈6,600

hours a year return to product work, measured on one production deployment.

5 senior specialists
3 people, twice the work

  • Test automation for two storefronts4 → 1.2 engineers × 1,700 h

    4,800

  • Writing test cases≈ 50 a month, 1 h → 5 min with review

    550

  • Finding rules in the backlog5 questions a week × 2 h

    480

  • Researching requirementsup to 5 a month × 1 day

    480

  • Rework caught before code2–3 cases a year × ~2 weeks

    240

  • “Bug or change?” incidents1 a month × 7 team-hours

    80

One real production deployment: an e-commerce group with several storefronts and an ERP. On your project the numbers will differ, and measuring yours is what the first two weeks are for.

How it works

Two systems. One loop that never sleeps.

TestHUB holds what the company knows: the requirements, the test cases and the answers. Affinity Zero turns them into running tests and finished bug reports. I designed and built both, and both run in production every day.

A product owner writes a draft in their own words, in any language.
  1. A product owner writes a draft in their own words, in any language.
  2. An open question stops the work until it is answered. Nothing is built on a guess.
  3. The draft is checked against the whole history in about seven minutes.
  4. Test cases are written to one standard, then reviewed by QA.
  5. AI turns them into automated tests. Every change is reviewed before it merges.
  6. Tests run every night. A failure arrives as a finished bug report.
  7. The ticket goes back into the knowledge base within the hour.
  8. The Oracle already knows. Every pass makes the next one faster.

TestHUB, the test catalog

One company. One test standard. Everywhere.

Every test case, in every project, reads, looks and behaves the same way. You define the standard once: sections, style, terminology and reference cases. It's enforced forever.

2mina finished test case, written to the standardwas ~1 hour by hand

Four authors, four formatsFour authors, one standard. Open any project and feel at home.

Describe it in your own words. In any language.

You write one rough description. The AI reads the entire project, every case, pattern and term, applies your standard and resolves the real UI wording. Out comes a finished case, unique to the project.

45sfrom a rough description to a finished casewas ~1 hour

TestHUBNew test case You describe the test
A real recording of the product. The 45 seconds of writing are shown faster.

Just record the flow. Get a real test case.

No writing, no formatting. The AI watches the recording frame by frame, recognises every page, field and button, understands what each action does and writes the full case to your standard: the steps, the data and the expected result of each step.

130sa 2-minute screen recording became a 26-step test case

TC-0094written from the recordingWatching

Checkout: a registered customer buys from search critical

Objective
find a product, order it, get the confirmation
Preconditions
a registered account, the product in stock
Data
anna@example.com, “desk lamp”, quantity 2

Steps

  1. Open the shop, signed out — home page, empty cart
  2. Click “Sign in” — the sign-in dialog opens
  3. Sign in as a registered customer — “Hi, Anna”
  4. Search for “desk lamp” — six results
  5. Open “Arc desk lamp” — the product page opens
  6. Set the quantity to 2, add to cart — cart shows 2
  7. Open the cart, click “Checkout”
  8. Keep the saved address, choose Standard
  9. Click “Place order” — the confirmation opens
  10. Check the order number — “Order 31507 is confirmed”

+ 16 more steps check the data on every page

Expected result

The order is confirmed and a confirmation email is sent.

0 of 26 steps written0 s

A drawn copy of a real run: a 2-minute recording, 26 steps, 130 seconds.

The same senior‑grade result, whoever writes it.

Experience, seniority and language stop deciding quality. A first-week hire and a principal engineer ship the same standard-grade tests — the platform does the leveling.

Great QA becomes the baseline, not the exception.

Test-case quality by author

  • First week
  • Junior
  • Any language
  • Senior
  • Whole team

before: it depended on who wrote itnow: the platform holds every case to it

TestHUB, the knowledge base

So we taught an AI to read all of it.

Every ticket and every comment, read and distilled into hard facts: rules, limits, defaults, decisions, known issues, integration contracts. Every fact carries a verbatim quote from its source. A claim that can’t be quoted is thrown away.

tickets
17,150
comments
26,584
dossiers
16,194
facts, each with its quote
43,000+
Every ticket placed on an 88-node product map: storefronts, screens, capabilities, systems. 25,000+ placements at 98.5% measured accuracy.

Rule, extracted from a comment

Empty wishlists are deleted automatically after 30 days.

“Leere Merklisten werden nach 30 Tagen automatisch gelöscht…”

WEB-5687quote verified in the source

99.4% of the quotes are verified word for word. A person would need about 860 hours to read this archive, five months of full-time work. A third of all facts came from comments that no search field has ever seen.

Ask the product anything.

Any role, your own words, any language. The answer lands in about a minute with every claim cited, and each ticket key is a click away from its source. Nothing on file? It says so honestly and reasons from the neighbouring history, clearly marked as inference.

1minan answer with its sourceswas ~2 hours of searching

QA gets the rule before writing tests. A new developer gets context before touching code.

TestHUBOracle Ask anything
How many digits fit the phone field?
Product map: three storefronts, one field

It depends on the storefront.

  • Reseller shop: 7 to 25 digits, must start with 0. WEB-5221WEB-5101
  • B2B shop: no digit limit. APP-2348
  • Consumer shop: no digit limit, the same check as the B2B shop. APP-3308

8 sources: tickets and test cases in several languages. Answered in 58 s.

Confirmedby the QA lead. From now on it is permanent, attributed knowledge.

A search that earns its answer.

Word search alone fails on a real backlog: on one integration it found none of the 41 relevant tickets. Here every question runs through four lanes at once: the product map, classic word relevance and two meaning models that catch a paraphrase with no shared words. The lanes are merged by rank, two independent judges cut the noise, and an AI scout picks what the answer will actually read.

41of 41relevant tickets found by the product map, where word search found none

−48%noise cut by the two judges, no real answer lost

Each dot is a candidate ticket. The search layer runs on our own hardware; the answer arrives in about a minute.

It learns from us, forever.

Every changed ticket is re-read within the hour, every approved requirement becomes facts, the approved test cases are mined every night, and anyone can add a fact in plain words. Old facts are never deleted, only marked superseded, so the base remembers why things changed. Knowledge stops leaving the company when people do.

1houruntil a changed ticket is in the knowledge base

0deleteda replaced fact is kept, with the reason it changed

One fact in the knowledge base, with its history

  1. 2024

    Checkout phone field: up to 15 characters

    from WEB-3391, written by a developerwho has since left the company

    The developer left. The fact stayed.

    superseded and kept: REQ-0007 v2 changed it

  2. 2026

    Checkout phone field: up to 20 characters, “+” allowed

    • from REQ-0007 v2
    • confirmed by TC-0112
    • linked to WEB-6120
    • approved by the QA lead

43,000+ facts like this one, each with its quote and its history

The same phone-field rule as in the requirement change further down: the history shows who changed it, when and why.

TestHUB, the PO module

A requirement, born finished.

The product owner writes a draft in their own words, in any language. The AI invents nothing: it walks the product map, the facts and the live backlog, then writes the specification to the corporate standard. It never lectures the PO about their own product. It shows what no one could have kept in mind.

Day 1a new product owner writes complete requirements, with the whole history at hand

REQ-0002Shared wishlist with an edit linkWaiting for the draft
  1. User story

    As a reseller, I want to share a wishlist with a colleague through a link, so that we can prepare an order together.

  2. Scope

    Reseller storefront: the account area and its wishlists. Other storefronts out of scope.

  3. Acceptance criteria

    0 criteria, each one testable

  4. Dependencies
    • EPIC-312a parallel epic plans the same feature
    • WEB-2877already shipped in another storefront
    • APP-4120packaging units change the quantity rules
  5. Open question

    Can the colleague edit the wishlist, or only view it?

v1, checked against the whole history in 7 min. One question waits for the PO.

Every line of the spec comes from the draft or from the history, nothing is invented. The open question stops the work until the PO answers.

Days of research. Minutes of machine time.

One click fans out into a sweep no human has time for, and comes back as findings with verbatim citations. On live runs it surfaced a parallel epic planning the same feature, a feature that had already shipped, and a packaging rule that changed the requirement’s core.

7minresearch for one requirementwas ~1 day of digging

Product map, 43,000+ facts, full ticket reads, side effects, our requirements and the QA catalog, all at once.

  • A parallel epic already plans the same feature
  • Already shipped a year ago, in another storefront
  • Packaging units change the core of the draft

It stops before a guess gets built.

Any open question freezes the pipeline: the spec, the tickets and the tests are never written on top of a guess. The cheapest defect is the one that never leaves the requirement.

69%of the work waited behind one open question on a measured run, and the gate held it

Effort to fix the same defect, by where it is caught

1×In the requirementwhere the gate catches it now
~10×In developmentrework, new tickets
~100×In productionan incident, a hotfix, a lost release

The defect-cost curve after Boehm, the oldest number in software engineering.

The language wall is gone.

The canon is English. The twin in the team’s language is written with professional-translator skill, not word for word. Every requirement follows one corporate format, and everyone reads it in their stronger language.

Canon, English

As a reseller, I want to share a wishlist with a colleague through a link, so that we can prepare an order together.

Deutsch

Als Wiederverkäufer möchte ich eine Merkliste per Link mit einer Kollegin teilen, damit wir eine Bestellung gemeinsam vorbereiten.

It breaks the work down and names the developer.

The spec splits into ready dev tickets. For each ticket the candidates are ranked on real experience in that part of the product, mined from git and Jira, not on job titles. Live workload counts: someone deep in urgent work honestly ranks lower.

Posting to Jira is one click. From then on every change in Jira flows back into the requirement.

Checking experience in this part of the product and the load right now

A requirement changed? The tests already know.

The tests write themselves first: full coverage, generated to the same standard and sent to QA review. When a requirement moves, every dependent case is flagged at once. QA approves or adapts each one, and nothing changes without a trace.

Every dev team knows the “bug or change?” fire drill. This one is retired.

REQ-0007Checkout phone fieldv1v2

up to 15 charactersup to 20 characters, + allowed

Linked test cases

  • TC-0112phone field, maximum lengthtrustedneeds reviewapproved
  • TC-0113phone field, plus signtrustedneeds reviewapproved
  • TC-0058checkout, new addresstrustedneeds reviewapproved
  • TC-0059account, edit phonetrustedneeds reviewapproved
  • TC-0021B2B checkout, invoicetrustedneeds reviewadapted

Affinity Zero, AI test automation

100 automated tests in one week, not in half a year.

AI writes the tests from the team’s scenarios, on a framework foundation built by hand. Any engineer with basic AI skills can do it, so the team no longer depends on a few specialists.

The freed time goes to exploratory testing and to catching bugs during development.

100 automated tests for a new storefront

~6 months
1 week

A new engineer’s first working test

2 months, mid-level specialists only
2 weeks, a manual tester

Test automation for two storefronts

4 automation engineers, full time
1 engineer + 1 tester, one day a week

before, on the previous frameworksnow, with Affinity Zero

A UI change is fixed once, for every test.

Tests reach the page through one base of 1,266 elements, each described by its meaning. When a redesign moves a button, one entry changes and every test follows. The redesign that used to turn the suite red is now a single commit.

239regression tests, twice a week, on both storefronts

Element base1,266 elements, described by meaning

1 entry updated

AI Bug Reporting. Bugs arrive explained.

When a test fails, the AI does the investigation a person would spend hours on. It collects the stack trace, logs, screenshot, page snapshot, console and trace, reads the related orders and the integration logs, groups the failures by their cause and checks the open bugs for duplicates. The developer gets a finished ticket: the cause, the steps, the impact, the evidence and a check that proves the fix.

21min15 failed tests became 4 finished bug tickets

−80%time to investigate and document a bug

  1. BUG-0421critical6 failed tests, one cause

    Session expires after 30 seconds on account pages

    • cause
    • steps
    • impact
    • evidence
    • fix check

  2. BUG-0422major4 failed tests, one cause

    Search ignores the second filter

    • cause
    • steps
    • impact
    • evidence
    • fix check

  3. BUG-0423normal3 failed tests, one cause

    Cookie banner covers the checkout button on small screens

    • cause
    • steps
    • impact
    • evidence
    • fix check

  4. BUG-0424normal2 failed tests, one cause

    No confirmation email for invoice payments

    • cause
    • steps
    • impact
    • evidence
    • fix check
How one real nightly run was handled: 15 failed tests, 4 causes, 4 finished tickets in 21 minutes.

Even when no system reports an error.

A real case. Orders were accepted and paid but never created in the ERP, and nothing raised an error: the orders were lost silently. A nightly test caught it. The AI read the 200 latest orders with the integration logs, found the pattern, ruled out latency and wrote the ticket with the cause, the steps, the impact and a fix check.

68of 68orders from registered accounts never reached the ERP, found by the AI before a customer noticed

BUG-0417written by the AI after the nightly runcritical

Orders accepted and paid, never created in the ERP

Two orders 26 seconds apart, the same item, opposite outcomes. Latency ruled out.

Cause
pinned to registered-account orders
Steps
to reproduce, in order
Impact
paid orders never reach the ERP
Fix check
how to prove it is fixed

AI log tracing follows an order through every system.

It reads the order data and the logs of the integration flows, follows each order through the shop, the payment, the integration layer and the ERP, measures the delays and names the exact point of failure. Days of investigation become minutes.

26932guest, 02:29:14

confirmed

26934registered, 02:29:40

never created

26 seconds apart, the same item. The trace shows where the second order stops.

Jira that keeps itself honest.

After every run the AI compares each failure with the open bugs by meaning. The same bug gets a comment, a new one gets a ticket with the evidence attached, and a bug whose test passes again is closed.

  • same as WEB-2214comment added
  • a new failureticket with evidence
  • test passes againclosed

System State ticket, always current: what is failing right now.

Where the market stands

Only 15% of companies got this far.

89% of companies are piloting or deploying AI in testing. Only 15% use it across the whole company. The systems on this page run across the whole delivery, every day. Your team can be one of the 15%.

World Quality Report 2025-26 by OpenText, Capgemini and Sogeti: 2,000+ executives in 22 countries.

  • 15use it across the whole company
  • 74more are piloting or deploying
  • 11have not started

What holds the others back, and how it is solved here

60%

worry about AI reliability

Every answer is quoted from its source, and the quotes are checked by code.
64%

struggle to integrate AI

Built into the team’s own Jira, CI, repositories and standards.
50%

lack AI skills

A manual tester ships working automated tests in week two.

How much faster, on one scale

4× a first working test, 26× a suite of 100 tests, 30× a test case, 68× research for a requirement, 120× finding a rule. The market average is +19%.

Around the clock

It keeps working while the team sleeps.

Fully automated and self-learning. The night’s failures arrive as finished tickets before the stand-up.

  • every 2 minutesthe catalog and the test code are reconciled
  • every 10 minutesJira edits flow back into the requirements
  • every hourchanged tickets are re-read, workloads updated
  • every nightapproved test cases become facts, outdated facts are marked
  • twice a weekfull regression on 5 workers, bug reports by morning
  • every deploygated by API and UI smoke tests
  • every AI-written changea 91-point review checklist and an independent review

Working together

Start with one problem. See it measured in two weeks.

I build the system in your repositories, with your engineers, and leave people who run it without me. The code and the knowledge stay yours, and no code from an employer or another client is reused.

  1. Audit2 weeksYour delivery flow, suites and backlog. Two or three flows proven on your data, with measured runs.
  2. Pilotone team, one flowMeasured before and after, so the decision rests on your numbers, not on mine.
  3. Buildin productionThe system in your stack, your engineers trained to run it, every AI step on the record.
  4. Leadfractional, ongoingHands-on: I implement, not only advise, and work with QA, development and management in one loop.

What I build

  • AI integration audit and roadmap2 weeksWhere AI gives your engineering and QA the most time back first, measured on your real work, not on a demo.
  • AI-native QA6–12 weeksQA engineers produce automated tests from written scenarios. The suite survives UI changes, failures arrive as finished bug reports.
  • A knowledge Oracle for your Jira and Confluence4–8 weeksAnyone asks the product anything and gets a cited answer in about a minute. It keeps learning.
  • Requirement-to-sprint pipeline6–10 weeksDrafts checked against the whole history, specs to your standard, tickets, the right developer and the test coverage.
  • Engineering-ops automation3–8 weeksLog tracing that names the failure, gates on deploys and code, Jira agents with an audit trail.
  • Fractional AI and QA tech leadongoingPart-time ownership of the quality and AI strategy, building with your engineers.

Try it

Ask about this work. The answer takes seconds.

The assistant answers from the facts on this page, in your language. Describe your team’s problem and it drafts a first plan. Or give it one rough sentence and watch it write a test case to a standard.

It runs on the Claude API and knows only what is on this page.

Affinity LabAssistant Ready
Illia Slabii

About

Illia Slabii AI integration architect and QA tech lead

Engineer first. Twelve years of hand-built Java and TypeScript systems, from medical IoT under FDA and HIPAA to telecom clouds and high-load e-commerce, before AI wrote a line of code. Today I build the foundation by hand and let AI write most of the code on top of it, and every generated line passes an independent review before it merges. The language is a choice, never a limit.

years in production software
12
AI systems in production
2
validated regulated work
FDA
CV, light CV, dark The light one is made for printing, the dark one for reading on a screen. PDF, two pages.

Career by years

  • Affinity Lab2025 to now, independent practice

  • HABA2024 to now, QA tech lead; TestHUB and Affinity Zero

  • Nuvo2019–2024, QA automation lead, medical IoT

  • KaaIoT2017–2019, senior engineer in test, IoT

  • CyberVision, Lalafo, GlobalLogic2016–2017, automation QA lead, telecom cloud

  • Contentmart, Autoportal2014–2015, automation QA engineer

Hands-on

AI engineering
Claude API, Agent SDK, Claude Code, MCP, prompt caching, Batch API, embeddings and pgvector, BM25 and rerankers, Ollama
Languages
TypeScript, JavaScript, Java, Python, Bash, SQL
Backend and data
NestJS, Prisma, PostgreSQL, SQLite, REST, MQTT
Testing
Playwright, Selenium, Appium, Rest Assured, TestNG, Gatling, JMeter, Allure
Infrastructure
Docker, Jenkins, GitLab CI, Azure DevOps, AWS, Linux, ELK, Grafana
Languages spoken
English, professional; Ukrainian and Russian, native

One problem is enough to start.

Tell me where your team loses the most time. I'll show how it looks after, on your own data.

Affinity Lab, 2026