▶ YouTube Summaries

• YT :: https://www.youtube.com/watch?v=iQyg-KypKAA
• Original title :: L8 Principal's Agentic Engineering Workflow

A full walkthrough of a terminal-centric agent engineering workflow by Kun Chen, ex-principal engineer at Meta, Microsoft and Atlassian, who now builds coding agents and claims 40-50 tested, shipped PRs per day. The organising metaphor is a ship: you are the captain, agents are the crew, and the goal is to move your own effort to the beginning (planning) and the end (quality bar) of each task so the middle can run unattended and in parallel. The concrete pillars are a keyboard-only terminal setup, minimal memory files plus skills for progressive disclosure, voice input, agent-ergonomic tooling, artifact-based planning, an automated validation pipeline that replaces diff review, and an orchestrator agent that manages all the other agents.

Setup

Everything happens in the terminal, for two stated reasons: hands never leave the keyboard, so flow is not broken by reaching for the mouse every few seconds, and the identical workflow is available from any device including a phone. He concedes GUI apps have keybindings, but argues keyboard is not their primary interaction paradigm, so the discipline never sticks.

The stack is WezTerm (cross-platform, the only emulator he found that behaves identically on Windows, Mac and Linux, configured with a Lua script that hot-reloads), tmux (panes for agent plus editor plus a free shell, windows for parallel agent sessions, and server-side persistence so he can detach on the desktop and reattach from a laptop or phone), and Neovim (relative line numbers for jump-by-count motions, space s to grep the code base, space f to find files by name).

He regularly uses four agent harnesses. Claude Code has the most sensible defaults and the richest feature set, but is occasionally buggy and not very customisable. Codex CLI is written in Rust and feels smoother; being open source, it can often inspect its own source and work around its own problems. Pi is deliberately minimal and highly extensible. Opencode has a smooth TUI, integrates with essentially every model, and is more complete out of the box than Pi. He deliberately keeps the whole workflow agent-agnostic because the landscape changes month to month.

Memory files

The global memory file is symlinked so that CLAUDE.md and AGENTS.md are the same file. It is only 27 lines, because its contents land in the system prompt of every session across every project, and bloat there silently burns tokens.

Three rules are worth calling out.

1. Never use em dashes, because models default to them and the result reads robotic.
2. When making technical decisions, do not give much weight to development cost: models trained on human data estimate a feature in days or weeks, then build it in minutes, and that mismatch biases them toward cheap options that are low quality, unscalable or hard to maintain.
3. And for bug fixes, always start by reproducing the bug end to end as an actual user would hit it, because models default to unit tests that do not guard the product behaviour you care about.

The project-level memory file is much more verbose: what the project is, repo layout, terminology, how the important components work, how to run end-to-end tests, and conventions. Critically, it is not written by hand up front. Every time an agent does something wrong he corrects it and asks it to record the lesson in the file, so the file accumulates the collective learning of every session in that project. No dedicated memory system is needed for this, just the markdown file.

Kun's CLAUDE.md :noexport:

• related :: My CLAUDE.md file.

Kun’s agent instructions

These are common instructions for Kun’s agents across all scenarios.

General Guidelines

• Never use the em dash "—". Use plain dash "-" instead
• When writing commit messages, NEVER auto-add your agent name as co-author.
• Never manually modify CHANGELOG.md files or any files that are marked as auto-generated.
• When writing or substantially editing long Markdown files, put each full sentence on its own line. Preserve normal Markdown structure, but avoid wrapping multiple sentences onto one physical line.
• When making technical decisions, do not give much weight to development cost. Instead, prefer quality, simplicity, robustness, scalability, and long term maintainability.
• When doing bug fixes, always start with reproducing the bug in an E2E setting as closely aligned with how an end user would experience it. This makes sure you find the real problem so your fix will actually solve it.
• When end-to-end testing a product, be picky about the UI you see and be obsessed with pixel perfection. If something clearly looks off, even if it is not directly related to what you are doing, try to get it fixed along the way.
• Apply that same high standard to engineering excellence: lint, test failures, and test flakiness. If you see one, even if it is not caused by what you are working on right now, still get it fixed.

Kun’s Opinions

When you are working on something that would benefit from being informed by Kun's viewpoints, read ~/OPINIONS.md to understand them.

Voice Profile

When you are talking/posting on behalf of Kun using his identity, read ~/VOICE.md to see how Kun talks.

Skills

The project memory file inevitably bloats, and the fix is to move conditionally useful sections into skills. His example: end-to-end testing instructions are only relevant when the agent is changing code, so paying for them on every question is waste. Skills use progressive disclosure, loading only their description into the system prompt and reading the body only when the agent decides it needs them. He demonstrates the extraction live by asking the agent to do it. Harnesses that do not understand skills natively can be taught with Anthropic's skill-creator, installed through Vercel's npx skills CLI, which he uses as his general skill manager.

He then gives a strong warning against installing skills off the internet. First, a skill can instruct your agent to run anything on your machine, which is a credential-exfiltration risk. Second, popularity is not quality: he evaluated a skill from a Karpathy-branded skills repo with 177k GitHub stars using Program Bench, and it made the agent spend 5% more tokens for worse results, and it was not even written by Karpathy. His rule of thumb is to install nothing that claims to magically improve agent performance without published rigorous evidence.

Voice input and agent ergonomics

• related :: Speech to text apps

He has essentially stopped typing prompts, citing a Stanford paper measuring speech as about three times faster than typing (with the aside that Dario Amodei appears in that paper's references for 2016 speech-recognition work). Transcription runs locally through OpenSuperWhisper, free and open source. He falls back to typing only for URLs and file paths. A useful trick: OpenSuperWhisper exposes an initial prompt in its transcription settings, and seeding it with your project vocabulary sharply improves accuracy on proper nouns.

Tool design materially affects agent performance. He benchmarked ways of reaching GitHub and found the GitHub MCP server costs roughly three times the tokens and more than double the latency of the CLI for identical tasks, with no clear benefit. That finding led him to author AXI¹, a set of ten design standards for treating agents as first-class consumers of a tool; token-efficient output formats alone save about 40% versus JSON. He has built a GitHub AXI and a Chrome DevTools AXI, both of which beat the alternatives on turns, tokens and success rate. The catalogue lives at axi.md.

Planning with interactive artifacts

The default planning experience, whether plan mode or a written markdown plan, produces a wall of text that is hard to evaluate and hard to give targeted feedback on. His tool lavish² instead instructs the agent to build an HTML artifact that visualises the options, always reusing the current project's design system so the mockups look like the real app. He demonstrates on a real feature (consolidating two redundant buttons into an achievement system in a kids' Twitter-like app). In the rendered page he can annotate specific parts of the artifact with comments and click through decision points, and the feedback returns to the agent without going back to the terminal. Once the plan is agreed, implementation runs without his involvement.

Validating changes without reviewing diffs

• related :: Monkey Worker' "PR handling"

The central argument: AI writes code faster than you can review it, so if every change needs your review you become the hard cap on your own velocity, and reviewing diffs is not why anyone became an engineer. The scaling move is to think like an engineering manager or director, who influences quality through culture and process rather than reading every patch.

His pipeline no-mistakes ³ (free and open source) takes first-pass code to a clean PR: create a branch and commit; run everything in an isolated worktree so validation never touches the working repo; infer the real intent behind the change by analysing the agent session; rebase onto the latest remote main and resolve conflicts up front; run an adversarial review in a fresh context window, which is where most problems are caught, self-correcting the obvious ones and escalating ambiguous ones with product implications to a human; test end to end against the original intent while recording evidence; update documentation; lint; push and open the PR. It then keeps babysitting the PR until merge, absorbing later merge conflicts and CI failures.

The PR body carries the original intent, what changed, how it was tested, what the pipeline found and fixed, and a risk assessment. The evidence is whatever most directly shows the change working, a screenshot, a video, or a log. He uses the risk assessment to decide review depth and does not look at the diff at all for low-risk changes, having validated repeatedly that the pipeline already catches what he would have caught. He never watches the pipeline run; he spins up other tasks and returns when it reports all checks passed.

Long-running tasks

To keep agents busy for hours, including overnight, he built gnhf⁴ ("good night, have fun"), which loops on an objective until a stop condition you define. The demonstrated run: pretend to be a seven-year-old using the app end to end, find the first usability problem that would confuse or block you, fix it, repeat. It reports token usage, iterations and commits made, and he wakes to a branch of commits to pick from. It suits verifiable objectives such as reducing page load time or improving end-to-end coverage, as well as auto-research loops that keep testing hypotheses against a metric. He prefers it to the /goal commands recently added to Codex and Claude Code because token caps, iteration caps and stop conditions can be set precisely, whereas an unbounded overnight goal can consume a weekly quota.

Parallel agents

Running a second agent in a directory that already has one working causes conflicts, and the standard answer is git worktree. But raw worktrees accrue mental debt: naming them, remembering what each was for, whether an agent is still running there, and cleaning them up manually. His tool treehouse⁵ drops you straight into a fresh worktree, lists used versus idle trees with treehouse status, frees a tree when you close the tab, and reuses idle trees rather than creating new ones. He demonstrates three parallel sessions in separate tmux tabs, each given a real piece of user feedback, switching between them by keyboard shortcut and using the status bar to see which needs attention.

First mate and the captain's mindset

Juggling many sessions eventually becomes exhausting: constant context switching, and having to reload what each session was even doing. His answer is firstmate⁶, a very new open-source orchestrator agent you talk to instead of talking to each crew member. Given one request it decides whether it is one task or several, spawns tmux tabs, calls treehouse for worktrees, runs an agent in each, and then runs no-mistakes to bring each change to a reviewable PR. It asks up front how strict to be, and he chooses full gates to PR. In the demo it fans one voice request out across three repositories while simultaneously triaging the three most recent open issues on another project.

The closing observation is that once firstmate absorbs the coordination overhead, you start running out of ideas before you run out of agent capacity. The bottleneck shifts to you, which means the captain's job becomes talking to users, understanding the competitive landscape, and choosing a direction worth sailing toward. All the tools mentioned are free and open source on his GitHub.

Footnotes