How I use AI in my production workflow

The rule I start with

AI writes code quickly, and I own what ships. If I can't explain a change in review, it doesn't go in, however fast it was written.

Five years in, I've stopped asking which model is best. The results come from the process around it: what the agent reads before it starts, what it has to prove before it stops, and what it isn't allowed to do. Most of this isn't my invention. It's close to what Anthropic recommends for Claude Code and what GitHub's spec-driven tooling does, adapted to how I work. I've listed my sources at the end.

The loop

Anthropic's guidance for agentic coding comes down to a rhythm: explore the code, plan, implement, verify, commit. Mine is the same rhythm with more of it written down. This is the loop my latest project, slayply, runs on, and every coding session follows it.

1. Read the pointerwhat's next, what's broken→
2. Read the speconly the relevant section→
3. Failing tests firstthe change is defined by a test→
4. Smallest changerun the full check→
5. Self-review, then PRupdate the pointer

Spec before code

I don't ask a model to build something. I write a spec: the problem, the behaviour, the edge cases and what's out of scope. Then I review it before any code exists. A wrong assumption costs a sentence to fix in a spec and a day to fix in a pull request.

This is the idea behind GitHub's Spec Kit, where a specification drives the plan, the task list and the implementation. I keep the specification in the repo as one file, plus an architecture decision record for every non-obvious choice. Slayply has twenty-three of them.

Tell the agent what it can't see

An agent reads the repo, but it can't read my head: the deploy process, the file it must never touch, the rule my team agreed last month. Anthropic's advice is to put that in a project file the agent loads every session. I do, with two rules:

• One source of truth. AGENTS.md holds the rules. CLAUDE.md, the Cursor rules and the Copilot instructions only point to it, so tools never disagree.
• A handoff pointer. One file says what's done, what's next and what's broken. Every session starts by reading it and ends by updating it, so a fresh session resumes without me re-explaining anything.

This portfolio works the same way: a plan, a roadmap and a handoff file.

Make it prove the work

"It looks right" isn't evidence. Before an agent may finish, it runs one command that does the type-check, lint and tests. Tests are the leash: I want a green suite telling me the change is safe, not my own tired reading of a diff.

Agents also invent APIs. So I make them check the installed type definitions or the package registry before using a function, and I record verified versions in one file. It's a small rule that has saved me many confusing build errors.

Guardrails that don't depend on good behaviour

Instructions can be ignored. Hooks can't. In slayply, a hook script runs around the agent's actions. It blocks edits to the spec and the lockfile, blocks commits to main, force-pushes and merges, and refuses to open a pull request unless the handoff pointer was updated. I added subagents with narrow jobs: an architect for trade-offs, a reviewer that checks the diff against my coding standards, and a red-team pass that hunts for bypasses.

The tools, and when I use each

I use more than one:

• Claude Code for work that spans files and needs a plan.
• Cursor for quick edits and reading around a codebase.
• Antigravity to try agent-first workflows.
• The OpenAI and Gemini APIs when I'm building something with a model inside it.

Monitored vibe-coding

Andrej Karpathy named vibe coding: you describe, accept what comes back and keep going. I do that for throwaway tools, but I stay in the room, watching and steering. It's fine for something only I depend on. It isn't how I'd ship something other people rely on, and that's what everything above is for.

What I'm still learning

These are things I haven't used properly yet, but I can see how they'd help:

• Graphify. It builds a knowledge graph of a codebase, so an agent asks the graph about functions, calls and dependencies instead of grepping and re-reading files. It parses code locally, writes a reusable graph.json, and can plug in through MCP. The pitch is fewer tokens and more accurate answers on big repos. I want to try it on a larger codebase, and check its claims before I repeat them.
• MCP servers, so agents reach the systems I work with directly, instead of me pasting context in.
• Evals, so that when I change a prompt I can measure whether it got better.
• Parallel sessions, running several agents on separate branches at once.

What I'd change

My loop is heavy for a small change, and I sometimes skip steps when I'm in a hurry. I'd like a lighter path for one-line fixes that still keeps the tests and the review.

Sources

• Best practices for Claude Code, Anthropic.
• Spec Kit, GitHub's spec-driven development toolkit.
• AGENTS.md, a shared format for agent instructions.
• Graphify, the codebase knowledge-graph tool.