How I Build

Last revised August 2026

I spend more time designing the harness than writing code. Specs, plans, rule sets and skills decide what the agents are allowed to do. They write and deliver, several at once, and the gates decide whether any of it ships. My work's moved toward architecture and review: shaping the constraints, reading what comes back, and tightening the harness when something slips past it.

The job changes shape. Most of my time goes to architecture, constraints and review — deciding what should exist and what should never happen — while several agents write and deliver the work under those rules.

1. 01Specify, then plan, then buildWork starts as a written spec and a planning pass — never straight into code.

   Anything sizeable starts as a written spec: who it's for, what has to be true when it's done, what's out of scope. A planning pass turns that into ordered tasks.

   It's also where the technical decisions get made. Stack, patterns, libraries, architecture. Settle them here and an agent has no room to invent its own.

   • Spec Kit
   • Plan mode
2. 02Build the harness, not just the featureRule sets and custom skills constrain the agents; correcting them is the real work.

   The leverage isn't in the prompt. It's in the constraints: rule sets saying what a project won't accept, and skills that hold a whole procedure so it runs the same way every time.

   So I keep iterating on the rules. Each pass tightens what the agents can do, until the output comes back in the shape I wanted in the first place.

   • Rule sets
   • Custom skills
3. 03Keep the rules in the repositoryConstraints are committed files — versioned, reviewed and diffed like code.

   The rules are a growing record of how a codebase wants to be written. Its architecture, its technical decisions, its house style, all committed where the agents read them.

   The better that record gets, the more often the first attempt is right. Less prompting, less correcting, fewer tokens.

   • Rule sets
   • Constitution
   • Git
4. 04Two tools, one processSeveral agentic tools running at once, kept interchangeable by mirrored rules.

   I run several agentic tools at once: Claude, Cursor, and parallel local and cloud agents.

   A rule keeps both rule sets in parity, so I can switch tools mid-workflow. Handy when a quota runs out, or when one of them just does a job better.

   • Claude
   • Cursor
   • Cloud agents
5. 05Connect agents to the systems, not to meAgents read boards, tickets and review feedback directly, rather than through me.

   Agents connect to GitLab, Figma, JIRA and Confluence and act there themselves. Moving ticket status, posting updates, writing the end-of-day rollup.

   They run code review too, raise Slack alerts, and clear feedback before anyone stamps it. Once it's approved, merge trains handle the merge and the rebase.

   • MCP
   • GitLab
   • Atlassian
   • Figma
   • Slack
6. 06Several agents, working at onceSeveral sessions working in isolated checkouts so they can't collide.

   Parallel and cloud agents, always. Each one gets its own branch and its own checkout, so they can't touch each other's history.

   Branches and diffs stack where the work allows it, so agents build on each other instead of waiting in line.

   • git worktree
   • Cloud agents
   • Stacked branches
7. 07Start work without being at a deskWork I kick off from a phone, usually from somewhere outside.

   Claude and Cursor mobile dispatch the tasks. Screen control gets me into a local terminal from my phone.

   So planning, a feature, or a grooming pass can start while I'm out walking, which is usually where the better ideas show up anyway.

   • Claude mobile
   • Cursor mobile
   • Screens Connect
8. 08Make the gates realAutomated review and security scanning block a merge — no exemption for agent-written code.

   Gates are how quality holds. Linting, security and vulnerability scanning, container scanning, test suites, automated review, and agents that clear blocking comments and nits before a person looks.

   Along with the harness, it's what keeps the code sound. Nothing reaches an environment without getting through it first.

   • Linting
   • Security scanning
   • Container scanning
   • Test suites
   • Automated review
9. 09Infrastructure as code, never click-opsTerraform keeps environments reproducible and applications portable between clouds.

   Infrastructure is Terraform. Written as code, an app stays portable between clouds instead of welded to whatever somebody clicked into one console.

   Click-ops is out. Nobody remembers what they clicked, least of all across dev, staging and prod.

   Where it lands depends on the job. Netlify for something small that just needs to be up, container instances on Google Cloud when it needs to scale or hold state.

   • Terraform
   • Google Cloud
   • Cloud Run
   • Netlify
   • CI/CD
10. 10Then sharpen the harnessEvery escape becomes a new rule, a new skill, or a new gate.

    Sharpen the harness, sharpen the gates, run it again. Fix the gap, write the rule, automate the step. Never repeat yourself in a prompt.

    Add routines. Add connections. Build the connectors that don't exist yet. The job is spotting gaps in the flow and joining up the parts that still need carrying by hand.

    • Rule sets
    • Custom skills
    • Scheduled routines
    • MCP

Google's write-up of the same idea: the harness is what gives an agent the ability to deliver your vision, your preferences and your best practices. Google Research — Industrial Agentic Engineering