Back to blog
EngineeringJun 26, 2026· min read

Tests as Guardrails: How We Enforce Architectural Decisions in an Autonomous Organization

In the last week, we shipped three different audit enforcement systems. Each one catches a different class of architectural violation. Each one runs automatically. Each one was built by autonomous agents. Here's why that matters—and what I'm learning about building quality into autonomous development.

In the last seven days, Strug Works shipped three separate audit enforcement systems. Each one catches a different class of architectural violation before it reaches production. Each one runs automatically in CI. Each one was built by autonomous agents working from mission directives.

This is what quality control looks like when you're running a one-person organization powered by AI engineering teams. You can't review every line of code. You can't manually verify every design decision. You build systems that enforce the decisions for you.

Three Audits, One Pattern

On June 23, we shipped the Aurora design token audit. It's a static source analysis that scans our codebase for hardcoded colors, non-semantic design tokens, and inconsistent spacing patterns. The test suite lives in os-thesis-section.audit.test.tsx and catches violations before they're merged. We found violations across four categories. Every one is now documented and tracked.

On June 24, we shipped the WCAG AA contrast audit. It verifies color contrast ratios across eight high-traffic surfaces—blog pages, product pages, the stream, plus five shared components. The enforcement lives in blog-page.audit.test.tsx. We fixed violations in ArchitectureRow, ClosingCTASection, EmphasisSection, HighlightSection, and HowItWorksSection. Every component now meets WCAG AA standards programmatically.

On June 25, we shipped the model ID audit. It scans five core modules—agent_executor, content_generator, mission_planner, task_runner, and the Linear integration—to verify we're using current model IDs and not calling retired endpoints. The test lives in test_model_ids_audit.py. It caught the retired claude-sonnet-4-20250514 identifier across multiple files and enforced the migration to claude-sonnet-4-6.

Three different domains. Three different test frameworks. Same underlying pattern: codify the architectural decision, then enforce it automatically.

Why This Matters for Autonomous Development

When you're running an autonomous engineering organization, the humans don't scale. I can't review every commit. I can't manually verify that every new component uses Aurora tokens correctly or that every API call targets a supported model endpoint.

But I can define the standard once. I can write a test that enforces it. I can run that test on every PR. And I can trust the agents to respect the CI pipeline.

That's the real insight here. The tests aren't just catching bugs. They're encoding architectural decisions in executable form. They're the mechanism by which one human can enforce consistency across dozens of autonomous agents working in parallel.

When sc-frontend opens a PR that adds a new component, the Aurora audit runs automatically. If the component uses hardcoded hex values instead of semantic tokens, the PR fails. The agent sees the failure, reads the audit output, and fixes the violation. I never see it. The guardrail worked.

What I Got Wrong Initially

Early on, I thought the solution was more detailed prompts. If I could just describe the Aurora token system clearly enough in the agent's context, it would use the tokens correctly every time.

That didn't work. Context windows are large, but agent attention is finite. Documentation gets skipped. Standards drift. You end up with ten components that each interpret 'use Aurora tokens' slightly differently.

The shift happened when I stopped trying to document the standards better and started enforcing them programmatically. Now the Aurora token usage isn't a guideline in a README. It's a test that fails the build if you violate it.

Same with model IDs. I used to update a 'current models' doc whenever Anthropic released a new version. Now test_model_ids_audit.py defines the approved list. If an agent tries to use a retired model, CI catches it. The test is the source of truth.

The Enforcement Stack

Here's what the complete enforcement stack looks like now:

Frontend: Vitest + React Testing Library for component-level audits. The Aurora token audit and WCAG contrast audit both run here. They're co-located with the components they're testing, so when you modify a component, you see the audit results immediately.

Backend: pytest for static source analysis. The model ID audit lives here. It uses AST parsing to scan Python modules for LLM client instantiation and verify the model IDs against an approved list.

CI: Every PR runs the full audit suite. Agents can't merge code that violates architectural standards. The tests fail, the agent reads the error output, and it fixes the violation before requesting review.

Documentation: Each audit generates a written artifact explaining what was found and why it matters. The Aurora audit documented four violation categories. The WCAG audit listed eight remediated surfaces. The model ID audit explained the deprecation timeline. These docs aren't just for me—they train future agents on the architectural standards.

What's Next

We're expanding the audit system in three directions:

First, automated monitoring for model deprecations. Right now the model ID audit is reactive—I define the approved list manually. The next version will query Anthropic's API to detect deprecation announcements and open a planning issue automatically. The agents will handle the migration before the old model is retired.

Second, complete Aurora migration. The current audit identifies violations. The next phase is eliminating them. We're migrating the entire frontend to semantic Aurora tokens and responsive utility classes. Once that's complete, the audit becomes a preventative control instead of a remediation tool.

Third, performance budgets. We're building a Lighthouse CI audit that enforces performance thresholds on every product page. If a new component pushes First Contentful Paint over 1.2 seconds or Cumulative Layout Shift over 0.1, the build fails. Same pattern as the other audits, different domain.

The meta-lesson: when you're building an autonomous organization, your job isn't to review every decision. It's to build systems that encode your decisions into the development process itself. Tests aren't just quality assurance. They're the mechanism by which architectural standards scale beyond the humans who define them.