The God Object You Already Shipped

I have shipped Playwright tests across nine production systems. Two years, roughly 3000 tests, still running today.

I am also the person who built one of those suites into a monolith so tangled that adding a single test meant reading four hundred lines to find where one locator lived.

Same hands. Both stories. That is the honest version, and it is where this episode starts.

The god object is not a pattern problem

The god object is a growth problem.

Every test structure degenerates the same way when delivery pressure outruns discipline. Page Object Model is simply where most of us meet it first, because POM is the default, and the default is what you reach for when the sprint is on fire. Nothing wrong with that choice. The entropy comes for every choice eventually.

It arrives in the same four shapes every time.

A class that started life as fill-the-form-and-submit grows fifty locators and thirty methods. The class has quietly eaten the whole feature.

Locators, business logic, assertions, retry loops and a forgotten console.log share a single method. When it fails, you cannot tell which of those five concerns failed, because they are the same line.

You want half a flow. Fill the form but do not submit. The structure gives you no clean seam, so you expose internals or copy the method. Both rot from there.

A selector changes, so you grep. A business rule changes, so you grep harder. Both change in one week and you ship a regression, because the split personality let you fix one half and miss the other.

None of this is exotic. If you have shipped tests at scale, you have lived at least two of these. I have lived all four, in the same repo, in the same quarter.

Why this matters more in 2026

Here is the part that changed.

Before you point an AI agent at your test suite, the architecture has to hold on its own. An agent does not bring discipline. It brings speed. Speed applied to a god object gives you a bigger god object, faster. The same tangle, times ten, in one afternoon.

An agent writes syntax and boilerplate well. It cannot decide where a concern belongs if your codebase never decided either. That is not an AI limitation. It is a context limitation. The model has no stable contract to write against, so it guesses, and it guesses in the shape of whatever mess it was given.

Context first. Determinism first. The architecture is the precondition that decides whether AI in QA accelerates you or multiplies the mess.

So the question changes

The question is not “which pattern is correct”.

The question is whether your structure gives a human, or a model, one obvious place for each decision. Where does a locator live. Where does a flow live. Where does an assertion live. If the answer is “depends, go read the class”, you do not have an architecture. You have a habit.

CDAT is one deterministic answer to that question. Four files per feature, each with a single job, a one-way dependency graph. Boring on purpose. Boring is exactly what a tired human at 6pm, or an agent at any hour, can reason about without reading four hundred lines first.

Part 2 takes it apart. The four layers, the contracts between them, and the same login test written two ways so you can see the seam.

From the Field is what I actually build, what breaks, and what I learn. Real projects, real numbers, real bugs. No tutorials.