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 sort of token cost.
Harry: Now, I'm so excited to welcome Jacob Eriksson, CTO at Legora, to the show today. The fastest growing enterprise company in history. They hit 100 million in ARR in just 18 months. Jacob is one of the best product minds I've had on the show. Specifically from the last crop of product leaders in this AI generation.
Jacob: Honestly, just work harder than the 800lb gorilla. People underestimate this. Like the 800lb gorilla, no one in the 800lb gorilla is extremely excited to be there.
Harry: Jake, dude, I am so excited for this. Now, we were just chatting and you said Legora is the first kind of big company of this size that you've worked at. And I was thinking, is that a blessing or is that a curse? How do you think about that?
Jacob: 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, maybe even, and so in that way it's really good that I come in naive and I'm like, okay, let's try to do it this way and 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 just work with the team β what's working well, what's not working well, how do we solve that, just like any other problem.
Harry: How is it different building a team or a product in 2026 versus 2024 and years prior?
Jacob: Everything is just changing all the time right now. Productivity is through the roof. Processes are up in the air. You can be huge teams, you can be tiny teams.
Harry: Productivity is through the roof β if we unpack that, why?
Jacob: Just AI tooling. What do we use internally? It's Claude Code, it's Cursor β those two are competing. We still have Cursor users; the Cursor harness is quite good. Some people use Claude Code, some use Pi because Claude Code's harness is annoying sometimes. We allow people to do both. And so we have efficiency against that. We ship more, we ship faster, we debug things faster, we iterate faster. Each engineer can produce much more than they could previously.
Jacob: A way I like to think about it is when you build software, there's three phases. Phase one is the product work β what are we building? Translate user pain, user dreams, nightmares into something tangible that we can iterate on. Then phase two β you write the code. Then phase three β you review it and you merge it. Number two was the primary bottleneck for the past 100 years almost. The rate limiter was how quickly can you write code? That is now super cheap. So that's been compressed, and the bottleneck now is the two other ends.
If you believe that code is cheaper to write, then naturally the two other things are bottlenecks. One of the focus areas is: how do we do the product work as efficiently as possible?
Jacob: Part of that is how do we make our PMs as efficient as possible? How do we take all the working-with-clients, synthesizing what they think, our own strategic priorities, our own taste and opinions of where our product is going β and hand that over to engineers as efficiently as possible? I'm not sure if I've solved that yet, but that's the way I'm thinking about it: constantly asking what's the bottleneck to our velocity, and then we try to solve that.
Harry: You mentioned the expansion of the Legora codebase β what percent of code created today is AI-generated versus human-generated?
Jacob: Actually, I took a look recently and it's Claude and Cursor on top, and there's like 2% between them. They are really really close. And then it's miles above the next engineer. So they're way above 50%.
Harry: Do we see AI code review becoming the dominant source of review, and does that then remove it as a bottleneck?
Jacob: I think so. We do AI code review today and it's in its nascent phase. We have AI review bots β security review, different specialized reviewers. They do tons of review, and they iterate with the AI coder. You see this pattern where it's like agents fighting each other until they arrive at something. But even then, current review tools are not good enough. I keep telling people at all events: if you're gonna 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, on systems design stability, on security boundaries. How does it take our system in the right direction? That's the kind of stuff you want to review. If that doesn't change, then maybe you don't have to review it at all β just unleash the agent. If there are strategic trade-offs, you want a human to say, "yeah, this is the right direction."
Harry: Is that the future of engineering β systems design, systems architecture, and bluntly code creation/maintenance is done by AI?
Jacob: Yeah, I think that's right. The job of an engineer is changing from typing a bunch of code to one layer above β what does the system look like? You have AI running around inside each of the pieces. Engineers think about the higher-level abstraction: what does the system look like, what are the bets we're making, do we want to invest into something here that we can reuse over there. The other thing engineers are doing more is the meta-engineering of making agents really effective. Like developer experience teams β but for agents. How do we make sure agents can independently self-improve the system? Can we gather data in a way that we can unleash agents and say "hey, increase conversion rate on my e-commerce store" and they go run experiments? That setting-up-the-loop is going to be the actual job of a lot of engineers.
Harry: Do you worry that we will see a next generation of security threat with the amount of AI-generated code opening vulnerabilities?
Jacob: Yes, absolutely. This is very top of mind for me. That's why we still at Legora β and probably in a bunch of other enterprise software β we review human PRs every single one, just because we have to be sure. I think that's inefficient. I want to get some risk scores in there. But fundamentally, threat actors are extremely efficient now, which means they can try so many different things. We need just as good defense, and I'm not sure if we're there yet. One of our vendors had a security incident just yesterday. We just rotated a lot of keys. It's just internal β doesn't affect any of our clients β but I think we're going to see more of them.
Jacob: Our codebase is starting to get large. We're starting to be a lot of engineers, and also a lot of agents working together. You start to think about how can I mechanistically enforce the system to behave a certain way. You can have custom rules β the agent tries to do something and we tell it, "no, you can't do that, because we want the system to be this way." That type of guardrail setting will be everywhere. If you're a big enterprise rolling out AI tooling and you have agents building your internal software β your HR system, your ATS system β you probably have some engineers just setting up "this is where you get the data, this is what you can do, this is what you can't do," and then letting agents run amok inside that.
Harry: How do processes change β PRs, postmortems?
Jacob: Postmortems is a great example. We run them really efficiently now. If you have an incident, you just unleash an SRE / incident agent. It will super quickly figure out what's going on β look at all the logs, all the metrics, all the telemetry. It's surprisingly good. Instead of having a bunch of engineers wake up in the middle of the night, you still have some waking up, but they're really well-equipped. The postmortem almost writes itself.
Broader in the software development life cycle β PMs can prototype super fast. They can frontload a lot of the work. A PM can prototype it, go to a user, test, iterate themselves. They don't even need to bring in engineering until they have something clearly super valuable.
We have a developer experience team β relatively new. A mistake I made: I should have staffed that earlier, when Opus 4.5 came out. They make sure our local dev setup is fast. We have our own background coding agent that allows each engineer to have 10 different agents running concurrently with all of our local development, a browser, all the iteration. They're building custom review agents, features so it waits in CI and only raises to a human when everything is green. They have three people now β too few.
Harry: Do you vibe code internally within Legora for customer presentations, for you name it?
Jacob: Constantly. We have a team now that's internally enablement β just reimagining from first principles. If you're building the most efficient company to go from 200 to 1,000 employees, what does that look like? Obviously Claude Code-equivalent for everyone, but also: can we just build a bunch of the tools we need ourselves? Can we vibe code our HR system? Our talent acquisition system? Our payroll system? There's so many things where tools exist, but you always need to customize them so much they basically never really work β and we just built them now, because it's so cheap to build.
Jacob: Ryan, who joined from Canada β we have a team of people moving from Canada to Sweden β vibe-coded an app to help everyone migrate. Very specifically: if you're Canadian, these are all the laws, all the steps you take, it's interactive, you can see how far you've made it. Took a day to vibe code. Saves so much time for an entire team.
I was with a friend who's a public company CEO. He said his chief of staff took three weeks off and basically vibe-coded Workday β they replaced Workday with it. And it works. It's brilliant.
Harry: What do you say to people who think that's ridiculous β why bother vibe coding an HR system when you can just buy it?
Jacob: It depends on the system. Two axes: how big is the product surface area, and how complex is it (deep vs shallow). If it's deep β there's just too much stuff and it's not viable for you to build. If it's shallow but requires a lot of customization, maybe you just build it. That's probably the right thing to do.
Harry: Does the role of the PM change in the next few years?
Jacob: Yes and no. A lot of people are saying product and engineering are converging β one person can do everything. For some companies that's true. For Legora, where you really need PMs, it's not β or it can be true but it's inefficient. The bottleneck is no longer coding β it's the product work. So you don't want your product people to do engineering, because the opportunity cost is really high. If your PMs are coding 50% of their time, we're missing out on so much product work. It's good if PMs do some vibe coding to show high-fidelity prototypes β reduces handover cost. But they shouldn't spend a lot of their time engineering.
Harry: Do we skip the design stage?
Jacob: Probably some companies will skip the design phase on functionality. You don't need a long discussion with 10 people figuring out where the button should be. But design still has a place β one level above individual features. The design language, the taste, the opinionated stance: who we are, what does Legora look like, what's the navigation, what's the hierarchy. More for consistency UX/UI and taste, less for individual functionality. We still use Figma β as soon as you build a system larger than something small, you want consistency. Figma's a storage feature though β could be something else.
If you don't have taste, you let AI slop converge to grayness β everything looks the same. You need taste to have an opinionated stance: this is who we are, this is what we do, we don't do these other things. Some of you are going to hate it, and that's okay. You need to have edges. If you're just letting AI rip, you're going to look the same as everyone else.
Jacob on copying: There are tons of people vibe-coding Legora, vibe-coding Salesforce, DocuSign. It's very quick to get to the 90% where it looks the same. It's the other 90% that's difficult β the edge cases, unhappy paths, audit logging, RBAC, weird scenarios at scale. That's what's hard. We just stay focused on creating value for clients and sprint towards that.
Harry: To what extent does Legora's quality depend on the underlying models?
Jacob: Much less than most people think. The value of Legora is so much more β the primitives that make sense for legal, all the enterprise features, the optimal routing between models. We wouldn't exist without the models, and every time models get better our product gets better. But if you took away a model, people would still pick Legora. They don't buy based on the model.
Harry: Do you use 15 models at the same time?
Jacob: Not 15, but maybe 10. For each task we evaluate what model is best at: latency, performance β not so much cost. Eventually cost will matter, but latency and performance are most important. Performance needs to be at a certain level; how much can we increase latency without dropping performance.
Harry: Performance or latency β pick one.
Jacob: Almost always performance. If you're a lawyer, you can wait two seconds more β or an hour more β for a better output.
Open source is having a great moment. There are so many great open source models now. We're moving very close to doing things on device. I have a local Qwen running on my Mac so I can keep coding on flights with no Wi-Fi. I really hope to see European and American open source models β they've been lacking. Game-theoretically, we don't end up in a great place if there's a duopoly or monopoly on the models.
Harry: Does Europe have any place to play in the model race?
Jacob: It should, but it doesn't yet.
Jacob on Cursor / xAI acquisition: I was a bit surprised and sad to see the acquisition. If they'd stayed independent, they had a really cool story. I see the synergies β they don't have enough compute, they probably have to train their own models β but it's a shame that the industry is vertically integrated that way. I think Cognition and Factory will do very well, because they're model-independent.
Harry: Do you think IDEs are dead?
Jacob: The current shape of an IDE will die, yes. The next one is not reading lines of code β maybe it's graphical. The architecture you look at, you review and plan there, and then agents run off and make sure whatever you're planning actually is what's being made. I don't know what it looks like, but it's not lines of code.
Harry: What's the most underrated AI company today?
Jacob: [laughter] Legora. I had to say it. WhisperFlow is great too β but it's not local. I think we're going to get more local models.
Harry: What have you changed your mind on most in the last 12 months?
Jacob: Hiring. We need to hire more. As long as adding someone is net positive, we should add someone.
Jacob: I had a slide I drew up a year and a half ago, showed the entire company β the 300 Spartans versus the Persians. I said we will cap out at 20 engineers or something like that. Which is way undershooting it. Today we're about 80. Way too small still.
Harry: How many engineers by end of 2027?
Jacob: I'm going to say a number that's too low. 200, maybe 300. If I have to pick β 270.
I'd rather miss my number and have A players than hit it with B players. As soon as you have people that you don't trust or the team doesn't trust, the A players won't stick around.
Harry: Do you have to buy companies to get the truly A talent?
Jacob: In a lot of cases β that's essentially why. If you find a really good founder, they attract really good talent. You have a small group of five A-players, and then you get five in one week. That's much faster than convincing them individually. People also like working with each other β they want to stay together.
Harry: When you've got engineering hires wrong, what did you miss?
Jacob: Typically it's because of my own β I'll be introspective β I've not run an engineering team this big before. I start doubting myself. It's happened once or twice when there's a very senior person, more senior than me. I sense something's wrong, but I end up convincing myself "they probably know more than me." Then 2, 4, 6 weeks in, you figure out they didn't.
Harry: How fast do you know if you've mis-hired?
Jacob: A month. Then you give really strong feedback β "you're not going to stay if you don't change this." Has anyone ever recovered from that? No β but they need the chance.
Harry: How important is being together in Stockholm?
Jacob: Very important. We talked about handover cost. If you have a PM, a designer, and an engineer sitting together, you almost don't even have the handover. Run at the problem together, three of you β next week it's done. If they're siloed with handover in between, you lose so much efficiency: jump on a Zoom call, lacking clarity, doc not well written, three reviews, comments, etc.
Jacob on Europe vs US hiring: US people are less risk-averse β ready to jump on a lot of things. Europe people are more risk-averse but more mission-driven and loyal. Takes time to convince them, but once they're in they really stay. We had to educate people in Sweden about how to value equity β they're just not used to the venture thing.
Harry: Everyone is encouraged to use as many tokens as possible. I'm on the board of public companies and they're hearing about "token maxing." What do you advise a CEO?
Jacob: A few things. One β having a leaderboard. A lot of people say "get a leaderboard, bring up token usage at performance reviews." That leads to token maxing β people just burn tokens to look good. That's a really stupid way to do anything. Do hack days, do demos, have people show everyone how efficient they are. Reward them for being effective and efficient and having more output β not for using AI per se. AI will be the way there.
This is actually where I think Cursor has a reason to live. If your options are Codex and Claude Code and a neutral third party β Cursor can help you optimize your token spend a lot, route to cheap open-source models, set limits per model.
Harry: Well, can they now, post-acquisition by xAI?
Jacob: Well, we'll have to see. I think Cognition and Factory will do well β they're model-independent.
Harry: What percent of developer salary would you be willing to spend on AI tooling?
Jacob: I don't want to say infinite, but for me it's a question of opportunity cost. We're in a competitive environment. So many things we can do, and the cost of not doing it is extremely high β almost outweighs any sort of token cost. Any efficiency gain is worth so much to us. For us, yes β we have a really high opportunity cost. For other companies, it will look different.
Harry: Finish this sentence β the biggest threat to Legora is not Harvey, butβ¦
Jacob: If we don't keep reinventing ourselves. If you had me on this podcast a year ago, it would have been very different. The main thing that's going to kill us is if we lose the ability to constantly react, readjust, and reinvent ourselves.
Harry: What's one thing you believe about the future of law that most people would say is crazy?
Jacob: Lots of analogies to coding. Law is very text-based. If I believe coding moves one layer above source code, the same will happen in law. Lawyers won't be nitty-gritty about the language of contracts β they'll work at the level above: what's our negotiation stance, what risks are we okay with, which ones are we not. They won't sit and type into Word.
Harry: Biggest advice to a founder competing where there's an 800lb gorilla?
Jacob: Honestly, just work harder than the 800lb gorilla. People underestimate this. No one in the 800lb gorilla is extremely excited to be there. The PM at Google you're competing against β he does not care if it goes well or not. If you're a small lean team and you work really hard, you can do really remarkable things.
Harry: What are we going to end the year at, revenue-wise?
Jacob: It's going to be above 250. Harry: 272. I think it's going to be above that too, but I don't know numbers.
[End of episode]