Laracon US 2026 CFP Abstract — Options

These three abstracts submit for "The Quiet Dev's Kernel." The CFP committee skims for two things: a hook that earns the second sentence, and a concrete payoff that justifies a slot. Reviewers are pattern-matching against "yet another AI productivity talk" — every abstract avoids that category by centering the OS reframe and the personal arc. The Brand thesis is withheld; it's the reward for being in the room. Three angles are presented because the same talk can lead with different true things — pick the one that fits how you want to be known.

Angle A: Lead with the moment

Lead hook: "I realized how tired I was working for another person's dreams."

Ten years into a Laravel career, I was good at my job — and that almost made it worse. Being good at shipping for other people meant I kept getting more of it. So I made a real step outside of comfort: I dropped reliable contracting work in favor of spending time on the things I actually cared about.

That decision created a problem. I now had leverage — AI tooling, multiple Claude sessions, subagents running in parallel — and no system for wielding it. I tried the obvious things: better CLAUDE.md files, smarter prompt patterns, more tabs open. They helped a little. They didn't scale.

Then I recognized something. Multi-session AI tooling is distributed, resource-constrained, and concurrent. It needs scheduling, memory management, inter-process communication, and access control. That's not a new problem. That's an operating system. Solved — in broad outline — fifty years ago.

So I built one. Not a framework. Not a methodology. An actual kernel: a process manager (~/pm) with a compass for state, two interleaved scheduling loops, an attention gate, a calibration system, and a permissions layer. In this talk I'll walk the OS mapping table row by row, show the live system on stage, and tell you what it earned me.

It's not for everyone. Nitty gritty heads-down developers who value full control might not want to use it. But if you're the kind of person who builds systems to solve hard problems — and you're tired of running yours like a chat window — this talk is for you.

Why this angle: Leads with the emotional center of the talk; will resonate hardest with the Laracon audience that already feels the quiet developer arc in themselves. Gives up some technical credibility in the first half of the abstract — the OS reframe appears mid-abstract rather than as the headline.

Angle B: Lead with the reframe

Lead hook: "Multi-session AI tooling is distributed, resource-constrained, and concurrent — that's an operating system, not a chat assistant."

Computer scientists solved this class of problem in the 1970s: scheduling unreliable processes across scarce shared resources, managing volatile memory, coordinating inter-process communication, enforcing access control. We have fifty years of theory. The question is whether we apply it to the probabilistic CPU sitting in front of us, or keep treating it like a very fast search bar.

I'm a 10-year Laravel developer. I built a kernel.

Not because I set out to write a systems paper — because I made a real step outside of comfort by dropping reliable contracting work in favor of spending time on the things I actually cared about. That decision exposed a problem: having godlike leverage and no architecture to run it through. I tried prompt engineering. Better session files. Smarter handoffs. Then I stopped and asked what kind of problem I actually had.

The answer was already in a textbook. RAM is a context window — volatile, scarce, compacted on GC. A scheduler is two interleaved loops: one holds the through-line, one samples for emergent capability. IPC is a bash gateway, JSONL trees, and daemon sockets. The user is a peripheral, not the operator. Once you see it that way, you stop prompting and start designing.

In this talk I'll walk the full OS mapping table, run a live demo of ~/pm, and tell you what the discipline of architecture returned to me that prompt engineering never could.

Why this angle: Most technically distinctive; opens the strongest possible distance from "AI productivity tips" framing. Best fit for a Laracon EU or technically-skewed review committee. Gives up some emotional immediacy — the personal arc enters mid-abstract rather than at the top.

Angle C: Lead with the kernel demo

Lead hook: I walk on stage, say "PM, what should I work on?" — and a voice answers.

What you're watching is ~/pm: a multi-LLM operating system kernel I built around my Laravel practice. In the next few seconds it's going to poll its compass, run an invention loop across my project state, and surface the highest-leverage next action — not because I told it to, but because that's what the scheduler does.

Ten years in, I was good at shipping for other people. That almost makes it worse — being good at it means you keep getting more of it. I made a real step outside of comfort by dropping reliable contracting work in favor of spending time on the things I actually cared about. That created a problem: suddenly I had leverage and no system to run it through.

The insight that unlocked the system was a recognition, not an invention. Multi-session AI tooling is distributed, resource-constrained, concurrent — it needs scheduling, memory management, IPC, and access control. That is computer science. Fifty years of it. I stopped prompt-engineering and started porting the discipline to a probabilistic CPU.

I'll walk the OS mapping table — RAM as context window, scheduler as the two loops, user as peripheral — then demo the live system: attention gate, invention loop, a subagent spawning and reporting back. You'll leave with the mental model and the architecture. Building one is up to you.

It's not for everyone. Nitty gritty heads-down developers who value full control might not want to use it. But if the demo lands, you'll know if you're someone who does.

Why this angle: Most concrete and stage-forward; CFP reviewers can picture the session immediately. Gives up some narrative arc in the opening — the personal moment appears mid-abstract, not as the first beat. Highest risk if the reviewer is skeptical of live-demo talks; highest reward if they're not.

Recommendation

Submit Angle A.

The Laracon US audience skews toward developers who are excellent at their craft and quietly unsatisfied with how they're deploying it. Angle A opens on the sentence that will stop those people cold — "I realized how tired I was working for another person's dreams" — and earns their attention before it asks for their technical curiosity. The OS reframe lands mid-abstract with enough substance to signal rigor without front-loading jargon on a skim read.

Angle B is the stronger abstract on pure technical merit and would place better with a Laracon EU committee. Angle C is the right abstract for a second submission after the talk has had a live rep and the demo is locked. For a first-time speaker submitting to Laracon US, the emotional hook is the competitive advantage. Use it first.