Video summary

L8 Principal's Agentic Engineering Workflow

Main summary

Key takeaways

Technology

Summary of the agent engineering workflow walkthrough (technological concepts + tooling)

The speaker (Kun) presents a complete, production-oriented “agentic engineering” workflow for building software with coding agents. He emphasizes that this is not demos, but a repeatable workflow he uses to ship 40–50 changes almost every day, with production-level testing and review.

1) Overall workflow structure (“chapters”)

He organizes the workflow into staged “crew” roles:

  • Assemble the environment (“ship”): work mostly in the terminal
  • Onboard/ramp agents (“crewmates”): use memory files and skills
  • Run 1 agent effectively
  • Scale to multiple agents in parallel
  • Add a “first mate” agent to manage overhead so the human stays strategic

2) Terminal-centric setup (productivity + workflow consistency)

He argues the terminal beats GUI for agent engineering due to:

  • Keyboard-first flow: avoids constant context switching between keyboard and mouse
  • Workflow portability: consistent experience across devices (including phones)

Tools highlighted

  • Western (terminal emulator)
    • cross-platform (Windows/Mac/Linux)
    • Lua-configurable with hot reload
  • tmux (terminal multiplexer)
    • split panes/tabs for parallel agent sessions and editors
    • persistent sessions so you can detach/reattach
    • can connect to the same session from another device
  • Neovim (vim-style editor)
    • designed to keep hands on keyboard
    • includes navigation/edit shortcuts and productivity plugins (e.g., search, file finding)

3) Agent harnesses (“crewmates”) and keeping the workflow agent-agnostic

He uses multiple agent harnesses:

  • Claude Code / Cloud Code (Anthropic subscription)
    • sensible defaults but sometimes buggy and less customizable
  • Codex (Codex COI)
    • smoother; open source; can inspect its own source
    • fewer “bells and whistles”
  • Pi coding agent
    • minimal and extensible
  • Open Code
    • model-agnostic integration; more complete out-of-the-box

Even though he demonstrates with Cloud Code, he stresses that his workflow is agent-harness-agnostic, since model/tool performance changes quickly.

4) Onboarding agents with “memory files” and “skills”

He distinguishes two mechanisms.

A) Memory files (Markdown prompts)

  • Global memory file loaded into the system prompt for every agent session
    • kept minimal to avoid token bloat
    • includes personal preferences and rules (e.g., style choices; decision-making heuristics)
  • Project-level memory files (more detailed)
    • repo context, terminology, component behavior
    • end-to-end testing conventions
    • evolves as the speaker corrects agent mistakes over time

Example decision analysis baked into memory

  • When an LLM is asked to estimate development cost, it gives human-like estimates (days/weeks/months).
  • But when asked to actually build, it can produce playable results in minutes.

He argues this creates a bias where models over-penalize “expensive” options and choose lower-quality scalable solutions—so he adds rules to counteract that bias (e.g., don’t overweight development cost).

B) Skills (progressive disclosure + modularization)

Problem: memory files can get bloated and waste tokens every request.

Solution: move conditionally needed instructions from memory into skills.

  • Skills are loaded progressively:
    • only a short description is included initially
    • full details load only if/when the agent decides to use that skill

He recommends:

  • Use a skill installer/manager:
    • Skill Creator (Anthropic)
    • NPC’s skills (from Vercel) to install/manage skills

Security/performance guidance

  • Avoid installing random popular skills from the internet:
    • they could run arbitrary actions on the machine (including exfiltrating secrets)
    • some skills can degrade performance (he cites a benchmark showing increased token use and worse results)

5) How he prompts the agents (voice input + local transcription)

He mostly uses voice input rather than typing:

  • citing a Stanford paper: speaking is ~3x faster than typing
  • transcription is done locally using Open Super Whisper (free/open source Whisper-based local transcription)

He warns:

  • avoid speaking URLs/file paths aloud; typing is preferred for those.

6) Tool efficiency matters (examples: GitHub MCP vs CLI; “AXI”)

He emphasizes that agents rely heavily on external tools, and tool design affects:

  • token cost
  • latency
  • success rate

Example benchmark claim

  • Using GitHub MCP server costs ~3x more tokens and >2x latency vs using the CLI, with no clear benefits.

Introducing “AXI”

He introduces AXI as a set of design standards/principles for tool ergonomics optimized for agent usage, including claims like:

  • token savings (e.g., token-efficient output formats can save ~40% tokens vs JSON)
  • he built and benchmarked “AXI versions” of tools like GitHub, browser tooling, etc.

He points to an AXI catalog/site/repo for adopting these standardized agent-friendly tools.

7) Planning + iteration UX: Lavish editor vs “wall of text”

For complex features, he uses Lavish AXI as a planning interface:

  • Without Lavish, the default planning tends to produce a long wall-of-text plan in the terminal.
  • With Lavish:
    • the agent creates an HTML artifact using the project’s design system
    • the human can annotate specific parts and make clickable decisions
    • feedback is sent back without returning to terminal-heavy editing

After requirements are clarified, the agent proceeds to implementation.

8) Reviewing at scale: avoid diff bottlenecks; use an automated “No Mistakes” pipeline

A key scaling insight:

  • Traditional agent workflows require humans to review every diff and manually test—becoming a bottleneck and “not fun.”

He recommends thinking like an engineering director/manager:

  • humans set culture/process/quality gates
  • agents handle execution and most verification

Tool: No Mistakes (free/open source)

It turns a first-pass agent code output into a clean PR by:

  • creating branch/commit if needed
  • validating in an isolated work tree
  • analyzing intent from the agent session
  • rebasing onto latest main and resolving merge conflicts
  • running an adversarial review in a fresh context window
  • running end-to-end tests aligned with original intent and capturing evidence
  • documentation updates
  • lint checks
  • pushing and raising PR
  • “babysitting” through merge-time issues (merge conflicts / CI failures)

He notes it can be triggered as a skill (“no mistakes”) and runs while he does other work.

PR output includes

  • summarized original intent
  • what changed
  • test/evidence (screenshots/video/logs)
  • risk assessment to decide review depth
  • ability to return to the agent for additional changes before merging

9) Long-running autonomy: “Goodnight. Have fun”

To keep agents productive while the human is away (e.g., sleeping 7–8 hours), he uses:

  • Goodnight. Have fun (free/open source)

It:

  • runs an agent in a loop until a stop condition or objective satisfaction condition is met

Example objective:

  • test the app like a 7-year-old user to find and fix the first usability problems, repeating until none remain

He monitors:

  • iteration counts/tokens and commits made

Then he reviews only the relevant commit list afterward.

He contrasts this with Codex/Cloud “slash goal” style goals:

  • Goodnight gives finer control via token/iteration caps and custom stop conditions.

10) Parallel multi-agent execution: git worktrees + “Treehouse”

To scale to multiple agents simultaneously, the key problem is avoiding repository conflicts when multiple agents write to the same directory.

He uses:

  • git worktree (separate filesystem clones of the repo working directories)

But he notes worktrees create “head debt” (remembering which worktree does what, cleaning them up).

Solution: Treehouse (his tool)

  • creates a fresh worktree environment quickly
  • manages/reuses worktrees
  • provides status and automatically frees worktrees when done

Result:

  • multiple “tabs/sessions” can run in parallel via tmux/treehouse
  • he can switch sessions with keyboard shortcuts

11) The “First Mate” role: manage overhead and coordinate crews

When parallelism becomes exhausting (context switching, tracking session intent), he adds:

  • First Mate (free/open source; new tool)

It acts like an orchestrator:

  • he talks to First Mate with objectives across multiple projects
  • First Mate creates tmux sessions, worktrees, runs agents, and triggers No Mistakes validation
  • handles repo tasks like updating npm versions across multiple projects
  • triages open issues and selects actionable ones

Additional detail:

  • He customizes voice transcription accuracy by injecting a system prompt into Open Super Whisper with vocabulary (e.g., project names).

He demonstrates:

  • First Mate juggling lavish/axi/Chrome dev tools/etc.
  • then coordinating which issues are actionable and delegating fixes.

12) Mindset shift to “captain” strategy

He concludes that after automation, the bottleneck shifts:

  • less time spent on reviewing execution
  • more time spent on:
    • understanding user needs
    • understanding competitive landscape
    • building a “treasure map” (direction/strategy) for the agents

Main speakers/sources (as mentioned)

  • Kun (main speaker; creator of AXI-related principles, and tools like No Mistakes, Treehouse, Goodnight. Have fun, First Mate, and contributor to other tooling)
  • Dario (mentioned in context of speech recognition work and Anthropics CEO)
  • Stanford paper (supports the claim that voice is ~3x faster than typing)
  • Program Bench (used to evaluate an example skill’s performance)
  • Tools/repos/callouts: Anthropic Cloud Code, Skill Creator, Vercel NPC’s skills, Open Super Whisper, No Mistakes, Treehouse, Goodnight. Have fun, First Mate, AXI catalog

Original video