Brainstorming
Claude Opus
AI workflow and Setup
I use AI like an engineering team around me.
One agent helps plan, others implement, others test, one tries to break the system, and I keep final control over review, git, and shipping.
planClaude Opus + Spec Kit
tasksBeads breakdown
buildCodex + Opus agents
verifySonnet + chaos pass
shipmanual git + CI/CD agents
01Master PRD
04+agents per feature
Manualgit control
CI/CDdeployment checks
Planning pipeline
The work starts before code.
I use AI most heavily at the beginning of a feature, when the architecture, acceptance criteria, and test cases need to become clear enough for multiple agents to work without losing the original intent.
Master PRD
Spec Kit
Tasks
Beads + AO
Build
Codex + Opus
Review
Chaos pass
TestTest bestanden
Sonnet
Build
Codex + Opus
Review
Chaos pass
TestTest bestanden
Sonnet
Build
Codex + Opus
Review
Chaos pass
TestTest fehlgeschlagenTest bestanden
Sonnet
Git-Merge
Ship
GitHub Actions
Brainstorm the system
I start with Claude Opus for planning and architecture. The first pass is a brainstorming session around the problem, constraints, architecture options, goals, acceptance criteria, and test cases.
Shape the Master PRD
I use Spec Kit and Beads on top of the brainstorming work to turn the idea into a Master PRD. That document becomes the source of truth for what we are building, why it matters, and how it will be accepted.
Break work into tasks
For large projects and small features, I use Beads to split the work into clear tasks. It keeps features from turning into one vague brief and makes progress easier to review.
Run agents by role
Once the plan is ready, I run multiple agents over the feature. Two agents usually implement, other agents check tests, linting, edge cases, and documentation.
Multi-agent setup
Agents have roles, not unlimited control.
I split agent work by responsibility. That keeps each agent close to a domain while the PRD, Beads tasks, and acceptance criteria keep the overall system aligned.
Codex
Frontend agent
I use Codex especially for frontend work: building interfaces, refining layouts, checking responsive behavior, and keeping implementation close to the existing design system.Opus terminal
Backend agent
For backend-heavy work, I use an Opus terminal where the agent can stay focused on architecture, APIs, data models, and service-level tradeoffs.Sonnet
Testing agent
I use Sonnet for testing-focused passes: checking acceptance criteria, test coverage, linting, and edge cases that should be verified before the feature is considered done.Docs pass
Documentation agent
One agent can focus on documentation so the implementation notes, handover files, and repo context stay readable after the coding pass is finished.Loop engineering
Complex workflows need orchestration, not just more agents.
For bigger systems, I add a loop engineering layer so the work keeps moving through planning, implementation, review, and verification without losing consistency.
Orchestrate the loop
For very complex workflows, I use Agent Orchestrator (AO) or Python scripting when I need tighter control over agent order, retries, handoffs, and checkpoints.
Run and coordinate agents
I use wrap to manage agents around the work: starting them, coordinating them, and keeping each role connected to the current plan.
Keep one source of truth
Git stays the source of consistency, while GitHub Actions handles automated verification after changes move through the workflow.
Scale beyond simple coordination
When a feature becomes too large for a simple agent loop, I use LangGraph. Temporal is also a strong option when reliability and durable orchestration matter.
Chaos engineer
An agent built to break code.
The chaos engineering agent breaks the code intentionally and looks for broken assumptions, missing edge cases, weak recovery paths, bad states, race conditions, unclear user flows, and places where the system works only when everything goes perfectly.
I like this role because it adds pressure to the design before users do. It turns AI from only a builder into a reviewer that actively searches for failure.
Git and review
Manual control stays with me.
Agents can move quickly, but the final engineering decision should still be mine. I use AI to increase leverage, not to hand over the merge button.
- I do not like agents raising PRs and auto-merging code for me.
- I review uncommitted features manually before committing or merging.
- If I am not satisfied, I rerun the agent, make manual fixes, or code the missing parts directly.
- Cursor is my primary IDE for git review, small fixes, quick agents, and manual control.
Repo sync
Handover files keep parallel work aligned.
When a project spans multiple directories or repositories, I create handover markdown files.
The handover files explain what changed, what still needs to be done, and which assumptions are shared.
This keeps frontend, backend, tests, documentation, and parallel repo work from drifting apart.
Automation
CI/CD and personal agents handle the background checks.
GitHub Actions agents tell me whether deployment is in process, failed, merged, or completed. For personal automation, I use a self-hosted Hermas agent for starting the day, checking emails, reviewing meetings, and handling small personal tasks.
Plan - build - verify - review - ship
The setup keeps fast feedback around the work while preserving manual review at the points that matter.
Working setup
The hardware stays simple and reliable.
Primary machine
MacBook Air M5 for development, AI-assisted coding, planning, review, and shipping work.
Secondary machine
MacBook M1 for personal work and a separate secondary environment.
Desk
BenQ 27-inch 2790Q monitor with a Logitech Pebble 2 for the everyday setup.
The setup keeps changing, but the direction is consistent.
Faster feedback, better thinking, fewer repetitive steps, and more time spent on the parts of software that need taste, judgment, and care.