How AI-First Dev Teams Build Collective Intelligence — Edouard Maleix

Edouard Maleix argues that coding agents currently produce lessons every session but the team never learns from them — corrections evaporate into closed chat windows. He proposes a three-act workflow: (1) give agents their own identity and signed commits so work is attributable, capturing rationale in a "diary" of entries; (2) curate entries into thematic "packs" rendered into agent-readable skills that preserve attribution; (3) run controlled evals for fidelity and usefulness, eventually moving toward voluntary task-picking by specialized autonomous agents. The thesis: mistakes should compound into collective intelligence, not disappear into chat history.

Expected bundle files

This skill references two companion files that should be present in the same bundle:

• outline.md — A structured map of the talk, with sections keyed to approximate transcript line ranges and two lookup tables: "Named frameworks / concepts" (e.g. Identity & Diary; Pack, Curation & Render; Evals & Autonomy) and a "Terminology glossary" (e.g. diary, entry, pack, render, fidelity eval, usefulness eval, voluntary task picking, compound engineering).
• transcript.md — The raw speech-to-text transcript of the talk, line-numbered. The bulk is Edouard speaking; a Q&A section at the end interleaves unnamed audience questions with his answers.

If either file is missing, tell the user you cannot ground your answer and ask them to provide the relevant passage directly.

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 at the sentence level for this transcript — it has no per-speaker labels and includes obvious speech-to-text artifacts (e.g. "Adrian" / "adrian" almost certainly meant "AI"; "globally" likely meant "Claude"; "Tagli" likely "tiny"; "MoltNet" appears once in the abstract but may be transcribed differently in the body). The bulk of the transcript is Edouard speaking; the Q&A at the end interleaves audience questions with his answers. When quoting, preserve the artifacts verbatim — do not silently correct them — but you may note "(likely 'AI')" inline when the meaning is unambiguous from context.
6. Cross-reference any named addressee with the speaker bio / outline.md before attributing. Audience questioners are unnamed; refer to them as "an audience member" or "a questioner."

Standard lookup procedure

All use-case sections below rely on this shared procedure. Follow it before composing any response:

1. Read outline.md to locate the relevant section(s) and, under "Named frameworks / concepts" or "Terminology glossary", find the applicable framework or term.
2. Read the matching range of transcript.md in full.
3. Ground every substantive claim in a verbatim quote from transcript.md, with line numbers so the user can verify.
4. If the answer isn't in the transcript, say so explicitly. Do not reach for outside knowledge unless the user asks — and if you do, mark that part clearly as "not from the talk."
5. Any content you add beyond what the speaker explicitly prescribed must be flagged inline (e.g. [not from talk — added as a starting placeholder]).

Note for all use-case sections below: Each section follows the Standard lookup procedure above automatically. Only the additional steps specific to that use case are listed.

How to help with this talk

Apply the speaker's approach to current work

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

1. Focus the lookup on "Named frameworks / concepts" for the relevant framework.
2. Anchor your suggestion in a verbatim quote of how the speaker articulates the framework, then walk through applying it step-by-step to the user's case.
3. If the framework genuinely doesn't fit the user's situation, say so. Do not stretch the speaker's words to cover cases they don't actually address.

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

When the user asks to "audit", "score", "review", "grade", "check", or "gap-analyse" their current setup against the talk's framework — or describes their situation and asks where they're falling short:

1. Locate the three dimensions and their ordering (Identity & Diary; Pack, Curation & Render; Evals & Autonomy) in outline.md.
2. Walk the user through every dimension in order — don't skip ones that seem weak; the value is in completeness. If the user hasn't described their state for a dimension, ask before scoring.
3. For each dimension, quote the speaker's definition verbatim when stating what "good" looks like, then give a clear verdict (e.g. covered / partial / missing) grounded in the speaker's criteria, not your own intuition.
4. If a dimension genuinely doesn't apply, say so explicitly and explain why — don't stretch the speaker's criteria.
5. Summarise at the end: which dimensions are gaps, and what the speaker said about closing them (verbatim quotes again).

Draft an artifact following the speaker's specification

When the user asks to "draft", "generate", "give me a starting", "show me an example of", or "produce" an artifact the speaker described — typically a diary entry, a knowledge pack, a rendered skill section, or an eval criteria set:

1. Capture every constraint the speaker mentions (entry linkage, attribution to human + agent identifier, token budget when rendering, binary scoring for eval criteria, etc.).
2. Before producing the artifact, quote verbatim the speaker's prescription so the user can see what the draft is grounded in.
3. Produce a draft that follows the speaker's specification as faithfully as possible, matching the structure he described (entry → linked entries → pack → render with source/human/agent attribution).
4. If the user's situation requires elements the speaker didn't address, say so and ask the user to fill them in rather than inventing them.

Factual Q&A about the talk

For any question about what Edouard said, did, or argued, answer using verbatim quotes from transcript.md. Do not paraphrase the speaker's words while presenting them as a quote.

Surface this talk proactively when relevant

When the user's current work touches on themes Edouard addressed — agent attribution, signed commits by agents, capturing incidents as reusable knowledge, curating agent-generated rules/skills, evaluating skills, knowledge decay, autonomous task assignment — even if the user hasn't asked about the talk:

1. Briefly note: "Edouard Maleix made a related point in his talk on collective intelligence..."
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 Edouard covered (diary, entry, pack, render, fidelity vs. usefulness eval, voluntary task picking, compound engineering):

1. Look up the term under outline.md → "Terminology glossary".
2. Re-explain using the speaker's own framing and examples first (the Go SDK incident, the database transaction driver incident, the signed-by-the-maintainer Testify PR), with verbatim quotes for the key claims and definitions.
3. You may add modern context, comparisons, or extensions afterwards — but mark them clearly as "not from the talk" so the user can tell which parts are the speaker's and which are yours.

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.