My Development Workflow

Turning an ambitious idea into a working product takes organization. To keep everything on track, I maintain a dedicated task list for every development phase and/or project. This ensures I never lose sight of the bigger picture while my three-step AI stack handles the heavy lifting.

Step 1: Planning and Research (Gemini Pro)

Before writing any code, I define what the project actually needs to do, then send AI out to do the legwork: pulling comparisons, surfacing tradeoffs, and stress-testing options against languages and stacks I'm already considering. It doesn't know what I want, so it doesn't get a vote on it; it just moves faster than I could alone.

That upfront work heads off problems before they happen. Because I've already run the alternatives, that plan stays adaptable if something shifts mid-build.

Step 2: The First Draft (Kimi K3)

With the plan settled, Claude Code boils it down into a single self-contained brief: what to build, the rules that cannot be broken, and the exact pieces of code being changed. That brief goes to Kimi K3, which writes the first draft. Kimi never touches my code or my server; it can only propose. The blank-page phase is still gone, and I get a second, independent perspective baked into the first version of the code.

Substantial builds get this full relay. Smaller changes skip it, and Claude Code handles those end to end.

Step 3: Review, Testing, and Landing (Codex + Claude Code)

Before the draft is trusted, OpenAI Codex examines the original brief plus Kimi's draft, ranking issues from major blockers to minor nitpicks. Claude Code, acting as the final authority, then checks the draft and findings against the active codebase. It executes all file edits, runs the test suite, validates the behavior in a live browser, and stages the result for my approval, whether that is a brand-new build or an update to a current project.

Steps 2 and 3 run on a small set of pieces, each with one job and tight boundaries:

• SKILL.md: The pipeline definition Claude Code loads when I invoke the relay. Strictly opt-in; it spells out what the brief must contain and labels everything except my brief as untrusted data, so nothing else can pose as instructions.
• kimi.sh: The wrapper that sends the brief to Kimi K3 and streams the draft back, with a stall guard for the long runs: Kimi K3 thinks at maximum reasoning effort, so a large draft can take ten to twenty minutes. Kimi gets no access to my machine, only a small capped allowlist of remote tools like web search.
• codex-review.sh (Codex): Runs OpenAI Codex, pinned to GPT-5.6 Sol at high reasoning effort, in a read-only sandbox over a disposable copy of the brief and draft. It returns findings ranked from blocker down to informational, treated as claims to verify, not conclusions.
• Claude review: The final gate. Claude Code verifies every claim in the draft and the findings against the real repository, and answers what the upstream models cannot: does this work for my actual setup, and does it respect the target app's privacy and compliance rules.
• Compliance checker: A read-only audit agent that runs before anything sensitive ships. It maps the change against my standing privacy and compliance rules and reports pass or fail per rule, with citations; I decide what to do with the findings.
• Secret scanning: One shared scanner both wrappers must pass. It blocks credential-shaped content before anything leaves the machine, and the API key itself never appears in command lines, prompts, or the environment of child processes.

Claude Code, the final authority in Step 3, is where most of my time goes, so it is the tool I invested in automating. Using an AI coding assistant out of the box exposes certain friction points: it redundantly reads the exact same files multiple times in a single session, interrupts with repetitive permission prompts, and balloons the session context until responses slow down. To fix this, I taught the tool my environment using a specific configuration that stops the assistant from asking repetitive questions and allows it to manage itself.

What follows is the technical detail behind that configuration. If that isn't your thing, skip ahead to The Result; you won't miss the story.

Layer 1: Durable Rules

A single standing-instructions file read at the start of every session. Not a script or an agent, just non-negotiable rules that override default behavior:

• Plan first: Sessions start in planning mode; no changes happen until I've seen and approved a plan. (Also enforced by the session default.)
• UI verification: Every interface change is verified in a real browser via Playwright before it's called done: navigate the page, exercise the flow, read the console and network activity, and capture a screenshot. If browser verification isn't available, the assistant stops and tells me.
• Read first, change second: Any file must be re-read in the current session before editing; past knowledge doesn't count. Behavior must be verified in the code before writing copy that describes it. If I say "stop guessing" or "read first," it stops and reads.
• Dangerous-command block: If a risky command is blocked by the guard, the assistant stops, reports what it was attempting, and waits. No rephrasing or working around it.
• Test before deploy: Anything beyond a trivial copy tweak must have passing tests before it ships. A clean build is not the gate; passing tests are.
• Graceful deploys only: Every deploy uses a graceful reload so the site stays up for users in the middle of a request.
• Memory files: Canonical facts and prior feedback are stored so the assistant references them instead of rediscovering them each session.

Layer 2: Automatic Hooks

Small scripts that fire automatically on specific triggers:

• Session start: A fast snapshot of the running environment status, disk usage, and dirty git repositories; this saves several discovery steps up front.
• Prompt submit: A context injector that supplies the relevant project's details when I mention it, so the assistant doesn't guess which app I mean.
• Before reads: An advisory that flags a file already read this session.
• Before risky commands: Guards that refuse destructive operations with a clear error, and steer risky deploy actions toward the safe path instead. Ordinary operations are untouched; only the specifically dangerous forms are blocked.
• Before edits: A claim guard checks every file edit against a registry of what each active session is working on. If another session owns the path, the edit is refused with instructions to hand the work across instead. Claims renew as the owner works and expire on their own if a session dies.
• After edits: Automatically formats the edited file to a consistent style.
• End of turn: Counts tool activity in the session and suggests compacting the context once it grows large, then reminds me periodically after that. It only advises; it never halts the work.

Layer 3: Manual Tools and Agents

Run on demand, either invoked by me or by an agent acting on my behalf when a task requires it. Each has a single responsibility and tight boundaries:

• Specialized agents: One drives a real browser and returns a clear pass or fail with evidence ("it compiles" is not "it works"); another does read-only health checks on active services without restarting anything; others clean up dead code, plan safe breakups of large files, and check performance impact. More exist for exploration, planning, debugging, and migrations.
• Compliance checkpoints: Before a change touches sensitive surfaces -- image uploads, ID/age checks, retention, or a marketing claim -- I have the assistant run a read-only compliance audit against my standing privacy and compliance rules first. It reports pass or fail per rule with exact citations; it never edits code or ships anything itself. I decide what to do with the findings.
• Peer sessions: No agent updates work that another one is already working on. Part of this is automated: each session registers a claim on the paths it owns, the before-edits guard blocks every other session from touching them, and each new session is shown the active claims and in-use test infrastructure the moment it starts. The rest is triggered manually: when one session has something for another, it hands findings across in a message and a shared folder rather than editing the other's files. Recent example: one session audited my browser's privacy scores while a second reworked a feature in the same codebase; the auditor delivered a scorecard and a prioritized fix list to the builder instead of editing the code itself.
• Design principle: Narrowness builds trust. Because the read-only and non-mutating agents can't change code or restart services, they're safe to invoke without close supervision.

This setup means I start every session with an environment that already knows the rules of the house. It blocks destructive mistakes, keeps the context window lean, and tests the app like a real user.

But automation only covers the mechanical half. The real quality control happens in how I actively interface with the loop:

• Pre-Deploy Compliance Auditing: Before anything sensitive ships, the compliance audit described above runs, and I act on its report before approving the deploy.
• Just-In-Time (JIT) UI/UX Reviews: I don't wait until the entire application is finished to see if things work. The moment Playwright finishes its automated verification, I step in immediately to review the live functionality and design changes. This tight micro-feedback loop keeps my understanding of the evolving codebase perfectly sharp.

While I still do the essential work -- reviewing the final code, making architectural decisions, and improving the UX -- automating the tedious parts frees me up to actually finish the project. It's the difference between booting up an environment that forgot your preferences overnight, and loading a perfect snapshot with the kind of digital muscle memory that lets you pick up exactly where you left off.