Tenex：按产出付费的AI原生研发流程

Last year, Alex Lieberman and his cofounder joined us to explain Tenex’s unusual bet: pay AI engineers for the work they deliver, rather than the hours they spend at a keyboard. If AI makes an engineer faster, an hourly rate can make the engineer less money for the same job. Tenex wanted the incentives to run the other way.

At AIE New York, Alex came back with CJ Hess to talk about what happens when you scale that idea into an engineering organization. We also put one of our own experiments on the table: Kill My SaaS, where we asked builders to replace a conference speaker-management tool we were quoted $43,000 a year to use.

Both stories raise the same question: when building gets cheaper, how do you decide what good work is worth?

Paying for output when the job keeps changing

Tenex still uses story points as an important part of engineering compensation. Alex says the feared failure modes—people inflating estimates or shipping bad code to rack up points—haven’t been the biggest problem. Tenex’s AI strategists are responsible for customer retention and growth, giving them an incentive to push back on work that doesn’t serve the client.

The harder question is how to reward work that doesn’t fit neatly into a ticket: understanding a customer’s problem, designing an architecture, or deciding what should be built in the first place. CJ describes spending less time directly coding as models get better, and more time getting the customer’s context into a form the model can use. A compensation system designed around shipped tasks has to make room for that work too.

Alex says Tenex has grown to 75 people, with customers split between Fortune 2000 companies and mid-market businesses. The firm started as an AI-powered development shop; increasingly, customers are asking for help with AI transformation across the company. Jump to the compensation discussion →

MetaHarness: keeping the project in the repo

CJ walks through Tenex’s MetaHarness: a shared set of skills, project documents and a CLI around the work. Plans and decisions are checked into Git alongside the code. When an agent comes back to a task, it can read not just what was built, but why the team chose to build it that way.

Tenex’s own AI-native SDLC article shows the idea as a project record that humans and agents work against, with views into Linear, GitHub and client updates:

Source: Tenex, Building an AI-Native SDLC.

The useful distinction is between making agents write code faster and making the surrounding work legible: the plan, acceptance criteria, decisions and evidence. Tenex’s article also notes the cost: that much structure can be overkill for a small team on one project. CJ explains the workflow →

Kill My SaaS: the cost of owning the thing you build

Our Kill My SaaS episode covered 72 submissions to replace our speaker-management software. The team that won with our human judges came 19th on our AI judge’s leaderboard. It was a useful reminder that checking whether software satisfies a list of scenarios and judging whether people want to use it are different jobs.

I brought the project to Alex as a real example of a company choosing to build its own software. His pushback: the further upmarket you go, the more expensive and risky it becomes to rip out an established system. And even for a smaller tool, someone has to maintain it. Is the saving big enough to justify that ongoing attention?

My answer is that the upside isn’t just the bill. Our team has lived with a mediocre product for a long time. If we own the workflow, we can make it better for speakers and operators and iterate in minutes instead of waiting months for a vendor. That potential has to be weighed against the maintenance Alex describes. Watch the exchange →

The case for—and against—vertical AI

Alex is generally bearish on vertical-specific AI products: if every enterprise expects a one-of-one solution, how do you deliver that at software margins? And as frontier models improve, how much of the underlying task gets absorbed by general-purpose tools?

I pushed back with examples like Harvey and OpenEvidence. Domain-specific data, specialized interfaces, integrations and user habits can matter even when the underlying model is available to everyone. Bloomberg is a useful comparison: a trader can get market data elsewhere, but the terminal brings data, workflows, communication and existing habits together.

CJ draws a distinction between a vertical product whose main feature is an agent performing a task, and a tool that improves the actual workflow around that task. That leaves a more interesting question than whether “vertical AI” wins or loses: which products become a durable place people do their work, and which become a feature of the agent they already use? Watch the debate →

Show notes

- Tenex — Alex and CJ’s applied AI company, working with enterprises on AI adoption and engineering.

- Alex Lieberman on Tenex — Alex’s introduction to the company and its approach.

- Building an AI-native SDLC — Tenex’s explanation of its agent-assisted development process and MetaHarness.

- Our earlier conversation with Alex and Arman — Tenex’s original case for paying AI engineers for output.

- Kill My SaaS — What we learned replacing a $43K-a-year speaker-management tool with AI agents.

Timestamps

0:00 Cold open

0:26 Introductions

0:51 What Tenex does

1:32 Why CJ joined Tenex

3:17 Paying engineers for outcomes

7:20 Inside MetaHarness

10:25 Models and long-running tasks

15:11 Token spending and ROI

19:29 The enterprise AI adoption gap

23:22 Why agent deployment is hard

24:42 Vertical AI and enterprise software

30:32 Kill My SaaS

35:23 AI and jobs

38:18 New York’s AI ecosystem

42:28 Hiring at Tenex

Transcript

Automatically generated from the interview; wording may contain errors and speakers are not labeled.

0:00 And I just felt my output getting better and faster, and ultimately getting paid less. Like I was charging hourly to my clients. I phrase it to the team as, you can’t automate a process that does not exist.

0:26 Okay, we’re here at AI Engineer checking with Tenex. Welcome back, Alex. Thanks. Thanks for having us. You brought your Director of Engineering, CJ. Welcome to the pod. Special projects lead at Tenex. Okay, special projects lead. All right, you’re the SWAT team. Yes, yes. So you’ve been on the pod before, and people are vaguely familiar with the Tenex story, but can you sort of reintroduce from the top what is the 2026, how you introduce yourself? Yeah, very simply, Tenex is an applied AI partner for some of the biggest companies in the world to help them go from AI absent to AI native. Our belief is that AI is incredible, but it is raw intelligence.

1:04 And the hardest problem to solve is the final mile to actually diffuse it through the economy. And so our view is to act as the player to help enterprises to figure all of this. Can I curse on? To figure all this shit out. Yeah, yeah. Yeah, we have the explicit tag on Apple Podcasts. Although I did recently discover that YouTube doesn’t like it. Oh, really? They’re so, like, yeah, you can’t say the F word. So did I just mess up your video? What are you going to do? I don’t care. Okay. We’re for adults. CJ, what drew you to Tenex? So I was actually the first hire. I don’t even know if Alex and Armand had the name Tenex quite yet,

1:40 but I have, like, a graveyard of startups I tried to start before Tenex, ultimately culminating in like my own kind of engineering consulting company. And I spent some time there doing traditional engineering, eventually moved over to doing some of this like AI consulting and just like building more and more with it. I’m a software engineer by trade. And I just felt my output getting better and faster and ultimately getting paid less. Like I was charging hourly to my clients. and I really liked kind of the ethos of Tenex that Alex had first posted

2:16 when I saw it on Twitter about kind of l