The Quiet Dev's Kernel

Working subtitle: How I stopped prompting and started building an operating system.

One-Sentence Pitch

A 10-year Laravel developer who burned out shipping other people's dreams built a multi-LLM operating system kernel — and discovered that every hard problem in AI tooling already had a 50-year-old solution in computer science.

Persona

This is the triad, in your words. Hold it.

"The quiet dev that gets things done who decided to believe in himself and get things done for himself instead of other people."

Quiet. Decided to believe in himself. Gets things done — for himself now. That's the through-line. Not "AI pioneer." Not "10-year veteran." Not "systems builder." The persona is the arc. The room will have a lot of people who are quiet, who are good, and who haven't made the turn yet. You made it. That's the talk.

The Moment

Verbatim. Do not paraphrase this in the talk. Say it exactly.

"I realized how tired I was working for another person's dreams. It took a real step outside of comfort by dropping reliable contracting work in favor of spending time on the things that I cared about instead."

This is the emotional center of the talk. Everything before it is setup. Everything after it is consequence. The room will go quiet when you say this.

Thesis

BURIED REVEAL — do not put this in the CFP abstract. It lands at minute 28.

Stewart Brand, Whole Earth Catalog, 1968: "We are as gods, and might as well get good at it."

Your answer: build a kernel.

The OS metaphor is not a clever frame. It's a recognition that scheduling, memory management, IPC, and permissions are solved problems — solved by people who were just as overwhelmed by the complexity of coordinating work across unreliable, resource-constrained processes as you were. You don't have to reinvent the discipline. You port it to a probabilistic CPU.

The cosmology: Kevin Kelly took Brand's premise into the digital age. You're taking it one level further. We are as gods who now have probabilistic subagents. The question is not whether to use them. The question is whether to run them like a chat window or like an operating system.

You have the kernel. The talk is the manual.

The Arc

1. Cold open: the quiet dev

Open on tiredness. Ten years. The pattern. You've shipped a lot for a lot of people and you're good at it and that almost makes it worse — because being good at it means you kept getting more of it.

Do not mention AI. Do not mention Laravel. Do not mention kernels. Just the room and the recognition. Laracon is full of people who are exactly here right now and don't know yet that the talk is about them.

2. The moment

Say the words. Let them land. The room will realize you actually did it — you didn't just think about doing it.

This is the one place in the talk where you slow down and give the sentence its full weight. Don't rush past it toward the technical content. The technical content is downstream of this moment, not the other way around.

3. The naive attempt

Prompt engineering. Better CLAUDE.md files. Smarter sessions. More tabs open. This is where the room is right now — and you were here too. Be honest about it. You tried the productivity-hack path first, just like everyone in the audience.

This section earns trust. You're not positioning from above. You're describing a shared starting point before you tell them what you found next.

4. The reframe

"Wait. I've seen this problem."

The pivot lands here. It's not a chat assistant problem. It's an OS problem. Multi-session AI tooling is distributed, resource-constrained, concurrent, and needs scheduling, memory discipline, IPC, and access control. That's not new. That's 1970.

The room sits up. This is the moment where a talk about AI tooling becomes a talk about computer science, and the computer scientists in the room feel the frame click.

5. The mapping

Walk the OS table. This is eight minutes of small AHAs. Each row should feel like the room is recognizing something they already knew in a different register — not learning something new, but finally naming something they'd been fumbling around.

Go slow on the rows that land hardest: RAM as context window, scheduler as the two loops, the user as peripheral. Those are the three that will make people pull out their phones to screenshot.

The table is the centerpiece. Don't rush it.

6. The kernel

Live demo of ~/pm. Four to five minutes. Voice input, attention gate, the two loops running, an invention firing. This is the only part of the talk where something could go wrong — which is exactly why it needs a backup video. Record a clean run before you travel.

Show the actual system. Not a mockup, not slides describing it. The system. Quiet devs who get things done show the work.

7. What it earned

Concrete. One specific thing you shipped for yourself — downstream of having the kernel — that you wouldn't have shipped without it. Time back, compounding leverage, the thing you actually cared about.

This is the payoff section. The room has been patient through the OS theory. Give them the answer to "but what did it actually do for you."

8. The honest cost

You earn the room's trust here by not overselling it. In your words:

"It's not for everyone. Nitty gritty heads down developers who value full control might not want to use it."

Say exactly this. The room will trust everything else you said twice as much once you say this. No hype. No universal prescription. This works for a particular kind of developer who is ready for it.

9. The reveal

Last two minutes. Stewart Brand, 1968. The Whole Earth Catalog. Kevin Kelly picking up the thread in the nineties. Now you.

"We are as gods, and might as well get good at it."

The cosmology lands here — not as a grand claim, but as a lineage you're joining. Humans have always had to figure out what to do with tools that made them more powerful than they knew how to be. The OS is your answer: discipline the power with architecture.

You have the kernel. The question is whether you'll build one too.

10. The invitation

Build for yourself.

Not "use my tool." Not "here's a framework." Not "follow this methodology." Just: the same move that worked for you — believing in yourself enough to build for yourself — is available to everyone in that room. The talk ends where it started: the quiet dev, deciding.

Substrate: ~/pm Architecture

The OS mapping table is the centerpiece of section 5. Use it exactly as-is from ARCHITECTURE.md.

The OS Mapping Table

Four Properties That Distinguish a Multi-LLM OS

CPU is probabilistic, not deterministic. Context grooming replaces instruction correctness as the primary discipline. A well-groomed context produces reliably correct outputs. A stale or incoherent context produces plausible-looking failures with no error code.

Memory is coherence-limited, not size-limited. A small incoherent context behaves worse than a large coherent one. Compaction is GC plus checksumming: the compacted state must be semantically equivalent to what it replaces, or the next session starts from a corrupted image.

Forks cost real money. Spawning is not free. The scheduler weighs dollar-cost alongside latency. Spawning a throwaway Opus subagent for a one-liner is the equivalent of buying a new CPU to run ls.

The user is a peripheral, not the operator. Attention-gate, pm-say, camera, and voice treat you as I/O the OS schedules around. PM does not interrupt the user any more than the kernel interrupts a running process without cause.

Two Loops

Steering loop. Hold the through-line. Compass tells PM which projects are active and what each main goal is. When a session drifts, it steers back. New ideas get triaged: adopt, park, or drop. Runs once per conversation turn. Decisions write to files, not context.

Invention loop. Continuously sample the event stream and the on-disk state of each project. Pattern-match for latent capabilities: features the project almost has, capabilities that adjacent projects already built, data that's already being collected but not yet consumed. This is where the autonomous dev shop becomes self-improving. Without it, the shop only executes what is queued. With it, the shop finds what should be queued.

Three-Layer State Architecture

Layer 1: Compass. ~/pm/COMPASS.md. Always loaded at session start. Hard cap: 50 lines. One line per active project: name, current main goal in one sentence, pointer to its roadmap, last activity timestamp. If it grows past 50 lines, quiet projects get archived.

Layer 2: Per-project roadmap. Loaded on demand for the project currently being reasoned about. Dropped at end of pass. Never two roadmaps loaded simultaneously. Contains: main goal (one sentence), active phase, periphery (parked ideas + candidate inventions), recent events pointer.

Layer 3: Event stream. Sampled, never loaded whole. Append-only logs the watcher daemon writes: subagent spawned/completed, commits, file changes, session activity. PM queries a window. Never reads raw JSONL directly — the aggregator reads it so PM does not have to.

The Honest Cost

Say this. Verbatim. Do not soften it and do not strengthen it.

"It's not for everyone. Nitty gritty heads down developers who value full control might not want to use it."

This is the line that makes the rest of the talk credible. You're not selling something. You're describing something you built for yourself and inviting the people it fits to recognize themselves.

Format and Target

Primary target: Laracon US 2026 session slot (Boston, July 28–29). CFP is open NOW at https://lrvl.co/laracon-us-cfp. This is keynote-grade material played at session level — lets you debut the kernel material without needing keynote-level community visibility yet.

Longer arc: Laracon US 2028 or 2029 keynote, via the Aaron Francis path (~3 years of intentional public output).

Backup and parallel venues:

• Laravel Worldwide Meetup (this week, with a DIFFERENT shorter talk: "Keeping AI honest: hooks-driven TDD in Laravel" — 20 min)
• Longhorn PHP 2026 (CFP closes June 30)
• Laracon India 2027 (CFP open)

Runtime: 30 minutes. Section breakdown approximate: cold open + moment (4 min), naive attempt + reframe (4 min), OS mapping table (8 min), live demo (5 min), what it earned + honest cost (5 min), Brand reveal + invitation (4 min).

Demo requirement: Backup video of a clean ~/pm run required. Record before travel. The live demo is the highest-reward and highest-risk 5 minutes in the talk.

Open Questions for v2

1. Demo scripting. Which exact 4-5 minute ~/pm interaction do you script? Candidates: a full invention loop firing and writing to periphery; a steering intervention mid-session; the attention-gate doing a real interrupt suppression. Pick the one that shows all four OS properties in a single flow.

2. Opening 90 seconds. Draft this separately. It sets the room's expectation for the whole talk. Options: open on a specific day or a specific line of code you shipped for someone else. Or open on silence. The quiet dev's first move in a room of 800 people should be deliberate.

3. Section 7 concrete. What's the specific thing you shipped for yourself? ~/pm itself as the shipped thing is recursive and interesting — you built the kernel and the kernel is the deliverable. Or something downstream: a project pm helped you actually finish. Decide before you write the abstract.

4. Practice venue — LOCKED. Keynote-grade material debuts at Laracon US 2026 session slot (CFP open now). Parallel practice: Laravel Worldwide Meetup this week with a different, shorter talk ("Keeping AI honest: hooks-driven TDD in Laravel" — 20 min). The kernel talk's full 30-minute debut is at Laracon US 2026 session; longer arc targets 2028/2029 keynote slot via the Aaron Francis path.

5. CFP abstract. The one-sentence pitch above is the spine. The abstract deliberately omits the Brand thesis reveal (it's the closer, not the hook). Draft the abstract as: who you are, what you built, what the OS reframe unlocks for the audience, no cosmology. The thesis is the reward for being in the room.