Dwa dni temu: teza. 1000 zadań, $700 vs $40, 70% nigdy nie dociera do LLM.

Wczoraj: mapa. Dziesięć warstw, A do J. Three-Layer Architecture jako kręgosłup.

Dziś: kalendarz.

Osiem tygodni. Cztery code dropy. Cztery odcinki standalone serii. Plus jak mnie zaprosić jeśli chcesz ten wzorzec w swoim stacku - i dlaczego 15 czerwca to twój forcing function.

Dziesięć warstw, raz jeszcze

Zanim wylądujemy w kalendarzu, szybka powtórka:

  • A Input Layer (otypowany QAContext z bałaganiarskich źródeł)
  • B Decision Layer (70% bez LLM, deterministyczna brama)
  • C Output Layer (Atlassian ADF, trik z 303 redirect)
  • D Orchestration (częściowe kontynuacje, heartbeats)
  • E HITL Safety (action queue state machine)
  • F Vendor-Agnostic Infra (zamień providera, nie orchestrator)
  • G Cost & Telemetry (per-task attribution)
  • H Operational Discipline (pięć produkcyjnych gotchas)
  • I Multi-Process Glue (jeden skrypt, trzy backendy)
  • J Approval UX (HITL UI które nie czuje się jak praca)

Z tych dziesięciu, oto co kiedy publikuje.

Sekwencja 9 tygodni

Tydzień#TematTryb
26-28 maja#04Performance audit 5-agent (WCAG ecosystem)standalone, kod
2-4 czerwca#05Multi-page WCAG (build story V0.4)standalone, kod
9-11 czerwca#06CDAT pattern (Page Objects od nowa)standalone, kod
16-18 czerwca#07Figma-to-code deterministycznystandalone, kod
23-25 czerwca#086 portali agent-ready w 70 minutstandalone, narracja
30 czerwca - 2 lipca#09Odcinek B “70% bez LLM”mini-portal, code drop
7-9 lipca#10Odcinek C “ADF bez łez” ⭐mini-portal, code drop
14-16 lipca#11Odcinek A “Input Layer”mini-portal, code drop
21-23 lipca#12Odcinek E “HITL Safety”mini-portal, code drop

Pięć odcinków standalone najpierw - to już-wysłane kawałki szerszego ekosystemu (WCAG, CDAT, Figma, agent-ready portale). Potem cztery code dropy mini-portalu z samej serii Context-First QA: B, C, A, E. Każdy ląduje w branchu repo który klonujesz, czytasz, adaptujesz.

Mini-portal repo: darco81/context-first-qa-patterns, AGPL-3.0. Main branch to index; każdy episode branch zawiera destylat kodu dla tej warstwy. Po publikacji branche mergują do main z zagregowanym README.

Pełna pętla

Oto end-to-end produkcyjny flow. Jeden ticket w Jirze wchodzi, jeden komentarz wychodzi, pełen audit trail między.

sequenceDiagram
    actor Dev as Inżynier
    participant Jira
    participant ETL as Deterministyczny ETL
    participant AI as AI Judge
    participant ADF as ADF Publisher

    Dev->>Jira: ticket stworzony
    Jira->>ETL: webhook trigger
    ETL->>ETL: równoległe fetch (Jira+Figma+Playwright)
    ETL->>ETL: enrichment, typowanie, walidacja

    alt 70% case (deterministyczny werdykt)
        ETL->>ADF: raport pass/fail
        ADF->>Jira: komentarz z audit trail
    else 30% case (potrzeba osądu)
        ETL->>AI: ustrukturyzowany QAContext
        AI->>AI: ograniczona decyzja (mały scope)
        AI->>ADF: zwalidowana output schema
        ADF->>Jira: komentarz z audit trail
    end

Mapy były komponentami. Pętla to integracja. Każda warstwa z części 2 mapuje na uczestnika albo przejście w tym diagramie.

Czego NIE publikuję - i dlaczego

Sześć z dziesięciu warstw (D, F, G, H, I, plus produkcyjne wersje A i E) zostaje w pitch-mode na razie. Nie staje się publicznymi code dropami w tym oknie.

Dlaczego:

  • D Orchestration jest multi-tenant i przywiązane do specyficznej infrastruktury dispatchera. Architektura jest do nauczenia; operational scaffolding nie.
  • F Vendor-Agnostic Infra jest mid-refactor jak piszę te słowa. Wolę opublikować jak skończone niż wypuścić snapshot który się rozjedzie za miesiąc.
  • G Cost & Telemetry ma compliance-adjacent observability concerns. Publiczny destylat wymagałby redakcji do poziomu który wprowadza w błąd.
  • H Operational Discipline to kawałek “pięć gotchas na produkcji”. Każdy gotcha to jeden paragraf; wzorzec da się nauczyć w jednym artykule a nie w code dropie.
  • I Multi-Process Glue jest najbardziej production-environment-coupled. Zakłada konkretny shell setup, konkretny CI, konkretny dev workflow. Lepsze jako praca konsultingowa niż publiczne repo.

To nie withholding dla samego withholdingu. To three-tier model w akcji:

  • Tier 1 (public, AGPL): metoda. Architektura, decyzje, działający kod na reprezentatywnych danych. Klonujesz, widzisz, adaptujesz.
  • Tier 2 (commercial): produkcyjna implementacja. Multi-tenant, compliance-aware, scaled.
  • Tier 3 (enterprise): design system federation, cross-repo audit, pełna integracja toolchain.

Publiczna wersja daje ci metodę. Produkcyjna wersja zajmuje 2-4 tygodnie pracy żeby ją zaimplementować pod twój stack. Tu wchodzę ja.

15 czerwca: forcing function

Jeśli twój team już uruchamia Agent SDK pipelines dla QA, performance audits, accessibility checks - 15 czerwca 2026 to data w twoim kalendarzu.

To dzień kiedy Anthropic odseparowuje programmatic SDK usage od interaktywnych okien subskrypcji Claude Code, i billuje SDK traffic po pełnych stawkach API z dedykowanego miesięcznego kredytu. Dziś agentic pipelines pożyczają z tego samego rate-limit budgetu którego twoi devsi używają do pisania kodu. Po 15 czerwca - nie. Mają własną linijkę, billowaną per token.

Co oznacza że cost math z części 1 przestaje być teoretyczna. Od połowy czerwca, każdy naiwny “LLM wszędzie” workflow który wysyłasz to wprost linijka faktury. Każda deterministyczna podłoga którą dorzucasz odejmuje wprost z tej faktury.

Jeśli wyceniałeś tę pracę jako “mieści się w moim Max planie”, odpowiedź zmieni się za cztery tygodnie. Deterministic-first pipelines które publikuję przez następne osiem odcinków były zbudowane przed tym ogłoszeniem - ale teraz są najbardziej bezpośrednim sposobem żeby trzymać koszty AI QA przewidywalne przez Q3.

Lepiej wysłać podłogę w maju niż odkryć rachunek w lipcu.

Jak się dogadać

Pracuję z 3-5 zespołami rocznie. Długie zaangażowania - nie “konsultacja AI tool for QA”, nie “sprototypujmy coś”, nie “możesz napisać dla nas testy?”.

Co robię:

  • Buduję deterministyczną podłogę pod istniejące QA, WCAG, performance audit.
  • Wpinam osąd LLM w właściwy slot - bounded, testable, attributable.
  • Stawiam toolchain tak, żeby następna osoba która to dziedziczy mogła to przeczytać.

Czego nie robię:

  • Nie daję ci “AI test writer”. Cała seria zakłada że tego nie chcesz.
  • Nie obiecuję konkretnych liczb dokładności bez przemierzenia twojego kodu.
  • Nie biorę pracy gdzie celem jest wolumen ponad reprodukowalność.

Jeśli szukasz “AI test writer” - nie będziemy pasować. Jeśli masz istniejący QA albo audit pipeline i chcesz dodać deterministyczną inteligencję na wierzch, DM to właściwy następny krok.

Więcej o usługach: sdet.it/services (portal mid-launch, DM działa już dziś).

Wtorek

Series #03 kończy się tutaj. Mini-portal Context-First QA jest teraz publiczną infrastrukturą - zakładkuj kalendarz, odcinki lądują zgodnie z planem.

Następnie: Performance audit, 5 specjalistów w parallel dispatch. Ten sam wzorzec Lead orchestrator co WCAG toolkit (Series #01, 5-7 maja). Inna domena. Inne liczby - 7 godzin z AI vs 16 billowalne vs tydzień klasycznie.

Mapa jest do góry nogami. Pętla jest ograniczona. Audit trail jest do zaufania.

I tyle.