Tenex — led by Alex Lieberman and his team — has been experimenting with a departure from traditional hourly billing: compensating engineers for delivered outcomes rather than clocked time. The core idea is simple: if AI makes a developer faster, paying by the hour can penalize them; Tenex wants incentives to reward higher throughput and value.
Started roughly 18 months ago as an AI-powered development shop, Tenex has expanded into broader AI transformation work. Lieberman says roughly half of the company’s clients are Fortune 2000 firms and the other half are mid-market businesses. The firm now has about 75 employees, and roughly 90% of them are either engineers or “AI strategists” (technical consultants responsible for customer retention and growth).
Paying for output: benefits and challenges
Tenex still uses story points as a central unit for compensation. Classic concerns about output-based models — people inflating estimates or shipping low-quality work to accumulate points — have not been the dominant problems. Part of the reason is that AI strategists are incentivized on retention and growth, which aligns them to push back on work that doesn't serve clients.
The tougher issue is accounting for valuable work that doesn’t map cleanly to tickets: discovering customer problems, designing architecture, or deciding what should be built. As models improve, engineers often spend less time typing code and more time turning customer context into the inputs models need. Tenex’s compensation system built around shipped tasks therefore needs mechanisms to reward that non-coding, high-value labor.
Lieberman noted meaningful pay dispersion inside the company: the highest-paid and lowest-paid engineers differ by roughly fourfold, illustrating how outcome-based models can create wide variance in earning capacity.
MetaHarness: keeping plans and decisions in the repo
CJ Hess described Tenex’s MetaHarness: a shared set of skills, structured project documents and a CLI that surround the work. Project plans, decisions and acceptance criteria are checked into Git alongside the code, so when an agent or developer returns to a task they can read both what was built and why it was built that way.
Tenex’s “AI-native SDLC” frames the project record as a common surface for both humans and agents, with views into Linear, GitHub and client updates. The useful distinction CJ emphasized is between making agents write code faster and making the surrounding work legible — plans, acceptance criteria, decisions and evidence. That structure can be costly or unnecessary for small teams or one-off projects, but it helps Tenex scale long-running tasks and handoffs.
Kill My SaaS: the build-vs-buy tradeoff
In the Kill My SaaS experiment, the team solicited 72 submissions to replace a conference speaker-management tool that had been quoted at about $43,000 per year. The human-judged winner placed 19th on an AI judge’s leaderboard, underscoring that verifying scenario coverage and measuring whether people actually want to use software are different problems.
Lieberman argues that the higher upmarket you go, the harder and riskier it is to rip out an entrenched system. Even for smaller tools, someone has to maintain what you build — so the one-off cost saving needs to be weighed against ongoing maintenance and operational risk. The counterpoint is that owning a workflow can let you iterate much faster and improve the experience for users; that upside must be balanced against the maintenance burden.
The debate over vertical AI
Tenex’s leadership is cautious about purely vertical, single-purpose AI products. Their concern: if every enterprise expects a bespoke solution, how can those products be delivered at sustainable software margins, and how much of the underlying task will general-purpose frontier models absorb?
There are counterexamples: domain-specialized products such as Harvey (law) and OpenEvidence (health) demonstrate that domain-specific data, unique interfaces and integrations can create durable value. CJ drew a useful distinction between vertical products whose primary feature is an agent doing a task and products that improve the actual workflow around that task. The more interesting question is which products become the durable place people do their work versus which become features plugged into a user’s primary agent.
Models, costs and practical adoption
Tenex staff mentioned Opus 5.5 as a current favorite for a balance of speed and cost; earlier eras of costlier models pushed teams to optimize token spend. Tenex estimates its raw token-to-employee spend at roughly between 1:1 and 2:1, and they’ve seen model improvements materially increase individual engineer output — Lieberman and Hess cited roughly a 2x increase in engineer output year-over-year as models improved and took on longer-running tasks.
Adoption across enterprises follows stages: general-purpose LLM rollouts are widespread; training and enablement lag but are common; coding agents are deployed in fewer companies; and agents in production for non-engineering work are still rare. Tenex views permissioning and RBAC (what an agent can read and do) as a major practical challenge for enterprises.
Conclusion: context matters when deciding what to build
Tenex’s experience shows that outcome-based compensation and agent-assisted development can scale inside an engineering organization, but both require careful calibration to reward non-ticket work and to preserve customer outcomes. Practices like MetaHarness that keep decisions and plans durable in the repo make agent handoffs and long-lived projects more manageable.
Finally, the choice to build versus buy depends on market segment, risk tolerance and whether the potential operational upside and iteration speed justify the ongoing maintenance. Tenex continues hiring for forward-deployed engineers and AI strategists as it pushes AI-native practices into enterprise customers.
