"If you wipe the test folder tomorrow, the architecture is still sitting right there. The tests are just the cherry on top."
That's Stefan Minchev, four minutes into the first ArchQA, Unscripted episode ever recorded, calmly walking out of the trap I set for him. A year ago, when I had to design a Playwright framework that five QAs across five different teams would use every day on a trading platform, Stefan was the person I designed it with. So for the first conversation of the series, I invited the one engineer who can't hide behind theory with me. We built the same thing. Time to defend it, decision by decision.
We split the conversation into four episodes. Here's what each round did to us.
🥊 Round 1: What Is Test Architecture
Stefan's claim: your tests are the tip of the iceberg, maybe the last 10 to 15 percent of the work. Architecture is every decision you make before you ever open a spec file. The folder tree, the fixtures, the data isolation, the rules that stop bad code from being committed.
We landed fast on the real enemy, tribal knowledge. All the conventions that live only in senior heads, so a new engineer discovers them by breaking them in a pull request. Then Stefan said the quiet part about documentation:
"Within a few months, your readme is just lying to everyone."
No pushback from me here. In Bulgaria we say the smart people write it down and the dumb people try to remember it, and I have been the write-it-down person since my civil engineering days. The fun part is the ladder Stefan walks, from the weakest way to store your rules all the way to the strongest, including the one rung he calls the best context you can give an LLM. I'm not telling you which rung. It surprised me a year ago and it's in the episode.
🥊 Round 2: The Cost of Bad Architecture
Stefan's claim: skipping architecture doesn't save the work. It converts it into maintenance, and the bill lands somewhere between month one and month six. Green checkmarks start lying, half the suite turns red after one UI change, and eventually someone says the most dangerous phrase in software engineering, "nobody touches that file."
I pushed back with the obvious objection, isn't this just normal tech debt, every codebase has it. His answer is the line I've been reusing ever since:
"There's a massive difference between the tech debt you choose and the tech debt you inherited."
Chosen debt is a tracked trade-off. Inherited debt compiles silently in the background because nobody ever set a boundary to violate. That distinction stuck with me. Point Stefan.
He also prices out the classic offenders one by one, duplication, the God object, magic strings, weak assertions, and picks the single most expensive one to fix first if your suite is already a mess. His pick was not the one I expected.
🥊 Round 3: Architect Your Own Framework
The screen-share round. Stefan opens a real scaffold and we walk the four pillars we actually built with: a single source of truth, design patterns, test data management, and rule enforcement so nothing rots back into tribal knowledge.
I brought the internet's favorite new take to the table, that the Page Object Model is dead in the AI era. Stefan didn't blink:
"If AI is making a mistake, you're not tweaking your AI correctly."
I wanted a fight and got agreement instead, because I've seen zero evidence an agent can't handle page objects when the rules are written down. The honest confession from my side: we didn't arrive at composition gracefully. We hit the inheritance wall, detoured through mixins, collected runtime collisions, and only then found components. That whole scar story is in the act, next to the ESLint setup Stefan says changed his entire life. Watch it just to learn what a lint config has to do to earn that sentence.
🥊 Round 4: Bring a Scaffold to Every Project
Stefan's claim: a good framework should be built from scratch exactly once. Then it becomes a scaffold, a product you carry into every new project, and a week of setup turns into hours. But he draws a hard line on how you're allowed to use one:
"Don't just download someone else's scaffold and copy paste without understanding it."
I build and sell a scaffold, and my first guest just told everyone not to blind-copy scaffolds. Including mine, presumably. He's right, and that's exactly why I agreed. A scaffold is a template that carries your lessons, not a substitute for understanding them.
The part worth watching is his honest answer to the question everyone asks, how long from git clone to the first running test. It's not a marketing number, and the real win he names isn't speed at all.
🧾 The Scoreboard
| Topic | Verdict |
|---|---|
| The iceberg | He survived my delete-the-specs trap without blinking |
| The maintenance bill | Chosen vs inherited debt is his line. I use it now. Point Stefan |
| POM in the AI era | We ganged up on the critics. Judge for yourself if it was too easy |
| Scaffold as a product | Even round. We built this opinion together |
▶ Check out the full ArchQA, Unscripted Playlist:
- Act 1, What Is Test Architecture:
- Act 2, The Cost of Bad Architecture:
- Act 3, Architect Your Own Framework:
- Act 4, Bring a Scaffold to Every Project:
🚀 Level Up Your Playwright
Round 4 was about treating a scaffold as a product. These are mine:
- 33 Playwright Tips & Tricks (free PDF)
- Agentic Playwright (the open source scaffold, yes, the one Stefan told you to understand before copying)
- Agentic Playwright Scaffold: The Full Guide (PDF, pay what you want)
- Agentic Playwright PRO (the private, full tier)
🙏🏻 Thank you for reading! Next in ArchQA, Unscripted: Lucas Smit on how to use AI in QA for real, no hype, no "QA is dead" part 2.
Top comments (0)