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 looking to reward engineers for their output as opposed to rewarding them for their time. I think you know fast forwarding two years you can see like how engineers can now parallelize a ton of work and just have a ton more output. At the time with you know Sonnet 3.5, Gemini 2.5 Pro, it might not have been that obvious, but I basically took the bet that I think with my skill set and leaning more into AI, I could have much higher output and ultimately have like a higher earning capacity to do that.
2:53 And since then I’ve just like fell in love with that model. I think that’s like what the future of engineering really looks like. And ultimately when AI is solving all these tech problems, companies are gonna pay based on outcome and they’re not going to want to pay based on the time that’s required to build something. Yeah. So for more detail on that, people can refer back to our previous pod where you literally pay people by story points. Yep. And you just have to agree what the story points are. But that also means that some 10x engineers can literally make millions of dollars a year and some others may not make as much just because they’re not as productive. Yeah, exactly. The thesis is that AI is really just a leveraged bet on a human’s intellect
3:29 and work ethic. And so you’re just going to have more variance than ever before in earning capacity. and our view is our model isn’t for everyone, but for the person who basically wants to go long themselves, who has this incredible foundation in software engineering, but also is constantly pushing themselves to leverage the frontier, to stretch their time as much as possible while having quality output, there’s no better way to earn. What’s the state of, like last time I talked to you, I think you had maybe two or three people making a million a year or over a million a year. Is there an update on that? Yeah, yeah, yeah. So just to paint a picture,
4:05 we started Tenex 18 months ago when we started the business. Really, we started as like an AI-powered dev shop. Really, like the original idea was engineering is kind of like the canary in the coal mine for AI. And part of the impetus was my co-founder, Armand, who’s technical by trade, was like starting to use coding agents a lot. And then he had some people he knew that were still typing into their ID, like not adopting the technology at all. And so we’re like, why don’t we just supercharge a company’s engineering org who isn’t adopting this? So we started there. Then as we started moving up market from startups and like mid-market
4:42 companies to now, you know, 50% of our customers are Fortune 2000. And then 50% are mid-market doing 100 to 500 million in revenue. They weren’t just asking for basically staff org and AI engineering. They were asking for like AI transformation as a service. Today, the business is at 75 people. 90% of those employees are either engineers or AI strategists, which are basically think of as like technical consultants. And I think the thesis has proved out true, which is there’s a very wide dispersion in earning capacity between the highest paid engineer at Tenex and the lowest paid engineer at
5:20 Tenex. It’s probably something around 4X difference. Oh, not 10X? Not 10X difference, yeah. That’s the dream. Yeah, exactly. but everything is proved right about the thesis. I do think like there’s been interesting learnings around our model of paying based on story points where there are limits to the model that we knew would be limits and how we think about that moving forward. But overall, I think the concerns that people had around this model of like paying people based on output, like the classic concerns are, well, story points are subjective. People are going to either sandbag story points or they’re just going to
5:55 ship a a bunch of bad code. Like barely check the box. Exactly. Right. But not actually do the job. Yeah, exactly. And I would say those two concerns have not been concerns at all because of our AI strategists. We incentivize, I think, perfectly at odds with engineers where AI strategists are incentivized for like customer retention and growth. Actually, the biggest challenge has been how do you compensate engineers for all the time that’s not spent coding, whether it’s architecting, meeting with clients. And so that’s where we’ve had to find nuance in the comp model,
6:30 but it’s still largely driven based on output. Anything to add? Yeah, on that, I spend a lot of time thinking about this because if I think about my tenure at Tenex, I was coding a lot, coding a lot, coding a little less, and now we’re kind of getting to the point where the models are more or less given the right context and can get you to 90% of the solution. and I do think there is some opportunity here to think about like really the value is sitting down with a customer, hearing everything that they can brain dump and then just providing that to the model
7:05 to actually get closer to the solution. So I imagine, you know, in the future, we’re going to start to look more at like true what this output is, how it works, how it looks as opposed to, you know, kind of that traditional story point model but still anchoring to those as the unit. I think one thing you’d also, I don’t know if we’ve talked about this before, but like the, this idea of like the meta harness, which is like the, the engineering workflows at Tenex that we use that has allowed us to do, I think like really meaningful work on long running tasks. Do you want to just talk through like what our process is? Cause I feel like people would find that interesting. Yeah. So we basically started trying to kind of standardize a set of skills.
7:44 Um, I think most engineering orgs have done something similar by this point. Um, and for us that grew into what is actually like a very structured set of documentation within a repo and then a CLI that’s around it that kind of the models are using to actually drive the work that’s being done, whether it’s creating a plan, a visualization, you know, creating some readout for a client, effectively like building all the pieces of the process around actually writing the code to just happen more automatically and standard across our team. So we have a couple of things, Like one is this like big canonical plan document that has some similar
8:20 structure, but I’d say as the models have gotten better, we’ve actually reduced the enforcements there in the structure. Kind of similarly across all of these. But once you have your plan, you actually build it out. And we have a very opinionated way on how agents will go and log their decisions and log what they’re doing and just keep track of what they’re up to. Everything checked into