Tenex's AI-Native SDLC: What Paying for Outcomes Changes

In Tenex's "Kill My SaaS" project, 72 submissions aimed to replace a speaker-management tool quoted at $43,000 a year. The team that won with human judges ranked 19th on the AI judge's leaderboard. ¹ That gap is a warning for anyone eyeing outcome-based software delivery: code that clears a test suite isn't the same thing as a tool people actually want to use.

A Latent Space episode with Tenex cofounder Alex Lieberman and CJ Hess lays out a model for paying AI engineers for delivered work instead of hours logged. Tenex still treats story points as an important part of compensation, so this is an operating model under development, not proof that outcome-based pay works broadly. ¹ The question for software leaders isn't whether "outcomes" sounds better than "hours." It's whether the outcome can be defined, verified, and pinned to someone who can actually move it.

AI outcome-based pricing: why it changes the delivery contract

A company can buy engineering time, access to an AI tool, or a defined result. Each choice assigns responsibility differently. Buy time, and you manage scope and judge productivity yourself. Buy tool access, and delivery is still on you. An outcome contract can shift responsibility to the supplier, but only if the result is well-defined and the supplier controls enough of the work to actually deliver it.

Tenex's approach treats the work as more than code production. The episode describes paying AI engineers for delivered work while keeping story points as an important part of compensation. ¹ Lieberman also says the problems you'd expect, such as estimate inflation and shipping bad code just to rack up points, haven't been Tenex's biggest headaches. ¹ That's a description of Tenex's experience, not evidence that story-point systems or outcome pay behave the same way everywhere.

The real shift here is in the unit of accountability. Instead of buying a block of effort or a license, buyer and supplier agree on a result a business stakeholder can actually assess. But the closer payment gets tied to that result, the more the contract language matters. Vague acceptance criteria turn "pay for outcomes" into an argument about what "done" means.

What counts as an outcome when the work is discovery or architecture

A shipped ticket isn't the only output worth paying for. The episode names customer-problem discovery, architecture design, and deciding what to build as work that often doesn't map to a ticket. ¹ A contract that pays only on ship date can leave this earlier work uncompensated, or push teams to rush past it.

A sturdier contract separates the work into layers, each with its own evidence and sign-off:

• Problem discovery: a decision-ready brief documenting the customer problem, assumptions, and supporting evidence.
• Architecture: an approved design with stated constraints and a record of the decisions behind it.
• Prototype: a validated workflow, tested against agreed scenarios with reviewed results.
• Production delivery: a capability that meets specified functional and operational criteria.
• Adoption: evidence the intended users can and do use the workflow, where adoption is part of the business goal.

These layers are contract-design options, not Tenex's own stated categories. The episode describes Tenex's project records (plans, acceptance criteria, decisions, and evidence), which a buyer could use as a template for making milestones reviewable: what was proposed, what assumptions remain open, what evidence backs the recommendation, and who signed off on the next step. ¹

There's a subtler risk worth naming: rewarding visible output while nobody checks whether the team is solving the right problem. Tenex's AI strategists are responsible for customer retention and growth, which the episode frames as an incentive to push back on work that doesn't serve the client. ¹ A contract can build in the same incentive by making discovery and scope changes their own milestones, rather than treating every request as a commitment to build.

How a buyer verifies an outcome is real and useful

The judging gap in "Kill My SaaS" shows why technical completion and user value need separate checks. The episode distinguishes software that satisfies scenarios from software people want to use. ¹ A test suite can confirm specified behavior works. It can't tell you the behavior is useful, or that the replacement is worth running.

Keep an acceptance record with fields such as:

Field	What to capture
Promise	The agreed deliverable and any explicit exclusions
Evidence	Tests, reviews, operational checks, or adoption evidence supporting acceptance
Owner	The person authorized to accept or reject the result
Remaining risk	Known gaps, assumptions, dependencies, follow-up work

Match the quality gate to the outcome. Implementation needs code review, scenario tests, and operational evidence. Discovery needs documented assumptions and a stakeholder decision. An adoption milestone needs review by the people who'll actually use the workflow. A demo is one piece of evidence in that mix, not the whole acceptance process.

Maintenance belongs in the same conversation. The episode notes that an internal replacement creates ongoing maintenance work that has to be weighed against whatever it saves. ¹ A system can clear every launch criterion and still be a bad trade if nobody priced out what it costs to run and change later.

Who is accountable when software development agents do the work

Agents can produce code, plans, or whatever artifact you ask for, but that doesn't settle who's on the hook for the result. The contract needs to name an accountable party for each outcome, and spell out who approves requirements, architecture, security, release, and ongoing operation. It also needs to say what happens if acceptance fails, if scope changes mid-stream, or if only part of the result lands.

That allocation matters more as the work itself shifts. CJ Hess says that as models improve, he spends less time writing code and more time shaping customer context into a form models can use. ¹ As context-setting and review take a bigger share of the job, a delivery failure could trace back to an unclear goal, thin context, an implementation bug, or a bad approval call. These are distinct problems with different causes. A good project record should make those causes distinguishable, not blur them together.

Tenex's "MetaHarness" bundles shared skills, project documents, and a CLI, with plans and decisions stored in Git alongside code so agents can see the reasoning behind earlier work. ¹ The episode describes project records covering plans, acceptance criteria, decisions, and evidence, with views into Linear, GitHub, and client updates. ¹ It also says this much structure can be overkill for a small team on a project. ¹ Teams thinking about how agents should load and use shared skills may also want to read Stop Loading the Whole Skill Library: What SPEM Changes for LLM Agent Architecture, and those running agent infrastructure themselves can use Ray on Kubernetes for AI Agents: A Reviewer's Checklist as a review aid.

For procurement, the lesson isn't to mandate a specific tool. It's to ask how context, decisions, acceptance criteria, and evidence actually persist between stages of work. Good records make delivery easier to audit, but they don't prove the result was worth building. The contract still has to assign who owns maintenance and remediation, not just who produced the artifacts.

Comparing outcome pricing with tools or engineering time

This is a decision framework, not a benchmark. The episode doesn't compare Tenex's cost, speed, quality, retention, or maintenance burden against other purchasing models. ¹

Purchasing model	Buyer's main responsibility	What to measure	Payment trigger
AI-tool access	Own delivery; decide how the tool fits engineering work	Whether the tool improves the buyer's own output	Access to the tool
Engineering time	Manage scope; assess productivity	Progress, quality, use of capacity	Time or agreed effort
Outcome-based service	Define acceptance; confirm the result	Evidence against agreed criteria, including ongoing costs	Acceptance of a defined outcome

Outcome pricing makes the most sense when the result is bounded, measurable, and largely within the supplier's control. It's a weaker fit when success hinges on factors the supplier can't touch, or when discovery is likely to move the goalposts. In those cases, staged milestones that separate learning, design, implementation, and adoption beat bundling everything into an ambiguous promise.

The internal-replacement example is a good reminder to price in lifecycle effort: potential savings aren't net value if the new system comes with its own maintenance tail. ¹ The episode doesn't claim Tenex's model is cheaper, faster, or higher quality than buying tools or engineering time outright. ¹ That comparison is still a buyer's to test, not an answer to take on faith.

If you keep delivery in-house and buy tool access instead, the measurement burden stays with you. An enterprise AI gateway with budgets, spend controls, usage analytics, and audit logs is one way to keep model costs and activity visible while you run that comparison.

Before signing an outcome-based contract

Start with a bounded pilot you can review independently. Before work begins, agree on the baseline, the deliverable, the acceptance evidence, the business owner, the maintenance period, and the remediation terms. If any of those is hard to pin down, that's useful information: the work may belong under discovery or time-bound capacity, not an outcome contract.

Ask the supplier to separate discovery, architecture, implementation, adoption, and ongoing operation. That follows from the episode's point that work like finding the customer problem or deciding what to build often doesn't fit a ticket. ¹ Put intended users and operators in the acceptance review. "Kill My SaaS" is evidence of why scenario checks and actual user desire can diverge. ¹

Last, measure over a window long enough to include quality and maintenance, and compare against a real alternative: tools or engineering capacity you could buy instead. The episode raises these questions without supplying comparative results or a measurement window that would settle them generally. ¹ Treat the contract as a test of whether the outcome can be specified and verified at all, not as a verdict on whether agents can write software.

Frequently asked questions

What is outcome-based pricing for software development? It is a commercial model in which payment is tied to an agreed result rather than only hours, tickets, or access to an AI tool. The Tenex episode discusses paying AI engineers for delivered work, but does not establish that the model works broadly. ¹

How do you define a payable outcome for AI-assisted development? Define the result, acceptance criteria, evidence, accountable owner, and maintenance responsibility. Discovery, architecture, and deciding what to build may need their own milestones because they do not always fit a shipped ticket. ¹

Who is responsible when software development agents produce a poor result? The contract should assign one accountable party for the outcome and document human approvals, agent contributions, requirements, and acceptance evidence. The episode raises this issue but does not report a standard allocation of responsibility. ¹

Is paying for AI tools better than paying for outcomes? Neither model is established as generally better by the source. Tool pricing leaves more delivery responsibility with the buyer; outcome pricing can shift more responsibility to the supplier but demands measurable outcomes, acceptance rules, and maintenance terms. ¹

---

Sources ¹ "AI for the Fortune 2000: How Tenex Builds an AI-Native SDLC — Alex Lieberman & CJ Hess," Latent Space, https://www.latent.space/p/tenex, Oct. 21, 2026.