My AI engineering workflow.

The short version

My workflow is not just “ask an AI to code”. It is a small operating system for agent-assisted engineering.

I use Pi as the workbench (pi.dev), then layer in model routing, nested project context, durable memory, subagents, diff review, and custom skills for planning, implementation, branch review, pre-commit review, and commit messages.

The shape of the setup

~/.pi/agent
├── settings.json              # provider, model, packages, transport
├── extensions/
│   ├── auto-model-router.ts   # complexity-based model routing
│   ├── nested-context-files.ts # repo instructions and local context
│   └── powerline-footer.ts    # model, git, context, and rate-limit status
├── skills/
│   ├── plan-work              # durable planning and fresh validation
│   ├── implement              # scoped implementation workflow
│   ├── branch-code-review     # merge-readiness review
│   ├── pre-commit-review      # local diff review before commit
│   └── create-commit-message  # commit message from diff and history
├── projects-memory/           # repo-specific memory
└── npm/                       # installed agent packages

The exact tooling will change. The underlying workflow should not: read the repo, understand the task, choose the right level of model, make the smallest safe change, then verify the result.

Model routing is part of the workflow

One of the most useful pieces of my setup is an automatic model router. Routine work should not always use the most expensive model. Hard work should not stay on a cheap model just because that was the default.

My router classifies prompts into rough tiers:

1. 01

   Cheap / fast. Read-only work, simple explanations, small lookups, quick edits, and low risk tasks start on a cheaper fast model.

2. 02

   Normal. Implementation, debugging, tests, components, APIs, and normal coding work route to a stronger everyday model.

3. 03

   Hard. Architecture, security, migrations, race conditions, production issues, long prompts, failed attempts, or explicit high-risk work escalate to the strongest model.

This matters commercially. If every task uses the premium model by default, the workflow becomes expensive very quickly. If every task uses the cheapest model, the workflow becomes unreliable for difficult work. Routing lets me use agents more often while keeping cost, latency, and risk in proportion to the task.

Nested context keeps agents grounded

Another important extension loads the relevant project instructions when the agent touches a path. If a repo has AGENTS.md or CLAUDE.md files in parent directories, the extension injects those instructions into the session when the agent reads, writes, edits, or runs path-like shell commands.

That solves a boring but common failure mode: agents ignore local conventions because the right context never made it into the working turn.

tool touches: src/pages/work.astro

load relevant context:
- /repo/AGENTS.md
- /repo/docs/style.md or local project rules when applicable

then work inside those constraints

For me, this is one of the differences between casual AI use and an actual agent workflow. The agent should not just be clever. It should be constrained by the project it is working inside.

Memory is for durable context, not magic

I use memory for things that should survive across sessions: project structure, repo conventions, known tool quirks, validation commands, preferences, and mistakes I do not want repeated.

I do not want memory to become a junk drawer. Useful memory is mostly boring: where things live, what command verifies a change, which gotchas have already cost time, and what the user has explicitly decided.

1. 01

   User memory. Stable preferences, working style, stack, and review expectations.

2. 02

   Project memory. Repo-specific conventions, commands, architecture notes, and recurring failure modes.

3. 03

   Failure memory. Tool quirks, broken assumptions, and corrections that should change future behaviour.

The goal is not to make the agent sound like it remembers everything. The goal is to stop wasting time rediscovering the same constraints.

Subagents are useful when they create better judgement

I do not want to split every task into a swarm. For small edits, one agent is enough. For higher-risk work, I use subagents when separation improves the quality of the decision.

The main pattern is simple: do not let the same agent that created the plan be the only one validating the plan.

planner -> writes a durable plan
validator -> reads the plan cold against the repo
implementer -> applies the approved change
reviewer -> checks the resulting diff

That cold-read step matters. If the validator inherits the same conversation, it can inherit the same blind spots. I want disagreement, not reinforcement.

The skills I keep reaching for

My custom skills turn repeatable workflows into named routines. The useful ones are not magic prompts. They are procedural rails that make the agent work in a way I can review.

1. 01

   Plan work. Draft a durable markdown plan, then send it to a fresh validator that checks the plan against the real codebase.

2. 02

   Implement. Apply an approved change by reading context first, following existing conventions, keeping the diff small, and running relevant checks.

3. 03

   Branch review. Review a branch for merge readiness and save a human-readable checklist under .agents/reviews/ so issues can be worked through one by one.

4. 04

   Pre-commit review. Review staged, unstaged, and untracked work before committing, with a readiness score and numbered issues.

The common thread is control. The agent can move quickly, but the workflow keeps asking: what changed, why, how do we know it works, and would I be willing to own it later?

How I use agents day to day

1. 01

   Explore. Ask the agent to inspect files, callers, tests, config, and existing patterns before it suggests a change.

2. 02

   Plan. For non-trivial work, turn the task into a small plan with success criteria, files to touch, risks, and a validation path.

3. 03

   Implement. Let the agent handle the mechanical work, but keep the scope fixed and the diff reviewable.

4. 04

   Review. Use diff review, pre-commit review, or a fresh validator when the change is complex enough to deserve a second pass.

5. 05

   Verify. Trust evidence over confidence: tests, builds, screenshots, manual checks, source-backed research, or a clear explanation of what remains unverified.

What I do not outsource

The agent can write code, explain code, draft tests, review diffs, research docs, and suggest options. It does not get final authority over product judgement, architecture, security-sensitive changes, business logic, or whether something is worth shipping.

The best version of this workflow is not flashy. It feels like a disciplined engineering loop with better leverage. AI makes the work faster, but the work is not done until the change is understood, constrained, verified, and worth owning.