Why AI-First Companies Fail Without Product Judgment

Legora’s hypergrowth reveals a hidden truth: the real bottleneck in AI-first companies isn’t code--it’s product judgment and system design. While everyone races to tokenize faster, Jacob Lauritzen exposes how over-optimizing for immediate output creates downstream fragility in architecture, security, and team dynamics. This isn’t about coding efficiency--it’s about who owns the why behind the work. For leaders in fast-scaling AI-native startups, the advantage doesn’t come from burning more tokens; it comes from resisting token maxing culture and instead investing in feedback loops, guardrails, and meta-engineering that make agents productive, not just active. The companies that win won’t be those with the most AI spend--they’ll be the ones who built systems smart enough to survive their own speed.

Why the Obvious Fix--More Tokens, Faster Output--Makes Things Worse

The podcast opens with a deceptively simple question: What percentage of developer salary would you be willing to spend on AI tooling? Jacob Lauritzen’s answer--“I don’t want to say infinite”--seems like a rallying cry for AI adoption. But peel back the tone and you find a sophisticated cost-benefit calculus rooted in competitive urgency, not unchecked spending. This is where most misinterpret the signal: Lauritzen isn’t advocating for mindless token maxing. He’s warning against it.

"Having a leaderboard... brings up token usage at performance reviews and that leads to token maxing which is people just burn tokens just to look good. That’s a really stupid way to do anything."

-- Jacob Lauritzen

Here’s the hidden consequence: when companies tie performance to token consumption, they incentivize activity over impact. The immediate benefit? More code, faster. The downstream cost? Engineers gaming the system, generating low-signal output, and bloating codebases with unreviewed AI-generated logic. Over time, this creates a fragile system where no one truly understands the codebase--because it wasn’t written by any one person, but by agents trained on inconsistent patterns.

Lauritzen’s insight reframes the entire AI productivity narrative. The real competitive advantage isn’t in how much AI you use, but in how intentionally you use it. He favors hack days and demos--measuring output, not input. This shifts incentives from “burn more tokens” to “ship more value.” The system responds by rewarding engineers who build with AI, not just through it.

This has profound implications for enterprise startups. Most assume that scaling AI means scaling usage. Lauritzen argues the opposite: scaling AI means tightening control. As he puts it, “We have to set up the guardrails really effectively.” Without them, the speed becomes self-destructive. The pattern repeats: burst of output → accumulation of unreviewed code → security debt → incident → slowdown. The faster you go without guardrails, the harder you crash.

The Bottleneck Has Shifted--And Most Teams Haven’t Noticed

For decades, software development was bottlenecked by code creation. Writing clean, functional code took time. That era is over. With tools like Cursor and Cloud Code, code generation is now “super cheap.” The rate-limiting step is no longer coding--it’s product work and review.

"The bottleneck now is... how can we actually do the product piece much more efficiently... because if you believe that code is cheaper to write, then naturally the two other things are bottlenecks."

-- Jacob Lauritzen

This is a systems-level insight most miss. Teams keep optimizing for a bottleneck that no longer exists. They hire more engineers, add more sprints, but fail to realize that the constraint has moved upstream--to product managers synthesizing user needs, and downstream--to code review processes that can’t keep up with AI-generated pull requests.

Lauritzen’s approach at Legora reflects this shift: PMs now prototype themselves using AI, front-loading validation before engineering even touches the code. This reduces handover cost and keeps PMs focused on high-leverage work: understanding users, not writing specs. The delayed payoff? A tighter feedback loop between user pain and product iteration--something that compounds over time.

But this only works if PMs aren’t distracted by low-level coding tasks. “If your PMs are spending 50% of their time coding, we’re missing out on so much product work,” Lauritzen warns. The opportunity cost is too high. This is where conventional wisdom fails: in a world where AI can code, the most valuable skill isn’t coding--it’s taste.

And taste, Lauritzen argues, is not Silicon Valley fluff. It’s the opinionated stance that prevents AI from converging on generic, indistinct outputs. “If you don’t have taste, you let AI slob converge to grayness,” he says. The companies that win won’t be the ones with the best models--they’ll be the ones with the clearest product vision, enforced through design language and architectural guardrails.

The 18-Month Payoff Nobody Wants to Wait For: Investing in Developer Experience

One of Lauritzen’s most revealing admissions? “Not investing in developer experience faster enough--definitely a problem.” This wasn’t just a missed efficiency; it was a compounding delay in organizational velocity.

His team now has a Developer Experience (DevEx) team--three people building tools that make every engineer 20% more efficient. They built a local coding agent, streamlined onboarding with AI-powered READMEs, and automated review workflows. The result? Faster ramp-up, fewer bottlenecks, and a culture where engineers can focus on high-impact work.

This is the kind of investment that pays off in 12--18 months--not because it’s flashy, but because it’s foundational. Most companies won’t make it. Why? Because the payoff isn’t immediate. You can’t put “improved developer experience” on a quarterly OKR and measure it in shipped features. But over time, it creates a compound advantage: faster iteration, better retention, and higher-quality output.

Lauritzen’s regret is telling: he underestimated how fast Legora would scale. He once thought 20 engineers would be enough. They now have 80--and are hiring for 270 by 2027. The lesson? “Everything we build will scale to 100x the usage.” This isn’t just about load testing--it’s about designing systems for burstiness, where 10x spikes become 100x. For example, their tabular review product behaves differently at 10,000 cells vs. 100,000. The solution? Fair queuing--letting large jobs wait while keeping small, interactive ones fast.

This kind of forward-thinking design is rare. Most teams optimize for 10x and call it a day. The competitive edge goes to those who design for 100x, even when it feels unnecessary. Because in hypergrowth, what feels unnecessary today becomes critical tomorrow.

How the System Routes Around Your Solution--And Why That’s Good

Lauritzen doesn’t believe in passive AI adoption. He believes in shaping the system. “We need to mechanistically enforce the system to behave a certain way,” he says. This means custom rules, review bots, and architectural constraints that guide AI behavior.

This is systems thinking in action: instead of assuming AI will do the right thing, you design the environment so that even suboptimal actions lead to acceptable outcomes. It’s like designing a city with one-way streets--drivers can still make mistakes, but the system routes them back on track.

One underrated implication? Enterprises that fail to set these guardrails will face a quiet crisis: they’ll lose control of their own software. As AI builds internal tools--HR systems, payroll, talent acquisition--without human oversight, the risk of drift, inconsistency, and security flaws grows exponentially.

Lauritzen’s vision--a team dedicated to internal AI systems--isn’t just about efficiency. It’s about sovereignty. “If enterprises don’t create that role, I’ll get really annoyed,” he says. Because the companies that win won’t be those with the best off-the-shelf tools--they’ll be the ones who built better feedback loops for their AI agents.

Key Action Items

• Over the next quarter: Replace token usage metrics with output-based performance reviews. Measure shipped features, not AI consumption.
• Within 3--6 months: Establish a Developer Experience team focused on onboarding, local tooling, and AI review automation--starting with at least two engineers.
• This pays off in 12--18 months: Design all new systems for 100x scalability, not just 10x. Invest in fair queuing and burst handling for high-load endpoints.
• Immediately: Implement AI guardrails--custom rules, model routing, and security review bots--to prevent uncontrolled code generation.
• Ongoing: Prioritize PMs who focus on user synthesis and product vision, not low-fidelity coding. Protect their time as a strategic resource.
• Within 6 months: Run internal hack days to prototype and demo AI-built tools--especially for HR, payroll, and enablement--before buying external solutions.
• Discomfort now, advantage later: Accept slower initial hiring to maintain team quality. A-player retention depends on not diluting culture with B-hires.