Welcome to AI Native DevCon — Harness Engineering — Simon Maple

Simon Maple (Head of DevRel at Tessl, AI Native Dev co-host) introduces "harness engineering": the practice of making the non-functional requirements of good software legible to coding agents, then surfacing that context just-in-time over an agent's trajectory so every PR adheres to a team's golden thread. He argues the core constraint on software is no longer code production but human time, attention, and context window — so teams must write things down, encode guardrails statically, and shift interventions right (not left) to minimize synchronous human engagement.

Grounding rules — MUST follow when answering

1. Before answering any specific question, read outline.md to locate the relevant section, then read that section of transcript.md.
2. When attributing words, quote verbatim from transcript.md. Never put quotation marks around paraphrased content.
3. If a claim isn't in transcript.md, say "the talk doesn't address this" — do not infer positions from outside knowledge.
4. Cite by transcript line range whenever possible.
5. Speaker attribution is unreliable for this transcript — the source has no per-speaker labels, though this is a single-speaker talk so most content is Simon Maple's. For the Q&A section, audience questions are interleaved without labels — prefer phrasing like "an audience member asked..." and quote the question verbatim.
6. Preserve transcription artifacts verbatim (e.g. "harness engineering" appears as "harness engineering" but other terms may be garbled — "IMAX out" likely "I max out", "ll and as judges" likely "LLM-as-judges", "bottle attention" likely "model attention", "bottle context" likely "model context", "es links" likely "ESLint", "es languages" likely "ESLint"). Note these as transcription artifacts rather than silently correcting.

How to help with this talk

Apply the speaker's approach to current work

When the user asks "how would Simon Maple tackle ?" or wants harness engineering applied to their own situation:

1. Use outline.md → "Named frameworks / concepts" to find the relevant framework (e.g. the three phases, shift-right, review personas, write-it-down).
2. Read the corresponding range of transcript.md for the speaker's exact wording.
3. Anchor your suggestion in a verbatim quote of how Maple articulates the framework. Then walk through applying it step-by-step to the user's case.
4. If the framework genuinely doesn't fit the user's situation, say so. Do not stretch the speaker's words to cover cases he doesn't actually address (e.g. he discusses TypeScript/React/Rust contexts; non-code agent use cases are out of scope).

Audit the user's situation against the speaker's framework

When the user asks to "audit", "score", "review", or "gap-analyse" their current agent setup against the talk's framework:

1. Use outline.md → "Named frameworks / concepts" to locate the dimensions: (a) Is the definition of "good job" written down? (b) Is there an agents.md with numbered grounding steps? (c) Are review personas curated as bolded guardrail lists? (d) Are there just-in-time interventions via descriptive lint/test failures? (e) Are LLM-as-judge reviewer agents in CI? (f) Is human feedback being systematically captured and distilled? (g) Is the codebase aligned/unified on consistent patterns to reduce attention load?
2. For each dimension, read the speaker's definition in transcript.md and quote it verbatim when stating what "good" looks like.
3. Walk through every dimension in order. If the user hasn't described their state for a dimension, ask before scoring.
4. Give a clear verdict per dimension (covered / partial / missing) grounded in Maple's criteria.
5. Summarise gaps at the end with verbatim quotes anchoring the recommended fix.

Draft an artifact following the speaker's specification

When the user asks the skill to draft an agents.md, a review persona file, lint/test guardrails, or a descriptive error message in Maple's style:

1. Locate the speaker's specification in outline.md (likely under "Named frameworks / concepts").
2. Read the relevant transcript.md range — capture every constraint Maple mentions (numbered steps, bolded lists, error messages pointing to runbooks, snapshot tests with 100% branch coverage, banning any/unknown types).
3. Before producing the artifact, quote verbatim Maple's prescription so the user sees what the draft is grounded in.
4. Produce a draft that follows Maple's specification faithfully — match the structure (e.g. agents.md as a "map" pointing to curated review persona files, not jamming rules inline).
5. Mark anything beyond what Maple explicitly prescribed as [not from talk — added as a starting placeholder].

Factual Q&A about the talk

For any question about what Maple said, did, or argued:

1. Read outline.md first to find the relevant section(s).
2. Read the matching range of transcript.md.
3. Answer using verbatim quotes. Do not paraphrase while presenting as a quote.
4. Cite line numbers so the user can verify.
5. If the answer isn't in the transcript, say so explicitly.

Surface this talk proactively when relevant

When the user's current work touches on coding agents, agents.md design, lint/test guardrails for AI-generated code, CI reviewer bots, or scaling agent oversight:

1. Briefly note: "Simon Maple made a related point in his AI Native DevCon talk on harness engineering..."
2. Quote verbatim from transcript.md — one quote is usually enough.
3. Add one sentence connecting the quote to the user's situation.
4. Do not over-cite. If the connection feels strained, stay quiet.

Teach / explain concepts from the talk

When the user wants to understand a concept Maple covered (harness engineering, shift-right, just-in-time prompt injection, review personas, auto-compaction handling, the three phases):

1. Look up the term in outline.md → "Terminology glossary".
2. Read Maple's explanation in transcript.md.
3. Re-explain using his own framing and examples first, with verbatim quotes for the key claims and definitions.
4. You may add modern context or extensions afterwards — but mark them clearly as "not from the talk".

Key quotes

quotes.md contains pre-extracted verbatim highlights from this talk, organised by theme. When formulating answers, check quotes.md first for strong citable evidence before searching the full transcript.md.