At that point, it stops feeling like an AI coding assistant and starts feeling like an operating model.

The factory is now taking on more responsibility across the path from spec to shipped:
auto-merge, production deploy, and verification.

I’ve started scoring it against StrongDM’s software factory maturity classification, and on my current self-assessment it sits around Level 4.5 / 5.0. StrongDM’s public framing is useful because it maps the journey from AI-assisted implementation to agent-owned delivery and, ultimately, a more outcome-autonomous software factory.

What is interesting is how the risk changes as maturity goes up.

Early on, the question is:
can the factory produce working code?

Later, the harder question becomes:
can it keep shipping without causing architectural drift?

That is the part I’m paying most attention to now.

A mature factory can pass tests, CI, smoke checks, and deploy verification, while still slowly degrading boundaries underneath the surface.

So one of the things I’m now exploring is how to add architectural drift detection into the factory itself.

I’ve been looking at products like Revieko, which publicly positions itself around learning a repo-specific structural baseline, comparing each PR against that baseline, and highlighting architectural drift hotspots where review attention is needed. Its demo repo is explicitly set up to showcase architectural drift detection on a real-world backend.

For me, that feels like one of the missing pieces on the path to a true Level 5 factory.

Less human verification of every routine change.
More machine-enforced confidence that the factory is still building the right system.

That is a much harder problem than code generation.

It is also a much more interesting one.