← Back to Blog

I Don't Prompt AI, I Orchestrate It

ai claude-code agentic-engineering workflow

Most people treat Claude Code like a smarter autocomplete. Ask a question, paste the answer, move on. That is a waste of the tool.

My Claude Code is not a chatbot. It is an engineering pipeline, composable commands, persistent memory, MCP integrations, and a spec driven build loop that runs autonomously while I do other work.

Here is how it is wired.

The Command Surface

I built this on the SuperClaude framework. Each command is a structured workflow that Claude Code loads and executes. The ones I use daily.

/sc:brainstorm    Surface requirements, ask questions, find edge cases
/sc:design        Produce architecture spec with diagrams
/sc:implement     Write code with TDD, persona aware (backend, frontend, security)
/sc:analyze       Review code across quality, security, performance, architecture
/sc:test          Run tests with coverage
/sc:git           Commit with structured messages
/sc:spawn         Break large tasks into subtasks and delegate
/sc:spec-loop     Run the full build loop from spec to PR

These chain together. They are not one off prompts, they are a pipeline.

The Core Workflow

For a well defined feature, the flow looks like this.

/sc:brainstorm  ->  /sc:design  ->  /sc:spec-loop
"I need X"          Spec written      Loop runs
Edge cases          to disk with      autonomously
surfaced            diagrams

Once /sc:spec-loop kicks off, the system takes over.

SPEC LOOP (automated, up to 2 cycles)

1. Worktree created (main branch never touched)
2. Builder agent learns codebase, writes tests first
3. Builder implements code to pass tests
4. Tests fail? Fix and retry (up to 3 times)
5. PR created
6. Reviewer agent reads PR diff only (cannot touch code)
7. Checks architecture, correctness, tests, style, security
8. Pass means PR ready. Fail means findings fed back to builder.

Then I review and merge.

The Builder and Reviewer are separate agents by design. The Builder writes code in an isolated git worktree. The Reviewer reads the PR diff through GitHub and cannot modify anything. If it finds issues, findings are structured as severity, category, and file line reference, then fed back to the Builder for the next cycle. This mirrors how real teams work. The person writing the code is not the person reviewing it.

Picking The Mode

That autonomous flow is one mode. I pick the mode based on the task.

SMALL TASK, CLEAR SCOPE
  /sc:implement  ->  I steer each step, approve as I go

WELL DEFINED FEATURE
  /sc:brainstorm  ->  /sc:design  ->  /sc:spec-loop
  System loops autonomously, I come back to a PR

LARGE AMBIGUOUS TASK
  /sc:spawn  ->  decomposes into stories
  Each story  ->  /sc:brainstorm  ->  /sc:design  ->  /sc:spec-loop
  The thinking phase is never skipped

For example, “migrate auth from sessions to JWT” is too big for one command. /sc:spawn breaks it into five stories, database schema, backend middleware, frontend token handling, test updates, deployment config. Each story then goes through brainstorm, design, and the spec loop individually.

For exploratory work where I need to steer as I go, I use /sc:implement plus /sc:analyze. I am the feedback loop instead of the system. Both produce the same quality. The difference is whether I am the loop or the system is.

The Behavioral Layer, Karpathy Style CLAUDE.md

Commands tell the agent what to do. CLAUDE.md tells it how to behave. Mine follows Andrej Karpathy’s four principles, distilled from his observations on where LLM coding agents go wrong.

1. THINK BEFORE CODING
   State assumptions. Ask when uncertain.
   Surface tradeoffs. Do not pick silently.

2. SIMPLICITY FIRST
   Minimum code that solves the problem.
   No speculative abstractions. No unrequested flexibility.

3. SURGICAL CHANGES
   Touch only what the task requires.
   Match existing style. Do not refactor adjacent code.
   Every changed line traces to the user's request.

4. GOAL DRIVEN EXECUTION
   Transform tasks into verifiable goals.
   "Fix the bug" becomes "write a failing test, make it pass".
   Loop until verified.

Without this layer, agents drift. They over engineer, they refactor code they were not asked to touch, they ship a plausible looking answer instead of a verified one. The Karpathy rules collapse that failure mode into four lines the agent reads on every session.

This is what turns a code generator into a disciplined engineer. The command pipeline handles orchestration. CLAUDE.md handles judgment.

Memory Across Sessions

The system maintains cross session memory. Each project has its own memory index that tracks conventions, decisions, and context. When I start a new session, it restores where I left off. I run 11 plus projects with individual memory systems and use git worktrees for parallel isolated feature development.

MCP Extends The Pipeline

MCP integrations extend the command surface beyond code.

  • Coolify MCP handles deployment
  • Asana MCP manages tasks
  • XcodeBuildMCP handles iOS simulator workflows and builds

All wired into the same command surface, so I go from spec to deployed feature without leaving the terminal.

The Principle

The spec is the product. The code is a side effect.

I handle the judgment. The system handles the volume.

That is the shift. Prompting is a skill from 2023. Orchestration is the skill now.