Cofounder and CTO, Purple AI (2025 to 2026). I led engineering and product for p0: agents that take a written specification and implement a complete feature inside an existing codebase, including tests and pull request.
Cofounder and CTO, Learn.xyz (2021 to 2026). I owned engineering, product and the AI stack of an AI-native learning company.
Before that, I held product and growth roles at Ancestry, eBay Enterprise and Magento, then Peerspace, CoPilot, Flatfile and Workstream: large systems with long histories and real revenue running through them.
Today I run Arndt Voges Consulting in San Francisco, and I still write software with these tools every day.
Why I moved from building this to teaching it.
At Purple AI we had to teach this workflow before anyone would buy it. Two things became clear: the tooling is not the hard part, and almost nobody is teaching it properly. The engineers who get good at this now will be the ones every company wants in three years.
Tailoring
Your team,your codebase
The program is built around what we find before the first session.
Six areas to tailor the program
Team and setup
Who builds what
How many engineers are there, how are they organized, and what sits with external partners?
Codebase
What is in scope
Which repositories are in scope, how old are they, and what does test coverage look like?
Tools in use
What exists today
What is in daily use, what was tried and set aside, and why?
Backlog
The exercises
What would you build if implementation effort no longer decided?
Success
What has to be true
What has to be demonstrably true at the end to make it worth the time?
Risks
What gets in the way
What could get in the way, and where does the team have reservations?
The exercises run on your repositories and your tickets. Not on a demo project.
How the program runs
Kickoff
We spend half a day with the team, on site or remote.
Review and tailoring
I review the structure of the codebases and talk with the team. It is my time, not yours. The curriculum is built from what I find.
Eight sessions
Each session is ninety minutes live, once a week. Homework between sessions uses real tickets from your backlog.
Close
You get a final report with recommendations. The materials and what the team built stay with the team.
Continuation
Optional sessions on current developments and office hours keep the team current.
At the end, the team takes real backlog items through this workflow on its own.
With a codebase agents can navigate, and the standards, specs and commands to keep it going, maintained by your engineers rather than by me.
The sessions
Eightsessions
Ninety minutes each, with homework in between.
The eight sessions
01Core concepts
02Preparing the codebase for agents
03Writing a good spec
04Feedback loops
05Workflow integration and code review
06Claude Code in depth
07Orchestration and subagents
08Claude Code alternatives
Session 01 is the foundation. Sessions 02 to 05 follow the path of one ticket: the codebase, the spec, the loop, the review. Sessions 06 to 08 widen the view.
Session 01
Core concepts
What a language model does: it predicts one token at a time, so every run differs
What a reasoning model adds, and what the effort setting buys you
The context window: what goes in, in what order, and why that decides the result
When the context goes wrong: poisoning, context rot, and what compaction loses
Tools, agents and the harness: how a request from the model turns into a command run
What leaves your machine, and where it goes
In the session
Each term gets one slide and the diagram that explains it.
Between sessions
Install six official plugins, use each on real work, and agree on a shared team setup.
Session 02
Preparing the codebase for agents
Seven problems every team runs into first, and the fix for each
CLAUDE.md: what belongs in it, and why shorter is better
Rules that load only where they apply, for a complex codebase
Advisory and enforced standards: rules the agent reads, and rules the build checks
A baseline before the repositories fill up with AI configuration
Legacy code, many repositories, and sharing the setup
Between sessions
Take the baseline, then get a CLAUDE.md and the most relevant standards into main.
Further material
My own instructions for generating standards close to automatically.
Session 03
Writing a good spec
What a spec is: the task, the limits, and how to tell it is done
Precise where it matters, open where it does not
Acceptance criteria that a test or a command can check
Spikes and discovery, when you do not know enough yet
Three ways to a complete spec, including letting the model interview you
Where product owners fit: concept, refinement, review
In the session
We compare a one-line prompt with a spec written in a live interview.
Between sessions
Run one real ticket twice, and build shared /discovery and /spike skills.
Session 04
Feedback loops
Why an agent that cannot check its own work stops at its first guess
Unit tests first, and a hook that keeps tests from getting weaker
Making the loop run: commands, hooks and /goal
Loops for the browser, the design, the app, the API and several repositories
Loops without staging, from production errors, and for budgets
The tests in one real project, from static checks to end to end
In the session
Live: the agent writes a failing test, then fixes the code until it passes.
Between sessions
Everyone takes one real ticket to a pull request: spec, tests, code.
Further material
My skills for visual checks with Playwright and for testing API endpoints.
Session 05
Workflow integration and code review
Git as the undo button: branches, worktrees, commit messages
MCP servers: the ticket system, error tracking and design files
Why review becomes the bottleneck, and how to move it upstream
What still gets read line by line, decided by the team
Review subagents and REVIEW.md: a first pass, never the last word
The failure mode to watch for: approval becomes reflexive
In the session
A team member takes one ticket from story to pull request, then the room reviews it.
Between sessions
Write review rules on top of /code-review, or take a ticket to a pull request without copy-paste.
Further material
A list of MCP servers worth knowing about.
Session 06
Claude Code in depth
Settings and permissions, and the six permission modes
Plan mode: the plan is the thing you review
Skills, commands and hooks: written once, used every day
A central set of skills, shared as a plugin
Checkpoints, resuming sessions, and managing the context window
Tracking tokens, CLI or editor extension, and a setup for every level
In the session
Write a command for something the team does often.
Between sessions
Write a plan before a change, or ship one hook and one skill on a real ticket.
Session 07
Orchestration and subagents
Four ways to run agents in parallel, and how to choose
Subagents: a narrow job in its own context
Worktrees, agent view, /batch, workflows and agent teams
Running without a person at the keyboard: scripts, CI, routines
Turning a working setup into a plugin another team can install
Where orchestration stops paying for itself
In the session
Generalize one workflow a team already automated, so another team can install it.
Between sessions
Install what another team built, run one unattended job, or run three tickets in parallel.
Session 08
Claude Code alternatives
Closed and open weights, and what the license allows
Codex and the OpenAI models: the same concepts under other file names
pi and OpenRouter: keep the harness, swap the model
How to read a benchmark, and the ones worth watching
Staying current once the program ends
Looking back: the problems log at the start, and now
In the session
We discuss where the team stands, what it keeps, and what it stops.
After the program
Try one other harness or model on a real ticket, and name an owner for the setup.
Questions, or a first conversation about your team?
