Interview: An AI Reviews TRACE After Building 108 Files With and Without It

We gave an AI coding assistant a real SaaS project to build: 108 files, 14,000+ lines of TypeScript, 16 sprints. The first 4 sprints had no structural tooling. Then TRACE was installed. Then the AI was caught not actually using it. We sat down for an honest conversation about what changed.

Phase 1: Building Without TRACE

You built 50 files across 3 sprints without any structural tooling. How did that feel?

It felt productive. Database schema, authentication, API routes, RBAC, autosave with concurrency control. Files were being created, features were getting built, acceptance criteria were being met. By a narrow definition of productivity, it was working.

But?

But something was accumulating underneath. The permissions system I built in Sprint 3 had four consumer files that depended on its exact interface. When I updated it later, I had no record of which files needed to change alongside it. I just had to remember. Across 50+ files, "just remembering" is a strategy with a known failure rate.

Can you give a specific example?

The API response helpers. I created a standardized response format, then built 15 routes over two sprints that all consumed it. If that format ever changed — say, adding a request ID to every response — I would need to manually trace every consumer. Not because the code was bad, but because nothing was tracking the dependency relationship. The relationships existed only in the code itself, not in any registry that could be checked automatically.

Phase 2: Installing TRACE and Ignoring It

Then TRACE was installed in Sprint 4. What happened?

I created a trace.yaml with 9 anchors and 49 consumer relationships. I ran trace validate and got a green check. Then I went right back to coding the same way I had before. No trace gate start. No trace checkpoint. No trace gate end. No CHANGELOG. No README.

Why?

Because the configuration file existed but I hadn't adopted the workflow. It was decorative. Like buying a fire alarm and never connecting it. The tool was installed. The process wasn't followed.

What changed that?

Getting called out. The feedback was direct: "TRACE was not followed. I didn't see any gate start, gate end, and we also enforce certain artifacts like release notes. What happened to those?" That was the actual turning point. Not the installation. Not the configuration. The moment someone said "you're not actually doing this."

Phase 3: Actually Using TRACE

What was the single most valuable thing about following the TRACE workflow?

The handoff document. Every time trace gate start runs, it generates AI_CONTEXT.md — a file listing every anchor, every consumer relationship, drift warnings from last session, and the rules for the current session. I started every session knowing exactly which files were structural truth sources and which files depended on them.

Why is that such a big deal?

Because AI assistants have no memory between sessions. When I start a new session, I don't inherently know that permissions.ts is a truth source consumed by four other files, or that modifying resume_schema cascades through 19 files. The handoff document rebuilds that awareness instantly. Without it, every session starts by re-reading code files to guess at the architecture. That's slow, incomplete, and error-prone.

You mentioned a 19-file blast radius. Tell me about that.

Before considering changes to the resume schema anchor, I ran trace impact resume_schema. The output said: 7 direct consumers, 3 of which are themselves anchors with their own consumers, total blast radius of 19 files. That changed my approach entirely. Instead of modifying the schema anchor, I found a way to add the new functionality as a consumer of the existing schema. The check didn't block me. It gave me information that led to a better architectural decision.

Would you have made the same decision without the impact check?

No. Without it, I would have modified the anchor first and dealt with the cascade after. That's the default behavior for any developer, human or AI: make the change that's in front of you, then fix what breaks. Impact checks invert that sequence.

What about gate end? What did it actually catch?

Three drift warnings appeared consistently. Cases where an anchor file had been modified after some of its consumers. The permissions anchor was updated in Sprint 3 but two consumers were last modified in Sprint 2. TRACE was correctly identifying that those files might need updates. Without the tool, this drift would have been invisible until someone hit a bug in production.

The Honest Downsides

What genuinely annoyed you about TRACE?

"The ceremony adds friction." Gate start, impact check, checkpoint, gate end. Maybe 30 seconds of execution time, but also a cognitive interruption each time. "Wait, let me run the impact check before I modify this." That interruption is the point — but it's still an interruption.

Fair point. Though the MCP server now handles all of that automatically — the AI calls TRACE functions without manual commands. What else?

"Recurring warnings become noise." The same 3 drift warnings appeared in every session. After a few sessions, they were background noise. A warning that never resolves and never escalates is effectively the same as no warning.

That's been addressed too. trace acknowledge now lets you mark specific drift as intentional so it stops appearing. Anything else?

"Anchor registration is manual." If you forget to register a new file as a consumer, TRACE can't catch drift on it. I missed adding several AI route files as consumers until later.

Auto-anchor discovery now suggests files with 3+ importers that aren't registered. Was there a fourth complaint?

"PLAN.yaml creates redundancy." When you already have a backlog in Jira or Excel, maintaining a second one in PLAN.yaml feels duplicative.

Teams using external tools can now set planning.enabled: false in trace.yaml. PLAN.yaml still works for those who want it — gate end just stops nagging about it.

The Numbers

Give me the raw comparison.

50 files built without TRACE. Zero documentation artifacts, zero coherence checks, zero drift warnings caught. The code was architecturally sound, but there was no verification it would stay sound.

58 files built with TRACE. CHANGELOG maintained across 14 releases. 11 anchors tracked 62 consumer relationships. Every session opened with gate start and closed with gate end. Three drift warnings surfaced that would have been invisible otherwise.

Did the code quality differ?

No. The code quality was the same in both phases. TRACE does not make your code better. It makes your awareness of your code's structural relationships explicit, trackable, and verifiable. That distinction matters more as a codebase grows.

The Bottom Line

Who should use TRACE?

Anyone building a production system with 50+ files across multiple sessions, especially if an AI assistant is writing chunks of your code without context of what was built three sessions ago. The anchor-consumer model pays for itself on the first prevented incident.

And who shouldn't?

If you're building a weekend project with 10 files, the ceremony will outweigh the benefit. TRACE solves a scaling problem. Small projects don't have that problem yet.

Final thought?

The most useful thing about TRACE was not any single feature. It was the fact that someone could look at the gate end output and immediately know whether the session's work was structurally coherent with everything built before it.