Jacob Lauritzen on AI Engineering, Legal Work and Building Legora

Legora CTO Jacob Lauritzen joins Harry Stebbings to discuss AI-assisted engineering, enterprise software and legal work. Stebbings says he is an investor in Legora; Lauritzen's assessments of its product and competitors come from his role at the company.

Lauritzen says Legora is the first company of its size where he has worked, and treats that lack of prior experience as both an opportunity to experiment and a reason for humility. He expects engineering organizations to keep revising processes as tools change.

He says Legora engineers use tools including Claude Code and Cursor and, in his experience, can ship and debug faster. The productivity comparison is his assessment of the team, not a controlled measurement or proof that all AI-generated software is better.

Lauritzen divides software development into product discovery, implementation and review. As writing code becomes cheaper, he sees product definition and reviewing architectural, security and reliability implications as growing bottlenecks. He is still working out how best to make the product process more efficient.

Legora uses AI review tools, but Lauritzen describes them as immature. He wants better tools that surface system-level consequences and trade-offs rather than forcing a reviewer to inspect every line; he sees continued human judgment as important for consequential changes.

He predicts engineers will spend more time designing systems and enabling agents, including setting up environments and feedback loops. This is a forecast about work, not evidence that code generation or maintenance can already operate safely without oversight.

For agents operating in a growing codebase, Lauritzen emphasizes guardrails: explicit rules about allowed actions, data access and system boundaries. Such controls can reduce risk but do not guarantee an agent will behave correctly in every case.

Asked about AI-generated code at Legora, he says Claude and Cursor account for well over half of the output, according to a recent internal look. He does not provide the measurement method, so the percentage should be read as his estimate.

Lauritzen agrees that more generated code can increase security concerns and says Legora still reviews every pull request by a human. He hopes risk scoring can improve efficiency, but says defenses are not yet where he wants them. He mentions an internal vendor incident that he says did not affect clients; the episode does not independently verify its scope.

He describes using an incident agent to examine logs and telemetry and help draft postmortems, while people still respond. Product managers can also prototype and test an idea with users before handing it to engineering for reliable integration, he says.

Lauritzen thinks design may shift away from discussing every individual feature toward consistent navigation, visual language and judgment. Legora still uses Figma for that purpose; he acknowledges the storage and design workflow could evolve.

He defines product 'taste' as an opinionated choice about what a company is and is not, rather than allowing generic AI output to make every product look alike. Stebbings questions whether taste is a durable differentiator; Lauritzen believes it can help create a distinctive experience.

A copy may look similar quickly, Lauritzen argues, but enterprise products also need edge cases, access controls, audit logs and reliable behavior. That is his competitive thesis for Legora's market, not a guarantee that a particular implementation is secure or defensible.

He distinguishes the speed of model development, product development and human adoption. For legal customers, he says the job is to translate rapidly changing technology into usable workflows and help clients adopt it; he hopes that reduces routine work and leaves more time for judgment.

Legora also experiments with internally built tools. Lauritzen cites an employee-created guide to help colleagues move from Canada to Sweden as a small example; it is a productivity anecdote, not legal advice or evidence that the app is complete or current.

On build versus buy, he distinguishes broad but relatively shallow applications from systems with deep hidden complexity. Heavy customization can make an internal build attractive in the former case, he says, while the latter may be impractical to recreate.

Should product managers become full-time engineers? Lauritzen says it depends on the business. At Legora, he believes customer research and synthesis are the bottleneck, so PMs should use prototypes to communicate clearly but avoid spending so much time coding that discovery suffers.

His advice to a new computer-science graduate is to learn how to learn and keep adapting as tools change. He believes adaptability and ambition will matter, although he does not claim there is a single guaranteed career path.

Lauritzen argues that Legora's value depends on more than an underlying model: he cites legal workflows, enterprise features and model routing. Models remain essential and improvements help the product, he says. This is the CTO's description of his company's offering, not an independent comparison.

He says the team evaluates roughly ten models for different tasks and generally prioritizes output quality over latency or cost. His example is that a lawyer may wait longer for a better answer; it does not establish that any AI answer is legally correct or suitable without review.

Lauritzen welcomes improved open models and gives examples of running smaller models locally. He wants competition and more European and US open models for sovereignty and security reasons, but does not claim any model is automatically secure because it is open.

On model architecture and training efficiency, he says he does not know whether current approaches will plateau or what will replace them. He mentions a new benchmark but explicitly says it needs validation; no comparative result is established by the interview.

Lauritzen expects enterprises to need people who build and maintain internal AI systems. He says Legora currently uses forward-deployed engineers to educate and help customers, while predicting the need for that support might decline over time.

Asked what competitor Harvey has done better, he says it hired more aggressively. Lauritzen regrets underestimating Legora's own engineering needs and says the team has about 80 engineers at the time of recording; that headcount is his statement, not independently verified.

He wishes he had formed a developer-experience team earlier. He says the current three-person team improves local environments, builds background coding and review agents, and helps new engineers find answers through repository documentation. These are his descriptions of internal tools and benefits.

Lauritzen offers broad impressions of hiring in Europe and the US, explicitly acknowledging that he is generalizing. He says Legora has also had to explain equity compensation to some European candidates; the experience should not be treated as a rule about workers in either region.

On token maxing, he criticizes leaderboards and performance reviews that reward consumption for its own sake. He prefers demos and recognition for effective output, and thinks routing and spending limits can help enterprises use different models appropriately.

Stebbings and Lauritzen discuss a reported acquisition involving Cursor and xAI and its potential effect on model independence. They treat the transaction as a premise, but the episode does not independently establish its terms or implications. Stebbings says he is an investor in competing companies elsewhere in the discussion.

Lauritzen predicts the integrated development environment will change, perhaps toward a visual representation of systems and architecture rather than a primary focus on lines of code. He says he does not know what the next interface will look like.

Asked how much he would spend on AI tooling per engineer, he says opportunity cost matters more than a fixed percentage: in Legora's competitive situation, faster learning and output can justify spending, while the right calculation may differ for another company.

He regrets investing too late in developer experience and underestimating growth. He now asks teams to consider whether systems can handle far more usage, including bursts from large document-processing jobs.

For a table that extracts information across many documents, Lauritzen describes fair queuing: large jobs can wait while small jobs remain responsive. This is an engineering design example, not a claim that all legal documents are correctly interpreted.

If offered either a superior model or superior engineers for six months, he would choose the engineers, believing a strong team can keep improving a system as models change. He also says he evaluates his own performance as CTO and would accept another person taking the role if they could solve the company's problems better.

Lauritzen says experienced technical managers can be hard to hire and describes small teams with a product manager and a hands-on engineering manager. The manager remains accountable for team health and prioritization rather than simply adding another layer of coordination.

He says close collaboration in Stockholm has helped Legora move quickly and acknowledges that its current approach will not suit every engineer who wants remote work. This is the company's preference, not evidence that remote engineers are generally less capable or productive.

Pressed for a headcount prediction, Lauritzen guesses roughly 270 engineers by the end of 2027 and says he is likely to be wrong. He would rather miss the number than lower the hiring bar; the figure is an uncertain guess, not an announced hiring commitment.

On acquisitions, he says buying a small company can bring a group of people who already work well together, sometimes along with technical learning. Whether a codebase is retained varies; he attributes smoother integration to people who focus on shared problems rather than titles.

Lauritzen reflects on hiring mistakes where he deferred to a more senior candidate despite reservations. He says he tries to give direct feedback early and a chance to improve, while admitting he has not seen someone recover after the strongest warning he describes.

He says CEO Max is involved in major product launches and vision, while smaller decisions are delegated. Lauritzen also says a campaign featuring Jude Law generated attention for Legora, an assessment from the company without independent campaign metrics.

In the quick-fire round, Lauritzen says he has changed his mind about hiring: he now thinks the company needs more people. He identifies failure to keep adapting as a greater long-term threat than any single competitor.

Asked for a bold prediction about law, Lauritzen suggests lawyers may eventually work more at the level of negotiation strategy and acceptable risk rather than drafting every clause themselves. He explicitly calls it a hunch and says he is unsure; it is not a description of present legal capability or advice to skip professional review.

He advises startups competing with large incumbents to work intensely and stay focused, expressing a broad personal view about large-company motivation. That generalization is not evidence about individual employees or a guarantee of startup success.

Asked for year-end revenue, Lauritzen and Stebbings offer tentative guesses above $250 million and $272 million. They immediately qualify the exchange; these are informal predictions, not company guidance or independently verified future results.