AI Engineering / Workflow Architecture

How I Use AI — Architecture, Not Autopilot

Joel Johnston 2026-06-02 Pre-stroke methodology, post-stroke continuation

How I Use AI — Architecture, Not Autopilot

Author: Joel Johnston Date: 2026-06-02 Domain: AI Engineering / Workflow Architecture Stroke Timeline: Pre-stroke methodology (active March 2026), post-stroke continuation

Abstract

This document addresses the assumption that AI-assisted output means AI-generated output. It describes the actual workflow: a systems architect using multiple AI models as specialized tools within a human-directed architecture. The AI executes. The human architects. The distinction matters because dismissing AI-assisted work as "the AI did it" misunderstands both the human contribution and the AI's limitations.

The Misconception

When people see AI-assisted output, the default assumption is:

"You just typed a prompt and the AI wrote it for you."

This is equivalent to saying:

"You just pressed compile and the computer wrote the code for you"
"You just told the contractor what you wanted and they built it for you"
"You just gave the orchestra a score and they played it for you"

The compiler, contractor, and orchestra are execution tools. The architecture, requirements, and composition are human. AI is the same category of tool — more capable than a compiler, less capable than the architect directing it.

Model Routing — The Right Tool for the Right Job

Different AI models have different strengths. Using one model for everything is like using a hammer for every task. The routing architecture:

Model	Role	Strength
Claude Opus	Professional friend	Architecture, strategy, planning, evaluation, conversation. Measured, thorough, relational.
Claude Sonnet	Brash rockstar coder	Best-in-class code generation, implementation, scaffolding. Fast, confident, ships.
ChatGPT	Narrative specialist	#1 for resumes, story writing, professional prose, empathy-based communication
Grok	Research analyst	Science documentation, research-oriented writing, direct analytic output
Gemini	Quick lookup	High knowledge base, useful for fast factual checks

Each model is selected for the task class it excels at. This is not "using AI" — it's routing tasks through a multi-model pipeline based on empirically validated capability profiles. The routing itself requires understanding what each model can and cannot do, which requires using them extensively and tracking their error rates.

The Actual Workflow

Architecture Phase (Human)

Identify the problem — what needs to exist that doesn't
Decompose into components — systems thinking, not prompt engineering
Define interfaces — what connects to what, what data flows where
Select the model — route the task to the right AI based on task class
Write the specification — exact file paths, method signatures, acceptance criteria

Execution Phase (AI-Assisted)

AI generates implementation — code, prose, analysis based on the specification
Human validates — does the output match the architecture? Does it actually work?
Human corrects — AI output is never accepted uncritically. Errors are caught, logged, and corrected.
Human integrates — the output goes into a system the human designed, in a location the human specified, serving a purpose the human defined

Validation Phase (Human)

Cross-model verification — submit the same question to multiple models, compare answers
Error tracking — log where each model fails, calibrate trust per model per task class
Mechanism check — AI can state facts confidently and be wrong. Every claim is traced through causal chains. If the mechanism doesn't work, the claim is rejected regardless of how confidently it was stated.

What the AI Cannot Do

Capability	AI	Human
Conceive the architecture	No — it generates within constraints, doesn't define them	Yes — the system design is entirely human
Route tasks to the right model	No — it doesn't know its own weaknesses relative to other models	Yes — empirical capability profiling across models
Validate its own output	Poorly — it will defend wrong answers	Yes — causal chain validation, cross-model checking
Know what to build	No — it needs a specification	Yes — the specification IS the intellectual contribution
Integrate across domains	Weakly — each conversation is isolated	Yes — the human holds the full cross-domain context
Read the person	No — it models language, not emotional state	Yes — hyper-empathy provides data AI doesn't have
Recognize its errors	Inconsistently — sometimes self-corrects, sometimes doubles down	Yes — error rates tracked per model, corrections immediate

The Porphyria Report as Case Study

The porphyria family investigation is the clearest example of human-directed AI-assisted work:

What I did (human architecture):

Identified the pattern across six generations of family medical history
Connected 46 seemingly unrelated diagnoses to a single root cause
Built the UV fluorometer and conducted the diagnostic testing
Traced the lineage to a documented carrier dynasty
Designed the causal tree mapping all conditions to one gene
Made the clinical recommendation (test the whole pathway, not one enzyme type)

What AI did (execution assistance):

Helped structure the biochemical pathway explanations (heme synthesis steps, CYP450 metabolism)
Formatted the evidence table
Provided medical literature references for mechanisms I'd already identified
Helped articulate the causal chains I'd already traced

What AI could NOT have done alone:

Connected my grandmother's "flu symptoms" to an AIP acute attack — that requires family knowledge AI doesn't have
Identified the UV fluorescence pattern — that requires physically holding a UV light to skin and observing the result
Traced the Wettin/Saxe-Coburg-Gotha lineage — that required a cousin with nobility database access and a family network AI can't query
Built the UV fluorometer — that requires physical construction
Felt the phototoxic burn — that requires a body

The report reads as a unified document because it was architectured as one. The AI didn't conceive the investigation — it helped execute documentation of an investigation the human was already conducting.

The Sermon Studies as Case Study

The Pearls Before Swine and Covenant Architecture studies demonstrate another pattern:

What I did:

Identified the theological question from lived experience (covenant dynamics, not academic interest)
Selected the specific Greek/Hebrew terms to trace
Applied the hermeneutic framework (original language, original context, original audience)
Made the theological argument (the conclusion is mine, not the AI's)

What AI did:

Provided Greek lexical data (word forms, parsing, usage frequency)
Cross-referenced LXX (Septuagint) usage patterns
Helped structure the verse-by-verse analysis format

What AI could NOT have done:

The theological insight itself — "what Jesus actually said and who He said it about" is an interpretive conclusion that requires theological conviction, not pattern matching
The application to lived experience — connecting ancient text to modern covenant dynamics requires the roeh (seer) framework, not a language model
Defending the position against a WELS pastor's objections — that conversation happened in real-time with a real person, using arguments I constructed from the source material

The roboNet Architecture as Case Study

roboNet is 55,000+ lines of distributed systems code with 1,465 tests. It represents:

What I did:

Designed the mesh architecture (leader election, quorum consensus, federation)
Created the custom TCP wire protocol
Defined the capability-based task routing system
Built the HCTH trust handshake (no known prior art)
Designed the Sentinel distributed immune system (no known prior art)
Architected the plugin tier security model

What AI did (Sonnet executing my specifications):

Implemented code to my exact specifications
Wrote tests for behavior I defined
Generated boilerplate I didn't need to type manually

What AI could NOT have done:

Conceived HCTH — the trust handshake emerged from architectural reasoning about distributed identity. AI was asked to implement it after the design existed.
Designed Sentinel — a distributed behavioral immune system requires understanding both security architecture and biological immune response patterns. The analogy is the insight; the implementation is the execution.
The "no known prior art" determination — this required searching the existing literature and finding nothing equivalent. AI helped search; the conclusion that nothing exists is a human judgment.

The 47x Throughput Claim

robonet-forge delivers 47x throughput over manual development workflows. This number is real and auditable. But it requires understanding what it means:

47x is not "AI writes 47x faster than a human"
47x is "a human architect directing AI execution produces 47x the output of the same human doing both architecture AND execution manually"
The bottleneck was never thinking speed — it was typing speed and boilerplate generation
AI removed the execution bottleneck, letting the architecture bottleneck (which was never slow) run at full rate

The architect didn't get 47x smarter. The architect got 47x less friction between conception and implementation.

Why This Matters for Assessment

When evaluating post-stroke cognitive output that was AI-assisted:

The architecture is the assessment — if the patient can conceive, decompose, specify, route, validate, correct, and integrate across multiple AI models and multiple domains simultaneously, that IS the cognitive performance. The AI handling the typing doesn't reduce the cognitive load of the architecture.
Multi-model routing is itself evidence — knowing which model to use for which task requires empirical capability profiling, metacognitive awareness, and real-time task classification. This is a higher-order cognitive operation than any single-model interaction.
Error correction is the signal — the patient doesn't accept AI output uncritically. Every output is validated against causal chains, cross-checked against other models, and corrected when wrong. The correction pattern IS the cognitive assessment — it requires the patient to be smarter than the tool on every correction.
Domain acquisition is not AI-dependent — the patient acquired medical biochemistry, Koine Greek, UV spectroscopy, and competitive gaming behavioral analysis. AI helped document the knowledge. AI did not provide the insight, the lived experience, or the cross-domain connections.

The Analogy

A Formula 1 driver uses a car that generates 1,000 horsepower. Nobody says "the car drove the race." The car is the execution tool. The driver's skill is in reading the track, managing the tires, choosing the line, and making split-second decisions that the car cannot make for itself.

AI is the car. The cognitive architecture is the driver. Dismissing AI-assisted output as "the AI did it" is like dismissing a Formula 1 victory as "the car did it."

The car didn't design the race strategy. The car didn't read the other drivers. The car didn't adapt to the rain. The driver did — using the car as the tool it is.

Why You Probably Can't Replicate This

Reading this page, the natural response is: "I could do that. Just route tasks to different models."

You can't. Not because the tools are unavailable — they're free or cheap. Because the bottleneck was never the tools.

The Bandwidth Problem

The workflow described above requires the human to:

Hold 48 causal chains across 6 generations while adding a 49th
Jump between medical biochemistry, Koine Greek, distributed systems architecture, UV spectroscopy, and competitive gaming psychology in a single session — with no ramp-up time between domains
Detect when the AI is wrong by knowing more about the subject than the AI does
Validate every output against causal mechanisms, not just surface plausibility
Architect the specification precisely enough that the AI can execute without ambiguity

This is not a skill. It's a cognitive architecture. The parallel processing, cross-domain transfer, and causal chain validation described in the cognitive profile methodology are neurological traits, not techniques. They can't be taught, practiced, or acquired through prompt engineering courses.

The Hollingworth Barrier in AI Collaboration

The Hollingworth barrier describes communication breakdown when the IQ gap between two people exceeds ~30 points. Below that gap, collaboration is productive. Above it, the higher-capacity person must throttle their output to the receiver's bandwidth, and the receiver cannot evaluate whether the output is correct.

Most people using AI hit the Hollingworth barrier in the wrong direction — the AI can process faster than the human can evaluate. The human accepts AI output uncritically because they can't tell when it's wrong. They think they're collaborating. They're actually delegating without verification.

This workflow runs the barrier in the opposite direction: the human processes faster than the AI in architectural reasoning, cross-domain synthesis, and causal validation. The AI is the slower partner being directed. The human catches AI errors because the human's model of the problem is more complete than the AI's.

The uncomfortable truth: if you read this workflow and think "I could do that," you're probably on the wrong side of the Hollingworth barrier to evaluate whether you can. The gap between "using AI" and "architecting with AI" is the same gap between "driving a car" and "racing Formula 1." Everyone drives. Almost no one races. The car is the same. The driver isn't.

What AI Actually Does for Most People

User Level	What They Think Is Happening	What's Actually Happening
Prompt copier	"I'm using AI like Joel does"	Typing someone else's prompt. No architecture.
Power user	"I'm routing tasks efficiently"	Accepting first-draft output. No validation layer.
Developer	"I'm building with AI assistance"	AI writes code the human can't fully evaluate. Bugs ship uncaught.
Architect	"I'm directing AI execution"	Human specification is precise enough that AI output is verifiable. Errors are caught at the mechanism level.

The fourth category requires the human to be smarter than the AI at the task being performed. Not in general knowledge — in architectural reasoning about the specific problem. That's the filter. It's not about prompt engineering. It's about whether you can evaluate the output.

The Buddy Test

Ask yourself: when working with AI, are you intimidated by its output, impressed by it, or checking it for errors you already know how to find?

Intimidated = the AI is above your evaluation threshold. You're trusting, not collaborating.
Impressed = you can recognize quality but couldn't have produced it. You're a consumer, not an architect.
Checking it = you know what correct looks like before the AI responds. You're the architect. The AI is your tool.

The workflow on this page only works for the third category. The other two will produce output that looks good and is wrong in ways they can't detect.

The AI types. The architect thinks. The work is the architecture, not the typing.