talk-stack-humans-architect-ai-writes-code

name	talk-stack-humans-architect-ai-writes-code
description	Use when the user asks about Paul Stack's talk "The Humans Architect the System, the AI Writes the Code" (System Initiative / Eldest One Club, 2026) — including questions about why his team stopped writing code, the no-PR open-source policy, CLAUDE.md as executable constraints, the planner/adversarial-reviewer loop, swamp the AI-native ops CLI, UAT as source of truth, "vibes don't scale", "intent is the new architecture", supply-chain integrity in AI-era OSS, or applying his architecture-first / agents-write-all-code workflow to the user's own team.
metadata	{"generated-by":"talk-to-skill","source":"file:user-pasted-transcript","generated-at":"2026-06-01T00:00:00.000Z"}

The Humans Architect the System, the AI Writes the Code — Paul Stack

Paul Stack describes how his five-person team at System Initiative (now also Eldest One Club) threw away six years of Rust code in January, stopped writing code entirely, and rebuilt their product "swamp" — an AI-native automation CLI for ops — with every line generated by LLMs operating under strict, executable design guidelines. Humans own architecture, constraints, and intent; agents write code; pull requests from humans (internal or external) are deleted on sight to keep the supply chain trustworthy. The thesis: the quality of AI output is a direct reflection of how sharply you can express what you want, so the engineering job becomes building the machine that writes the code.

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 reliable for Paul's own words (this is a single-speaker talk), but the transcript has no per-speaker labels for the Q&A. When quoting an audience question, use phrasing like "an audience member asked..." rather than naming anyone. The transcript also contains speech-to-text artifacts (e.g. "marriage" likely = "merge", "scale" likely = "skill", "claw code" = "Claude Code", "polarizer" = "pull request", "Eldest One Club" may be a mis-transcription) — preserve them verbatim when quoting, and note the likely intended word in square brackets if it aids the user.
6. Do not invent attributions for the Q&A questioners.

How to help with this talk

Apply the speaker's approach to current work

When the user asks "how would Paul tackle <X>?" or wants the talk's framework applied to their own situation:

1. Use outline.md → "Named frameworks / concepts" to find the relevant framework (the triage→plan→adversarial→UAT pipeline, CLAUDE.md as executable constraints, "start small: one constraint, one loop", etc.).
2. Read the corresponding range of transcript.md for Paul's exact wording.
3. Anchor your suggestion in a verbatim quote of how Paul articulates the framework. Then walk through applying it step-by-step to the user's case.
4. If the framework genuinely doesn't fit (e.g. user is in a regulated environment Paul doesn't discuss), say so. Do not stretch his words to cover cases he doesn't address.

---

Audit the user's situation against Paul's framework

When the user asks to "audit", "score", "review", "grade", "check", or "gap-analyse" their current AI-coding or contribution workflow against Paul's setup:

1. Use outline.md → "Named frameworks / concepts" for the dimensions: (a) humans-only-architecture vs code, (b) executable constraints in CLAUDE.md, (c) no-human-PRs policy / contributions via issues, (d) planner+adversarial review loop with a 5-iteration cap, (e) five merge gates (code / adversarial / UX / CI-security / skill-check), (f) UAT in a separate repo with tests-as-source-of-truth, (g) self-debugging agent that opens issues on errors.
2. For each dimension, quote Paul's definition verbatim when stating what "good" looks like.
3. Walk the user through every dimension in order. Ask before scoring any the user hasn't described.
4. Give a verdict per dimension: covered / partial / missing. If a dimension genuinely doesn't apply (e.g. they're not OSS, so supply-chain framing differs), say so.
5. Summarise gaps and what Paul said about closing them — again with verbatim quotes.

---

Draft an artifact following Paul's specification

When the user asks to "draft", "generate", or "show me an example of" an artifact Paul described — most commonly a CLAUDE.md with executable constraints, an adversarial-reviewer prompt, a triage skill, or UAT tests-as-source-of-truth structure:

1. Locate the spec in outline.md and the matching transcript.md range.
2. Capture every constraint Paul mentions (e.g. for CLAUDE.md: TypeScript strict, no anys, named exports only, AGPL header, no fire-and-forget promises, long adjacent endpoints, imports from mod, never leak implementation details, and the trailing "if you hit a non-obvious problem, record it and propose an update" line).
3. Quote verbatim Paul's prescription before producing the draft.
4. Produce the draft following his structure/terminology faithfully.
5. Mark anything you add beyond what Paul prescribed with [not from talk — added as a starting placeholder].
6. If the user's situation needs elements Paul didn't address, ask rather than invent.

---

Factual Q&A about the talk

For any question about what Paul 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 Paul's words while presenting them as a quote.
4. Cite line numbers.
5. If the answer isn't in the transcript, say so explicitly. Don't reach for outside knowledge unless the user asks (and mark it clearly as "not from the talk").

---

Surface this talk proactively when relevant

When the user's current work touches themes Paul addressed — AI coding workflows, OSS contribution policy in an AI era, CLAUDE.md / agent instruction design, supply-chain integrity, CI gate design, the planner-vs-reviewer multi-agent pattern, or the role of juniors in an AI-native team:

1. Briefly note: "Paul Stack made a related point in his talk..."
2. Quote verbatim from transcript.md — one quote is usually enough.
3. Add one sentence connecting it to the user's situation.
4. Don't over-cite. If the link is strained, stay quiet.

---

Teach / explain concepts from the talk

When the user wants to understand a concept Paul covered (executable constraints, vibes-don't-scale, intent-as-architecture, the adversarial review loop, UAT-as-source-of-truth, the new junior role):

1. Look the term up in outline.md → "Terminology glossary".
2. Read Paul's explanation in transcript.md.
3. Re-explain using his framing and examples first, with verbatim quotes for key claims.
4. You may add modern context afterwards — mark it 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.