AI practice / paired development

I build with AI, and I stay accountable for the result.

AI is part of how I work every day, at my job and on my own projects. It doesn't replace engineering judgment. It runs inside a disciplined loop: specs first, agents in parallel, verification as the gate, and a person owning every decision that matters.

Spec before code

Requirements, design, and a task list with acceptance criteria come first, and I review them before an agent writes anything. The spec is the contract that both the agents and I are held to.

A 39-task permission spec

Parallel agents in dependency waves

Independent tasks run at the same time, up to five agents per wave, and tasks that touch the same files never run together. The work moves faster without agents overwriting each other.

Wave-based delivery

Verification is the gate

An agent's report is not proof. Type checks, tests, end-to-end runs, and CI decide whether something is done, under an evidence-based Definition of Done.

Quality and security gates

People own decisions and side effects

Agents draft, trace, and implement. I make the architecture calls and approve anything with real-world effects. In my finance app, no order is placed without my review.

Stock App safety model

Memory that outlasts the session

Lessons learned, handoffs, and current state are written down, so the next session (in any tool, on any machine) starts from what the last one learned.

Eleanor AI

Share the workflow with the team

The spec templates, steering rules, and verification steps I use live in the team's shared repositories, written for both Windows and Mac developers, so new teammates pair with AI the same way.

Shared platform onboarding

The loop

How a feature moves

  1. Spec
    • Requirements, design, and tasks with acceptance criteria, reviewed by me.
  2. Plan waves
    • Tasks grouped by dependency; tasks that touch the same files are kept apart.
  3. Pair and build
    • Agents implement in parallel. I steer, review, and make the calls.
  4. Verify
    • Type checks, tests, end-to-end runs, and CI. Evidence, not reports.
  5. Record
    • Lessons and handoffs written down so the next session starts smarter.

Tools

What I use, and for what

Claude Code

  • Multi-file implementation, reviews, and orchestration

Codex

  • Validation-heavy work streams and parallel tasks

Kiro

  • Spec-driven development with steering files and hooks

ChatGPT

  • Planning, discussion, and prompt refinement

Ollama

  • A local LLM for advisory code review, kept advisory-only