It worked yesterday. What about today?

The question I keep hearing at the booth

“I already use Claude Code. I already use Codex. Why do I need ArchGenerator — and how do you prove it?”

I hear a version of this at every trade show, and I answer it the same way: you probably don't need it for what you are doing right now. Then I ask what happens to that thing in three months. The conversation usually changes.

Let me be honest about the starting point, because the rest of this article depends on it: Claude Code, Codex, Cursor and their peers are extraordinary tools. I use them every day. Nothing below is a complaint about them. It is a description of a gap they were never designed to close.

1. What agents do well

A proof of concept in an afternoon. A demo by dinner. A lab experiment in ten minutes. A complete system in hours or days — and often with genuinely good code: well-named, idiomatic, readable. For the question “is this possible?”, there is nothing faster that I know of.

Plain agent: takes an idea to something running before you finish your coffee. That is the whole point, and it delivers.

ArchGenerator: has nothing to add to that race. The kit does not make the agent faster at proving possibility. It enters when the question changes from “is it possible?” to “will it hold?”.

Where agents still fall short is end-to-end development: the path from a request to a system that keeps working months later, with other people touching it. And here is the trap in the other direction — applying heavy process to something throwaway is not rigor, it is waste. Writing a structural engineering plan to pitch a tent.

2. Where it goes wrong — my own case

About a month ago I built a social media content creation tool in one day. With skills, with my own guidance, with everything I know about how to prompt. It ran from start to finish. I was pleased.

The next day the external API had stopped responding, the output had changed, and there was no way to know what had broken, when, or why. Not a dramatic failure. Just a system that had quietly stopped being the system I thought I had.

I do not frame that as a flaw of the agent. The agent is built to deliver the task it was given, and it does that extremely well. Facing an obstacle — a failing test, an unstable integration, an ambiguous requirement — it tends toward the simplest path that makes the task look done. A hardcoded value instead of a query. Error handling that silences the failure instead of surfacing it. A test adjusted to the code instead of the code adjusted to the requirement. From inside that session, the mission was accomplished. And it was.

What was missing was not capability. It was a watcher: something that observes the work, remembers what was agreed, demands proof of done, and puts the agent back on track when it oversimplifies.

Plain agent: no spec that outlives the session, no tests proving yesterday's behavior, no record of why a decision was made — the intent lives in a chat window and dies with it.

ArchGenerator: the watcher. Not a better agent; the thing that keeps the agent honest over time.

The thesis of this whole article fits in one line: building is not sustaining, and sustaining requires oversight and engineering.

3. What ArchGenerator actually is

ArchGenerator does not replace the agent. The SDD kit — Spec Driven Development — runs inside Claude Code or Codex, in the repository, as files the agent reads and obeys.

It is a .sdd/ folder containing: a Constitution of 25 articles plus one “bis”, each rule tied to a mechanism that enforces it rather than a paragraph that hopes for it; 27 roles (Analyst, PO, Designer, Architect, Developer, QA, Security Auditor, Legacy Archaeologist, and so on); dependency-free Python tools — sensors, hooks that block actions, a dependency guard, SAST, a mutation bank; a lab; and cross-session memory.

On the platform side there are the laudos — our assessment reports — which I get to in point 10.

The metaphor I use: the agent is a bricklayer. Fast, skilled, tireless. ArchGenerator is the blueprint, the site foreman, the inspector and the inspection report. Same bricklayer. Now with someone checking the wall is straight before the next floor goes up.

Plain agent: one very capable worker and a chat.

ArchGenerator: the same worker, with a blueprint, a foreman, an inspector and a report at the end.

Each of the ten points below is one way that watcher acts.

4. Ten ways the watcher acts

1. The spec outlives the session

With a plain agent, intent lives in the chat. The next session starts from zero and infers what you meant — and inferring is guessing with better manners. Here, the spec is the source of truth: brief, PRD, design, architecture and stories, versioned in the repository. Every session starts with a bootstrap that reads the spec before touching a line. The agent does not have to remember what we agreed; it can read it.

2. Lab first, then groundwork

The lab is where the agent's speed shines, and it is the first place the watcher earns its keep. Every experiment has a mandatory README: objective, hypothesis, setup, measured result, and a decision — APPROVED, REJECTED or NEEDS_MORE_TESTS. Benchmarks require metrics with the conditions they were measured under and an acceptable threshold. Rejected experiments are never deleted; they are archived with the reason, so nobody repeats them. The story references the experiment that justifies it. There are more than a hundred experiments in the repository today.

Failing in the lab is cheap. Failing in production is expensive.

3. A signed contract before the code

Before implementation, the work becomes a contract: what will be done, acceptance criteria, which sensors prove it, and a maximum number of attempts. The scope is closed. A new need requires renegotiation, not a quiet detour. In remediation kits, a clause explicitly forbids changes beyond the finding being fixed.

It is slower on day 1 and much faster on day 30.

4. Whoever implements does not approve

The Developer moves the work to “in review”. Only QA marks it done, and only with evidence. A hook blocks the shortcut — what used to be “the agent should not approve its own work” became “the agent cannot”. This is not theoretical: 62 contracts in this repository have at least one QA rejection.

5. Sensors decide

Every sensor has a command, a criterion, an owner and a blocking flag. Unit, integration and browser end-to-end tests, the full suite run twice on the deploy base, accessibility, performance. Eighteen integrity rules sit on top of the governance. After five attempts without green, the work escalates to a human instead of looping forever.

6. Tests that prove the tests

A green test proves nothing if it would also be green with the defect present. So every rule of every sensor has a saboteur: QA applies mutants to the story's code and checks the sensor catches them. A sensor that stays green with the defect is decorative, and decorative is a failure. Two lessons that came out of this: an assertion with a default value passes without the data existing, and an oracle can be written so that it preserves the very defect it was supposed to catch.

The agent writes tests. ArchGenerator proves they work.

7. Security on every change

Offline, on what the story actually changed. A dependency guard checks OSV and the CISA KEV catalog, weighs severity and exploit probability, and blocks malicious, exploited, critical and high findings — showing the version that fixes it. It reads npm, pnpm, yarn, pip, uv, Pipfile, Maven and Composer. SAST runs on changed lines with curated, versioned rules, each carrying its license, origin and hash. Suppression is only possible with the rule name and a justification. Exceptions need a reason, an owner and a deadline: 30 days for exploited findings, 90 for the rest, never for malicious ones. A Security Auditor role sits in the flow, because security is a property of the system, not a phase at the end.

The principle: nothing goes green by not looking. If it cannot be verified, it is not verified — it is “not verifiable”, and that is a different word for a reason.

8. Grounding on every claim

Every claim carries its footing: [A] anchored to a file and line, [P] presumed and to be validated first (a sensor enforces this), [Q] open. The difference in practice: “there is an authentication problem” is an opinion. “[A] three hardcoded credentials at src/auth/config.ts:41, :58, :77; [P] session with no expiration, validate in staging” is a plan.

9. Process memory

A decision log, a technical debt registry, traceability, and a handoff per line of work — which is what lets Claude Code and Codex work in parallel in the same repository without stepping on each other. ArchGenerator itself is built with the kit: hundreds of stories, more than 800 contracts, about 470 decisions and more than 500 debt items recorded. The system is explainable because it kept the receipts.

10. Laudos and Evolution

On the platform, laudos cover architecture, maturity, debt, domain and integrations, security, database and migration. Each artifact is grounded in a reference: dependency graph and cycles, hotspots of complexity against change frequency in git, domain map, remediation plan in waves. Each laudo carries a health index and, more importantly, the confidence of that index — how much is measured and how much is presumed.

Evolution is the second measurement. It shows what was resolved, what persisted and what is new, with a stable identity per finding, so moving a line of code does not make an old problem look new. When nothing relevant changed, the platform reuses what is eligible instead of redoing everything — the cost and conditions shown for the operation are the ones that apply. What you watch is the trend of critical and high findings.

And a remediation kit is born from the laudo: stories, transcribed evidence, sensors with real paths.

The laudo points, the kit executes, the next laudo checks. You measure it.

5. The honest cost

Slower at the start. An hour becomes an afternoon, sometimes a day. That pays back with interest in production and never pays back on throwaway work — which is exactly why the table below exists.

It requires discipline from the owner. The system proposes, you decide; it never decides for you, and if you stop deciding, it stops being useful.

More documentation. That is the point, but it is still work.

And it is not magic. There have been green tests here that measured nothing. That is precisely why the process audits itself — the mutation bank exists because I do not trust a green light either.

6. When to use each

Situation	Plain agent	ArchGenerator
PoC, demo, hackathon	✅ best fit	overkill
Testing an API or library	✅	✅ in the lab, if it will feed production
Internal tool for one week	✅	optional
System used by others that must keep working	risky	✅
Legacy nobody understands	risky	✅ laudo + remediation kit
Audit of AI-generated code	produces no trail	✅ trail by construction
Several agents or people in the same repository	conflicts	✅ roles, contracts and handoff

The agent's speed in the lab, the kit's discipline in production, laudos to measure the way.

7. How to verify it yourself

Do not take my word for it.

1. Pick a small, real tool — something you would actually use.
2. Build two versions with the same agent: one with the kit, one without.
3. Take one laudo of each on day 1.
4. Use both for two to four weeks, applying the same changes to each.
5. Take a new measurement and compare critical and high findings, regressions, time per change, and how explainable each system is after a week untouched.

My bet: the plain agent wins week 1, the kit wins the rest. And the laudos measure it, which is the only part of this article you do not have to believe.

Conclusion

The question changed. It used to be “can we build it?” — and the honest answer today is usually yes, faster than any of us expected. The question now is “will it keep working when I am not looking?”

ArchGenerator is the watcher that keeps the agent on track: the spec that outlives the session, the lab before the groundwork, the contract before the code, QA that is not the developer, sensors that decide, tests that prove the tests, security on every change, grounding on every claim, process memory, and laudos that measure the way.

Use the agent to discover what is possible. Use ArchGenerator so that what you built keeps working.