L8 Principal's Agentic Engineering Setup (just copy him)

Technological concepts & setup overview

Terminal-first agent workflow

• Uses a frameless, highly customized terminal setup (via Western) for a “hands-on keyboard” development habit.
• Runs Herder (described as a modern alternative to tmux) as the terminal multiplexer/workspace manager.

Herder sessions as “agent-aware” workspaces

Herder is highlighted because it understands agents/sessions, not just terminals/tabs:

• Displays agent working status (e.g., “still working, not waiting on me”).
• Supports connecting remotely: the same terminal session can be accessed from a phone via SSH while preserving the exact environment.

First Mate: coordinator agent + crew mates

• The core system is First Mate, an “agent orchestrator” coordinating multiple crew mates (sub-agents).
• Motivation: managing many parallel agent sessions (e.g., 20–30 repos/sessions) becomes cognitively overwhelming if humans juggle tabs.

First Mate’s role

• Handles routing and coordination across projects.
• Delegates blocking tasks to other crew mates so the main coordinator remains responsive.

Key workflow patterns (how the system is used)

“Brain dump” model

• The speaker offloads thoughts and tasks to First Mate.
• Then they focus only on ambiguous decisions requiring human judgment.
• First Mate can return decisions or escalate when needed.

Delegation to avoid blocking

• Example: checking Apple App Store review status is delegated to another crew mate so First Mate remains available for other questions.

Managing many repositories

• The system scales to roughly 20–30 GitHub repos.
• First Mate knows which project corresponds to each request.
• Includes a workspace navigation view to jump into specific agent sessions when needed (rarely).

Model routing, reasoning control, and costs

Primary agent/model choice

• Uses Claude 5.6 (Sonnet 5.6) as the main “First Mate” agent (described as “juggling a lot of context”).

Crew mate model selection by rules

• A agents/routing rules file determines:
  • Which agent/model to use based on task complexity (e.g., complex technical/product design may use Fable-like capability).
  • Reasoning effort levels (“how much it thinks”).

Quota/usage bottleneck

• The bottleneck is LLM quota, not speed.
• Emphasizes saving scarce Fable quota for high-value tasks.
• Prefers slow/cheaper modes for background work.

Fast vs slow modes

• Some providers offer a fast mode (higher cost/lower latency).
• The speaker prefers slower for background tasks to maximize total throughput.

Review & validation tooling (reducing “AI slop” risk)

Code review bottleneck shifted to validation

• AI can generate code quickly, but the hard part becomes reviewing and ensuring correctness.

“No Mistakes” pipeline

Introduces “No Mistakes”, an automated validation pipeline for AI-generated changes.

Pipeline flow

1. Create a branch/commit from working directory changes (via a helper command like no mistakes -y, described as nm).
2. Perform intent understanding based on the agent session that produced the change.
3. Rebase on latest origin/main to reduce merge conflicts.
4. Adversarial review using GPT 5.6 Sonnet medium:
   • Autofix obvious bugs.
   • Escalate to human when changes affect product implications or are non-trivial.
5. Run testing to produce evidence.
6. Do documentation linting.
7. Open/push a PR and “babysit” CI until ready.

Operational note

• The speaker typically doesn’t babysit manually; later, First Mate can launch it automatically.

Cost control strategy

• Acknowledges heavy pipelines can burn tokens/cost on large codebases.
• Uses selective application:
  • Only run the heavy validation pipeline for changes where quality matters (production-like projects).
  • For simple fixes, make judgment calls to skip some steps.

Effectiveness metrics

Tracking stats over ~3 months:

• ~1000 changes across ~59 repos
• ~63% of changes go through “mistake cut” outcomes (issues caught/fixed)

Main failure modes caught:

• Edge cases found during adversarial review
• Documentation drift (README not updated to match code changes)

Interactive design review using artifacts

Lavish HTML artifacts for technical design trade-offs

• Uses Lavish to generate an interactive HTML “artifact” that visualizes:
  • design decisions,
  • trade-offs,
  • open questions.
• The user can provide feedback (e.g., adjusting diagrams/boxes) and send it back to the agent.

Speech vs typing

Voice input is the default

• Uses voice input most of the time.
• Exceptions: copying URLs/file paths where speaking is inconvenient.

Harness/tooling comparisons (Pi vs Codex vs Cursor vs others)

Pi as primary harness

• Chooses Pi because it’s highly customizable via plugins and offers more “bells and whistles” (background processes, workflow smoothness) than Claude/Codex-style harnesses.

Claude models via different harnesses

• Claude models routed through Cloud Code (described as “bans everything else”).

Groq harness

• Uses Groq 4.5 for fast performance (described as “Opus but on fast mode”).
• Notes EU availability limitations (speaker says Groq isn’t available in EU).

OpenCode / other TUI harnesses

• Uses OpenCode for a TUI experience, but gradually leans more toward Pi.

“Axi” and agent-native interfaces (product-level analysis)

Prediction: most software will become agent-operated

• Claims 99.9% of software/tools will eventually be used by agents.
• Reason people lag: they build human-native UI (web click workflows) instead of agent-native backends (CLIs/headless APIs).

Why MCP can be inefficient

• Some MCP servers are token-inefficient compared to best existing CI/API/COI-style interfaces.
• Example claim: GitHub MCP approaches cost more tokens and turn more, while GitHub’s optimized interface (COI) is more efficient due to long-standing usage patterns in training data.

Axi framework

• Mentions a site/resource like axi.md and “axi” wrappers making tools more agent-ergonomic.
• Key principles:
  • Token-efficient output (avoid verbose JSON where semantics only are needed)
  • Minimal default schema (avoid dumping every field/column)
• Benchmark-style claim:
  • Wrapping tools (e.g., Chrome DevTools) can reduce average cost by 20%+ and improve latency without functional loss.

Direction of standards

• Claims a community “catalog” of axi exists (GitHub axi, Chrome DevTools axi, Lavish itself, quota-related axi, and more).

Why the setup exists (emergent tooling from real bottlenecks)

The speaker describes building this after hitting solo bottlenecks:

• validating AI-generated code,
• interactive planning vs terminal scroll walls,
• juggling many sessions.

They then created tooling to address these issues and became an open-source maintainer (having to manage PRs/issues also shapes time allocation).

Main speakers / sources

• Guest speaker: Kun (ex Meta / Microsoft / Atlassian engineer; described as building coding agents; referred to by name David during the interview)
• Interviewer: David (the host)