Spearleaf · Position Zero Playbook v11 · 2026-06-16 Start here Changelog
Reference

"Andrew (Ansley, unconfirmed) - Vibe coding and harness engineering with AI agents"

Andrew's Day 1 case for harness engineering, the disciplined layer above vibe coding that makes Claude Code agents repeatable through domain-first naming, lean context windows, and hooks.

On this page

On Day 1, a developer who introduced himself only as Andrew (the session filename references "Andrew Ansley," so the surname is unconfirmed from the recording) of Thorbit.ai walked the room through harness engineering: the disciplined layer above raw "vibe coding" that makes AI coding agents (specifically Claude Code) repeatable and scalable. His core thesis is that everything you do with an agent is a prompt, so the goal is to build an operating system around the AI rather than write better one-off prompts. He demoed a Q&A and poll web app he says he vibe-coded in two to three hours, then spent the talk on the constructs that turn one-off output into a reproducible system.

Main takeaways

  1. Harness engineering beats vibe coding for anything you want to reproduce. Andrew frames three tiers (vibe coding, vibe engineering, harness engineering). Raw vibe coding can produce good output once, but you cannot reliably reproduce it. The fix is building a system around the AI, not writing better isolated prompts.
  2. Name folders after the work (the domain), not the code type. Domain-first naming (for example a folder called "estimates" for a construction company) lets agents grep and navigate intuitively, which Andrew says cuts token use by roughly 50% and makes the AI work about twice as fast.
  3. Keep context windows under about 100k tokens and use sub-agents to fetch context. Andrew claims agent performance drops off significantly past 100k and hallucination climbs after 200k, so large advertised windows (he cites a 2M Grok figure) are a "money grab." Thin sub-agents that gather and report back keep the main window lean.
  4. Hooks are the anti-hallucination and automation layer. Any executable can fire on Claude Code events (before a tool runs, on session end, and so on). A single "stop" hook (the "Ralph Wiggum" pattern) creates a self-correcting agent loop. Hooks give observability, enforceability, dependability, and therefore scalability.
  5. Build the system, not the prompt. Because no memory persists between agent runs (the cold-start problem), the brief is everything. The system's job is to build that brief automatically.

Key points

Speaker background and claims

Tools, products, URLs

Three tiers of building

Domain-first naming

Context window management

The cold-start problem

"Everything is a prompt"

The harness: hooks, commands, skills, agents

Hooks (the standout topic)

Other named patterns

Start-next-week procedure (his closing)

  1. Find the prompt you retype the most and write it as a skill (a folder plus a markdown file).
  2. Add one hook that fires when a phase completes; have it write a one-line log.
  3. Name every output file with its trust level (validated, approved, needs-review) by writing to a small JSON or YAML checkpoint file that allows only a handful of states.
  4. Build the system, not just the prompt.

Audience Q&A points

Slides

The deck below is from a SEPARATE presentation, "Vibe Coding for Non-Coders" by Aaron Gruenke, NOT by Andrew. Aaron Gruenke and Andrew are different presenters with different tools and offers; no deck file was provided for Andrew's actual talk. The slides are included here for reference only and should not be attributed to Andrew.

Slides (11) - Aaron Gruenke deck, a different presenter (not Andrew) Slide 1 Slide 2 Slide 3 Slide 4 Slide 5 Slide 6 Slide 7 Slide 8 Slide 9 Slide 10 Slide 11

Source

Session transcript: SEO ST Day 1 (Andrew of Thorbit.ai, harness engineering). No deck file was provided for Andrew's talk. The embedded slides above are from a different presenter's deck file, aaron-gruenke-seo-st-vibecoding-rev5 (Aaron Gruenke, "Vibe Coding for Non-Coders"), included for reference only. Source notes live in the project knowledge folder, which is not published on the live site.