The ACE Framework: Architect, Constructor, Evaluator

The ACE Framework in practice: Architect (design), Constructor (implementation), Evaluator (verification) coordinated through a shared orchestration layer.

Why the future of software development isn’t about choosing the best model — it’s about orchestrating them.

The ACE Framework is a practical way to think about multi-model AI systems using the same role separation that works in real engineering teams.

Why I Stopped Trying to Make One Model Do Everything (and Started Orchestrating Instead)

I didn’t arrive at a multi-model AI workflow because it sounded clever.

I arrived there because my original setup was working — until it very clearly wasn’t.

For a long stretch, my workflow looked like this: I used ChatGPT (GPT-5.2) in the web UI as my “Architect.” I’d work through system design, constraints, and next steps there. Then I’d manually copy prompts and commands into Claude Opus CLI (I pay extra for the “good” version) for implementation, or into PowerShell or WSL when it was time to actually run something. When Claude produced output, I’d copy the results — sometimes a lot of them — back into the ChatGPT web session so the “architect” could see what happened and guide the next move.

At first, it felt powerful. Almost intoxicating. Like pairing with a tireless senior engineer who never lost patience.

But after a few hours, the cracks started to show.

The web session would accumulate noise: logs, stack traces, command output, partial experiments, dead ends. Responses would slow…badly. Subtle constraints we had already agreed on would start slipping. Eventually, I’d hit the same wall every time: I’d need to ask for a handoff prompt, spin up a fresh instance, and start again.

The problem wasn’t intelligence. It was organizational design.

Despite careful handoffs, something always got lost — nuance, context, the why behind earlier decisions. The new instance technically had “context,” but not understanding. We’d spend time rediscovering decisions we had already made, and occasionally repeating mistakes we had already corrected (PowerShell oddities in particular).

None of this was a failure of any single model.

It was a failure of role clarity.

I was forcing one conversational surface to be:

• an architect
• an implementation guide
• a debugger
• a command runner
• and a long-term memory system

Real engineering teams don’t work this way.

Architects don’t sit inside terminals. Engineers don’t redesign the system every time they hit an error. QA doesn’t live in code comments. And nobody relies on one person’s short-term memory to carry an entire system forward.

That’s when it clicked:

I wasn’t hitting a model limitation — I was hitting an organizational one.

And that realization changed how I approached AI entirely.

The One-Model Era Is Over

For the past few years, the AI conversation has revolved around a single question:

Which model is the best?

In 2026, that question is no longer useful.

The real inflection point isn’t raw intelligence — it’s agentic orchestration. The teams getting outsized leverage from AI aren’t betting on one “super-model.” They’re assembling complementary systems that mirror how high-performing enterprise teams already work.

If you’re paying for Claude Opus, Codex, and Gemini, you’re not being redundant.

You’re accidentally doing something very right.

What follows is the stack I ended up with — not because it was fashionable, but because it solved the exact failure modes I kept running into when I tried to make one model do everything.

The 2026 Tri-Model Development Team

The key insight is simple:

Each model has a different failure mode — and that’s exactly why they work best together.

When you intentionally assign roles, the system starts to look less like “AI tools” and more like a mature engineering organization.

1. The Architect — Codex (GPT-5.2 / Codex Max)

Codex excels at structural integrity.

It’s not eager. It’s not chatty. And that’s a feature, not a bug.

Codex is strongest at:

• System decomposition and boundary definition
• Database schemas and data ownership
• API contracts and invariants
• Threat modeling and security review
• Asking uncomfortable questions early

Typical prompt:

“Analyze this requirement. Propose a scalable architecture, a Mermaid diagram, and a strict API contract. Identify failure modes and security risks.”

Why Codex belongs here: Codex tends to fail by being conservative or slow, not reckless. It will poke holes in an idea before implementation begins — which is exactly what you want before any code exists.

Think of Codex as your principal architect who refuses to approve a design without sharp edges clearly defined.

2. The Engineer — Claude Opus (4.5 Max)

Claude Opus is where real work gets done.

It shines in long-horizon implementation, where continuity, refactoring discipline, and context retention actually matter.

Claude is strongest at:

• Writing production-grade code
• Refactoring large codebases
• Implementing complex business logic
• Following contracts precisely
• Maintaining forward momentum

Typical workflow (CLI or IDE):

“Implement Step 1 of the Codex architecture. Follow the API contract exactly. Do not introduce new endpoints.”

Why Claude owns implementation: Claude’s biggest strength is momentum. Its biggest risk is confidence. That’s why it should build inside boundaries, not define them.

When Codex draws the map, Claude is the best tool I’ve found for actually paving the roads.

3. The Inspector — Gemini (now 3.1)

The Reality Gap: Why Great Code Still Fails

This is where most stacks quietly fail.

You can have a perfect Architect (Codex) and a tireless Engineer (Claude), and they can produce 1,000 lines of bug-free, syntactically correct code that still results in a total failure for the end user. Why? Because Claude and Codex are essentially “hallucinating” the visual outcome. They are predicting what the code should look like based on text patterns, but they aren’t actually looking at the screen. They can’t see that the “Submit” button is hidden behind a floating footer, or that the contrast ratio on your new “dark mode” makes the text unreadable for anyone with a visual impairment.

In a traditional AI stack, you are the only one with eyes. You become the bottleneck, manually checking every UI tweak and accessibility requirement.

Gemini is the secret weapon because it breaks the “Text-Only” silo.

Gemini isn’t just another reasoning engine; it’s natively multimodal. It allows the ACE framework to close the loop between Intent (Codex), Implementation (Claude), and Reality (Gemini). While the first two models work in the world of logic and syntax, Gemini works in the world of pixels and perception — meaning it can evaluate reality, not just code.

Gemini is strongest at:

• Visual QA and UI inspection
• Accessibility and ADA/WCAG compliance
• UX inconsistencies
• Layout, spacing, contrast, and affordances

Typical workflow:

• Point Gemini at a live localhost or staging UI
• Prompt it with (as an example):

“Inspect this UI. Identify WCAG 2.1 contrast issues, missing aria labels, keyboard-navigation failures, and layout problems for motor-impaired users.”

Why this matters: Claude and Codex infer outcomes from text. Gemini sees the pixels.

That difference alone justifies its place in the stack.

Shared Context Is the Real Multiplier

The models don’t need to talk to each other.

They need to share truth.

In practice, that means:

• Codex produces versioned artifacts (architecture docs, OpenAPI specs)
• Claude consumes those artifacts verbatim during implementation
• Gemini evaluates rendered output against the same intent

Whether you use MCP, a conductor layer, or disciplined file-based handoffs, the pattern matters more than the tooling.

This is where AI stops being assistive and starts being organizational.

The ADA Inspector: Where This Stack Pays for Itself

Accessibility is a perfect example of why single-model workflows fail.

Most accessibility bugs:

• Pass code review
• Pass tests
• Fail humans

Gemini routinely catches issues text-only models miss:

• Insufficient contrast that technically compiles
• Interactive elements with poor hit targets
• Keyboard traps
• Confusing focus order

This isn’t just about compliance. It’s about quality debt that accumulates when nobody is actually looking at the UI.

4. The Orchestration Layer: The Infrastructure of Truth

If Codex is the mind, Claude is the hands, and Gemini is the eyes, then the Orchestration Layer is the nervous system.

The biggest risk in a multi-model workflow is Semantic Drift. This happens when Claude, in the heat of implementation “momentum,” makes a small, logical pivot that isn’t reflected back in the Architect’s original design. Without a dedicated layer to manage this, you end up exactly where we started: with a “handoff” that contains context but lacks understanding.

To move from a manual process to a true system, the ACE framework requires an Infrastructure of Truth.

The Project Ledger (The “Source of State”)

We no longer rely on the model’s “memory” or the chat history. Those are ephemeral and prone to noise. Instead, we maintain a Project Ledger — a single, version-controlled Markdown file (PROJECT_STATE.md) that serves as the system's long-term memory.

• The Rule: No implementation starts without Claude reading the Ledger.
• The Handback: When Claude finishes a feature, its final task is not just to “provide the code,” but to update the Ledger with the new “Current State,” including any technical debt incurred or new file paths created.
• The Audit: Periodically, Codex (the Architect) reviews the Ledger to ensure the implementation hasn’t drifted from the original structural integrity.

The Protocol of Immutable Artifacts

Models in the ACE framework should never talk to each other through you as a “messenger.” They should communicate through Immutable Artifacts. By forcing the output into specific file types, you create a “Contract” that the next model must follow:

• **.arch (System Design):** The Mermaid diagrams and boundary definitions from Codex.
• **.spec (The Contract):** The OpenAPI or TypeScript interfaces that Claude is forbidden from changing.
• **.ledger (The State):** The living document of what has actually been built.
• **.report (The Reality):** The visual and accessibility audit from Gemini.

UPDATE: The Workspace: Bringing the Conductor to the Podium

You might be wondering how to physically manage all these artifacts without drowning in overlapping browser tabs and disjointed console windows. Since the original submission of this article I have found a very good tool for this.

My solution is Zellij.

Because the ACE framework relies heavily on command-line implementation — like running Claude Opus CLI, local server instances, and file-watchers simultaneously — Zellij acts as my terminal multiplexer and the physical “podium” for the Conductor role. It allows me to snap my Architect’s outputs, the Constructor’s active CLI, and the .ledger into persistent, unified panes on a single ultrawide monitor.

More importantly, Zellij provides session persistence. If I step away or a terminal crashes, the orchestration state isn’t lost. I don’t have to rebuild my workspace; I just reattach to the session and pick up exactly where the flow of responsibility left off.

Closing the Loop: The Conductor Role

In this framework, your job shifts from Coder to Conductor. You aren’t just copy-pasting; you are enforcing the “flow of responsibility.”

When a model hits a wall, you don’t ask it to try harder. You determine which role failed. Did the Engineer (Claude) fail because the Architect (Codex) provided a weak .spec? Or did the Engineer fail because it ignored the .ledger?

By managing the flow of artifacts rather than the flow of words, you ensure that the “Cognitive Singularity” you’re building remains organized, scalable, and — most importantly — accurate to your original intent.

5. The Human-in-the-Loop: The Chief Systems Engineer

There is a dangerous myth in 2026 that “Agentic Orchestration” means the human is now optional. In reality, the more complex the multi-model system, the more critical the Human-in-the-Loop (HITL) becomes.

In the ACE framework, you are not a “user” of AI tools; you are the Chief Systems Engineer. Your role is to provide the “intentionality” that models lack.

The “Veto” and the “Pivot”

Models are optimized for completion, not correctness. Claude might confidently implement a feature that is technically sound but commercially useless. Codex might design a system that is secure but impossible to maintain.

• The Human Role: You are the only one who understands the Business Context. You must act as the ultimate gatekeeper for every handoff.
• The Rule: Never allow a model to update the Project Ledger without a human review of the diff. If you skip this, you aren’t orchestrating — you’re just watching a slow-motion train wreck.

Critical Checkpoints for Human Oversight

To maintain alignment, you must insert yourself at these three “high-friction” points:

1. The Design Freeze: After Codex produces the .arch and .spec, you must manually sign off. If the architecture is flawed here, Claude will perfectly implement a disaster.
2. The Edge-Case Injection: Models struggle with “unknown unknowns.” You must look at the Engineer’s plan and ask: “What happens if the database connection drops here?” or “What if the user double-clicks this button?”
3. The “Vibe” Reality Check: Gemini can check ADA contrast and layout, but it cannot tell you if the UI feels like a premium product. Only you can judge the “soul” of the application.

Avoiding “Automation Blindness”

The greatest threat to this framework is Automation Blindness — the tendency to trust the output because the “system” generated it.

Warning: If you stop reading the code because Claude is “usually right,” you have ceded control of the system.

The ACE framework is a force multiplier for your expertise, not a replacement for it. The models provide the Cognitive Labor, but you provide the Cognitive Direction. You define the “Why,” the models execute the “How,” and you verify the “What.”

Common Anti-Patterns (Learned the Hard Way…trust me)

A few rules that make this stack work:

• ❌ Don’t let Claude design security boundaries
• ❌ Don’t let Codex generate UI
• ❌ Don’t ask Gemini to refactor backend logic
• ✅ Do keep each model in its lane
• ✅ Do force explicit handoffs
• ✅ Do treat architecture as a first-class artifact

Knowing what not to do is half the battle.

From Coder to Orchestrator

The biggest shift isn’t technical — it’s cognitive.

You’re no longer prompting a tool. You’re directing a system.

In 2026, the most effective developers won’t be the ones who type the fastest or prompt the cleverest. They’ll be the ones who design flows of responsibility, enforce boundaries, and verify outcomes from multiple angles.

The future isn’t one model to rule them all. It’s knowing which mind to trust — and when.

That’s what “vibe coding” looks like when it grows up.