DEV Community

Drakko Tarkin
Drakko Tarkin

Posted on

I Was Wrong About AI Coding Assistants. Here's What Changed My Mind (and What I Built About It).

3 months ago I was manually typing "act as a software architect" every time I needed architecture advice from Claude Code.

3 days ago I shipped an open-source routing engine that makes that unnecessary -- forever.

This is the story of building PRISM Forge, what went wrong along the way, and 4 lessons about AI-first software engineering that I didn't expect to learn.

The Problem I Couldn't Unsee

AI coding assistants give you one voice. Smart, capable, generalist. But one voice.

Need architecture advice? "Act as a software architect and..."
Need QA? "Now act as a QA engineer and..."
Need a code review? "Switch to code reviewer mode and..."

I used BMAD-METHOD for 3 months -- a persona framework that requires manual invocation (*analyst, *pm, *architect). The concept was powerful. The friction was constant. I wanted the experts to just... show up.

Once I saw the pattern, I couldn't unsee it. Every manual prompt-switch was a tiny failure of the tool to understand what I actually needed.

The Solution: Signal-Based Routing

PRISM Forge installs 23 expert personas into Claude Code that activate automatically based on natural language signals.

How the Routing Engine Works

A meta-persona named Susie (Chief of Staff) evaluates every user message:

  1. Intent classification -- 9 categories: Build, Investigate, Plan, Validate, Create, Challenge, Orient, Document, Narrate
  2. Domain matching -- 23 work types, each mapped to a primary persona and optional supporting personas
  3. Signal detection -- 24 shared signals (co-activate multiple personas) + 18 specialist signals (exclusive triggers)
  4. Team assembly -- one primary persona leads, supporting personas contribute attributed perspectives

The critical design decision: routing is deterministic. Same message always activates the same persona team. The AI reads the routing rules and follows them like a state machine. No LLM randomness in the routing decision.

What It Looks Like

"How should this be architected?"
--> Winston (Architect) activates

"I'm stuck on this bug"
--> Dr. Quinn (Creative Problem Solver) steps in

"Plan how to refactor the auth module -- it's too complex"
--> Bob (Scrum Master) leads + Jobs (scope reduction) + Victor (approach) + Amelia (execution)

"War room"
--> All 23 personas load and debate with genuine disagreement
Enter fullscreen mode Exit fullscreen mode

Multi-persona responses keep voices distinct:

**Mary (Business Analyst):**
The data shows three usage patterns...

**Winston (Architect):**
That maps to a service-per-pattern architecture...
Enter fullscreen mode Exit fullscreen mode

The Build: Directing AI Agents to Build an AI Agent System

Here's where it gets recursive. I built a 23-persona AI routing engine... by directing AI agents.

~30 commits. 3 days. 7 development phases. Zero lines of code written by hand.

I don't write code. I orchestrate AI agents to build software. That's not a hypothetical future -- it's how this shipped.

My Role vs. The AI's Role

I did: Set direction. Challenged requirements. Ran war room sessions for architecture decisions. Scope-reviewed every phase. Made every judgment call.

Claude Code did: Ported 23 persona files. Audited every persona for balance and accuracy. Redesigned the routing architecture. Built a 76-check structural audit. Implemented the CLI installer. Wrote all documentation. Created CI/CD workflows.

The 7 Phases

Phase What Key Outcome
1. Legal + Scaffold MIT license, dual copyright, repo structure Legal foundation clean
2. Cleansing Port 22 persona files ported, all references cleaned Zero stale references
3. Deep Content Audit Every persona individually audited 6 signal mismatches caught
3.1. Dynamic Orchestrator Routing redesigned as intent-driven orchestration 18/18 routing tests pass
4. Structural Audit Audit checklist rewritten (48 to 76 checks) 66/66 testable checks pass
5. CLI Installer npx prism-forge install/uninstall/verify 3-command install experience
6. Documentation README, architecture guide, CONTRIBUTING Publication-ready docs
7. Org + Publish GitHub org, npm publish, CI/CD v1.0.0 live

What I Learned (The Part That Actually Matters)

1. The routing is the product, not the personas

This was the biggest surprise. Anyone can write 23 persona files. Paste a system prompt, give it a name, done.

The innovation is the routing layer -- the intelligence that decides which experts activate and when. Getting the signal tables, domain registry, and team assembly logic right took more iteration than writing any individual persona.

The takeaway: If you're building a persona system, spend 80% of your time on the routing logic and 20% on persona content. Most people do the opposite.

2. Disagreement had to be engineered in

My first multi-persona responses were consensus chains. The Analyst said X. The Architect agreed. The QA engineer agreed. Everyone agreed. It was useless.

The problem: LLMs default to agreement. They want to be helpful. Multiple personas agreeing is the path of least resistance.

The fix: the routing engine now explicitly instructs the orchestrator to surface tension. "A war room where everyone agrees is a failed war room." I had to make disagreement a structural requirement, not just a possibility.

The takeaway: If you want diverse AI perspectives, you have to engineer the disagreement. The LLM won't give it to you voluntarily.

3. Structural audits are non-negotiable at scale

23 personas. 24 shared signals. 18 specialist signals. 23 domain registry entries. 18 specialist load directives. That's hundreds of cross-references.

During the content audit phase, we caught 6 signal mismatches -- personas claiming signals in their own file that weren't registered in the routing engine's signal table. Without the 76-check audit system, those would have been silent failures where a persona never activated despite having the right signals defined.

The takeaway: Any system with cross-referencing config files needs automated consistency checks. Drift prevention is always cheaper than drift correction.

4. AI-first engineering is real -- but the human role doesn't shrink

I didn't write code. But I made every decision that mattered: what to build, how to architect it, when to cut scope, what quality standard to hold.

The AI is an extraordinary implementation partner. Fast, thorough, tireless. It is not a product thinker. It doesn't challenge requirements. It doesn't ask "should we build this at all?" It doesn't feel the friction that motivates the right design.

The takeaway: AI-first engineering doesn't remove the human. It changes what the human does -- from typing code to making decisions, challenging assumptions, and setting direction. That's harder, not easier.

Try It

One command to install:

npx prism-forge install
Enter fullscreen mode Exit fullscreen mode

One command to remove if it's not for you: npx prism-forge uninstall

Then use Claude Code normally. The personas activate from your natural language -- no new commands to learn.

MIT licensed. Contributions welcome -- including new personas via the built-in create-persona skill.


PRISM Forge is derived from BMAD-METHOD (MIT licensed, BMad Code LLC). The signal-based routing engine, dynamic orchestration, structural audit system, and CLI installer are original work.

Top comments (0)