A field note on how I configured my AI coding workflow around Pi, el Gentleman, Gentle AI, OpenSpec, subagents, model routing, skills, restore paths, and review gates.
Most developers describe their AI setup as a list of tools: Claude, Cursor, Codex, ChatGPT, local models, terminals, extensions.
That is not how I think about mine.
My setup is a development harness: a controlled way to turn powerful models into reviewable engineering work. The goal is not to make the model sound smarter. The goal is to make the workflow safer, more inspectable, and easier to hand off.
The core stack I use today is built around Pi, a terminal coding harness that can read files, edit code, run commands, and be extended with skills, extensions, prompt templates, packages, and custom tooling. On top of that I layer my own operating discipline: el Gentleman, Gentle AI, OpenSpec, subagents, memory, review gates, context tools, and model routing.
The important part: this is not just a vibe or a prompt. The setup has structure: global rules, model routing, SDD phase agents, workflow skills, safety gates, restore paths, and review rules. The value is not that the configuration exists somewhere. The value is that the configuration makes the agent behave like a controlled engineering environment instead of a loose chat session.
This post is the public explanation of that system.
AI coding gets messy fast.
A model can inspect ten files, suggest an architecture, write code, run tests, and summarize the result in one long session. That sounds productive until you ask basic engineering questions:
My harness exists to answer those questions.
I do not want AI as a magic text box. I want AI as a disciplined engineering runtime.
Pi is the terminal surface. It gives the model a small, concrete set of powers: read files, edit files, run shell commands, and use installed capabilities.
That minimalism matters. Instead of starting from a giant IDE abstraction, I start from observable operations:
read → understand
edit → change
bash → verify
write → persist artifactsPi is also extensible. It can load skills, extensions, themes, prompt templates, and package-provided capabilities. In my setup, that means the raw coding harness becomes a full workflow environment without forking the tool itself.
The harness is more than a list of installed tools. It controls how work enters the system, who is allowed to act on it, how context is bounded, when artifacts are required, and what must be verified before I call something done.
The main pieces are:
global operating rules how the parent session talks, delegates, edits, and verifies
model routing which model gets orchestration, coding, review, research, or media work
skill routing which workflow should handle SDD, PRs, reviews, docs, releases, or comments
SDD/OpenSpec flow when intent becomes proposal, specs, design, tasks, apply, verify, archive
subagent contracts scout, worker, reviewer, verifier, researcher, each with a bounded job
safety policy no destructive git, no commits, no deploys, no secrets without explicit approval
restore path how the setup can be rebuilt without copying private sessions or credentialsThat is the real point. A normal AI setup says “use this model and these tools.” My harness says: this is how work moves through the machine.
The most important part of my setup is not a giant system prompt. It is the workflow around the model.
I use a senior-architect persona I call el Gentleman. The point is not personality theater. The point is operating rules:
That turns the model from “autocomplete with shell access” into something closer to an engineering assistant with process constraints.
This is the shape of the harness today:
Pi terminal runtime
├─ Global operating rules
├─ Model routing policy
├─ Skill routing and workflow constraints
├─ Restore and safety paths
├─ el Gentleman orchestration rules
├─ Gentle AI workflow discipline
├─ OpenSpec / SDD artifacts
├─ Subagents for scout / worker / reviewer / verifier roles
├─ Lumen for codebase/context discovery when available
├─ Headroom for context compression when sessions get large
├─ Engram memory for durable decisions and session summaries
├─ Skills for specialized repeatable workflows
├─ Custom CLIs and shell scripts for local automation
└─ Model routing by task: reasoning, coding, review, research, mediaThe point is that each layer has a job. I do not want one giant assistant trying to remember everything. I want a harness where decisions, files, agents, and verification steps have clear boundaries.
That structure matters because it makes behavior auditable. If something changes, I can ask: is it a global rule, a Pi setting, a skill, a model-routing decision, a restore path, or a package update? That is the difference between “I prompted the model” and “I operate an AI coding environment.”
Gentle AI is the workflow layer I use to keep AI work from turning into a giant unreviewable diff.
The rules I care about most:
I edited my setup around that idea. The model can be powerful, but the harness should stay boring: clear scope, clear files, clear checks, clear handoff.
For non-trivial changes, I use Spec-Driven Development with OpenSpec artifacts.
A typical flow looks like this:
explore → proposal → specs → design → tasks → apply → verify → archiveThe important part is that intent leaves the chat and becomes files:
openspec/changes/<change-id>/proposal.md
openspec/changes/<change-id>/design.md
openspec/changes/<change-id>/specs/**/spec.md
openspec/changes/<change-id>/tasks.mdThat gives me a few benefits:
This portfolio itself was built that way: proposal, design, specs, tasks, implementation, verify.
I use subagents for work that benefits from fresh context or separation of concerns.
The roles I use most often:
| Agent type | What I use it for |
|---|---|
| Scout / locator | Finds files, symbols, routes, style systems, or relevant code paths without loading the whole repo into the parent session. |
| Context builder | Reads a focused slice and returns a compressed map: what matters, where it lives, and what to avoid touching. |
| Worker | Implements a bounded change after the parent has clarified scope and success criteria. |
| Researcher | Looks up current API docs, library behavior, or design references before implementation. |
| Reviewer | Audits a diff from fresh context before I call the work done. |
| Verifier | Checks whether an implementation satisfies OpenSpec tasks, specs, and verification criteria. |
| Council | Runs multiple viewpoints, for example copy/UX/implementation, then I synthesize the decision. |
The parent session remains the orchestrator. It decides what to delegate, receives the result, verifies the actual files, and reports back.
That separation is important. If the same model that made the assumptions also reviews the result, the review is weaker. Fresh-context review catches different failures.
Two tools changed how I think about context:
Lumen is for finding and understanding codebase context without brute-force reading everything. When I need conceptual lookup or codebase discovery, I prefer a targeted search path over dumping huge files into the main session.
Headroom is for keeping large sessions usable. If a tool output or research pass becomes too big, I want compression before reasoning. The goal is to preserve decisions and evidence, not every line of raw output.
My rule is simple:
large context → compress or delegate
exact symbol → find_definition / grep
known file → read directly
unknown area → scout firstThat discipline matters because context budget is an engineering constraint. Treating it casually makes the model worse and the session harder to review.
I use many skills, but these are the ones that shape my workflow the most.
For proposal, specs, design, tasks, apply, verify, sync, and archive. This is the backbone for changes that need artifacts instead of chat memory.
I use this to avoid default AI UI: generic cards, SaaS blue, centered hero, no aesthetic direction. It forces a visual decision before generating code.
For reviewable plans, fresh-context audits, diff checks, and independent verification. This is how I avoid trusting the implementation summary blindly.
For README, PR notes, architecture docs, and handoffs. The rule is: lead with the answer, chunk information, and make review paths explicit.
For human-facing comments, review replies, and collaboration notes. Technical correctness is not enough if the message is hard to act on.
Those skills are not magic. They are reusable constraints. They make the model repeat a workflow I would otherwise have to restate every time.
I also keep a layer of local CLIs and scripts around the harness.
Examples:
gh for GitHub issues, repos, PRs, and review workflow;playwright for screenshots and UI smoke checks;mmx for MiniMax media workflows;The rule is: if I do it twice and it is easy to get wrong, it should become a command, checklist, or skill.
I do not use one model for everything.
My default pattern is:
The goal is not to chase model names. The goal is to route work by job:
reasoning → planning/review/specs
execution → code edits/large reads
research → external info/API docs
verification → independent audit
media → MiniMax / mmx pipelineI treat memory as a separate layer, not something the harness magically owns.
When memory tools are available, I save decisions, discoveries, bug fixes, and artifact summaries. When they are not available, I do not pretend persistence exists.
That distinction matters because memory can become dangerous if treated as unquestioned truth. A saved memory is useful context, not proof. For architecture-sensitive work, I still verify against the current repository.
The harness has hard gates I try to keep:
For AI projects specifically, I also care about:
That is why the chatbot on this site works even without a MiniMax key. If the provider is not configured, the UI falls back instead of pretending to be live.
A typical non-trivial task looks like this:
1. Clarify the objective.
2. Check repo status and project instructions.
3. Decide if the task needs OpenSpec.
4. Use scout/research if context is broad.
5. Write or update artifacts.
6. Let one worker implement a bounded slice.
7. Run the smallest meaningful verification.
8. Run a fresh review if the change is non-trivial.
9. Save important decisions to memory.
10. Report only the outcome, paths, checks, and next action.That loop is slower than blind generation for the first five minutes. It is much faster when the work survives review, handoff, and production.
A lot of AI engineering is not model magic. It is workflow design.
Can you build a system where:
That is the work I am most interested in.
My Pi setup is a practical answer to that problem. It is not the only way to work with AI, but it matches how I want to build: controlled, artifact-driven, reviewable, and production-oriented.
My harness is:
Pi terminal runtime
+ operating configuration for rules, routing, safety, and restore
+ el Gentleman operating discipline
+ Gentle AI workflow rules
+ OpenSpec / SDD artifacts
+ subagents for scoped work
+ Lumen and Headroom for context management
+ skills for repeatable workflows
+ restore scripts and local automation
+ memory for durable decisions
+ model routing by task
+ strict verification gatesThe result is a workflow where AI helps me move faster without turning engineering into an unreviewable chat transcript.
That is the kind of AI development I want to keep doing: not just prompting models, but designing the systems and workflows that make them useful in production.