Licious Engineering Bootcamp · 2026
AI-Native From coding assistants to software factories.
Opening · 1 / 4
Welcome. Before anything else, set expectations about what this is not : not an intro to LLMs, not prompting tricks, not "watch an agent build a todo app", not a vendor bake-off between Codex, Claude Code, Cursor, Devin.
This session is about one question: what changes about software engineering when producing code stops being the scarce resource?
Two promises for the next two and a half hours:
You will leave with a new mental model of engineering. Not "how do I use Codex better" but "how should our engineering system change when agents become real participants". You will leave with a starter kit , not better prompts. A repo you can clone tonight: task contracts, context architecture, skills, invariants, evals, a readiness scorecard, an autonomy matrix. Housekeeping: four live demos, two exercises where you work on your own repo, one break at roughly the 70 minute mark. Interrupt me. The demos are more interesting when someone in the room says "that would never work on our codebase".
Run of show · 150 minutes
Five acts. Four demos. Two exercises. One starter kit. I The Shift why engineering itself is moving II The Engineer how you work differently on Monday III The Repository making code legible to two readers IV The SDLC the lifecycle becomes machine-executable V The Organization compounding judgment into infrastructure
Opening · 2 / 4
Timings, roughly:
Act I, The Shift — 20 min. Why engineering itself is moving. Pure ideas, fast.Act II, The Engineer — 45 min. Demo 1 (one task, three levels) and Demo 2 (adversarial development). What you personally do differently on Monday.Break — 10 min at about 1:10.Act III, The Repository — 40 min. Demo 3 (context surgery) and Demo 4 (build a Skill live). Exercise 1: score your own repo.Act IV, The SDLC — 15 min. Optional stretch demo: incident to PR.Act V, The Organization — 20 min. Exercise 2: write a task contract for your last ticket.Close — 5 min.If we run long, Act IV compresses first. The stretch demo is the one to cut. Never cut the exercises. The exercises are where people realise the talk is about their repo, not mine.
Both can be true. AI made engineers faster. AI made engineers slower.
Opening · 3 / 4
Open with the contradiction, because it kills the sales-pitch suspicion in the first ninety seconds.
Observation A. AI tools are everywhere. Engineers report feeling more productive. DORA-style surveys and internal dashboards at many companies show higher throughput and more PRs.
Observation B. METR ran a controlled study with experienced open-source developers working on mature codebases they know intimately. With frontier AI tools they were slower , about 19 percent slower, while believing they had been about 20 percent faster.
Both are true. And that is the doorway into the whole talk.
The useless question is "is AI good or bad for productivity?". The useful question is: under what engineering conditions does AI amplify productivity, and under what conditions does it amplify friction?
Pause here. Ask the room: who has personally felt both? Nearly every hand goes up. That's the point.
The question was never whether AI is good for engineering. It's under which conditions it amplifies work, and under which it amplifies friction.
Opening · 4 / 4
Reframe the debate. "Is AI good?" is a religious question. "Under which conditions?" is an engineering question, and engineering questions have answers you can act on.
The conditions turn out to be things we already know how to build: clean boundaries, fast deterministic tests, legible architecture, explicit invariants, observability an agent can reach. The rest of this session is a tour of those conditions.
Transition: so let's name the principle that explains both the METR result and the DORA result at the same time.
Act I
The Shift Why engineering itself is moving.
Opening The Shift The Engineer The Repository The SDLC The Organization Closing
The Shift · 1 / 10
Act I. About 20 minutes. Goal: make the room understand that this is a change to software engineering , not a change to typing.
Sequence: amplifier principle, the ghosts, eras of AI coding, "AI-native is not AI writes code", model vs agent, harness, the stack.
Keep it fast. This act is ideas, no demos. Energy matters here because the demos come later.
AI is an amplifier, not an exorcist. It scales your engineering system. Including the ghosts.
your engineering system AI your engineering system, louder ---- the ghosts, also louder The Shift · 2 / 10
This is the first big mental model and it explains the contradiction from the opening.
AI amplifies whatever system it is inserted into. If your system has clean interfaces, strong tests, deterministic build commands, good observability, clear ownership, explicit invariants, then an agent moves fast and safely. That's the DORA result.
If your system has tribal knowledge, fragile builds, ambiguous architecture, undocumented exceptions, slow CI, weak tests, then AI produces confusion faster. That's the METR result: experienced people on mature, quirky codebases, where the expert's head was the only reliable context.
The diagram: same signal, louder. The dashed wave is the ghosts. They got louder too.
Say it plainly: AI will not exorcise your technical debt. It will scale it.
A bad abstraction can now be copied ten times faster. Congratulations.
The Shift · 3 / 10
Make the ghosts concrete. Land each one with a beat:
A bad abstraction can now be copied ten times faster. A broken convention is now faithfully reproduced everywhere. Agents are the most obedient junior engineers you have ever hired. A slow CI pipeline now blocks ten agents instead of one developer. A weak review process now receives four times the PRs without getting four times better. The punchline of this slide is the implication: AI-native transformation is not a tool rollout. Buying seats changes nothing about the ghosts. It is an engineering-system transformation, and that is good news, because engineering systems are something this room knows how to change.
Four eras. The unit of work keeps getting bigger. I Assistance Human drives. AI types. II Collaboration Human and agent take turns. III Delegation You assign work. You don't watch it. IV Factory The SDLC itself runs on machines. unit: a line unit: a task unit: a workstream unit: the lifecycle The Shift · 4 / 10
Orient the room on where we actually are.
Era I, Assistance. Human drives, AI types. Autocomplete, inline completions, one-function suggestions. Unit of interaction: a line. This is a typing accelerator.
Era II, Collaboration. Human and agent take turns. The agent inspects files, edits across files, runs commands, reads errors, iterates. Unit: a task. The model is now inside a feedback loop, not just generating text. This is where most of this room lives today with Codex, Claude Code, Cursor agents.
Era III, Delegation. You do not watch every token. You assign work. Agent A does the PR, Agent B investigates, Agent C writes tests, Agent D drafts the migration plan. Unit: a workstream. Human attention starts to become the scarce resource.
Era IV, the Software Factory. Not just many coding agents. A lifecycle where many stages can be executed by machines: reproduce, diagnose, regression test, fix, independent review, CI, rollout, production verification. Unit: the lifecycle.
Most teams are in Era II and think Era III is "more Era II". It is not. Era III changes what your job is.
The bottleneck didn't disappear. It moved. Upward. Into intent, context, environment, and evidence.
The Shift · 5 / 10
This is the central thesis, stated once, cleanly.
The naive story: a human writes 100 lines an hour, AI helps them write 500. That framing is too small.
The real transition: human specifies intent, designs constraints and environment, agent investigates, proposes a plan, executes, verifies, independent systems challenge the result, and the human spends attention where judgment is needed.
As turning intent into code gets cheap, relative value moves into: choosing the right problem, structuring the task, supplying the right context, constraining the solution, exposing the right tools, building a safe execution environment, designing tests and evaluators, reviewing evidence, coordinating parallel workers, deciding what deserves human attention.
Say it: when code stops being the bottleneck, engineering does not disappear. Engineering moves. Everything after this slide is about where it moved to.
Everyone having Codex does not make you AI-native. That's a procurement event.
The Shift · 6 / 10
This gets a laugh and it should, because half the industry is confusing the two.
A company is not AI-native because everyone has a premium seat, engineers use Claude Code a lot, PR count went up, or more code got generated.
Give the maturity ladder verbally: tool access → AI-assisted individuals → agent-legible repositories → reusable team knowledge → agent-capable platforms → machine-verifiable SDLC → software factory.
Most organisations are on rung two and are describing themselves as rung seven in the all-hands deck.
Ask the room to privately place Licious on that ladder. Don't ask for hands. Let it sit.
AI-native ≠ AI writes code. AI-native = the SDLC itself becomes machine-executable.
The Shift · 7 / 10
A more mature definition: individuals have agents, repositories are agent-legible, teams encode reusable skills, platforms expose tools and context safely, CI produces machine-verifiable feedback, SDLC processes accept machine workers, and the organisation measures system-level outcomes.
That is an agent-native engineering organisation . Notice that "AI writes code" is one small line in that list.
Concrete Licious-shaped version: an incident fires, an agent reproduces it, diagnoses it, writes the regression test, implements the fix, a separate agent tries to break the fix, CI verifies, the deployment system rolls out, observability checks production. The human is in that loop at exactly the points where judgment matters. That is the picture to hold in your head for the rest of the session.
Model ≠ Agent. The same model is brilliant in one harness and useless in another.
MODEL + INSTRUCTIONS + TOOLS + CONTEXT + ENVIRONMENT + VERIFICATION + FEEDBACK LOOP = AGENT
The Shift · 8 / 10
The most important correction in Act I. A powerful model is not a capable agent.
A practical engineering agent is roughly: model plus instructions plus tools plus context plus environment plus verification plus a feedback loop. Remove any one and the same model gets dramatically worse.
A raw frontier model knows Java, Kafka, Postgres, Kubernetes, Spring. It still fails at Licious because it does not know which repository is the source of truth, which service owns an invariant, what command boots the project, which schemas must stay backward compatible, what "allocation" means here specifically, where the metrics live, which shortcuts are forbidden, or how success is verified.
So the interesting question stops being "which model is best" and becomes: what harness are we giving the model?
Demo 1 will prove this on a real bug. Same model, three harnesses, three wildly different results.
The model is getting better whether we do anything or not. The harness is our engineering problem.
The Shift · 9 / 10
This is the sentence I want people to repeat at their desks.
Harness engineering is the discipline of everything around the model: a clearly defined task, the right context, the right tools, a controlled environment, the ability to execute, feedback from tests, observable state, a way to recover from mistakes.
For Licious, the durable advantage is never going to be owning a model. Everyone rents the same models. The advantage is proprietary context, proprietary workflows, internal tools, agent-readable architecture, high-quality evaluators, encoded domain expertise, institutional feedback loops.
Put differently: OpenAI and Anthropic are working on the model for you. Nobody is working on your harness for you.
Reference for the curious: OpenAI's "Harness Engineering" post and Anthropic's "Harness design for long-running apps" both describe this from the inside.
Reliability comes from the stack, not the model. INTENT What should happen? KNOWLEDGE What already exists? SKILLS How do we solve this class of problem? TOOLS What can the agent actually do? ENVIRONMENT Where can it act safely and reproducibly? VERIFICATION How is the result proven correct? MODEL What can it reason about? The Shift · 10 / 10
The AI-native engineering stack. Walk it top to bottom, one line each.
Intent : PRDs, issues, specs, acceptance tests. What should happen?Knowledge : code, docs, architecture, domain. What already exists?Skills : how this organisation solves recurring classes of problems.Tools : git, shell, database, MCP, internal APIs. What can it actually do?Environment : sandbox, worktree, CI, browser. Where can it act safely and reproducibly?Verification : tests, linters, evals, telemetry. How is the result proven?Model : reasoning and generation capability.The model is the bottom layer and it's the only one you can't engineer. Every other layer is yours. Each act of this talk is basically one or two layers of this stack. Act II is intent and verification at the individual level. Act III is knowledge, skills, tools in the repo. Act IV is environment and verification across the lifecycle. Act V is how the org accumulates all of it.
Act II
The Engineer What you do differently on Monday.
Opening The Shift The Engineer The Repository The SDLC The Organization Closing
The Engineer · 1 / 17
Act II, about 45 minutes including two demos. Goal: change individual behaviour.
Topics: inspection before implementation, task contracts, context as attention, fresh contexts, parallel agents and worktrees, adversarial development, and the attention bottleneck.
Demo 1 comes early (one task, three levels). Demo 2 (adversarial) comes at the end of the act.
This is the act people will remember because it's about their hands.
Don't ask an agent to solve a problem it hasn't proven it understands. Inspection before implementation.
The Engineer · 2 / 17
The most common failure pattern in the wild: Jira ticket → "implement this" → agent starts editing files within four seconds.
Better process: issue → inspect → explain current behaviour → identify invariants → identify affected components → plan → critique (human or agent) → implement.
The rule: inspection before implementation. The agent should first prove it understands where the behaviour lives, which systems depend on it, what assumptions exist, what can break. In a brownfield system this is not optional; it is the whole game.
Practical form: your first message to an agent on any non-trivial task should contain the words "do not modify anything". Make it explain first. If the explanation is wrong, you just saved yourself a bad PR and a review cycle.
OpenAI's own Codex guidance says the same: describe work like a good GitHub issue, use planning first for substantial changes.
A prompt is a conversation. A Task Contract is an engineering artifact. Goal what observable behaviour changes Non-goals what must not change Existing behaviour what happens today Invariants what must stay true Acceptance criteria how we know it's done Starting points files, PRs, dashboards Allowed surface what it may touch Forbidden surface what it must not touch Verification which tests prove it Rollback how we undo it Unknowns what to investigate first tap a section to see it filled in for the FEFO change
The Engineer · 3 / 17
This might be the single most immediately useful artifact in the kit, more than Skills, because you can use it tomorrow with zero infrastructure.
Walk the headings quickly; they're on screen. The interesting ones:
Non-goals — the thing agents violate most. "Do not touch the public API" is worth more than three paragraphs of goals.Invariants — what must remain true regardless of implementation.Allowed and forbidden change surface — literally which directories it may edit. Blast radius by construction.Verification — which tests, metrics, scenarios prove it. If you can't fill this in, you're not ready to delegate.Rollback — forces you to think about reversibility before autonomy.Unknowns — what must be investigated before implementation. This is where "inspect first" lives inside the contract.Frame: prompts are disposable chat. Task contracts are reviewable, versionable, reusable engineering documents. They live in the repo under task-contracts/. They become the eval cases later. Same shape.
“Fix inventory reservations” is not a task. It's a wish.
The Engineer · 4 / 17
Comic beat, but a real one. Most delegation today is a wish handed to a very fast, very literal contractor with no context and infinite confidence.
Contrast on the spot, verbally:
"Fix inventory reservations" versus: Goal, reservations for short-shelf-life SKUs must select FEFO instead of FIFO. Non-goal, non-perishable SKUs keep FIFO, the public API contract does not change. Invariants, reservations stay idempotent, stock never goes negative, expired inventory is never allocated. Forbidden surface, do not touch the event schema. Verification, the reservation contract tests plus a new FEFO property test. Rollback, feature flag.
The second version takes four minutes to write. It saves four hours of review. Segue into Demo 1, where we do exactly this.
Demo 1 · One task, three levels
Same model. Different engineering system. Casual prompt → structured investigation → task contract plus harness.
The Engineer · 5 / 17
Setup : one small realistic repo with a planted bug in inventory selection. Reset between attempts with git. Same model throughout. Time-box: 12 minutes.
Attempt A, casual. "Fix this bug." Let it run. It will modify code. Might even pass tests. Note out loud: files touched, assumptions it made silently, no questions asked, tests added, blast radius.
Reset.
Attempt B, structured. "Investigate this bug. Do not modify anything. Explain current behaviour, likely root cause, relevant components, invariants, smallest safe change, verification strategy." Then: "Now implement the approved plan." Already much better: fewer files, explicit assumptions, it names the invariant.
Reset.
Attempt C, engineered. Give it the task contract, the repo's AGENTS.md and context files, the relevant Skill, and the verification script. Watch it investigate, implement, run tests, inspect behaviour, produce evidence.
Compare on a whiteboard : files touched, assumptions, questions raised, tests added, blast radius, evidence produced.
Closing line: Same model. Different engineering system. That is Model ≠ Agent, proven, not asserted.
Fallback if the live run misbehaves: have the three transcripts pre-recorded as text files and walk through them. The comparison is the demo, not the live typing.
Context is attention, not storage. Every token you add competes with every token already there.
The Engineer · 6 / 17
Central line of the talk. Technically a context window is storage. From an engineering perspective the useful metaphor is attention, because every piece of information competes with every other piece for influence on the output.
So the goal is not "maximise context". The goal is maximise useful signal per unit of attention.
Good context engineering asks: what does the agent need right now? What can it discover later? What is authoritative? What can be summarised? What should load only for a specific skill? What should be excluded because it distracts? When should we start a fresh context?
Anthropic's context-engineering guidance frames it exactly this way: context is a finite resource whose utility must be optimised, not maximised. That framing is a much more sophisticated discipline than prompt engineering.
Please do not write a 40,000-token AGENTS.md. That's not context engineering. That's context littering.
The Engineer · 7 / 17
The most common well-intentioned mistake. Someone reads "give the agent context" and generates a monster AGENTS.md from every wiki page.
What a giant instruction file contains in practice: stale information, irrelevant information, conflicting guidance, low-priority details, redundant explanations, exceptions that rarely matter. All of it competing for attention on every single task, including the ones it has nothing to do with.
More context is not the same as more useful context.
Evidence slide, verbally: Meta's brownfield work on huge data pipelines. Rather than throwing thousands of files into context, they built concise navigation documents encoding the non-obvious relationships, and reported roughly 40 percent fewer tool calls in preliminary testing. Smaller, sharper context, fewer wasted steps.
Onboarding an agent by dumping every document on it is like onboarding an engineer by dropping Confluence on their head. The Engineer · 8 / 17
Let this one breathe. It's the funniest line in the deck and it's also exactly true.
We would never onboard a senior hire by printing the wiki. We'd say: here is the architecture doc, here's the glossary, here's the one weird thing about inventory nobody understands, here's who to ask, here's how to run the tests. Progressive disclosure. The agent deserves the same courtesy, for the same reason: attention is finite.
AGENTS.md should be a router, not an encyclopedia. AGENTS.md Architecture? read ARCHITECTURE.md Touching inventory? read context/inventory.md Production incident? use $incident-investigation Kafka schema change? use $kafka-schema-change Before implementing write an execution plan Before finishing run ./scripts/verify The Engineer · 9 / 17
The alternative to the monster file. AGENTS.md answers three questions: where am I, how do I work here, what should I read next. Then it routes.
Architecture? Read ARCHITECTURE.md. Touching inventory? Read context/inventory.md. Production incident? Use the incident-investigation skill. Kafka schema change? Use that skill. Before implementing, write an execution plan. Before finishing, run ./scripts/verify.
This is progressive disclosure: only the information relevant to the current task enters attention. A fifty-line router beats a five-thousand-line encyclopedia every time.
OpenAI's own agent-first repository does this: architecture, execution plans, product specs, quality and security knowledge live as separate documents in the repo, and AGENTS.md points at them rather than containing them.
Prompt engineering asks what to say. Context engineering asks what the model should know right now.
The Engineer · 10 / 17
The one-line distinction.
Context engineering includes: repository navigation, selective retrieval, hierarchical instruction files, summaries, relevant excerpts, domain glossaries, architecture maps, known-weirdness documents, execution state, tool outputs, fresh context windows, subagent handoffs, compaction, progressive disclosure.
Notice how little of that is "wording". The quality of the question matters. The quality of the information environment matters more.
One technique worth naming explicitly because it's underused: fresh context on purpose. When a conversation has accumulated three wrong hypotheses and two abandoned approaches, that history is now attention pollution. Start over with a clean window and a one-paragraph summary. Compaction is forgetting on purpose, and forgetting on purpose is a skill.
Parallelize uncertainty, not dependency. main worktree-a find the simplest implementation worktree-b find the safest backward-compatible one worktree-c argue we shouldn't do this at all agent D: compare complexity · risk · blast radius The Engineer · 11 / 17
For difficult tasks, exploit parallelism, but be precise about what to parallelize.
Best-of-N: Agent A finds the simplest implementation. Agent B finds the safest backward-compatible one. Agent C argues we shouldn't make the change at all. Agent D compares all three on complexity, correctness, migration risk, blast radius, maintenance cost, and recommends one.
Different agents search different hypothesis spaces. That's the value.
Good candidates for parallel agents: alternative architectures, independent root-cause hypotheses, security review, performance review, API design alternatives, migration strategies.
Bad candidate: five agents editing the same coupled state simultaneously. That isn't parallelism, that's a merge conflict with extra steps.
Parallelize uncertainty, not dependency. Demo 5 in the stretch list shows this live with three worktrees if we have time.
Branches isolate versions. Worktrees isolate workers. The Engineer · 12 / 17
Git worktrees used to be trivia. Now they're infrastructure.
Parallel machine workers need independent filesystems, independent build state, isolated dependencies, independent commits, controlled merge points. That is exactly what a worktree gives you: one repo, many checked-out directories, each with its own branch.
worktree-a: feature implementation. worktree-b: regression tests. worktree-c: dependency upgrade. worktree-d: bug investigation. Four agents, zero stepping on each other.
Cursor and Codex both expose worktree-based agent workflows now; the starter kit includes a spawn-agent.sh that creates a worktree, boots the env, and launches an agent with a task contract. It's twenty lines. Steal it.
Live demo · Three agents, three worktrees
Parallelize uncertainty. Watch it happen. licious — worktree swarm
click to spawn three worktrees ▌
The Engineer · 13 / 17
Two ways to run this. The on-slide simulation (click to spawn, click again for agent D) is the fallback and the recap. The real thing is a terminal.
Live version. In the repo there is demos/worktree-swarm.sh. It creates a throwaway git repo with a tiny inventory selector, then three worktrees on three branches. Run it and show:
git worktree list: three directories, three branches, one .git. In three terminal panes, cd into each worktree and start an agent with the same task contract but a different objective: simplest, safest and backward-compatible, and "argue we shouldn't do this". While they run, point at the isolation: separate working trees, separate dependencies, separate test runs, no stepping on each other. Branches isolate versions; worktrees isolate workers. When they finish, start a fourth agent in the main checkout: "Compare the three branches fefo/simplest, fefo/safest, fefo/challenge on complexity, correctness, migration risk, blast radius, maintenance cost. Recommend one." The verdict on the slide is what a good agent D produces: B, behind a flag, rolled out to one warehouse, using C's evidence for the rollout plan.
Line to land: parallelize uncertainty, not dependency. Three agents explored three hypotheses. Zero merge conflicts, because nobody parallelised the same file.
Cleanup: git worktree remove each fefo directory, or delete the scratch directory the script created.
Never let the builder self-certify. BUILDER implements the change ATTACKER 'your job is to break this' TEST CRITIC 'what is still untested?' every arrow is a fresh context window diff findings gaps → repair The Engineer · 14 / 17
Core principle: never let the agent that wrote the code be the only entity deciding whether the code is correct.
The loop: builder implements. Attacker, in a fresh context with a different objective, tries to break it. Test critic, also fresh, reviews only the tests and asks what behaviour is still untested. Builder repairs. Independent verification runs.
Why fresh context matters: the builder's window is full of its own reasoning, its own assumptions, its own confidence. It will grade its own homework generously, not because it's dishonest, because it's anchored. A fresh window has no anchor.
Reviewer prompt you can copy: "Your job is to break this change. Look for concurrency, backward compatibility, stale state, idempotency, timestamp edge cases, race conditions, missing tests, implicit behaviour changes."
Meta is pushing testing this direction with just-in-time LLM-generated tests aimed specifically at catching regressions from an individual change.
The cheapest reviewer in the building is another fresh context window. It augments human review. It does not replace judgment.
The Engineer · 15 / 17
Say the caveat out loud and mean it: this augments human review, it does not automatically eliminate it for high-risk changes. A fresh-context reviewer catches the mechanical stuff so the human reviewer can spend attention on the judgment stuff: is this the right change, does it belong in this system, what does it do to the roadmap.
Also the honest version: a fresh-context attacker will find real bugs in AI-generated code at a rate that should make everyone slightly uncomfortable. That's good. Better to be uncomfortable in review than in production.
Segue to Demo 2.
Demo 2 · Adversarial development
“Your job is to break this change.” Builder → attacker → test critic → builder.
The Engineer · 16 / 17
Setup : Agent A has already implemented FEFO inventory selection (either live from Demo 1 attempt C, or pre-staged). Time-box: 12 minutes. This one should be theatrical.
Step 1. Do not ask Agent A whether it works. Open a new session, fresh context. Paste the diff. Prompt: "Your job is to break this change. Look for edge cases, backward compatibility, concurrency, idempotency, stale inventory, timestamp weirdness, race conditions."
Agent B finds something. It almost always does. In the staged version there's a planted issue: two SKUs with the same expiry date and no deterministic tiebreak, which makes reservation non-idempotent under retry.
Step 2. Agent C, fresh context: "Review only the tests. What behaviour is still untested?" It will notice there's no test for equal expiry dates, none for an expired batch appearing mid-reservation.
Step 3. Back to Agent A: "Here are the findings. Fix them and add the missing tests."
Draw the loop on the whiteboard: builder → attacker → test critic → builder.
Landing line: the cheapest reviewer in the building is another fresh context window. Then the caveat, again: augments, doesn't replace.
Fallback: pre-recorded transcripts of B and C.
You can now start more work than you can inspect. Attention is the new bottleneck. Delegation without verification is optimism with a budget.
The Engineer · 17 / 17
Thought experiment: one engineer, eight hours of attention. Agent A produces four hours of work. B six. C three. D seven. E two. Twenty-two hours of machine output against eight hours of human attention.
The scarce commodity is now human attention. The engineer's value shifts toward deciding: which tasks deserve inspection, which need an independent reviewer, what should be tested, what can be delegated, what should be ignored, where uncertainty is highest, where blast radius is largest.
New productivity question: how much human attention is required per shipped unit of value? That will turn out to be a far better metric than code volume, and we'll come back to it in Act V.
Second line on the slide is mine and I stand by it: delegation without verification is optimism with a budget. If you spin up five agents and can't verify any of them, you haven't parallelised work, you've parallelised risk.
Break after this slide. Ten minutes.
Act III
The Repository Your code now has two readers.
Opening The Shift The Engineer The Repository The SDLC The Organization Closing
The Repository · 1 / 19
Act III, about 40 minutes with two demos and one exercise. Goal: show that repositories need to evolve.
Topics: the repo as interface, agent legibility, brownfield, context complexity, the context architecture, Skills, tools, invariants, verification surface, readiness scorecard.
Demo 3 (context surgery) after the context architecture slide. Demo 4 (build a Skill live) after the Skills slides. Exercise 1 (score your repo) at the end.
The repo is the prompt. Your repository now has two readers: humans and agents.
The Repository · 2 / 19
Intentionally provocative. It does not mean dump the repo into a context window. It means the repository itself is becoming an interface consumed by both humans and agents.
Historically repos were optimised for compilers, runtimes, version control, and human maintainers. Now there's a second reader, and it needs to discover: how the system is structured, where to start, how to boot it, how to test it, what terms mean, what boundaries exist, what invariants matter, how production is observed, what changes are dangerous.
That is agent legibility. And the uncomfortable principle: software that is understandable by humans is not automatically understandable by agents. Humans have a Slack history and a colleague at the next desk. The agent has the repo.
If it isn't in the repo, it doesn't exist. A Slack thread from 2024 isn't context. It's folklore.
The Repository · 3 / 19
Agents can reason only about what they can see and interact with. If a crucial fact lives only in somebody's memory, a Slack thread from eighteen months ago, an undocumented Grafana dashboard, a hidden release ritual, or a tribal debugging incantation, then for the agent that fact does not exist.
This has an uncomfortable consequence: every piece of tribal knowledge is now a bug in your agent's environment. Not metaphorically. Literally. It will produce wrong output at exactly the point where the folklore mattered.
The fix isn't "write everything down". It's: write down the non-obvious, in the place where a reader would look for it, in a form a machine can route to. That's the context architecture coming in three slides.
Brownfield is archaeology with a pager. The Repository · 4 / 19
Why AI looks magical on greenfield and mortal on your actual codebase.
A small repo has one dominant architecture, few dependencies, low historical baggage, conventional patterns, clear naming. Much of it fits in effective context. Clear requirement plus good acceptance criteria gives a good implementation. That's where vibe coding shines.
A mature enterprise codebase is not a bigger small codebase. It has history: many services, multiple languages, legacy and modern frameworks side by side, seven ways of doing caching, multiple API generations, hidden compatibility requirements, historical migrations, security constraints, incident history, business-specific invariants.
The question is no longer "does the model know Java". It's can the agent find the correct 0.01 percent of organisational knowledge for this task?
Archaeology, with a pager, because the thing you dig up is also on call.
At scale, coding is a search problem before it's a coding problem. Can the agent find the right 0.01% of what your company knows?
The Repository · 5 / 19
State it as an engineering claim: at scale, AI coding becomes a retrieval, navigation, and context-selection problem before it becomes a code-generation problem.
That means the levers are retrieval levers: a repository map, a domain glossary, ownership metadata, architectural boundaries, a known-weirdness file, and skills that know where to look for a given class of problem.
If your reaction to "the agent got it wrong" is "the model isn't smart enough", you're usually wrong. It didn't find the thing. Ask what it would have needed to find, and put that in the repo.
Time complexity. Space complexity. Context complexity. How much of the system must be understood to safely change one behaviour?
svc A svc B DB cron Kafka util svc C to change one thing, understand everything interface impl to change one thing, understand one boundary CONTEXT COMPLEXITY: HIGH CONTEXT COMPLEXITY: LOW The Repository · 6 / 19
A new abstraction for the toolbox. Traditional CS gave us time complexity and space complexity. AI-native engineering needs context complexity : how much of the system must an agent understand before it can safely modify one behaviour?
Left side: to change one thing you must reason about service A, service B, the DB, a cron, Kafka, a shared util, and service C. Huge context requirement for a local change.
Right side: a public interface with a small implementation boundary. The agent changes behaviour without understanding the whole company.
Historically, abstraction reduced human cognitive load. Now abstraction also reduces machine context load . Good architecture just got a second customer, and that customer pays per token.
Good architecture just got a new customer. Abstraction now reduces machine context load, not just human cognitive load.
The Repository · 7 / 19
This is the slide that should make architects in the room sit up, because it gives architecture a new economic argument.
For twenty years the case for modularity was "humans can't hold it all in their heads". That argument was always a little soft; you could hire people with bigger heads. The new argument is hard: a low-context-complexity system lets an agent do safe work with a small window, which is faster, cheaper, and more reliable, on every single task, forever.
So a service boundary is now a context boundary. A clean interface is now a prompt-size optimisation. Every refactor that shrinks the blast radius of a change also shrinks the context an agent needs to make it. Architecture is now a per-task cost line.
Seven small files beat one giant one. AGENTS.md Where am I? How do I work here? What do I read next? ARCHITECTURE.md What are the components and the boundaries? context/domain-map.md What do reservation, allocation, fulfilment actually mean here? context/invariants.md What must never become false? context/known-weirdness.md What looks wrong but exists for a reason? runbooks/ How do we execute known procedures? skills/ How do we solve recurring classes of problems?
The Repository · 8 / 19
The practical context architecture. Seven files, each answering one question, each small.
AGENTS.md routes. Where am I, how do I work here, what do I read next.ARCHITECTURE.md : components and boundaries.context/domain-map.md : what reservation, allocation, fulfilment mean here, specifically. Licious vocabulary.context/invariants.md : what must never become false.context/known-weirdness.md : things that look wrong but exist for a reason. This file alone prevents a category of confident, well-intentioned, catastrophic agent refactors.runbooks/ : how we execute known procedures.skills/ : how we solve recurring classes of problems.Not one giant instruction blob. A shape. And every file in this shape is also useful to the next human you hire, which is how you'll get people to maintain it.
Segue into Demo 3, where we measure the difference these files make.
Demo 3 · Context surgery
More context is not better. Better context is better. Three short files. Count the tool calls.
before · bare repo click to run
“Explain how order cancellation works.”
after · three small files click to run
+ ARCHITECTURE.md · domain-map.md · known-weirdness.md (≈150 lines)
The Repository · 9 / 19
On-slide simulation : click the left card to "run" the bare-repo attempt and watch the counters climb. Click the right card for the post-surgery run. Use it as the recap after the live run, or as the whole demo if the live one misbehaves.
Setup : an unfamiliar repo the agent has never seen, with a moderately tangled order-cancellation flow. Time-box: 10 minutes.
Run 1. Fresh context. "Explain how order cancellation works." Watch it search around. Count tool calls, files opened, wrong assumptions, time to a useful answer. Narrate the wandering.
Surgery. Add three concise files: ARCHITECTURE.md, context/domain-map.md, context/known-weirdness.md. Not huge. Maybe 150 lines total. The known-weirdness file explains the one thing that looks like a bug and isn't (say, cancellations after dispatch that still succeed because of the cold-chain return path).
Run 2. Fresh context. Same question. Compare: tool calls, files opened, wrong assumptions, time to a useful plan.
Then the evidence slide, verbally: Meta's navigation documents for huge data pipelines and the roughly 40 percent fewer tool calls result. What you just saw on a toy repo is what they measured at hyperscale.
Landing line: more context is not better. Better context is better. And: context is attention, now made visible instead of philosophical.
A prompt is disposable. A Skill is institutional memory. The Repository · 10 / 19
Skills. Shallow description: a reusable package of instructions and resources an agent loads when needed. Deeper description: organisational knowledge compiled into software.
A Skill captures how experienced people solve a recurring class of problem. It can contain instructions, checklists, examples, scripts, queries, templates, validation logic, links to relevant context, failure modes, rollback steps.
Anthropic describes Skills as folders combining instructions, scripts, and resources. OpenAI describes them as reusable workflows containing instructions, resources, and potentially code. Same idea from both sides.
The phrase to keep: a prompt is disposable, a Skill is institutional memory. When the engineer who knew how to do a Kafka schema migration leaves, the prompt leaves with them. The Skill stays in the repo.
Skills without tools produce consultants. Skills plus tools produce engineers.
The Repository · 12 / 19
Land this one hard, it always gets a reaction.
A Skill with no tools can tell you what a senior engineer would do. It cannot do it. It writes a beautiful investigation plan and then asks you to go run the queries. That's a consultant.
Give it query_metrics, query_logs, search_code, git_diff, get_recent_deployments, and now it runs the investigation. That's an engineer.
This is why the starter kit has a sibling concept, licious-agent-tools: a small library of well-typed, deterministic, auditable, permission-aware, read-only-by-default internal tools. Service catalog, owners, deployments, logs, metrics, traces, feature flags, Kafka schemas, runbooks, incident history, DB schemas, recent PRs. The model gets a rich environment without raw unrestricted access.
Demo 4 · Build a Skill live
We just turned how a senior engineer thinks into infrastructure. Runbook in. Skill out. Incident triggered. Watch it follow the process.
The Repository · 13 / 19
Setup : a plain-English incident-investigation runbook, nine steps, the kind that lives in a wiki. Time-box: 12 minutes.
Steps: identify deployment window, inspect latency and error graphs, correlate affected endpoints, inspect traces, compare deployment diff, form hypothesis, reproduce, create regression test, propose smallest fix.
Step 1. Paste the runbook. "Turn this process into a reusable Agent Skill. Include a SKILL.md, a checklist, and the queries as files." Show the generated folder: SKILL.md, queries/, checklist.md, examples/.
Step 2. Trigger a mock incident in the sandbox: "Checkout latency jumped after today's deployment. Investigate." The agent should discover the skill and follow it, step by step, without being told to.
Step 3. Point at the transcript. Deployment window, graphs, traces, diff, hypothesis. It's the runbook, executing.
Landing line: we just turned how an experienced engineer thinks into infrastructure.
Then the deeper point: skills can contain executable artifacts, not just English. A Kafka schema skill ships a compatibility-check script. A DB migration skill ships a locking guide and a rollback template. That is engineering culture, made executable.
Fallback: pre-generated skill folder plus a recorded incident transcript.
Instructions ask agents to behave. Invariants make bad behaviour impossible. inventory:
- stock_count_must_never_be_negative
- reservation_must_be_idempotent
- expired_inventory_must_never_be_allocated
orders:
- payment_capture_must_not_happen_twice
- cancelled_orders_cannot_become_dispatched
events:
- existing_consumers_must_survive_schema_evolution
services:
- domain_layer_cannot_depend_on_transport_layer each one becomes →
a unit test
a property test
a contract test
an architecture test
a custom linter
a reviewer instruction
an eval criterion
and stops being
a Slack message The Repository · 14 / 19
Organisations document implementations: "use Kafka this way". AI-native systems should also encode what must always remain true , regardless of implementation.
Read two or three off the slide. Stock count never negative. Reservation idempotent. Expired inventory never allocated. Payment capture never twice. Cancelled orders can't become dispatched. Existing consumers survive schema evolution. Domain layer can't depend on transport.
Then the right column: each invariant becomes a unit test, a property test, a contract test, an architecture test, a custom linter, a reviewer instruction, an eval criterion. And it stops being a Slack message.
OpenAI's harness team said this outright: they stopped micromanaging implementations and instead encoded architectural and taste invariants, mechanically enforcing dependency directions, logging requirements, naming rules.
Instructions ask agents to behave. Invariants make bad behaviour impossible. Prefer the second whenever you can get it.
Generation got cheap. Evidence got expensive. The Repository · 15 / 19
One of the most important shifts in the whole talk, and it's one sentence.
If one engineer can create ten times the change volume, then somebody or something must verify ten times the change volume. There is no escaping that arithmetic.
Therefore tests, type systems, schema checks, static analysis, contract tests, property tests, browser automation, performance assertions, telemetry, canaries, rollback mechanisms all become more valuable, not less. Anyone who tells you AI makes testing less important has the sign wrong.
The corollary for this room: the highest-leverage thing a senior engineer can build in 2026 is often not a feature. It's a verifier.
Safe autonomy ∝ verification surface. How much of an agent's work can the machine independently prove correct?
SYSTEM A "looks plausible" a human reviews everything verification surface: tiny SYSTEM B types unit tests property tests contracts architecture checks integration env browser / e2e production metrics verification surface: huge → autonomy can be huge The Repository · 16 / 19
A second new concept for the toolbox: verification surface . How much of an agent's work can the machine independently prove correct?
System A: agent writes code, it looks plausible, a human reviews everything. Verification surface is tiny. Every unit of autonomy costs a unit of human attention.
System B: types, unit tests, property tests, contracts, architecture checks, an integration environment, browser and e2e, production metrics. Verification surface is huge.
The relationship: safe agent autonomy is proportional to verification surface. The larger the surface, the more work can happen without continuous human supervision, safely.
So when someone asks "how much should we let agents do?", the right answer is "how much can we verify?". Not a policy question. An engineering question. Build the surface, then widen the autonomy. Never the other order.
A flaky test used to annoy one engineer. Now it lies to fifty agents.
The Repository · 17 / 19
This one is mine and I feel strongly about it. It's the amplifier principle applied to verification.
In the old world a flaky test was a nuisance. Someone re-ran CI, muttered, moved on. In the agent world your test suite is the primary signal an autonomous worker uses to decide whether it is done. A flaky test is now a liar in the loop. It will cause agents to "fix" things that aren't broken and ship things that are.
Same for slow tests: a forty-minute suite used to cost one engineer a coffee break. Now it caps how many iterations every agent can afford.
Practical: fix flakiness and speed in the verify path before you scale agents. It's the cheapest autonomy you'll ever buy.
Before asking whether Codex is good at your repo, ask whether your repo is good at Codex. Bootability
Testability
Legibility
Observability
Documentation
Determinism
Safety
Isolation
Skills
Invariants
agent readiness: 17 / 30
tap the dots to score your own repo
The Repository · 18 / 19
The Agent Readiness Scorecard. One-page takeaway. Rate every repository 0 to 3 on ten dimensions:
Bootability : can an agent boot this project unattended?Testability : can it determine whether a change works?Legibility : can it understand the architecture quickly?Observability : can it access logs, metrics, traces?Documentation : is non-obvious knowledge discoverable?Determinism : are setup, build, test commands predictable?Safety : are dangerous operations constrained?Isolation : can agents operate in worktrees or sandboxes?Skills : are repeated procedures encoded?Invariants : are important rules mechanically checked?Score out of 30. The example on screen is 17, which is a very normal, very honest score for a real service.
This turns an abstract idea into an organisational programme: pick the lowest-scoring dimension on your most important repo and fix it this sprint. It also gives you a before-and-after number, which matters when someone asks whether the AI investment worked.
Exercise 1 · 8 minutes
Score your repo. Ten dimensions. Zero to three each. Be honest. Nobody's watching. (I'm watching.)
The Repository · 19 / 19
Eight minutes. Everyone picks the repo they touched most recently and scores it on the ten dimensions. Scorecard is in the kit under scorecard/agent-readiness.md; the QR is on the last slide, or just do it on paper.
Then, in pairs, thirty seconds each: what's your lowest-scoring dimension, and what's the smallest thing you could do this week to raise it by one point?
Collect a few out loud. You'll hear "Skills: zero" a lot and "Documentation: one" a lot. That's fine. That's the roadmap.
Point to make when you wrap up: the scores are usually lowest on the dimensions that are cheapest to fix. An AGENTS.md router and a working ./scripts/verify can move a repo from 12 to 18 in an afternoon.
Act IV
The SDLC The lifecycle becomes machine-executable.
Opening The Shift The Engineer The Repository The SDLC The Organization Closing
The SDLC · 1 / 8
Act IV, about 15 minutes. Goal: show end-to-end machine participation using one realistic Licious scenario.
This is the act to compress if we're behind. The stretch demo is optional. The three concept slides (pipeline, reason once, corrections) are not.
AI-native ≠ coding assistant. It's the whole lifecycle, with humans placed where judgment lives.
incident reproduce diagnose regression test fix adversarial review CI deploy observe human attention lands on judgment, not typing The SDLC · 2 / 8
Weak AI interaction: "here's some SQL you could optimise." AI-native environment for a latency incident: inspect recent deployments, compare traces before and after, query Grafana, correlate slow endpoints, inspect DB query changes, reproduce locally, propose a hypothesis, write a regression test, implement the smallest fix, benchmark, open a PR, adversarial review, CI, deploy, observe.
The agent is operating across the lifecycle, not generating code. That's the difference between a coding assistant and an engineering agent.
Notice where human attention lands on the diagram: at the hypothesis, at the review, at the deploy decision. Judgment points. Not typing points.
Meta's efficiency agents already do a close cousin of this, combining profiling, configuration, and code tools with expert Skills to find regressions and take them to ready-to-review fixes.
Stretch demo · Incident to PR
p95 went from 180 ms to 1.8 s after release 8271. Investigate. Metrics → trace → query → diff → hypothesis → regression test → fix → PR.
The SDLC · 3 / 8
Only if we have time. Prepare it reliably or don't do it live.
Setup : synthetic Grafana metrics, logs, traces, and a git history in a sandbox. Scenario: after release 8271, inventory-reservation p95 goes from 180 ms to 1.8 s. Agent has query_metrics, query_logs, search_code, git_log, and the performance-regression skill.
Prompt is one line: "Investigate the latency regression."
Ideal flow: metrics show the endpoint, trace shows the slow span, span points at a DB query, git log shows the commit that dropped an index hint or added an N+1, hypothesis, a regression test that fails, the fix, a benchmark showing p95 back to 180, a PR with all of it as evidence.
This is where the room understands that AI-native is not a coding assistant. It is the entire SDLC.
Fallback: play a recorded transcript at 2× and narrate.
Reason once. Automate forever. Repeated model reasoning should become deterministic software.
The SDLC · 4 / 8
A subtle one, and one of the deepest in the deck.
If an agent repeatedly does grep, jq, curl, awk in the same pattern, tell it: "You've done this workflow several times. Build a deterministic script for it and update the relevant Skill to use that script." Now future agents call a tool instead of re-deriving the procedure. The loop: LLM reasoning → repeated operation → deterministic tool → every future agent uses it.
Why this matters: an AI-native system should gradually convert repeated model reasoning into deterministic software. Determinism is cheaper, faster, testable, auditable. The model's job is to discover the procedure once; the codebase's job is to keep it.
This is also how the tools repo grows: not from a platform team guessing what agents need, but from agents noticing what they keep doing.
Corrections should not disappear into chat history. Every expensive mistake should become a cheap future test.
The SDLC · 5 / 8
The self-improving engineering system, in one loop.
Agent makes a bad migration. Engineer corrects it. Old world: the correction lives in one chat window and evaporates. AI-native world: capture the regression case, add an eval, update the db-migration skill or the invariant, rerun the eval, and every future agent stops making that mistake.
Corrections should not disappear into chat history. Every expensive mistake should become a cheap future test.
OpenAI does variants of this: practitioner corrections become traces and evals, which become targets for systematic improvement. For an engineering org it means: AI creates a bad migration → engineer explains why → migration eval added → db-migration skill updated → every engineer and every agent benefits. That's organisational compounding, and it's the bridge into Act V.
4× code generation + 1× review = a very sophisticated queue. code generation 4× code review 1× CI 1× QA 1× deployment 1× ← everything piles up here The SDLC · 6 / 8
Queueing theory, briefly, because it's the failure mode every organisation walks into.
Code generation becomes four times faster. Review, CI, QA, and deployment stay at one. The organisation does not become four times faster. It creates a queue, and the queue sits exactly where the diagram shows it: in front of review.
Licious version: a cutting line that gets ten times faster does not make the plant ten times faster if packaging still runs at the old rate. It makes a pile.
Principle: don't accelerate the coder. Accelerate the SDLC. This is why agentic CI, fresh-context reviewers, and a large verification surface matter: they're the only way review scales with generation.
Don't accelerate the coder. Accelerate the SDLC. The SDLC · 7 / 8
Say it once more, alone on a black slide, and move on. The whole talk in seven words.
If a team asks "which AI tool should we buy", the better question is "which stage of our lifecycle is the slowest, and what would it take for a machine to participate there?"
Nobody was ever promoted for lines of code. Now nobody will be hired for them either. Measure attention-minutes per shipped change.
The SDLC · 8 / 8
As generation gets cheaper, output metrics become actively misleading: lines of code, commits, PR count, files changed, code generated. All of them go up when you deploy agents, whether or not anything got better.
Better metrics: idea-to-production time, PR cycle time, review wait time, rollback rate, escaped defect rate, MTTR, deployment success rate, time on toil, human-attention minutes per shipped change , and percentage of work independently machine-verified.
Frame: do not measure the speed of the station. Measure the flow of value through the factory.
The attention-minutes metric is the one I'd pick if I could only have one, because it goes down when the harness improves and goes up when you've just created a queue. It's honest.
Act V
The Organization Compounding judgment into infrastructure.
Opening The Shift The Engineer The Repository The SDLC The Organization Closing
The Organization · 1 / 11
Act V, about 20 minutes plus Exercise 2. Goal: move from individual leverage to institutional leverage.
Topics: autonomy as a dial, the autonomy matrix, garbage-collection agents, Agent Capital, evals, the new senior engineer, the four layers, the starter kit, anti-patterns.
Autonomy is a dial, not a switch. explain suggest edit files run tests commit open PR merge low-risk deploy respond to prod earn the next notch with evidence The Organization · 2 / 11
The shallow debate is "should we trust agents". The useful framework is a dial.
Level 0 explain. 1 suggest. 2 modify local files. 3 execute tests. 4 commit. 5 open PR. 6 merge low-risk PR. 7 deploy. 8 respond to production.
Different actions require different levels of evidence. You earn the next notch on the dial by widening the verification surface for that class of action. Autonomy is earned through verification. Not granted by policy, not withheld by fear. Earned.
Most teams should sit at "open PR" today for most repos, and that's fine. The point is that "open PR" is a position on a dial, not a permanent state.
Autonomy is earned through verification. Risk × verification strength × reversibility × blast radius.
default · no approval
read source ✓
search docs ✓
run unit tests ✓
modify worktree ✓
create commit ✓
open PR ✓
query prod metrics ✓ read-only
bounded · audited · gated
merge PR ⚠ approval
modify feature flag ⚠ approval
production deployment ⚠ approval
execute DB migration ✗ never
access secrets ✗ never
production write ✗ never
The Organization · 3 / 11
The concrete organisational artifact: the Autonomy Matrix. In the kit under autonomy/permissions.md.
Default, no approval: read source, search docs, run unit tests, modify the worktree, create commits, open PRs, query production metrics read-only.
Approval required: merge PR, modify a feature flag, production deployment.
Forbidden: execute a DB migration, access secrets, production writes.
The risk model behind it: action risk times verification strength times reversibility times blast radius. Low risk, well verified, reversible, small blast radius: automate it. Any of those goes bad: put a human at the gate.
This is exactly OpenAI's internal Codex governance principle: low-risk operations stay frictionless, higher-risk capabilities are bounded and auditable. It gives the security and platform people in the room something concrete to own.
The same agents that generate entropy can collect it. Technical-debt garbage collection. Nightly.
The Organization · 4 / 11
Agents are extremely good at reproducing patterns, including bad ones: duplicate abstractions, slightly different utilities, inconsistent conventions, unnecessary wrappers, redundant comments, architectural drift. That's the "slop" problem.
OpenAI reported spending roughly 20 percent of a week manually cleaning accumulated AI slop before switching approach: encode golden principles, then run recurring Codex cleanup tasks.
The idea: technical-debt garbage collection. Every night, an agent scans for architecture violations, duplicate utilities, deprecated APIs, missing tests, missing observability, unsafe patterns, and opens small cleanup PRs. Not a quarterly sprint. A nightly process.
Golden principles in the kit, seven of them: parse external data at boundaries, never invent payload shapes, prefer established shared utilities, async consumers must be idempotent, public schemas stay backward compatible, new business behaviour needs telemetry, domain code doesn't depend on transport. Those drive the linters, the architecture tests, the reviewer prompts, and the nightly GC.
Agent Capital. Knowledge that compounds instead of retiring.
time reusable knowledge knowledge in heads forgets, leaves, retires knowledge in skills · evals · invariants · tools every engineer + every agent run, forever 3 hours on a Kafka edge case The Organization · 5 / 11
Companies traditionally accumulate capital as code, libraries, platforms, documentation, data. An AI-native company additionally accumulates skills, evals, agent-readable context, tools, invariants, runbooks, successful trajectories, failure cases. Call that Agent Capital.
The example on the graph: an engineer spends three hours understanding a bizarre Kafka edge case. Old world, the knowledge goes into one head; it forgets, it leaves, it retires. Dashed line. AI-native world, it goes into a skill, an invariant, an eval, a context file, and every future engineer plus every future agent run benefits, forever. Solid line.
The organisational question becomes: how much of today's expensive human reasoning becomes tomorrow's reusable agent capital? If the answer is "none, it's all in Slack", you're spending capital, not building it.
Build your own SWE-Bench from your own engineering history. Stop answering “is it better?” with vibes.
licious-agent-evals/
├── inventory/
│ ├── negative-stock/
│ ├── duplicate-reservation/
│ └── expired-product/
├── payments/
│ ├── retry-idempotency/
│ └── duplicate-capture/
├── events/
│ └── backward-compatible-schema/
└── architecture/
├── forbidden-dependency/
└── service-boundary/ each case:
task
expected invariants
expected subsystems touched
forbidden behaviours
tests
scoring rubric
then compare, with numbers:
harness A vs harness B
skill v1 vs skill v2
huge AGENTS.md vs router AGENTS.md
model X vs model Y The Organization · 6 / 11
Eventually somebody senior will ask: "Is our new Codex setup actually better?" Right now every team on earth answers that with vibes.
Instead: take 20 to 50 real historical engineering tasks, strip sensitive details, and for each one store the task, expected invariants, expected subsystems touched, forbidden behaviours, tests, and a scoring rubric. That's an eval.
Then compare, with numbers: harness A versus harness B, skill v1 versus v2, huge AGENTS.md versus router AGENTS.md, model X versus model Y.
Now Licious has its own SWE-Bench, on the problems Licious actually cares about, and the AI platform team has something concrete to build and something concrete to be judged by. It also closes the loop from the corrections slide: every expensive mistake becomes an eval case here.
The senior engineer stops scaling hands. They start scaling judgment.
OLD LEVERAGE senior engineer a good abstraction 100 engineers benefit AI-NATIVE LEVERAGE senior engineer invariant · skill · tool · eval 100 engineers + 10,000 agent runs The Organization · 7 / 11
"Senior engineers will just write better prompts" is far too weak a story.
The new senior engineer becomes unusually valuable at: constraints (what must never happen), decomposition (what can be solved independently), interfaces (which boundaries minimise context), verification (what evidence proves this works), context (what does the agent actually need), risk (how much autonomy is justified), and taste (which technically valid solution belongs in this system).
Old leverage: senior writes a good abstraction, 100 engineers benefit. AI-native leverage: senior encodes a good invariant, skill, tool, or test, and 100 engineers plus 10,000 agent runs benefit.
AI makes engineering judgment more valuable precisely because implementation becomes cheaper. That's not a consolation. That's the job description.
Where the transformation actually happens. ORG agent-skills · agent-evals · agent-tools TEAM task contracts · golden principles · autonomy matrix REPO AGENTS.md · ARCHITECTURE.md · invariants · runbooks · verify ENGINEER plan · delegate · verify · critique · parallelize The Organization · 8 / 11
The map that ties the talk together. Four layers, each with its own artifacts.
Org : agent-skills, agent-evals, agent-tools. Shared across every team.Team : task contracts, golden principles, the autonomy matrix. How a team delegates and governs.Repo : AGENTS.md, ARCHITECTURE.md, invariants, runbooks, a verify script. What makes one codebase legible.Engineer : plan, delegate, verify, critique, parallelise. What you do with your hands on Monday.Point: AI-native transformation is not an individual productivity technique. It happens at all four layers, and the bottom layer is the only one you can do alone. The other three need the room.
Every idea in this talk maps to something you can clone tonight. ai-native-engineering-kit/
├── AGENTS.md
├── ARCHITECTURE.md
├── GOLDEN_PRINCIPLES.md
│
├── context/
│ ├── domain-map.md
│ ├── invariants.md
│ ├── glossary.md
│ └── known-weirdness.md
│
├── task-contracts/
│ ├── feature.md
│ ├── bug.md
│ ├── migration.md
│ └── incident.md ├── skills/
│ ├── incident-investigation/
│ ├── kafka-schema-change/
│ ├── service-extraction/
│ ├── database-migration/
│ ├── production-readiness/
│ └── performance-regression/
│
├── evals/
│ ├── inventory/
│ ├── payments/
│ ├── events/
│ └── architecture/
│
├── runbooks/
│ ├── deployment.md
│ └── rollback.md ├── agentic-ci/
│ ├── review-change.md
│ ├── find-test-gaps.md
│ └── architecture-guardian.md
│
├── worktrees/
│ └── spawn-agent.sh
│
├── autonomy/
│ └── permissions.md
│
├── scorecard/
│ └── agent-readiness.md
│
└── labs/
├── 01-bad-prompt/
├── 04-build-a-skill/
└── 07-adversarial-review/ The Organization · 9 / 11
The starter kit. This is roughly what the .gitignore moment for AI engineering looks like: every serious repository will eventually contain some version of these primitives.
Map the philosophy to the artifact, fast:
Context is attention → context/ architecture and a router AGENTS.md. Skills are executable culture → skills/. Autonomy is earned → autonomy/permissions.md. Agents create entropy → GOLDEN_PRINCIPLES.md plus agentic-ci/. Never self-certify → evals/ plus the adversarial reviewer in agentic-ci/. Repo is the prompt → scorecard/agent-readiness.md. Model ≠ Agent → the whole kit is the harness. Senior engineers scale judgment → skills, invariants, evals. Reason once, automate forever → tools and the scripts inside skills. And labs/: a dojo. Ten exercises with a starter repo, a broken state, a challenge, and a solution. Build a Skill from a runbook. Navigate a brownfield repo with a hidden invariant. Catch three planted bugs in an AI-generated PR with an adversarial loop. The session continues after the session.
Exercise 2 · 8 minutes
Write a Task Contract for the last ticket you closed. Then notice which section you couldn't fill in. That's where the bug was.
The Organization · 10 / 11
Eight minutes. Everyone takes the last real ticket they shipped and writes the task contract for it, retroactively. Template in task-contracts/feature.md, or just the headings on a napkin.
The interesting part is not the writing. It's the section they can't fill. Usually it's Invariants, or Verification, or Rollback. Say it out loud: the section you couldn't fill in is where the incident would have come from.
Collect two or three. Ask: if you'd had this contract before you started, would the agent have needed you at all for the implementation? Most people say "for the contract, yes; for the code, no." That's the whole talk in one answer.
Ten ways to fail at this. "Everyone has Codex, so we're AI-native."
Dumping every document into context.
The 40,000-token AGENTS.md.
Letting the builder grade its own work.
Counting PRs and calling it productivity.
Infinite parallel agents, zero decomposition.
Full autonomy with no verification surface.
Letting agents drift the architecture, unopposed.
Re-solving the same problem in chat every week.
Corrections that die in chat history.
The Organization · 11 / 11
Quick tour, one line each, because a sophisticated session names its own failure modes.
1. Tool access is not transformation.
If you only remember three: don't litter the context, don't let the builder grade itself, don't measure typing.
The question keeps changing. 2023 How much code can you write? 2024 How much code can AI help you write? 2025 How much work can you delegate? 2026 How well can you design a system where humans and agents build together?
Closing · 1 / 3
The close, in four questions.
2023: how much code can you write? 2024: how much code can AI help you write? 2025: how much work can you delegate? 2026: how well can you design a system in which humans and agents build together?
Each question makes the previous one look small. Nobody in this room will be evaluated on the 2023 question again.
The best AI-native engineer won't write the best prompts. They'll build the best environment for intelligence to operate inside.
Closing · 2 / 3
Individual version of the thesis.
And the organisational version, right after: the best AI-native company won't be the one with the most AI-generated code. It'll be the one that turns engineering judgment into compounding infrastructure.
The role of software engineering has always been tied to writing code, but code was only ever one representation of intent. As machine implementation gets capable, the human role concentrates on intent, abstraction, architecture, constraints, evaluation, risk, taste, product judgment. That doesn't make engineering less important. It makes the parts that were always hardest visible.
Thank you
From using AI to write software, Clone the kit. Score a repo. Write one contract. Build one skill. Then come find me.
Closing · 3 / 3
Last slide. The one-sentence transformation: from using AI to write software, to engineering software systems in which intelligence can operate.
Four asks for Monday, in order of effort:
Clone the kit. Score one repo on the readiness card. Write one task contract before your next delegation. Turn one runbook into one Skill. Then the seven-phase adoption blueprint if anyone asks how this scales: personal workflow → repo readiness → team skills → internal tools → agent evals → agentic CI → controlled autonomy. It's in the kit's README.
Leave the URL up during questions. Update the foot text with the real repo URL before the session.