⚡️ 年薪100万美元的10x AI工程师——Alex Lieberman 与 Arman Hezarkhani，Tenex

Okay, we're here in the remote studio with Alex Lieberman and Arman. Oh my God, I did not prep this. [laughter]

Leave it in.

How do I—how do I—

Leave it in? [laughter]

I just say “Arman.”

Keep it rolling. Keep it rolling. If it makes you feel bad, for the first probably 20 times that I said Arman's name, I said it the wrong way. He was very polite in guiding me to the right pronunciation. I used to say “Armen,” not “Arman,” so it's okay.

It's totally fine.

Me, too.

I don't think you have to. I mean, it's Hezarkhani, but we don't need—

Yeah, yeah, yeah. “Arman Hezarkhani” is fine.

Amazing.

Yeah, that's honestly even funnier now, where, as you're about to introduce him, you just dub Arman's saying his own name over your mouth. [laughter] That's so funny. It's like when you're on a voicemail and you're saying your name while the automated machine is talking.

Totally. So you guys are the co-founders of 10x and also MCs and speakers at AI Engineer, right? I have a little bit of extra context on Alex because I've followed Morning Brew for a while. You've been an inspiration in the newsletter business. But let's talk about 10x. I think my goal here is just to introduce people to you guys, maybe to you individually and then to you together. Whoever wants to take it first.

Well, I can give you a little bit of the backstory behind the business and how Arman and I got to know each other. Arman and I met in 2020, when I had invested in his previous business, Parthean. Parthean was an AI financial tools business, originally for consumers, then providing AI tooling for financial advisors, RIAs. Throughout Arman's building that business, we had continued to talk about our philosophy on product and how AI was influencing product in general.

I think, especially for nontechnical folks like myself, there's a moment where you get smacked in the face by how profound this technology can be if harnessed in the right way. I experienced that moment in conversation with Arman. This was probably 9-ish months ago. Arman and I were talking, and he had shared a story about how, with Parthean, he unfortunately had to downsize his engineering workforce. When he downsized his engineering organization, he had to decrease the size of his engineering team by 90%.

When he did so, he had to rebuild—basically, rearchitect—the entire product and engineering process to be AI-first because he no longer had the human resources. He needed to accelerate it with this technology. What Arman had shared with me was that the output of production-ready software had 10x'd after making this shift with the organization. I didn't believe him at first because I had never seen that level of leverage. I'd used ChatGPT, I'd used Grok, I'd used all these things, and yes, they've been life-changing for me, but I wouldn't have explained them as 10x experiences.

We basically talked through it, and he shared with me why AI—and specifically LLMs—have made such a profound impact on engineering as a type of knowledge work. From there, the thought was that the way in which engineers are compensated has to change materially. Historically, people charge for their time by the hour, and then all of a sudden, let's say you're truly an AI engineer who's 10x higher throughput. Imagine you're selling your work and someone's used to spending $100 an hour for an engineer, and you go to them and look them dead in the eyes and say, “Yeah, I'm $1,000 an hour.” You're going to get laughed out of the room, even though you're a better engineer than the engineer they would have hired.

You're also perversely incentivized because you're leveraging AI in your work and operating faster, but you're incentivized—just like a lawyer or any hourly-paid knowledge worker—to rack up as many hours as possible. The kernel of insight that started all of 10x was: How do we hire the best engineers in the world? How do we offer them unlimited upside by compensating them for output rather than hours? And then how do we harness that in the right direction to help companies transform their businesses with AI? I know there's a lot there, but Arman, is there anything I missed?

Basically, yeah. I think Alex covered it. I was writing code, and I was deeply incentivized to generate more output—high-quality output, but faster and more—because it was my company. But the whole thought is that when you work at someone else's company, even if you have some equity, even if you deeply care about the mission, you're not deeply incentivized day in and day out to try new AI tools and push yourself to work better, faster, and smarter.

The economic model behind our company is one that does drive that. My talk is basically to show how we do that and how I think other companies might be able to adopt similar models.

This is very tempting because every question I'm going to ask might actually just leak your talk. [laughter]

It's okay. The talk will just reiterate very important points.

I mean, it should stand on its own on YouTube, right? I do like to encourage people to remix the content in different formats. This is the podcast version.

I think the classic question is: What is a unit of output for a software engineer? Is it a PR? Is it a story point? It's extremely unclear, and it's basically unsolved. Don't tell me you've solved it—you may have, I don't know—but I'm default skeptical of the idea that what gets measured gets gained.

Yeah, we do use story points. But you're right that it's easy to game them. If we were to hire somebody who just—if you think about a technical system, a smart hacker will find ways to exploit it. The easy way to exploit the story-point system is to deflate the concept of a story point and decide that any line of code is directly proportional and equal to story points. Then, of course, you've hacked the system, but your clients will churn, you'll probably get let go, and it just won't work long-term.

What we found is that this problem gets solved in the hiring process, and it gets solved by hiring people who fall into 2 buckets. One is people who are selfish, but they're long-term selfish. Everybody's selfish, but we need to look for people who are long-term selfish—people who understand that these incentives are longer than just today's story points. They're forever, right? We need to think about how we maintain the client relationship. That means we're going to give them very robust story points so that we can maintain the relationship and continue to make money.

The other is that we hire people who just like writing code and like working with really smart people. They're not sharp-elbowed; they just want to do great work. That sounds squishy, but that really is a part of it as well. I think both are really important.

Just 2 other things I'd quickly add. One, when we work with clients at 10x, there are basically 2 role players. There's the AI engineer and then there's the technical strategist. One of the best ways to fight perverse incentives is to incentivize 2 people at odds with each other in a healthy way.

Our technical strategists are incentivized based on NRR, based on retention and account growth for a client, and they are the final ones to sign off on the engineering plan for a client before we begin a sprint. They're the last line of defense for quality before a client ever sees anything. So that's one thought.

The interesting thing—and I don't know if Arman has thoughts on why this is—is that we have not yet—and again, we're a young company, so this could change at some point—but we have not yet had any clients argue about how we assign story points or ever feel like we are sandbagging story points or any of these things. It's just interesting because, to your point, Swyx, I would have expected that to have already happened.

Yeah, it can be a political process when things don't go well, but when things go well, no. Everyone's just steaming ahead.

Okay, you hire great people. You work well with story points. I think one thing I'm trying to get my guests to do a better job of is just brag. Could you brag a bit about some really impressive project that you accomplished, just to open people's minds? Let's get specific without maybe naming the exact client, unless you can. And then also, since you're technically young, what's the highest hourly rate that one of your engineers has made?

Yeah, so I'll answer the last one—or the second one—first. We will probably have more than 1 engineer make $1 million in cash next year based on this model, and that is just with story-point compensation. It's very likely that we'll have more than a handful of folks make more than $1 million next year.

The answer to the first question is, for example, 1 project we built. We work with a company that partners with retailers to basically make cameras in their businesses more valuable. The way they do that is they deploy what was historically a Gen 4 Raspberry Pi to the stores, and they would run 1 model on that device.

We basically took some off-the-shelf models, trained some models ourselves, and then quantized them down so they could actually run on that Raspberry Pi 4, as well as on Jetsons and Nanos. We got them all to run in parallel. Now, what these models allow you to do is get a heat map of a store. You can see where lines and queues are forming, get pictures of shelves to understand what needs to be stocked, and do things like theft detection because we have body analysis and can understand whether people are crossing their arms.

This took our team 2 weeks to put together as an early prototype, and now we're refining the accuracy and improving the metrics from there. Again, this was one of many examples. Of course, with that specific example, it's more of a research project, and it's going to take a while to improve the accuracy. We're not claiming that we're magical beings, but previously, building a prototype of that alone would have taken several quarters for a robust team of engineers. We were able to prototype it very quickly, and now we're working with that team for a year to build more and do all that stuff. Alex, anything?

I guess another one is Snapback Sports. We built them a mobile app in a month that hit 20th on the App Store globally. There was no AI in this app. It was a really fun trivia app, but we built it together, deployed it, and hit 20th in the world.

One other example I would add is looking at things from a different angle: sales. I think the power of AI engineering and fast prototyping is incredibly powerful within sales motions now. One example is that we had a big influencer who wanted to build basically ChatGPT, but specifically as if it were your fitness coach, health coach, and nutritionist. So it has all this context—

As a fitness influencer.

Exactly. We originally reached out to work with him, and he said no because he thought we were too early. We didn't have a design team built in yet, so it seemed like the conversation was done. One of our engineers said, “I'm just going to build a working version of this app as soon as humanly possible.”

It probably took him 4 hours to get a working version of the app into the hands of this influencer. That influencer hasn't launched the app yet, but we are number 1 on their list to do the build. The only reason is that the speed at which a working product could be in someone's hands is faster than it's ever been.

Yeah, that's amazing. Okay, so a quick question on the stack that you guys have landed on: Is there a house stack? What are you finding in terms of the various coding agents and all that?

We work in a number of different stacks and languages, but we feel pretty strongly that high structure allows agents to work autonomously for longer. Our default stack is TypeScript front end and TypeScript back end, with a shared folder where all of our shared types, schemas, and things like that live. Typically, it's a React front end, or even something as simple as Express on the back end.

We don't really care about the frameworks. It's more that TypeScript allows us the flexibility of JavaScript with the constraints of TypeScript. Those error messages allow Claude Code, Cursor agents, or whatever we're using to iterate on themselves, run things, see the errors, and continue.

In terms of the actual AI engineering stack—what coding agents and things like that we're using—I always tell clients this: Our team doesn't have a favorite coding agent of the year, the month, or even the week. If I go over to our team right now and ask them what model is performing the best for coding, they'll say, “Today at 4:42, we're noticing that Claude Code is performing better because of X, Y, Z reason.” But yesterday, Codex was outperforming Claude Code on activities like X, Y, and Z.

We stay deeply on top of all the different models and all the different applications of these agents to make sure that we're really pushing the most out of them and advising teams on how they should best use these things.

That's very anecdotal, though, right? Don't you need more comprehensive evals? Otherwise, you're just believing things based on the luck of the draw. At this stage, did a samurai have a measurably better sword than the person to their left or right? No. At a certain point, I think a warrior's weapon becomes a matter of feel.

These coding agents are so good that, yes, you can have evals that provably show one is better than another, but for many of these things, it really is about feel. It's like, “This agent—I can just work better with it on a warm-blooded level,” or it writes code more the way I like it to. At least, that's what we've noticed. Yeah, fair enough. I think you have kind of a SWAT team approach. You're very meritocratic—I think that's probably the right term for this. Are you human-bound or agent-bound? What is your limiting factor in 10x becoming a bigger business than either of you have run before?

Today, it's human-bound, 100%. That is—

You're recruiting.

Yeah. We are. The thing that keeps us up at night is how we can hire enough good engineers fast enough. The second thing that keeps us up is how we match those great people within the business with the right process, such that delivery doesn't suffer as we scale.

More and more, as we build this business, technology is going to be an enabler of the work we do. Long term, if we're talking about the future of the business, we have ambitions beyond just acting as a transformation and engineering partner for companies. We have ambitions to build our own technology, but today, and probably for the foreseeable future, we're constrained by human capital.

How do you interview? You don't have to give the exact interview questions, but has interviewing changed for either of you from pre-AI to post-AI?

This is actually somewhat controversial. A lot of my friends stopped doing take-home interviews after AI. We still do take-homes, but our take-homes are immensely difficult. They're unreasonably difficult.

When I first wrote them up, I told Alex, “Hey, people might get mad at you. You have a public persona, and we're sending these to people. Your reputation might take a hit if we send these to people because they're so unreasonable for us to ask this of people.”

Alex, in classic Alex fashion, was like, “Forget it. Let's just do it. If this is the bar, then we need to do it.”

What we found is that 50% of people don't even respond to the take-home interview. But because our take-home is so difficult, our interview process is actually quite short. We do 2 calls before the take-home, then we send the take-home, review it, and, if it goes well, do maybe 1 or 2 meetings afterward. It can be done in as little as a week. It's very quick if people can get through that take-home.

A few things to add: I'm thinking about some of the most common questions we ask. One that Arman asks, which I really like, is this: If you had infinite resources to build an AI senior software engineer—truly one that could replace either of you on this call right now—what would be the first major bottleneck you would have to figure out how to overcome to build that? That's one question he always asks.

Arman, out of curiosity, I don't know if you want to share it, because then people will start giving the right answer to it.

I can offer one. I don't know—

Yeah, let's hear it.

The classic answer is model intelligence. We think the models are good, but they've actually been trained into a certain sort of local minimum: Here's all the Python, because SWE-bench is all Python, all Django. Beyond that, we've maybe generalized a little bit of front end, but we haven't really done full back-end distributed services and all that.

Model intelligence is going to be the main blocker. But I don't know if that's a good answer, because it's kind of like, well, you just wait, and maybe the frontier labs will solve it.

I generally think it has to do with context. It's not necessarily context length; I think it's context engineering, in Andrej Karpathy's words. It's the problem of how you get the right context into the LLM and get the LLM to pay attention to the right parts of that context. All of that, I would consider context engineering.

From there, there are a lot of ways you could solve that. At the model layer, you can do a lot of work to make sure the attention mechanisms are paying attention to the right stuff.

You could do work on the application layer for context engineering. You can extend context lengths. There are a lot of different approaches, and it leads to a really interesting discussion. So, yeah, that's one thing.

One thing I was just going to say is, I feel like Dan, who's one of our engineers at 10X, shared a different answer. I remember your reaction to it was like it broke your brain a little bit. Do you remember what his answer was?

No, I should ask him. But I believe it had to do with entropy. I should ask him what it was. There he is.

Dan, come here. What was the question that we asked you during the interview? Remember, I asked you if you had unlimited resources and you needed to build an AI engineer, what would you need to solve? You gave me an answer—what would be the limiting factor, the hardest thing?

Yeah. What was it?

Dan

I said it was controlling entropy.

Oh, there it is. Yeah. Controlling entropy. Controlling entropy. Swyx does not agree with Dan.

Wait, come closer so they can hear you. Come closer to my headphones. This is Swyx. You're on a podcast. Yeah, we can hear you. It's good. We're rolling with it.

Dan

So, basically, if there is some—your question was about a fully autonomous coding loop: what would it take to get the human out of the loop? If in that loop you have some error rate, let's say it's 99% accurate with code, even that 1% error rate will just multiply and decay more and more, and that entropy will build and accumulate.

That's kind of a compounding thing that will derail the agent more and more. So I think it's less of a context-engineering question per thing you're implementing, and more about making sure that the agent can reduce the entropy for a given task such that it gets to 100% accuracy. Then you don't have this accumulating-error issue.

Cool, man. Thanks, brother.

No, that was impressive. Oh, no, actually. So—

Yeah.

That's the sophisticated version of context engineering, right? A lot of people are going to answer context engineering. We have one of the people who coined context engineering coming to speak, I think, in one of the early sessions on Friday.

This is actually the advanced version. This is one of the 4 ways in which long contexts fail, and if you have enough experience, you know that this is the one that gets a lot of agents off track. Once they're off track, it's really hard to get them back on track. Exactly. And going back to your question—

I wouldn't use the same words, but, yeah, I get it. [laughter]

And going back to your question about constraints in the business, it's just: how do we find more people like him? That's the thing that keeps us up at night.

Well, you know, I'm in the business of making more. You're helping to contribute by putting this conference together, where we're just sharing knowledge. The more people who watch are drawn to you, and they might answer your call to action of trying out one of your super-hard tests, or at least just learning and advancing the state of the industry.

For sure.

So, I'm excited to have you guys. Do you have any questions for me? I mean, it's like a whole 2- or 3-day affair. I've done this a little bit now.

One question I have for you is—as Arman knows, I'm voraciously curious and a lifelong learner, but I'm also not an engineer by training. My goal is to get as smart about this space as quickly as possible. One of the first things I did was—Arman, did you send me the 3Blue1Brown lecture on LLMs? I took that. Then he was like, “If you want to go super deep, do any of Andrej Karpathy's lectures.” He does a lecture series on how ChatGPT works, and he's like, “Actually write out notes by hand, and you truly understand the math behind these models.”

Arman did that, and he was like, “That's how you understand things at the deepest level.” When I'm not either working or taking care of a 4-month-old at home, that's next on the list. But I guess my question for you is: as a nontechnical person who's always been both enamored and intimidated by technical folks, what would you do if you were me to make the most of this conference, when I'm not the core archetype of the person who's there?

Jeez. Yeah, that's a tough one because I spend 0 time thinking about that. Okay, so I think latch onto the keywords and whatever people are excited about.

People were excited about context engineering maybe 4 or 5 months ago, and now it's entering the mainstream. Typically, the people at this kind of conference would be stewing around those ideas. MCP—the last time we were here in New York, MCP was just taking off, and we did the workshop, and it really blew up MCP. I think that's something that you will see a little bit of—

By the way, Arman grinned because he has very strong feelings about MCP. Very strong feelings. We're hosting a debate.

I just think that MCP is a 3-letter word for API. And Alex always—every time he hears someone say the letters MCP in that order, he tells them that I hate MCP and starts a religious debate.

Well, I will say, though, I do think a few of our engineers have warmed you up to it more with specific use cases. Are MCPs useful? Of course. I use all the MCPs with Claude Code.

I just think that what bothers me is when people create a new name for something and then use that to raise some inordinate amount of money because they know that 3-letter acronyms get investors excited. That's why I giggle when I hear MCP, because I'm like, a lot of people just say that. The tweets that bother me are, “MCP is coming for your job. Here's why you need to know about MCP.” And it's like, no, it's just a useful thing.

Maybe this is relevant to Alex's question. I do take a sociological and anthropological stance toward tech in terms of different groups of people coming in and having different terminology to communicate with each other. It's just human behavior. I'm kind of nonjudgmental about it. People have to do what people do, and they always invent new language. There are only so many ideas going around in the world; they're going to be recycled.

Totally. That said, I will defend MCP in the sense that there actually are other parts of the spec that are not just API wrappers, but people comparatively don't use them as much. I think it's a little unfair to MCP as a whole protocol. But that's why we have a debate where we actually have a podcast booth and we're hosting a pro-and-con debate. I think it's really fun.

Yeah. Yeah. That's awesome.

So, I actually really want to get into this because I think we learn more by contrast than by agreement, right? In a single talk, you're the authority. You're up there on stage, you say whatever you want to say, and no one can really challenge it. People just fight in the comments, but they're never going to rise to the same level.

I think in a real debate, you can learn from both sides and make up your own mind. I think that's what we're going to see.

That's awesome. What we're trying for—

Yeah, yeah. I love that.

Well, it's great to meet you guys. I'm looking forward to your talk. Alex, you're opening the show for us, so all power to you.

I intentionally left that block that you're in as the consulting block. We also have McKinsey speaking, but McKinsey is not in the consulting block. I'm very curious because I think my theory is that a lot of our attendees will be from enterprises that might be looking to talk to you guys, and I'm curious to see how this sector grows.

It's not something I'm personally that familiar with because I mostly just work in companies as an engineer, but the consulting and digital transformation industry is kind of new. It's also very much in demand, as you guys know very well. I'm just excited to feature it for the first time.

We're super excited to be there. Thank you for having us, and I'm pumped to learn a ton from you, from the other speakers there, and from the people who are attending.

Yeah. Yeah. Yeah. I mean, everyone from the labs to the Fortune 500s—it'll be a whole party.

All right. Thank you.

Love it. Thanks, man.