Grindhouse
My own environment. Runs agent loops beside the code on my machines, groups work by project and task, and is where almost all of my development happens.
How I work
Agents write the code. I review, test and ship it.
For almost two years now, almost none of the code I ship has been typed by me. That did not make the job smaller. It moved the work to the places where judgment matters: what to build, in what order, how to check it, and when to stop.
The loop
Five steps, repeated per vertical slice
The depth of each step scales with how much the change can affect the rest of the system.
- Research and context
Explore the problem, the existing system and its constraints, and gather the information the implementing agent will need. Most failed agent runs trace back to this step being skipped.
- Architecture and vertical slices
Split higher-impact work into small end-to-end increments that can be exercised before the next one expands them.
- Implementation and review
Agents write the code. I read the changes for defects, unnecessary complexity, and structures that do not fit the system.
- Independent application testing
A separate agent uses the application through browser or computer-use tools. It can inspect code and logs when blocked, then reports what it found.
- Issue routing and judgment
Clear issues go back to the development agent with context. Ambiguous reports get a second model’s opinion before I decide what changes.
Tooling
What runs the agents
One orchestration layer, more than one model. No single provider gets to be the only opinion.
Claude Code
Primary coding agent for implementation and review passes. Connected to Grindhouse as a runtime.
OpenAI Codex and GPT models
Runs behind the native Grindhouse agent and in independent testing passes, so ambiguous findings get a second model before I decide.
- Models
- I switch between providers and default to their top production-ready models, currently Claude Opus and OpenAI’s Sol-class GPT models. Something faster or cheaper only when a specific job clearly calls for it.
- Local
- Nothing runs on local models. What runs locally is my own harness from Grindhouse, executing agent loops beside the code and calling frontier models.
- Second opinions
- Ambiguous test reports or disputed review findings go to a different model than the one that did the work. Two models disagreeing is itself information.
Rules
What I delegate, and what I don’t
Agents do
- Write all production code, tests and migrations.
- Research the codebase and summarise constraints before a change.
- Exercise the running application and report what they see.
- Give a second opinion on another agent’s findings.
- Repair Grindhouse when a self-update breaks it.
I do
- Decide what to build and in which slices.
- Read every diff that touches architecture, data or money.
- Decide whether a test report is a defect or noise.
- Set the boundaries: which tools an agent may call, which systems it may write to.
- Ship, and answer for what shipped.
Stack
Languages and platforms
Chosen per problem. Agents lower the cost of the right tool, so I use fewer compromises than I used to.
- Now
- Go for executors and CLIs. Elixir and the BEAM for long-lived connections and the server side. TypeScript and React for interfaces. Postgres.
- Agent systems
- Agent loops and tool design, context management across runs, independent testing agents, usage metering, integrations with CRM, chat, email and calendar APIs.
- Infrastructure
- Google Cloud, self-managed Linux servers, WebSockets at scale, payments and GDPR-sensitive data handling.
- Earlier
- C#/.NET, PHP, Java, Swift, Xamarin, React and Electron desktop, SQL. Mobile apps and games, government and finance systems.