Why do we need a runtime?

I have spent more than a decade looking at spreadsheets no learner would ever see.

Some held data exported from learning platforms; others combined stakeholder inputs, customer signals, performance models, assessment results, and decisions that had nowhere else to live. I have operated programs at million-learner scale, where my attention was finite and the surface I was expected to hold together was not.

Every system could describe its own part of the world, but none could hold the whole performance problem: what we were trying to change, what evidence mattered, what contradicted it, or what should survive into the next initiative.

So the practitioner—with spreadsheets and whatever context survived in human memory—held it.

That experience exposed a structural problem: learner-facing systems record the intervention, while practitioners preserve the reasoning that should have determined it.

The practitioner has been the runtime

For years, enablement software has been positioned around the learner with a consistent promise: make content easier to find and consume, increase engagement, and improve completion. While the intent is right, the operating model follows what buyers can most easily see and quantify.

The practitioner responsible for understanding the performance problem became a secondary user. We received administration screens, exports, and dashboards, while connecting the data, assumptions, decisions, and next action remained our work.

The learner experience looked coherent because the practitioner absorbed the fragmentation behind it. Our cognition became the integration layer, and Excel gymnastics were the tax we paid to make the work thinkable.

That tax created a familiar cadence: a problem appeared, an initiative was commissioned, a plausible intervention was produced, activity was reported, and everyone moved on.

That made training the default intervention: it was the easiest thing to see, fund, deliver, and measure, while causes, standards, and performance evidence were easier to lose.

That is the stateless condition: the systems remember activity, but the work starts over.

I was not short of software; I was short of a place where the whole problem could remain intact.

Eventually, I realized the spreadsheets were not the runtime. I was.

Code changes who can build

Until recently, this felt like an operating constraint we simply had to manage, but the boundary around who can create software is now moving.

We keep saying everyone is becoming a developer, which is directionally right and practically misleading.

Code is becoming more accessible, but building something dependable, secure, maintainable, and genuinely useful is not becoming easy. The cost of producing a first output is collapsing; the cost of operating it reliably is not.

The bottleneck is moving from syntax toward judgment: what should be built, how it fits the work, what good looks like, and whether it improves performance. AI does not remove the need for diagnosis; it increases the number of things we can build before we understand the problem.

It also gives domain practitioners a new option: a spreadsheet can become a workflow, a framework can become an application, a diagnostic method can become an agent, and evaluation criteria can become a repeatable system.

What begins as a workaround can become reusable infrastructure, carrying context and method from one performance problem to the next.

That distinction matters because the practitioner does not need another task executor alone. A runtime provides a cognitive break—not freedom from judgment, but freedom from reconstructing the whole system before judgment can begin.

It preserves the facts, assumptions, contradictions, priorities, standards, decisions, and evidence surrounding a performance problem. It then assembles the relevant state at the start of the next piece of work and keeps the performance question intact while interventions come and go.

The learner still matters, and training remains available. Whether it is the right intervention depends on the operating environment of the practitioner diagnosing the performance problem.

By retaining that state, the runtime lets the practitioner apply finite cognition where it matters most.

That argument becomes practical in LXNow, where I am testing whether a practitioner-owned runtime survives contact with the work.

What LXNow is testing

The experiment has three parts.

First, whether building can be a method of research and self-education—and whether sustained use reveals the difference between abundant machine output and a coherent practice. By my own accounting, these experiments have processed roughly 100 billion tokens across OpenAI’s Codex and Codex CLI in VS Code; Anthropic’s Claude Code and Cowork; and Lovable.

Because token accounting differs across systems, the figure is directional: it describes the scale of use, not the quality of the learning. At that volume, the novelty wears off and the harder questions emerge—where these systems improve a practice, where they redistribute work without reducing it, and where they create new failure modes.

Second, whether practitioner-first design can challenge the provider-defined operating model. I still make buying decisions and, for the past three years, have closely followed both incumbents and newcomers in enablement. Across the products I have evaluated or helped buy, I have seen meaningful progress in learner delivery and administration, but less progress in preserving the practitioner’s reasoning across systems and initiatives.

While each product improves its own surface, the practitioner still reconstructs the performance problem between them. LXNow tests the opposite direction: begin with the practitioner’s performance problem, preserve the reasoning across tools, and ask what part of that professional operating layer can legitimately remain portable.

Third, whether the platform can radically improve the productivity of my own practice. My working design target is 170×, to be measured against a manual baseline while holding quality, evidence, and human approval constant.

This is not an achieved result, a customer promise, or a goal to produce 170 times more content. It is a constraint on the design: can the platform eliminate reconstruction, reuse accepted knowledge, carry decisions forward, automate mechanical work, and reserve cognition for diagnosis, judgment, and consequential decisions?

Progress will be measured by time to a coherent performance brief, time lost to context reconstruction, the rate of responsible reuse, rework before acceptance, and useful work advanced per practitioner hour. Until one primary productivity ratio is defined and evidence exists, 170× remains an ambition—not evidence.

If those gains come from retained state rather than one-off automation, the result is more than faster work: it is a professional practice that can travel.

The practice becomes portable

Once a practice can retain and compound its own state, it can become portable, which is where the employment question begins.

Historically, a company hired a practitioner and supplied the operating environment. I expect more high-leverage practitioners to arrive differently. Your next employee may bring more than an agent; they may bring the platform through which those agents operate.

A platform in this context is not a laptop filled with favorite apps, but a persistent professional environment containing the practitioner’s methods, models, software, workflows, evaluation rules, and evidence of what has worked. Its agents are components of that environment, not the environment itself. The platform should never contain a previous employer’s confidential information; it should contain the practitioner’s ability to perform.

Before joining a company, a practitioner may practice inside their own environment using public, synthetic, or permissioned information. Rather than relying on description alone, they can demonstrate the system they use to diagnose a performance need, design the response, produce the intervention, and evaluate what changed.

Likewise, a sales-performance practitioner may arrive not only with a presentation about performance matrices, but with the machinery for establishing one.

At that point, the company is no longer evaluating a person alone; it is evaluating a compound capability: the practitioner, their platform, its agents, and the judgment required to adapt that system safely to the organization.

Hiring begins to overlap with software procurement and consulting. The same practitioner may move between employment, product, and consulting modes—sometimes concurrently, where contracts and conflicts permit. They may license the repeatable product, advise on its local application, and continue improving what can legitimately travel.

Employment becomes one possible arrangement between an organization and a practitioner who brings a platform and agents of their own.

The employment contract has not caught up

By turning previously tacit practice into a durable asset that can travel, a runtime makes the old ownership bargain incomplete.

Most employment agreements assume that the company supplies the operating environment and the employee supplies the labor—an assumption that breaks when a practitioner brings years of encoded practice and improves the platform through the work.

This is not only an intellectual-property problem but an incentive-design problem: salary compensates someone for performing a role, while a reusable platform may require a license, shared upside, support obligations, or another mechanism negotiated alongside that role.

Company data, confidential decisions, customer information, standards, and company-specific outputs must be protected, but a practitioner should not surrender the operating system of their practice every time they accept a role.

We will need to answer three questions explicitly:

The method may be portable even when the organization’s data and decisions are not; what happens to the improvements between those layers must be negotiated.

Portability without governance will not earn trust. Ownership without portability will not retain the best practitioners.

An experiment, not a prophecy

My next step is not to declare the thesis proven, but to build this platform inside my own practice, apply it to real performance problems, establish the manual baseline, and publish what survives contact with the work.

We need a runtime because the reasoning around performance cannot continue to live only in practitioner cognition.

The immediate question is not whether every employee will become a software founder, but what happens when a capable practitioner arrives with a system that makes their capability repeatable.

What, exactly, is the company hiring then: the person’s time, their judgment, their agents, the platform around them—or some new combination of these?

For more than a decade, practitioners like me have acted as the runtime. The next generation should not have to; their platforms and agents can carry the state with them.

We should answer the employment question before that compound capability arrives.