Inside Legora's Tech Stack: Why Token Maxing is Failing Enterprise Startups | Legora CTO

What percentage of a developer's salary would you be willing to spend on AI tooling for them?

I don't want to say infinite, but for me, it's a question of opportunity cost. We're in a competitive environment. There's so many things that we can do, and the cost of not doing it is extremely high. This almost outweighs any token cost.

Honestly, just work harder than the 800-pound gorilla. People underestimate this. With the 800-pound gorilla, no one in the 800-pound gorilla is extremely excited to be there.

1. You Can Build Faster Than Lawyers Can Consume

We were just chatting, and you said Legora is the first big company, or company of this size, that you've worked at. Is that a blessing or is that a curse? How do you think about that?

2. What Harvey Has Done Better Than Legora

I'd like to think that it's a blessing. I just have to be really humble about it. Essentially, I don't have any priors coming into how to build an engineering org. I think building an engineering org in 2026 is very different from doing it in 2024.

In that way, it's really good that I come in naive and say, "Okay, let's try to do it this way." If it doesn't work, we keep iterating. Just like we keep iterating on our product, we keep iterating on our organization and our processes.

I work with the team: what's working well, what's not working well, and how do we solve that, just like any other problem?

Dude, how is it different building a team, an org, or a product in 2026 versus 2024 and years prior?

Everything is just changing all the time right now. Productivity is through the roof. Processes are up in the air. You can have huge teams; you can have tiny teams.

Productivity is through the roof.

Yeah.

If we unpack that, why is it through the roof?

Well, just AI tooling. I mean, what do we use internally? It's Claude Code. It's Cursor.

Those 2 are competing? Yeah, yeah. Wow. Because everyone's like, "Run from Cursor," whenever I interview. So, you still have Cursor users?

We still have Cursor users. The Cursor harness is quite good. There are some personality differences on our team, but a lot of people still use Cursor. Some use Claude Code, and some use Pi because the Claude Code harness is annoying sometimes. We allow people to do both.

Okay.

And so we have efficiency against that. We ship more. We ship more, we ship faster, we debug things faster, and we iterate faster. Everything is faster now, and each engineer can produce much more than they could previously.

3. Code Is Now Cheap: So What's the New Bottleneck?

That just has a ton of ripple effects throughout the org, basically, on how you structure it. A way I like to think about it is that when you build software, there are 3 phases. There's phase 1, which is the product work: what are we building? You translate user pain, user dreams, and nightmares into something tangible that we can try and iterate on and figure out if it works.

Then, once you have that and know what you want to build, you build it, write the code, review the code, merge it, and get it going. Number 2 was the primary bottleneck for the past 100 years, almost. The rate limiter was how quickly you could write code.

Mhm.

That is now super cheap. That's been compressed, and the bottleneck now is the 2 other ends. One is review: how can we do that much more efficiently? Then it's how can we actually do the product piece much more efficiently? If you believe that code is cheaper to write, then naturally the 2 other things are bottlenecks. That means one of the focus areas is how do we do the product work as efficiently as possible?

How do you think about that, then?

That's a great question. Part of that is: how do we make our PMs as efficient as possible? How do we take all the work with clients, synthesize what they think, and combine that with our own strategic priorities, our own taste, and our opinions about our vision for where our product is going?

How do we make them do that as efficiently as possible and hand that over to engineers as efficiently as possible? I'm not sure if I've solved that yet. But I do think that's the way I'm thinking about it: constantly asking, what's the bottleneck to our velocity? Then we try to solve that.

You said that review could be one element of it that could be a bottleneck. Do we see AI code review becoming the dominant source of review, and does that then remove it as a bottleneck?

I think so. I think that's one of the solutions. We do AI code review today, and it's in its nascent phase.

It's like when I was young, my mother used to just say I was big-boned.

Okay. You just ate all the Maltesers, Harry.

"Here, it's in its nascent phase" is sweet.

4. AI Code Review Is Still Broken

That's the nice way to put it. Yeah, rough edges still.

No, I completely think that's right. We have AI review bots today. You can have security review and different specialized reviewers. They do tons of review and iterate with the AI coder. It's kind of weird because you see this pattern where agents are fighting each other until they arrive at something.

Even then, I think current review tools are not good enough. I think we need something new. I keep telling people at all the events I'm at, if you're going to do a startup, please do something that solves the review thing. No one wants to look at all the lines of code.

What's important is the impact on systems architecture, the impact on systems design, stability, and security boundaries. How does it take our system in the right direction? That's the kind of stuff that you want to review.

If that doesn't change, then maybe you don't have to review it at all. Just unleash the agent. But if it does, if there are some strategic trade-offs, then you want a human to say, "Yeah, this is the right direction to take."

5. The Future Engineer: Systems Design Over Writing Code

Is that the future of engineering: systems design, systems architecture, and then, bluntly, code creation and code maintenance are actually completely done by AI?

Yeah, I think so. I think that's right. The job of an engineer is changing from typing a bunch of code to thinking one layer of abstraction above it: what does the system look like?

You can have AI running around inside each of the pieces, but you have engineers thinking about the higher level, one layer of abstraction above. What does the system look like? What are the bets we're making in different places? Do we want to invest in doing something here that we can reuse in a bunch of places over here, and that's going to make everything much more stable?

I think the other thing that engineers are doing more and more, which is an explicit role with us soon, is the meta-engineering of making agents really effective. You know how you have developer-experience teams that might help write custom linting or custom developer setups to make developers efficient?

We need to have the same team for agents. How do we make agents really effective? How do we make sure that we can enable agents to independently self-improve the system? Can we gather data in a really good way so that we can just unleash agents and say, "Hey, increase conversion rate on my e-commerce store," and they can just go and run experiments?

That sort of sets up the loop so agents can just run and optimize. I think that's going to be the actual job of a lot of engineers.

How do you think we do that? I spent a lot of time with Jason Lemkin and Ann Miura-Ko, who's amazing. But they both told me that, fundamentally, in a world where agents are the pickers of software, the API quality that we have is the core determinant of what agents will choose software based upon.

Mhm.

How do you think about how we make agents more effective? Is it a simple question of data and making sure we're the best at that? How do you think about that?

We have to set up the guardrails really effectively. This is actually something that I'm thinking about right now. Our code base is starting to get large. It's a good problem to have.

We're starting to have a lot of engineers. We're also starting to have a lot of agents that are working on this together. You start to think about how you can mechanistically enforce the system to behave a certain way. I'll try to give an example: you can have custom rules where the agent tries to do something and we tell it, "No, you can't do that."

For whatever reason, you can't do that because we want the system to be this way. I think that type of guardrail setting will be seen everywhere. If you're a big enterprise rolling out AI tooling and you have agents that build your own internal software, you have AI tools that build your HRIS system, your ATS system, and whatever else. You probably have some engineers setting up where you get the data, what you can do, and what you can't do, and then you can just let agents run amok inside that system.

You mentioned the expansion of the Legora codebase today, but what percentage of code created today is AI-generated versus human-generated?

6. Over 50% of Legora's Code Is Now AI Generated

I took a look recently, and Claude and Cursor are at the top. There's, I think, about 2% between them, so they're really, really close. Then it's miles above the next engineer, so they're way above 50%.

Do you worry that we'll see a next generation of security threats with the amount of AI-generated code that blindly opens vulnerabilities we didn't know we had?

Yes, absolutely. This is very top of mind for me, and that's why we still, at Legora—and probably in a bunch of other enterprise software companies—review every human PR, every single one, just because we have to be sure. I think that's inefficient. I want to get some risk scores in there and change that so we can run really fast. Fundamentally, I think you're right: threat actors are extremely efficient now, which means they can try so many different things and keep running at it. We need just as good a defense, and I'm not sure we're there yet.

I definitely don't think we're there yet, which is why we see so many hacks. [laughter] Whenever I see a hack on Twitter, I'm like, “Oh, poor them; their weekend is thoroughly ruined.”

Yeah, yeah, yeah. One of our vendors had a security incident just yesterday. We just rotated a lot. To be clear, this was internal; it doesn't affect any of our clients or anything like that. I think we're going to see more of them.

I totally get that. I interrupted you when we spoke about the efficiencies that come with AI. You mentioned the second was the processes that change. How do processes change, be it PRs, be it postmortems?

Actually, postmortems are a great example. We run them really efficiently now, and it's great. If you have an incident now, you just unleash an SRE agent—an incident agent—and it will quickly figure out what's going on. It looks at all the logs, all the metrics, and the telemetry, and it's surprisingly good. It's really, really good.

Instead of having a bunch of engineers wake up in the middle of the night, you still have some waking up in the middle of the night, but they're really well equipped. The postmortem almost writes itself as well. That's a great example of something that we can run really efficiently.

7. How AI Is Making PMs and Postmortems Faster

More broadly, in the software development life cycle with AI, PMs can prototype super, super fast, which is really great because that means you can front-load a lot of the work. A PM can start, however long before, once he or she has the smallest inkling of an idea that we might want to do this. They can prototype it, go to a user, test it, and iterate themselves. They don't even need to bring in engineering until they have something that's clearly super valuable. Then we can switch and say, “Okay, now we take this from a prototype to something that actually fits in the system and is super reliable.”

Do we skip the design stage in a world where prototyping and getting to V1 is so much easier?

Probably some companies will skip the design phase. I think we can skip the design phase for functionality. You don't necessarily need to have this long discussion where you have 10 people figuring out where the button should be.

I do think design still has a place, but it's maybe one level above the individual features and the individual stuff that we build. It's the design language that we choose to have, the taste, and the opinionated stance we have about who we are. What does Legora look like? What's the navigation? What's the hierarchy? It's more for consistency, UX/UI, and taste than for functionality.

Totally get that. Do you still use Figma today?

We still use Figma. Yes, I know where you're going with this. [laughter] As soon as you start building a system that's larger than something very small, you want consistency, and you want to have a design language and all that kind of stuff. You need somewhere to store what your button looks like, what your pages look like, and what's this and what's that. For us, that's Figma, and it works great for that.

Do you think that's the case? Do you think that's the case moving forward? I don't mean anything against Figma, but it's a storage feature.

Yeah, I know. Exactly. I mean, it could be something else. You're right. Then the question is—

Is it faster for designers to take a prototype to something really crisp in Figma versus prototyping directly? We mentioned the wonderful word earlier—the word of the moment—which is taste. Oh, no, no, no: taste is what separates us. [laughter] How do you think about the idea that, “Don't worry, taste is what the differentiator will be”? Is that true, or is that, bluntly, Silicon Valley and tech BS that's trying to protect us?

8. Does Taste Matter or Is It Silicon Valley BS?

I think taste is important. There are different flavors to taste. [laughter] It depends on what you mean by taste. In tech, taste is having an opinionated stance on something. If you don't have taste, then you let AI slop converge to a sort of grayness, and everything looks the same. I think you need to have taste to have an opinion and a stance in the world: this is who we are, this is what we do, and we don't do these other things. That's not for everyone.

To me, that's what taste means. It's like, this is who I am, this is who we are, and some of you are going to hate it—and that's okay—because you need to have some edges. If you're just letting AI rip, you're going to look the same as everyone else.

When copying is quicker than ever, does that change how you think about product? You're in a very competitive space, and people can copy very quickly. Does that change how you think about product?

No, not really. The important thing for us is that we're building something our clients get a lot of value out of, and we build that as fast as we can, but we don't build it faster than that. There are tons of people who are vibe-coding. There are people vibe-coding Legora, Salesforce, DocuSign, and other companies.

It's very quick to get to the 90% where it looks the same and, in 80% of the cases, works similarly. It's the other 10% that's difficult: ensuring all the edge cases work, all the unhappy paths, all the audit logging, all the RBAC, and all the weird scenarios that you end up with at a certain scale. That's what's difficult. We just keep focused on how we create the most value for our clients and sprint toward that as fast as humanly possible.

My girlfriend is a lawyer, and she's wonderful, but they're not the fastest in terms of adoption and usage. I'm going to get in huge trouble for saying that. I was not talking about her; I was talking about the legal profession.

You can build product so much faster than your customer can consume it.

Yes.

How do you think about that?

That's a great question. You have this notion internally that there's the speed of AI, there's the speed of our product, and then there's the speed of humans. [laughter] They're not necessarily the same. I think that's part of the beauty of what we're doing: we're translating the immense speed of AI development into a user base that's been historically underserved, and we're taking them along for the ride.

Sometimes it can be frustrating, but it's also really rewarding that we can take this huge base of people and change the way they work—their efficiency and their productivity. We can remove the buttloads of awful work they spend their time doing and help them focus on more strategic, more important work.

What have you not done that you wish you had done?

An email client would have been really cool. I would have loved to build that. I vibe-coded one just for fun. We're probably a little way away from that because there are other high-priority things, but I think an email client is where a lawyer sits.

Do you vibe-code internally within Legora for customer presentations—for, you name it—constantly?

Constantly.

Is that the future of enterprises, or is that, bluntly, Legora at the very precipice of innovation?

It will be the future. I don't know when, but it will be the future. I think there's, like—

Just so we understand, what does that mean? You build sites for Slaughter and May so you can pitch to them, and Clifford Chance so you can pitch to them.

No, but it’s way broader than that. We have a team now that’s internally focused on enablement, which is just reimagining, again from first principles, with all the stuff that we have today. If you’re building the most efficient company to go from, let’s say, 200 to 1,000 employees, what does that look like?

That obviously means Claude Code and similar things for everyone, but it’s also: can we just build a bunch of the tools that we need ourselves? Can we vibe code a bunch of the tools? Can we vibe code our HR system, our talent acquisition system, or our payroll system? There are so many tools that exist out there, but you always need to customize them so much, and they basically never really work. We just build them now because it’s so cheap to build.

What have you been able to vibe code away?

We’ve added a bunch of things that are additions to vibe coding. A great, really stupid example is Ryan, who joined from Canada. We have a team of people joining from Canada, and they’re all moving to Sweden. He vibe coded an app to help everyone migrate.

Very specifically, if you’re Canadian, these are all the laws and all the steps you take. It’s interactive, you can see how far you’ve made it, and it’s awesome. It took, I don’t know, a day to vibe code, and it saves so much time for an entire team.

You can build the big systems, but even just all the small ones that you can build really add up. I was with a friend who’s a public company CEO the other day, and he was like, “My chief of staff took 3 weeks off and basically vibe coded what was likely Coupa, and we replaced it.” It works, and it’s brilliant.

What do you say to people who are like, “That’s ridiculous. Why would you ever bother vibe coding and taking months to do an HR system when you could just buy it off the shelf?”

It really depends on the system. There are certain systems—I think, basically, there are 2 axes to systems. There’s the horizontal one, which is how big your product surface area is, and there’s the vertical one, which is how complex it is.

If it’s deep, essentially, your surface area looks quite simple. It’s a simple app, but it does a lot of complex stuff. It hides away a lot of complexity from the user. Then there’s the other one, which is your very, very shallow app, where there are tons of things you can do, but there’s not that much complexity.

If it’s a shallow app and it requires a lot of customization from you, maybe you just build it. That’s probably actually the right thing to do. If it’s a very deep one, there’s just too much stuff for you to build, and it’s not viable for you to do. That’s kind of how I think about it.

We mentioned PMs and their proximity to customers, and then that delivery mechanism back to engineering, which is kind of what PMs have always done and done best. Does the role of the PM change in the next few years?

Yes and no. [Laughter] I think a lot of people are saying that product and engineering are converging. It’s becoming one thing: one person can do the product work, build the system, ship it, and do everything.

For some companies, that’s true. For companies where you really need PMs, it’s not true, or it can be true but it’s inefficient. I’ll tell you why. We were talking about how you do the product work first—the scoping—then you build it, ship it, and review it.

In a company like Legora, we’re always focused on the bottleneck, and the bottleneck is no longer coding. That means the bottleneck is the product work, so you don’t want your product people to do engineering because the opportunity cost of that is really high. What you really want them to do is the product work: talking to customers, figuring things out, and doing the synthesis. That’s the bottleneck.

So that’s how I think about it right now. For certain companies, if you’re doing developer tooling or consumer products, where engineers intrinsically have a good sense for their own clients, you maybe don’t need a PM at all. But I think you haven’t needed a PM before AI either there, so I don’t think that changes with or without AI.

PMs can now do engineering. That changes with AI, but it’s not always efficient to do it. It’s a matter of opportunity cost, and there’s handover cost. If I do all the product work and then give it to an engineer, you lose efficiency there.

It’s good if PMs do some amount of vibe coding to show, in very high fidelity, “Here’s a prototype. This is exactly what it looks like,” because then you reduce the handover cost.

Exactly. Yeah. Exactly.

But they shouldn’t spend a lot of their time engineering because if they just focus on actual engineering, we lose out on the product work.

I’m your little brother coming out of CS at university. What would you advise me to do to be best placed in the next 3 to 10 years? If I were to advise someone in social media marketing, I’d say, “Hey, you need to be full-stack. You need to be able to create the image, get it out, and amplify.”

A similar thing, I think. For engineers, the most important thing is that you need to learn how to learn. You need to figure out how you can constantly reinvent yourself, keep learning, and keep improving, because things change all the time.

Right now, every week there’s something new you should be doing. You need to change the way you’re working or whatever. The most important thing you can do for yourself is figure out how to keep yourself at the forefront of what’s happening all the time.

If you can do that, if you’re adaptable enough and ambitious enough, then the rest kind of works out. If you can just learn faster than everyone else, then over time you win.

To what extent does the quality of Legora as a product depend on the quality of the underlying models?

It’s much less than most people think. The value of Legora is that there’s so much more around it, whether it’s the primitives that make sense for legal work and make it more efficient to work with AI, all the enterprise features, or the optimal routing between models.

We wouldn’t exist without the models, and every time the models become better, our product becomes better and our agent becomes better. But let’s say you took away a model from Legora—people would still pick Legora. They don’t buy it based on the model.

Totally get that. How has model usage changed for you over time?

It changes a lot. The best model changes almost weekly. We’ve switched between OpenAI and Anthropic. We keep evaluating all the different models.

Do you use 15 at the same time for different tasks?

We’re not at 15, but yeah, maybe 10.

Yeah.

For each task, we’ll evaluate what model is best in terms of latency and performance, not so much cost. Eventually it will be cost, but latency and performance are most important.

Performance needs to be here. How much can we increase latency without dropping in performance? By building our agent and our other AI features in a way that lets you decompose the problem, you can use them really efficiently.

You can have latency or performance—the fastest, but it may not be the best output, or slower but great output.

Yes. Yeah.

Which one?

If I have to choose, almost always performance. Performance is more important—almost always. If you’re a lawyer, you can wait 2 seconds more for the output if it’s better. You can probably wait an hour more for the output if it’s better.

What do you think about the future of open source as we move more and more toward a focus on cost?

9. Building Engineering in 2026 vs 2024

Yeah. I think open source is having a great moment. It really, really is. There are so many great open-source models now, and they’re really easy to run. There are great inference providers that let you run them really efficiently.

We’re moving very close to being able to do things on-device. Transcription can run on-device; it can run on my iPhone. I have local transcription on my Mac. When I take flights and there’s no Wi-Fi, I have local models running so I can keep coding. It’s just a “Gwen” model that runs and helps me code.

I think open source is going to play a huge role. I hope it continues to evolve the way that it currently is. I think it’s important that we have open-source models for sovereignty reasons and for security reasons. We should have great open-source models.

Can I ask what worries you today? A lot of people are worried about open-source Chinese models, which I was thinking about. More broadly, what worries you when you look at the landscape that we’ve discussed?

I really hope to see European and American open-source models. They’ve been lacking, and I think it would be really, really good to have some.

I think, just game-theoretically, we won’t end up in a great place if there’s a duopoly or monopoly on the models, for obvious reasons. You do want to have some competition.

Does Europe have a place to play in the model race today?

It should, but it doesn’t yet.

How far do you think we are on the efficiency frontier in training? Are we 1% of the way there, or are we 90% there and might eke out a little bit more?

That’s a great question.

One thing is just the current architecture. How long does that plateau? Do we need something new? There's a model released 2 days ago that's subquadratic, which is huge for context length. That's super exciting. I don't know if I trust the benchmark yet. We need to validate that. But there are still architectural innovations going on, and I don't know—maybe the current language-model architecture isn't the one to take us all the way.

Can I ask what role doesn't exist today that you think will be very common in 5 years' time?

I think it's the internal AI systems role for enterprises. I think it can have a flowering moment here and go from being internal IT that's setting up your computers and whatever to maybe having an AI-assisted team that's building a ton of internal tools that just make your life so much easier.

I think that if enterprises don't create that role, I will get really annoyed, because there's so much efficiency to gain there by really getting into the enterprise and having all of that for them.

Do you have to have FDEs to have usage in the enterprise? You work with relatively sticky lawyers.

Yeah. We currently do.

Do you have to have people show them, “Here you go, here you go”?

We currently do. But I think that's just an education thing. In 5 years, maybe we don't at all, to be honest. But that's the price you pay for being on the forefront. You have to educate and help, and that's why people want to work with us also. We take them for the ride.

Are you ready for an unfair one?

Yes.

What have Harvey done better than you from a product or engineering perspective?

I think they've been more aggressive with hiring, and I actually think I have not been aggressive enough with hiring. I've always tried to have a very, very small, very lean team, which I believed in a lot. I consistently underestimated how many people we needed to be.

I had this slide that I drew up maybe a year and a half ago that I showed the entire company. It was the 300 Spartans versus the Persians, and it was Legora and the 300 Spartans. I'm pretty sure I said we would cap out at 20 engineers or something like that, which is way undershooting it.

How many engineers do you have today?

Today, we're about 80. You got that wrong on Twitter, didn't you?

Yeah, I got that really wrong.

And we're way too small still.

As a result of being too small, are you too slow, or are you not able to build what you want to build?

Second, there are loads of features that you can basically staff a team to build.

Can you ramp as quickly as you need to and retain quality?

Yes, we're really good at this, actually. First, we're extremely selective with hiring. Maybe that's also why we're slower at hiring. We hire really great people, and the ramp-up time is extremely fast.

How do you make ramp-up really fast, as specifically as possible? Anything that you do?

I can tell you what we probably should do.

Sure.

The reality is that things move really fast. You need to have—so, we have a developer experience team, relatively new. Again, a mistake I made. I should have staffed that earlier.

They are making everyone's life so good. What do they do?

10. The Developer Experience Team: The Most Underrated Hire in Engineering

They make sure that our local development setup works really well. It's super fast and spins up really quickly. We have our own background coding agent that they built that allows each engineer to have 10 different agents running concurrently with all of our local development, a browser, and all the iteration stuff.

They're building custom review agents. They're building features so that it can wait in CI until everything looks green and all the reviews are good, and then raise it to a human. The efficiency gains there are huge.

They also build tooling that helps onboard people. It can be as simple as making sure you have really good README files in your repository, so that a new engineer can just ask their Claude Code or their Cursor about all their questions. That's remarkably effective. Even just AI tooling makes it faster to ramp.

How many do you have in developer experience, and when do you think you should have done it?

We have 3 people now, which is too few. I should have done it when Opus 4.5 came out, I think. The productivity of each engineer was 10x, let's say. If you can make everyone 20% more efficient, it's even more gains.

How does hiring engineers in Europe differ from hiring in the US?

11. Hiring Engineers in Europe vs. the US

There are a few different ways that it differs. In the US, people are generally less risk-averse. They'll be ready to jump on a lot of things to test. I think in Europe, people are more risk-averse.

People in Europe—and I'm super generalizing now—but I think generally are more—I don't want to call them mission-driven or loyal, but they really buy into the company that they work for and work with. It takes a lot of time to convince them, but once they're convinced, they really stay. That's great.

And the US is more transactional?

I think so. Yeah.

Do you find the attachment to equity different?

It's actually something that we had to educate people on in Sweden and in Europe. I think people are just not used to the venture thing. They don't know how to value equity the same way. You have to really explain: this is how it works, this is what it means, and if this happens, then you get this much money. But you don't get it in cash. It's not like—

Yeah, exactly. And then there's tax and—

I do it with our team, and they're like, “Wait a minute, you're giving me half a million?” Not literally, but in the future.

In a way. Yeah, exactly.

That's been a little bit difficult for us. But I think that's part of just creating the ecosystem. In 10 years, the next startup that comes out of Stockholm hopefully won't have this problem.

Totally get that. Can I—everyone is encouraged to use as many tokens as possible. I'm on the board of public companies, and they're like, “Oh, I'm hearing about token maxing.” What do you advise a CEO in terms of intelligent usage of AI? Should we just be pushing tokens as much as possible, or do we just need to pump the brakes a little bit here?

A few different things on that. I think, one, having a leaderboard. A lot of people say this: get a leaderboard and bring up token usage at performance reviews. That leads to token maxing, which is people just burning tokens to look good. That's a really stupid way to do anything.

Do hack days, do demos, and have people show everyone else how efficient they are and how much better they're doing. Reward them for being effective and efficient and having more output, not necessarily for using AI. But AI will be the way there.

I think that's one of the points for enterprises. This is actually where I think Cursor has a reason to live, a reason to exist: if your options are Codex, Claude Code, and a neutral third party, and you pay consumption-based costs, Cursor can help you optimize your token spend a lot. They can optimize your usage. They can route requests to the cheap open-source model or help you set limits for whatever models you want to use for whatever thing.

Well, can they now, post-acquisition?

We'll have to see if they—

I actually disagree, and that's why I think both Cognition and Factory will do very well, because they're model-independent. But if you—

Okay, because you think now that they're tied to X?

100%.

Yeah, I was a bit surprised and a bit sad to see the acquisition.

Why?

Because I thought that if they stayed independent, they had a really cool story. But I see the synergies, obviously. They don't have enough compute, they can't train their own models, and they probably have to train their own models. I just think it's a shame that the industry is vertically integrated in that way.

Do you think IDEs are dead?

The current shape of an IDE will die. I don't know what the new, the next IDE is, but it's not reading lines of code. It's maybe graphical, honestly. Maybe it's the systems, the architecture that you look at, review, and plan there, and then agents run off and make sure that whatever you're planning actually is what's being made. I don't know what it looks like, but I don't think it's lines of code.

What percentage of developer salary would you be willing to spend on AI tooling for them?

I don't want to say infinite, but for me, it's a question of opportunity cost. We're in a competitive environment.

Are you?

Yeah.

No way. I didn't know that.

There's so much—so many things that we can do.

Fascinating.

I know. The cost of not doing it is extremely high, and it almost outweighs any sort of token cost. Any efficiency gain is worth so much to us. It's not like that for us, but for certain companies, that will look different.

Is it worth us spending a ton of tokens to learn if it maybe gives us 20% efficiency? For us, yes. We have a really high opportunity cost.

What did you do that you wish you hadn't done?

Not investing in developer experience fast enough. Definitely a problem. Underestimating our growth was also a problem.

Now I make sure everything we build will scale to 100× the usage. I used to say 10×, but that was not enough. So now everything needs to scale to 100×.

What changes when you're building for 100× versus 10×? I'm sorry, I'm very naive.

No, that's not naive at all. It doesn't always have to change, but there are certain limits that you often put in place. You say, “This probably is good enough for the next 3 months.” If we bound the problem in this way, which is maybe 10×, then we can do X, Y, Z, but maybe that doesn't hold if you're at 100×.

Sometimes you need to think about particular problems where there's burstiness to them. Tabular is one of our products where you can bulk-extract from many documents and many, many cells. There's a very big difference between 10,000 cells and 100,000 cells in terms of the load on the system, because it spikes immediately. That's one of those systems where there's a difference.

What do you do in that case, where the spike is so immensely different? What does that mean you subsequently do differently?

We have to think about the experience. If 10 people do that crazy thing at the same time and we still have a bunch of other users who we want to have a good experience, we need to think about fair queuing, basically.

If you're running 100,000 cells, you're probably okay waiting a bit. You can go grab a coffee, and that's fine. But if you run 10 cells at the same time, those should be really fast.

Totally get you. If I ask a really unfair one, if I gave you access to a superior model for 6 months ahead of anyone else, or superior engineers for 6 months ahead of anyone else, which would you rather have?

Engineers, for sure, because the models change all the time. They get better all the time. But if you have really good engineers, you can build a system that exponentially improves, and that's worth a lot more.

What do you know now that you wish you'd known when you started on day 1?

Honestly, I wish I'd known how quickly we were going to scale, because that was the thing that I underestimated all the time. I don't think I was ready for this journey. I became ready because I got slapped in the face every 3 months.

Do you buy that people are destined for certain stages of companies? I'm getting very personal. If I was you now, I'd have in my mind, “Am I the CTO that takes this to public companies?”

It's a very fair question. Do I? No, I don't buy that. To me, it's a question of how quickly I can solve problems. Am I the person who can solve the problems that we have right now the fastest, or can someone else solve them faster than me?

We have a great culture at Legora in that no one has any ego. I currently have 2 engineering directors. I've told both of them, when I hired them, that if there comes a day when I think they'll do better than I will, then we swap, or I do something else.

I have very little tied into my title or my role, and they also have very little tied into theirs. We are here to build something huge, and that's the most important thing. I continuously evaluate myself on my job performance, and if I don't do well, I try to rectify that really quickly. I haven't been unable to rectify it yet, but maybe there comes a day.

What's the secret to hiring the best engineers with no ego, and how obvious are they?

It's obvious if they have ego. You can tell even when you negotiate salaries and titles.

I don't know about you, but I always say great people want more money. They don't mind so much about the title.

I think that's right. I think that's absolutely right. Most of the people we hire, we don't even talk about the title. We talk about the difficult problems that they're going to work on.

How important is it that you're together in Stockholm?

It's been very important for running really fast. We talked about the handover cost.

If you have a product manager, a designer and an engineer, and they just sit together, you can almost not even have a handover. If you just run at this problem and do it together, the 3 of you, next week it's done.

But if you have them siloed and there's a handover in between, you lose so much efficiency. You jump on a Zoom call lacking clarity.

Yeah, this document is not well written enough.

You have to do another meeting, and then you have to do 3 reviews of the document. Then someone else has an opinion, sees it somewhere and writes a comment somewhere, and then you have to talk about that.

How do you factor that into the fact that the best engineers like to be remote?

We're very opinionated about who we are and who we aren't. If you're a great engineer and you want to be remote, then you probably also want to work on very isolated problems. That can be fine. We probably have those problems, and we probably will have those, but they're not for us right now.

We'd rather find the people who want to solve the same problems with other people.

How many engineers will you have in 2 years, or by the end of 2027? You're at 80.

Yeah, I'm going to say a number that's too low.

I'm going to WhatsApp it to you on December 31, 2027.

Were you wrong?

The answer will be yes. I don't know—300, maybe 200.

Two hundred and 300 are different. You've got to put your name on one.

If I have to put my name on it, I want to say the lower number. Let's say 270.

270. Okay, so we're going to have 190 more.

Yeah. Can you retain A talent with 190 more? That's essentially adding 2.5 a week.

Yeah, that's possible if it's linear. I think so. I'd rather miss my number and have A-players than hit it with B-players, because as soon as you introduce B-players, as soon as you have people you don't trust or that the team doesn't trust, the A-players won't stick around.

12. Token Maxing: Are Enterprises Using AI Wrong?

You're buying more companies than I'm doing podcasts these days.

And you're laughing because it's true.

It's not true. I'm essentially an investor. My question to you is: do you have to buy companies to get truly, truly A talent in a lot of cases?

I don't think so, but it's faster. That's essentially why. If you find a really good founder, they're able to attract really good talent. You have a small group of 5 people who are just A talent, and then you get 5 in 1 week. If you have to get 2 every week, that's much faster than going to all the big companies, or even the startups, and trying to convince them to come over.

People also like it if you have a small startup of 5–8 people. They want to work with each other.

Do you just shed their codebases then, or is it pure acqui-hire in a lot of cases?

It can be both. If they've worked on adjacent things, or things in a similar field, or even unrelated but similar technology, we'll take all their learnings and we might rebuild them into Legora.

I think that's what happens in most cases, but they become fully embedded into the team. They're all Legorans working on their Legora codebase, and then they might bring some learnings.

Is integration hard?

No, it's surprisingly easy if you hire people with low ego. That's the thing. If you get 5 great engineers who don't care about their titles or where they sit in the org chart, and who just want to solve problems, it's surprisingly easy to integrate.

When you've got engineering hires wrong, what did you not see that you wish you had seen?

Typically, when this goes wrong, it's actually because of—I'm going to be a little bit introspective here—my own lack of experience. I've not run an engineering team this big before.

I start doubting myself. I'm not confident enough to say that this person, who's more senior than me and has seen more than me, is wrong. It's happened once or twice with a very senior person. We talk, and they talk about building and design and how they think about all of this.

I sense that something's wrong, and I know that all the time, but in the end I convince myself that they probably know more than me, or that they've figured it out. Then, if 2 weeks in, 4 weeks in or 6 weeks in you start to figure out that they didn't, you know.

How fast do you know if you've made a mess?

A month. Then you know, and then you give them really strong feedback. I give really strong feedback after 2 weeks.

What does really strong feedback mean, Jacob?

“You're not going to stay if you don't change this.” That's what really strong means. Feedback is feedback.

Has anyone ever recovered from a “You're not going to stay if you don't change this”?

No, but they need to get the chance, and if they do, they stay.

What is the hardest role to hire for today?

I think senior management is extremely difficult to hire for.

Senior management? Horizontal senior management.

No. Yeah, engineering directors and engineering managers within product and engineering. Maybe that's always been difficult, but I think it's because we only have really technical people also being managers, and anyone who's seen scale is typically no longer technical.

Do we still have managers? One of my dear friends, Jason Lemkin from SaaStr, says that anyone on LinkedIn who talks about their team should be fired—fired straight away. We don't want managers who manage other managers who manage other managers. If you can't do full-stack, get out, pick up your severance, and go away. Do we still want senior managers?

It really depends. You can build a company of super-senior engineers that can do everything, and you probably don't need to manage them at all, especially if they know what they're trying to achieve. The Codex team, for example, all know what they're building. They can just run at it, and they don't need anyone to tell them that they're doing well.

But if you have a more complex product that can go in many directions, you have to do constant prioritization, and you have a suite of engineers and a team of engineers. The way that we have engineering teams is relatively small teams—let's say 6 people, a PM, and an engineering manager. The engineering manager is super technical and spends most of their time coding. They're not people who hold each other's hands and sing songs. [laughter]

It's still important that I have someone who's accountable to team health. Are people doing good jobs? Are people having fun? I can't walk around and judge everyone. Are they doing well? I think it's important to have someone who's accountable, and that's how we run it. They decide their own roadmap. They're their own little startup, but one person is accountable.

Is Max on every new product feature?

On big ones, yes. On smaller ones, no.

Is that right?

It's worked for us. So far, it's worked great. At the same time, Max is an amazing salesman, which you probably know. [laughter] I think Max spends his time on that, and he spends his time on product vision and the important product things—big launches and big things. He's involved early and for the duration of the project, but for small things, that's the reason you hire great people: so you can let them do this.

The thing with Max that's special is that he so believes what he says. Often, when you're being sold to, you know you're being sold to.

Yeah. Yeah. Yeah.

No, no. There is no way that he sees himself being wrong—

In his bones.

Absolutely.

Yeah. Absolutely.

There was this brilliant—we naturally hate them because they're cunts—but Sifted did that piece, “A Taste of Blood.”

Yeah. Yeah. Yeah. The “A Taste of Blood” piece.

Did everyone at Legora just go, “Oh my God”?

Yeah, that was hilarious. There are screensavers now that say “Blmuck” [?] on them. [laughter] It's become this internal meme.

Did you guys like the Jude Law campaign?

I loved it. I've sat on that secret for 9 months.

Did you think it was done well?

I think so. Yeah.

Yeah. Well, you asked, I guess, if it was not done well. I think the Jude Law idea was great. Did it do well for you guys, do you think?

Amazingly well. No, no—crazy.

Yeah, it's wild.

Yeah. People see it everywhere, which is great. People talk about it a lot, which is the goal of the campaign, right? We need to get everyone talking about us.

Dude, we're going to do a quick-fire round. I say a short statement, and you give me your immediate thoughts. Does that sound okay?

Yeah, let's do it.

What have you changed your mind on most in the last 12 months?

Hiring. [laughter]

Hiring.

Yeah. We need to hire more. The net is, as long as adding someone is net positive, we should add someone.

What's the most underrated AI company today, do you think?

Legora.

Dude, I'm an ambassador, and even I'm like, “No fucking way, dude. Goodbye.” [laughter] You're going to give me another one.

I had to say it.

I had to say it.

I know there are loads. One for me would be Whisper Flow. The pain of removing Whisper Flow for me is immense.

Whisper Flow is great.

I think we're going to get more local models, though. Whisper Flow is not local.

So you're probably going to get a similar Whisper. Well, maybe they should just go local. But the tool itself is great.

The thing that's going to kill us is if we don't keep reinventing ourselves. This sounds really boring, but I think we talk a lot about staying in our swim lane, focusing on our product and our users, while the entire environment is moving so much. If you had me on this podcast a year ago, it would have been very different. I think the main thing that's going to kill us is if we lose the ability to constantly react, readjust, and reinvent ourselves.

You just worked with Jude Law in terms of brand campaigns. What sports team would you most like to see Legora across? It could be F1, football, or the NBA.

F1 would be great. I'm a big F1 fan, but F1 would be awesome.

Strategically, would that be awesome? You do golf very strategically.

We do golf. We sponsor the Yankees in New York, which is also great.

You sponsor the Yankees?

Yeah. You didn't know this? Aaron Judge.

Holy hell. How much does that cost?

That I can't tell you. [laughter] But the team that I would want us to sponsor is my local FC Copenhagen football club. That would be a childhood dream. They're doing really badly right now, though, so it's probably really cheap, actually.

It's called exposure.

Yeah. [laughter] You would get no Champions League. No.

Yeah. No Europe.

They're not even top of the Danish league.

Yeah. Yeah. You know, you should be cheap.

It's okay. [laughter]

What is one thing you believe about the future of law that most people would say is crazy?

13. The Crazy Prediction: Lawyers Will Work One Level Above the Contract

If I had to get crazy, I think there are lots of analogies to coding. In law, it's very text-based. The agentic AI features are similar. If I believe that in coding we're going to look less at source code and more at one layer above, I have to say the same thing about law. Eventually, lawyers will not be nitty-gritty about the language of contracts. They will work a level above, which is maybe, “What's our negotiation stance?” or, “What risks are we okay with? Which ones are we not okay taking?” They won't sit and type into Word.

I'm not sure if this is true, but this is my hunch—that it's going in this direction.

Like lawyers' processes. Now I'm just like, wow, you seem to have done 100 NDAs. Why are we writing it fresh?

This feels like a solved problem.

I'm going to get in so much trouble for this show. [laughter] Holy hell. What's the biggest piece of advice to a founder competing in a business or industry where there is an 800-pound gorilla?

Honestly, just work harder than the 800-pound gorilla. People underestimate this. No one in the 800-pound gorilla is extremely excited to be there, you know? If you're competing against Google, the PM at Google that you're competing against does not give a shit if it goes well or not. Maybe she tries really hard, but I don't think that if you're a small, lean team and you work really hard, you can't do really remarkable things.

You ready for a bet?

Yes.

What are we going to end the year at, revenue-wise?

It's going to be above 250.

I'm going with 272.

272.

Yeah, I think it's going to be above that, too.

I don't—yeah, but I don't want to. I don't know numbers.

I didn't mean it. Max and Patrick, I don't know. David's going to call me really mad soon. [laughter]

Dude, this has been such a pleasure. I've loved having you, and you've been fantastic.

Thank you.