Tenex Pays AI Engineers for Outcomes, Not Hours. That Choice Rewrites the Org Chart

Start with the mechanism, because it is less obvious than it sounds. Under hourly billing, the client buys time and hopes it converts into output. The engineer sells time and is indifferent, financially, to how much output each hour produces. For decades that indifference was tolerable because productivity per hour moved slowly. A good engineer was perhaps twice as fast as an average one, and rates adjusted over years.

Agents change the slope. The productivity gain now arrives in weeks, it varies wildly by task, and it accrues mostly to people willing to restructure how they work. Tenex's framing names the result precisely: the same job, done faster, pays less. An engineer who adopts agents aggressively is fined for it.

That produces three bad equilibria, and every hourly shop is drifting toward one of them:

• Padding. The engineer uses the agent, finishes early, and bills the old number of hours. The client overpays and the relationship rests on a fiction.
• Honest attrition. The engineer bills true hours, earns less, and eventually leaves for a structure that pays for output.
• Quiet multiplexing. The engineer fills recovered hours with a second or third client, which works until attention, not time, becomes the bottleneck.

None of these is fraud in any dramatic sense. They are rational responses to a price signal that no longer means anything.

The deeper problem is that hours fail to describe what the valuable work now is. Simon Willison's account of building Battle Drones, a vibe coded RTS, is instructive here. He admits he got the game to be genuinely fun "by telling Claude to 'Make it a LOT more fun'." That is a joke, and also not. The leverage point in that project was judgment: knowing the game was not fun yet, knowing what fun should feel like, and knowing when the agent had delivered it. The keystrokes were nearly free.

An hourly invoice cannot price that sentence. It can only price the time around it. When the expensive part of the work is taste and verification and the cheap part is typing, billing for typing time is billing for the wrong thing.

This is why Tenex's move matters beyond Tenex. It is an early, explicit admission that the time-for-money contract, the default ai agent business model for services firms, is mispriced in an agent-native workflow. The firms that keep it will not collapse. They will simply bleed their most agent-fluent people to firms that let those people keep the gains.

Paying for delivered work sounds clean until you try to write the contract. What counts as delivered? Who decides when a feature is done? Who pays when the client changes the requirement halfway through? Hourly billing dodged all of these questions by making the client absorb variance. Outcome pay hands the variance to the engineer, or to the firm standing behind the engineer.

That transfer is the point, and it is also the risk. Under outcome pay, an engineer who misjudges a task's difficulty eats the overrun. An engineer who cuts corners to finish faster gets paid the same as one who builds it properly, unless someone checks. So the firm must get very good at two things hourly shops never had to master:

• Decomposition and pricing. Turning a vague client need into discrete, priced units with explicit acceptance criteria.
• Verification. Confirming each unit actually works, at a cost far below what it took to build.

This is where The Autonomy Spectrum earns its place. Agent deployments range from copilot to full autonomy, and most failures come from deploying at the wrong point. Outcome pay has a similar spectrum. Work that is easy to verify, such as a migration with a test suite, an integration with a clear contract, or an internal tool with a known workflow, sits comfortably under fixed outcome pricing. Work that is hard to verify, like performance tuning under unclear load or architecture decisions whose consequences surface in a year, does not. Pricing the second category as if it were the first invites exactly the shortcut behavior outcome pay is supposed to prevent.

The pattern resembles the shift from time-and-materials to fixed-bid contracts in construction and consulting, with one difference. In those industries the cost of building was stable enough to estimate. With agents, the build cost for a given unit is falling and unevenly so. A task priced last quarter may be twice as cheap to build this quarter. That makes the pricing library a living asset that needs constant recalibration, not a rate card printed once a year.

The implication for an organization like Tenex is that the scarce skill is no longer writing code. It is writing the definition of done. Engineers who can take an ambiguous request, carve it into verifiable outcomes, and predict how much agent effort each will take are the ones who make the economics work. Everyone else is a cost center with a fast autocomplete.

One engineer paid for outcomes is a freelancer with good incentives. A whole organization paid that way is a different machine, and that was the subject of Lieberman's return conversation with CJ Hess: what happens when you scale that idea into an engineering organization.

ClawBlog's Harness Hypothesis holds that the value in AI is not in the model but in the harness that connects the model to the world. Apply that to a firm and it clarifies what an outcome-paid engineering org is actually selling. Every competitor can buy access to the same frontier models. Every engineer can install the same coding agents. The model layer is not where differentiation lives. What a firm can own is the organizational harness around those models: the scoping process, the review discipline, the shared prompts and conventions, the pricing history that says what a given unit of work really costs.

The evidence that individual authorship is already blurring is sitting in public release notes. Pydantic AI's recent releases open with the line "This comment was posted by Codex Desktop using gpt-6.1-sol on behalf of David," as seen in both the v1.107.9 notes and the v2.59.0 notes. That is a small thing. It is also a clean illustration of where engineering work is going. The agent drafts, the human is accountable. Ask how many hours David spent writing that release note and the question collapses. Ask whether the release shipped correctly and the question still means something.

An outcome-paid organization formalizes that distinction. It stops tracking who typed what and starts tracking who is accountable for which delivered result. That has consequences for structure:

• Career ladders shift from tenure and scope of code ownership toward throughput of verified outcomes and accuracy of estimates.
• Review becomes a first-class job, not a tax on senior engineers' calendars, because verification is what protects the firm's margin.
• Shared tooling becomes capital. A reusable agent workflow that cuts the cost of a common task type by half flows directly to the firm's margin on every future outcome of that type.

The interesting tension is between individual and collective incentives. If engineers are paid per outcome, who builds the shared harness that makes everyone faster? Nobody gets paid for an outcome called improving the team's tooling. An outcome-paid firm either finds a way to price internal infrastructure work or watches its harness decay while each engineer optimizes their own queue. That is the organizational design problem underneath the compensation headline.

The same Latent Space episode included an experiment worth taking seriously: Kill My SaaS, in which builders were asked to replace a conference speaker-management tool. The excerpt does not tell us how the replacements fared, and this piece will not pretend to know. The framing of the experiment is the signal.

For most of software's history, a services engineer delivered features inside someone else's product, and the product itself was a subscription you rented from a vendor. Speaker management for a conference is a classic niche SaaS category: a narrow workflow, a modest number of users, a recurring license fee. Asking builders to replace it outright treats an entire product as a single deliverable.

That is where outcome pay and agent productivity compound. If a firm can quote a fixed price to build a bespoke tool that does exactly what a client needs, the buyer's comparison changes. The choice is no longer between hiring engineers at hourly rates for an open-ended project and paying a vendor's annual seat price. It becomes a choice between a known one-time outcome fee plus maintenance and a perpetual license for software built for someone else's workflow.

Read through Disruption Theory, this is a low-end entry pattern. Bespoke agent-built tools will not beat mature SaaS on depth, polish, or compliance tooling at first. They will win at the bottom of the market: the narrow, underserved workflows where the incumbent product is overbuilt, overpriced, or awkward. The incumbent vendors, focused on their most demanding enterprise customers, have little reason to defend the long tail of small buyers with idiosyncratic needs. That is the classic opening.

Two caveats keep this from being a eulogy for SaaS:

• Maintenance is an outcome too. A replaced tool that breaks in six months is not cheaper. Outcome-paid firms will need to price ongoing ownership, not only the initial build, or they will be selling liabilities.
• Verification gets harder as the deliverable grows. A feature has a test. A product has users with opinions. The bigger the unit of delivery, the more the definition-of-done problem from the previous section dominates the economics.

Still, the direction is clear. When the unit of delivery grows from a ticket to a product, the services firm and the software vendor start competing for the same budget line. Outcome pricing is the contract structure that makes that competition legible to the buyer.

The most useful companion to the Tenex conversation came from the same event. Latent Space recorded its interview with Evan Conrad of SF Compute on the sidelines of the new Compute Trading track at AIE NYC, and the argument there rhymes closely with outcome pay.

Conrad's framing starts with history. Software-defined networking, the idea from former guest Martin Casado, virtualized the routing network "by separating the control plane from the data plane," and it was disruptive enough that Cisco was ready to pay $600m for it before VMware outbid at $1.3B. That revolution, the piece argues, "is now coming for GPUs," where previously running your own supercompute cluster required $50-100m upfront.

Set the two conversations side by side and a single pattern emerges. In both cases, a resource that used to be sold in a crude, capacity-shaped unit is being repriced in a finer, more programmable unit:

• Labor moves from rented time (hours) toward priced results (outcomes).
• Compute moves from owned capacity (a cluster you buy outright) toward a tradeable, programmable resource you can buy in the shape you need.

On a Wardley Map, both are sliding right along the evolution axis, from custom and capital-intensive toward product and commodity. And as components commoditize, the higher-order activity built on them becomes where firms compete.

The connection is not only metaphorical. An outcome-paid engineering firm takes on a cost that hourly shops passed straight to clients: the compute bill. When an engineer is paid per delivered result, the agent's inference cost for that result is the firm's problem. If an agent burns through a long, expensive session to finish a task priced at a fixed fee, margin evaporates. That makes compute pricing an input cost to labor pricing in a way it never was when engineers were humans billing hours on laptops.

A market where compute is programmable and tradeable is therefore a precondition for outcome pricing to scale. Firms need to forecast and, eventually, hedge the compute cost embedded in each outcome, the same way a manufacturer hedges raw materials. It is telling that one conference programmed a track on trading compute next to a talk on paying engineers per outcome. Those are two halves of the same new cost structure, even if the agenda did not present them that way.

Here is where the consensus reading of Tenex, that outcome pay is simply better for engineers, deserves some resistance. It is better for engineers right now. Whether it stays better depends on who controls the price of an outcome, and the frameworks suggest it will not be the engineer.

Start with Aggregation Theory: platforms win by owning the user relationship and commoditizing supply. In an outcome-paid services firm, the client relationship and the scoping process sit with the firm. The engineers, however skilled, are supply. As agents get better and more engineers become agent-fluent, the supply of people who can deliver a given outcome grows. Competitive pressure then pushes outcome prices toward the new, lower cost of producing them. The productivity gain that hourly billing confiscated outright, outcome pricing hands to engineers temporarily, until competition passes it on to clients.

Then apply Commoditize Your Complement. A firm selling fixed-price outcomes benefits from everything adjacent to it getting cheaper: models, agent tooling, and, per the SF Compute conversation, the compute underneath. Its revenue per outcome is set by the client; its cost per outcome falls with every improvement in the stack. The engineer's labor is also a complement. The firm's long-run interest is to make each engineer's contribution to an outcome as cheap and substitutable as possible, which is precisely what a strong organizational harness does.

None of this makes Tenex's model cynical. It makes it honest about what it is: an incentive structure that aligns the engineer with speed during a transition, inside a firm that keeps the durable assets. Those assets are the client relationships, the pricing library, and the definition of done.

Taken to its limit, this logic points toward the zero human company idea that circulates in agent circles: an organization where scoping, building, and verifying are all agent work and humans own only accountability. Outcome pay is a waypoint on that road, because it is the first compensation model that does not care whether a human or an agent produced the result. Nobody should claim the endpoint is close. But the contract structure is already indifferent to it.

What to watch, then:

• Whether outcome prices hold as agent-fluent engineers become common, or compress toward build cost.
• Whether firms share the margin from falling compute and tooling costs with engineers, or keep it.
• Whether the engineers who write the definition of done get paid like owners. They are the ones holding the scarce skill.