Kun Chen (ex-Meta/Microsoft/Atlassian principal, now building coding agents) frames the whole workflow as being the captain of a ship crewed by agents: you direct, they row. The payoff he claims is 40-50 well-tested, production-shipped PRs a day, done in a way that is calm rather than frantic. The through-line of the video is that the leverage comes less from any single tool and more from a mindset shift, so the concrete tooling below is organised around the ideas it serves.
The terminal-first foundation
Almost everything happens in the terminal, and the reason is flow, not aesthetics. Keeping both hands on the keyboard avoids the constant context-switch of reaching for a mouse, and a terminal setup is identical everywhere, including over SSH from a phone. He is careful to say the terminal is a preference, not the point: the concepts transfer to GUI workflows.
The stack is three layers. WezTerm is the emulator, chosen because it is genuinely cross-platform (the same config runs on Windows, Mac and Linux) and fully scriptable in Lua, so config is dynamic and hot-reloads live. Inside it runs tmux, the terminal multiplexer, which gives split panes (an agent in one, an editor in another, a spare shell for commands), multiple windows for parallel agent sessions, and crucially persistent sessions on a server that you can detach from and reattach to from any device. Neovim is the editor, a modern Vim, valued for the same keyboard-only discipline: motion keys, relative line numbers for fast jumps, and plugins bound to shortcuts for grep and file-finding. All of it takes upfront configuration and muscle memory, which he treats as an investment rather than overhead.
Recruiting and ramping up the crew
Fresh agents know nothing about how you work, so they need onboarding, done through two mechanisms: memory files and skills.
He stays deliberately harness-agnostic because the landscape moves monthly, and uses a symlink so a single file serves both Claude Code and the standard AGENTS.md-style location.
He rotates through Claude Code (best sensible defaults, occasionally buggy), Codex CLI (Rust, smoother, open source so it can debug itself), a minimal highly-extensible harness for tinkerers, and opencode (model-agnostic, good out-of-the-box TUI).
The global memory file is kept tiny, around 27 lines, because every line is loaded into the system prompt of every session across all projects and silently burns tokens. It holds durable personal preferences: no em-dashes, do not over-weight development cost when making technical decisions (models inherit a human’s cost intuition and pick cheap, low-quality options, when in reality the agent can build in minutes what a human estimates in weeks), and always reproduce bugs end-to-end rather than defaulting to unit tests. Project-level memory files are allowed to be verbose because they are the accumulated learning of every session in that repo; the way to build one is not to write it by hand but to correct the agent when it errs and have it record the lesson.
To stop project memory bloating, conditionally-useful instructions (like end-to-end test steps only needed when editing code) get moved out into skills.
Skills use progressive disclosure: only a one-line description loads at startup, and the full file is read only when the skill is actually invoked, so large bodies of knowledge cost nothing until needed.
Anthropic’s Skill Creator skill, installed via Vercel’s npx skills tool, teaches any harness to author skills.
The strong warning here: do not install random skills from the internet, however many GitHub stars they have.
They can run anything on your machine and exfiltrate keys or credentials, and even setting security aside, many degrade performance.
His example is a 177k-star skills repo where a skill, benchmarked with Program Bench, used ~5% more tokens while making results worse.
Popularity is not evidence; treat any skill claiming to “magically” improve your agent with suspicion unless it publishes rigorous proof.
Talking to agents, and building tools for them
Two ideas about the agent’s interface to the world sit underneath the rest of the workflow.
The first is input: he has moved almost entirely to voice, citing a Stanford paper that talking is roughly 3x faster than typing (with a fun aside that Anthropic’s Dario Amodei appears in its references for 2016 speech-recognition work). Transcription runs locally and free via Open Super Whisper (a local Whisper model), and its accuracy on odd project names comes from feeding common vocabulary into its initial-prompt setting. The only time he falls back to typing is URLs and file paths, which are miserable to dictate.
The second is that agents lean on external tools, and tool design dramatically changes performance. His benchmark shows the GitHub MCP server costs about 3x the tokens and more than 2x the latency of the GitHub CLI for the same tasks, so using the MCP wastes both time and money for no benefit. The best performer in that benchmark is his own “axi” standard: a set of ten design principles for making tools treat agents as first-class citizens and optimise for agent ergonomics. One example: a token-efficient output format saves about 40% of tokens versus JSON. He has shipped several, including a GitHub axi and a Chrome DevTools axi (the latter uses fewer turns and tokens than rival browser tools), collected in an “axis” catalog. The general lesson is to research the efficiency of any tool you hand an agent, because it sets how much mileage you get.
From writing code to directing it
This is the conceptual heart of the video: stop being the person who writes and reviews every line, and become something closer to an engineering director who shapes quality through process rather than inspecting every diff.
Planning happens up front in a tool called lavish (a “lavish axi”, named as being richer than a rich editor). Instead of the agent dumping a wall of plan text into the terminal, lavish has it generate an HTML artifact that visualises the options using the current project’s own design system, so prototypes look like the real app. You annotate specific parts, comment, and click through decisions, sending feedback back without leaving the tool. He contrasts this directly with the default experience of reading a markdown plan you cannot easily point at, and says he can no longer go back to reading plans as terminal text.
Once requirements are clear he lets the agent implement without interfering, and the tricky moment is when it declares “done.” The instinct to open an editor and review the diff is the trap: AI writes faster than any human can review, so gating every change on your review hard-caps your velocity, and reviewing diffs is not why anyone became an engineer. His answer is a pipeline called No Mistakes (free, open source, also invokable as a skill) that carries first-pass code all the way to a clean PR inside an isolated worktree. It creates a branch and commit, infers the real intent from the agent session, rebases onto the latest remote main and resolves conflicts up front, then runs an adversarial review in a fresh context window where obvious problems self-correct and ambiguous product decisions escalate to a human. It tests the change end-to-end against the original intent and records evidence (a screenshot, a video, a log) so you can confirm it actually works, does a documentation pass, checks linting, pushes, and raises the PR. It then keeps babysitting the PR through merge conflicts and CI failures until it merges.
Review then becomes risk-gated rather than universal. The PR summarises intent, changes, testing evidence, and what the pipeline caught and fixed, plus a risk assessment. For low-risk changes he does not look at the diff at all, because validation has repeatedly shown the pipeline catches what he would; only higher-risk changes earn detailed review. The pattern that emerges is that his time concentrates at the two ends of a task (planning in lavish, holding the quality bar at the end) while the middle is automated, and the more middle he frees up, the more tasks he can run in parallel.
Scaling through parallelism
With the middle automated, the question becomes how to keep agents busy longer and how to run many at once.
For long-running work he built Good Night Have Fun (free, open source): give it an objective and it loops until a stop condition, with precise token, iteration, or condition caps.
A real example is telling it to role-play a seven-year-old using his kids’ app end-to-end, find the first usability confusion, fix it, and repeat, so he can literally go to sleep and wake to a branch of commits to cherry-pick.
He uses it for verifiable objectives (page-load time, test coverage, hypothesis-driven metric improvement) or ones where the agent’s judgement is trustworthy.
He prefers it to the newer /goal commands in Codex and Claude Code because those can silently burn a weekly quota overnight, whereas his caps are precise.
Running several agents in one directory makes them step on each other, and the standard fix is git worktrees, but worktrees create mental debt: naming them, remembering what each was for, and cleaning them up.
Treehouse (his tool) removes that: run it and you are dropped into a fresh worktree, run it again for another, treehouse status lists them, and closing the tab frees the worktree for reuse.
With this he comfortably drives three parallel Claude sessions, each told to run No Mistakes after implementing, and switches between tmux tabs by keyboard while the top status bar tells him which need attention.
Juggling many sessions is still exhausting, so the top of the stack is First Mate (new, open source): an orchestrator agent you talk to as a captain. You clone it, run an agent in it, and describe work; it decides that one request is really three parallel tasks, spins up tmux tabs, calls Treehouse for worktrees, runs agents, and runs No Mistakes to validate and open PRs, all while you keep feeding it more, including triaging open issues. He describes First Mate as all his tools coming together as one workflow, and watching it context-switch on his behalf as oddly satisfying.
The captain’s mindset
The final concept is that automating the crew relocates the bottleneck, and the bottleneck becomes you. Once First Mate absorbs the mechanics you start running out of things to ask for, which is the signal that you now need to spend your energy on knowing what actually matters: talking to users, understanding the competitive landscape, and drawing a good “treasure map” that points the crew in the right direction. That shift, from executing work to deciding which work is worth doing, is what he calls graduating from a sailor into a captain.
Key takeaways
- The leverage is a mindset shift from writing and reviewing code to directing agents and shaping quality through process; the tools just serve it.
- Keep global memory tiny (loaded into every prompt); let project memory grow from corrections; push conditional knowledge into skills for progressive disclosure.
- Never install unvetted internet skills: they can exfiltrate secrets and often degrade performance; stars are popularity, not evidence.
- Tool design matters a lot. The GitHub CLI beats the MCP server (~3x tokens, ~2x latency); token-efficient output over JSON saves ~40%.
- Voice input via a local Whisper model is ~3x faster than typing; fall back to typing only for URLs and paths.
- Plan visually (lavish HTML artifacts you can annotate), do not read walls of plan text.
- Do not review every diff. Route “done” work through a validation pipeline (No Mistakes) and review only by risk tier.
- Scale with long-running loops (Good Night Have Fun), cheap worktree management (Treehouse), and an orchestrator agent (First Mate).
- Stay harness-agnostic; the model and tool landscape changes monthly.
Sources
- Watch the video: youtube.com/watch?v=iQyg-KypKAA
- Full transcript: agentic-engineering-workflow
- Related: what-are-ai-agents, rewriting-bun-in-rust