Claude Code
My own products, every day
Planning, incidents, long threads, anything that needs product context or memory. Writes the specs other agents execute.
AI engineering
How I build products with AI coding agents
I use Claude Code as my default agent, Codex CLI for bounded tasks that already have a written spec, and Kiro CLI inside a large enterprise codebase at my day job. Agents write most of the code. What makes it shippable is everything around them: specs, written engineering standards, deny rules and hooks, unit, integration and E2E tests, evals, a second-agent review, and my own review of every pull request before I merge it. Every section below links to a first-hand write-up from my own production work.
Which agent gets which job
Codex CLI
My own products, next to Claude Code
Bounded jobs that already have a written spec, run in their own git worktree, plus a second-opinion code review.
Kiro CLI
A large enterprise codebase at my day job
The approved agent inside strict enterprise constraints: small, reviewable changes with a human in every loop.
The routing rule and the shared setup: Claude Code vs Codex CLI and Kiro vs Claude Code.
How a feature ships
- 01
Spec
Written with a planning agent: the product model, hard constraints, a numbered test list and a finish block.
Specs an agent can finish → - 02
Agents build to my standards
Claude Code or Codex CLI in their own git worktrees, held to written rules: SOLID, DRY, KISS, small pure functions, deny rules on anything irreversible.
Parallel agents in worktrees → - 03
Tests and gates
Unit tests on rules and edge cases, integration tests on data paths, Playwright E2E on user flows, lint on staged files, evals for AI features.
Evals before merge → - 04
Agent review
A second agent in a fresh session reviews the diff against the spec and the standards, so I start my review from the findings.
A second agent as reviewer → - 05
I review and merge
Human in the loop: I read every pull request myself, run what changed, and merge only when I am sure. Then I watch production.
How I review AI-generated code →
I stay the human in the loop. Agents never merge. Every pull request gets my own read of the diff, a run of what changed, and a merge only when I am sure it is right, not when the checks turn green.
The standards agent code has to meet
Agents load these rules before they touch production code, and I check them in review. Fast code that nobody can maintain is not a speed-up, it is debt with a delay.
- SOLID, applied, not recited
- Routes validate and delegate, business logic lives in the domain layer, SQL in the repository layer. Payments, email and LLM providers sit behind adapters, so swapping a vendor means one new adapter.
- DRY with judgment, KISS by default
- Search before writing, one source of truth for every value, a shared package instead of a third copy. The simplest design that meets the spec, no speculative abstractions, and no merging code that changes for different reasons.
- Small units
- A function fits on one screen, roughly 40-50 lines, and a file stays within a few hundred. Code is split by responsibility, not by line count, so every unit can be named without an "and".
- Pure logic, effects at the edges
- Business rules are pure functions that take data and return data. I/O, time and randomness stay at the edges, which keeps the rules testable without mocks and makes agent changes easy to review.
- Tests that catch regressions, not coverage
- Unit tests on rules and edge cases, integration tests on the paths that touch money, auth and data scoping, Playwright E2E on the flows users depend on. Every bug gets a failing test first. No tests for getters.
- Secure by default
- Every ID in a request is treated as forged and every query filters by owner. Validation and authorization run on the server, and every endpoint that calls a model has a per-user limit, a daily cap and a kill switch.
The harness around the agent
An agent harness is everything around the model: what it may run, what is blocked, what it loads at start and when a session has to stop. This is where most of the safety and most of the cost control live.
- Giving a coding agent shell access without losing sleep: the guardrails I runA four-layer safety model for coding agents with shell access: permissions, deny rules, pre-execution hooks, and behavioral guardrails.
- Auditing my coding agent's guardrails: the holes I foundAn audit of a coding agent harness: an API-form bypass, a hook that failed open, paid branch protection, and secrets leaking in via always-allow rules.
- A hook that keeps coding-agent sessions on one topicAn agent harness hook that keeps coding-agent sessions on one topic: topic blocking, a parking inbox, 250K-650K context thresholds and forced handoffs.
- Why I stopped loading every skill into every Claude Code sessionHow to structure Claude Code context by project, keep skills and MCP servers focused, and avoid wasting tokens on instructions a session does not need.
- Context engineering for coding agents: making project docs resumable in 7K tokensHow I structure project docs so a coding agent resumes a thread in 6.7K tokens instead of 39.5K: hub and entry-block limits, splitting, rule format.
- MCP in daily engineering: lean sessions, heavy servers on demandUsing MCP servers in daily engineering: per-session profiles, deferred tool schemas, incident triage with logs and analytics, read-only access.
Delegating work to agents
Which agent gets which job, how a task is written so an agent can finish it alone, and how to tell a finished task from a confident status report.
- Codex CLI next to Claude Code: one rulebook, two agentsClaude Code vs Codex CLI in daily use: which agent gets which job, one shared AGENTS.md and hook, MCP parity, and 272K vs 1M context.
- Two agents, two contexts: Claude Code at home, Kiro CLI in an enterprise codebaseKiro vs Claude Code from daily use: Claude Code on my own product, Kiro CLI in an enterprise codebase, and which practices transfer.
- Spec-driven development with coding agents: specs an agent can finish without meSpec-driven development for coding agents: the seven parts of a spec an agent can finish alone, hard constraints, review cost, and failure modes.
- Same agent, opposite results: exit criteria decide the outcomeWhy coding agents succeed on bounded tasks and stall on open research: numeric exit criteria, recorded verification, and routing work by model tier.
- Running coding agents in parallel with git worktreesHow to run coding agents in parallel with Git worktrees: split low-conflict tasks, define contracts, restrict access, and integrate once.
- Cheap sweep, strong synthesis: routing models across multi-agent workHow to route AI models across multi-agent work: a model ladder, lower effort first, pilots before fan-out, minimal subagent context, pinned models.
- Model picks latency, the spec picks quality: choosing effort in Claude CodeHow to choose model and effort in Claude Code: when latency matters, when deeper reasoning pays off, and why a precise spec matters most.
Quality and cost
A green build is a shape check. Evals, review and a clear view of what the tokens actually cost decide whether agent output is worth shipping.
- Evals before merge: the golden set behind an AI matching pipelineLLM evals for a ranking pipeline: a golden set from human decisions, P@10, NDCG@10, MRR, a zero-violations ship gate, and a noise threshold.
- A green build is not proof: how I review AI-generated changesWhy a passing build is not proof AI-generated code works: lint gates, runtime guards, slopsquatting checks and a second agent as reviewer.
- What my coding agent would cost on the API: 30 days of transcripts, measured30 days of coding agent transcripts priced at API rates: $4,176, over 90% cache reads. What it means for subscription vs API and context engineering.
- Eight months of running a product solo with AI agents as co-engineersEight months of using Claude Code and Kiro CLI as co-engineers on a production product: workflow, gains, limits, guardrails, and monthly cost.
LLMs inside the product
The other half of AI engineering: features that call a model in production, with typed output, spending limits and a hard line between model-facing text and public pages.
- Tool use over parsing: getting structured data out of an LLM in productionStructured output from LLMs in production: tool use and strict JSON Schema over parsing, validation, retries, and a provider adapter.
- Every endpoint that calls a model is an open walletCost guardrails for LLM endpoints: per-user limits, a daily spend cap, a kill switch, fail-closed counters and a spend ledger against denial of wallet.
- How an LLM instruction header ended up in my public structured dataHow LLM prompt text leaked into public JSON-LD structured data, how I found and fixed it, and the rules that keep model-facing text off public pages.
- Cosine similarity is not a probability: tuning pgvector thresholds for real matchingWhy cosine similarity is not a probability, how pgvector score distributions vary by model, and how to calibrate thresholds with evaluation pairs.