Kun, previously an L8 principal engineer across Meta, Microsoft, and Atlassian, published a long walkthrough of his agentic engineering workflow: the terminal setup, the memory files, the planning surface, the review pipeline, the overnight loops, and the orchestrator agent he calls a first mate. He claims 40 to 50 tested PRs shipped to production on a good day. When I wrote up my own four-week setup, I referenced his profile in one sentence. This post is the thorough version: his workflow, annotated by someone who has shipped software for 15+ years and now runs a one-person consultancy on coding agents.
My receipts for the comparison: the live demo on this site went from spec to production in 29 days and 74 commits, one person plus agents; client work has peaked at 117 merged PRs in a week; and the 24 posts on this blog document the method piece by piece. Different scale than his numbers, different risk model too, and that difference turns out to be the most instructive part.
Where two independent workflows converge
The convergence is worth more than any single trick, because neither of us copied the other and we arrived at the same load-bearing walls.
The constraint is the human in the middle. His framing: AI writes code faster than you can review it, so reviewing everything caps your velocity, and the fix is to think like an engineering director who shapes process instead of reading every diff. My framing, from the consultancy post: delivery throughput equals review throughput, and everything in the setup either raises it or routes around it. Same wall, different paint. Both of us spend our human time at the beginning of a task, pinning intent, and at the end, holding a bar, with machinery in between.
Minimal global memory, accumulated project memory. His global memory file is 27 lines, because every line rides in the system prompt of every session and silently spends tokens. His project memory grows by accumulation: each time the agent gets something wrong, the correction gets written down so the mistake stays fixed. That is exactly how our skill library started, and his next move matches ours too: conditional knowledge moves out of the always-loaded memory file into skills that load on demand. He calls it progressive disclosure. We learned the same law the expensive way, when 200 tool definitions became a 9k-token catalog: the context window is rent, and anything that rides on every call has to earn its seat.
The development-cost bias. The sharpest observation in the video, and I have not seen it stated this cleanly anywhere else. Ask a frontier model to estimate a project and it answers in human-weeks, because it learned estimation from human data. It then carries that bias into technical decisions, implicitly pricing better designs as too expensive and steering toward cheap options, even though it could build the better design in an afternoon. He corrects this with a standing rule: when making technical decisions, do not give too much weight to development cost. That line is going into my global memory file, and it retroactively explains a pattern I have been correcting by hand in spec reviews: agents proposing the modest design when the right one costs them twenty more minutes.
Skills deserve benchmarks, not stars. He benchmarked a viral skills repo with 177k GitHub stars and found it made the agent 5% more expensive and the results worse, and his rule is to install nothing that claims magic without published evidence. Full agreement, with a governance twist: our answer to the same problem is a library of about 85 versioned skills where every entry carries an ADOPT, FORK, or BUILD label and a semver pin that fails CI when it goes stale. His warning and our bookkeeping are the same instinct at different scales: popularity is not evidence, and an unevaluated skill in the seam of every session is a liability with stars.
Tool ergonomics compound. He benchmarked GitHub access paths and found the MCP server costing three times the tokens and double the latency of the CLI for identical tasks, then wrote design standards for agent-efficient tools. Our version of the same discovery is documented across the MCP post and the catalog diet: agents re-read their tool surfaces on every turn, so a fat interface is a tax you pay per turn, forever. He is right to push this from "trim the catalog" to "design the tool output format itself for agents." Token-efficient output beats pretty JSON when the reader has a meter running.
Where his tooling is ahead of mine
Three pieces of his stack I will not pretend we match.
The planning surface. His planning tool renders options as an annotatable HTML artifact in the project's own design system, so reviewing a plan means clicking through something that looks like the product, commenting on specific elements, and making decisions with buttons. Our specs go through 4 to 5 review rounds as markdown. For backend contracts, markdown is fine. For anything UI-shaped, he is right that a wall of text is the worst possible surface for the most consequential conversation in the whole workflow, and an artifact you can point at beats a plan you can only quote.
Evidence over prose. His pipeline records proof that the change works: a screenshot, a video, a log, attached to the PR. Our gates produce numbers, and eval deltas on every PR are strong evidence for pipeline behavior, but "here is a recording of the feature doing the thing" is a better artifact for product-shaped changes than any test summary an agent writes about itself. Agents report success in confident prose; recorded evidence does not negotiate, which is the same reason we like red tests.
Worktree ergonomics. He pools git worktrees behind a tool that hands out a fresh one on demand, tracks which are busy, and reclaims idle ones. Our landing lanes are planned per spec, which prevents conflicts but makes ad-hoc parallel work heavier than it needs to be. Pooled worktrees are the better ergonomics for unplanned tasks, and this one is going on my list.
Where my pager disagrees
The disagreements are not about mechanics. They are about whose name is on the consequences.
Skipping low-risk diffs. His pipeline assigns each change a risk assessment, and for low-risk changes he does not read the diff at all, trusting that anything he would catch, the adversarial review already caught. On your own product, where you own the blast radius and can ship a fix in minutes, that is a defensible velocity trade, and his volume numbers are the payoff. On client work I hold the opposite line, stated in the operator brief: I read every PR, because the person who accepts a change answers for the outage it causes, and "the pipeline reviewed it" does not transfer accountability to a client who paid for my judgment. The honest synthesis is that risk tiering decides how long I look, never whether I look. His director analogy is good and incomplete: directors do not review PRs, and directors also do not sign consultancy contracts where the deliverable is their personal review.
The first mate. His orchestrator agent receives voice directions, decomposes them, spins up worktrees and sessions, runs the pipeline, and juggles so the human does not. I believe him that it feels like becoming a captain. My caution comes from production: on a multi-agent platform we run, manager-pattern orchestrators burned tokens negotiating with themselves, and the lesson was that routing beats managing. A dev-time first mate is a fairer case for the manager pattern than a production system, because it is a proxy for one human and its transcripts have an audience of one. But the failure mode does not disappear; it moves. A first mate that mis-decomposes your intent multiplies the mistake across every crew mate it spawns, and you find out after the tokens are spent. I stay closer to the sessions for now, and I say that as a preference with a cost, not a law.
Overnight loops. His loop tool runs an agent against an objective with caps and stop conditions while he sleeps, and his examples are well-chosen: verifiable objectives like test coverage, load time, or find-and-fix-the-next-usability-problem. The caps are the mature part; an uncapped goal before bed can eat a weekly quota by morning. On our own products, with iteration caps and an eval as the stop condition, I would run this tomorrow. On client repositories, never: unattended agents spending metered tokens against systems I answer for is exactly the class of unattended operation the week-one incident log taught me to distrust. The tool is sound. The question is whose meter and whose blast radius.
What I am taking
Three things go into my setup from his video: the development-cost-bias rule in the global memory file, recorded evidence artifacts in the review pipeline for product-shaped changes, and pooled worktrees for ad-hoc parallel work. That is a good haul from one walkthrough, and it is the correct way to consume anyone's workflow video, mine included: steal the pieces that survive contact with your own constraints, and keep the constraint you actually answer to.
Because the destination we agree on is the same. The human ends up holding intent at one end and judgment at the other, with machinery in between, and the better your machinery, the more of your attention moves to the only question tooling cannot answer: what deserves to be built next. His crew sails toward that with a first mate and skipped diffs. Mine gets there with written specs, eval gates, and a rule that every merge crosses one human. Same ocean, different insurance policies, and the systems both methods shipped are public: his tools are on his GitHub, and mine is answering questions at the live demo with the receipts in the operator brief.