Becoming AI-Native: How Lean Teams Match Enterprise Output

An AI-native company is one built — or rebuilt — to remove bottlenecks by leveraging AI from the ground up, rather than bolting it onto legacy processes. As Truffle's Sean puts it, AI-native companies 'don't have any of the legacy and the complexity that comes with like decades of running a business'.

Becoming AI-native is rarely automatic, even for AI product companies. Truffle was 'probably not as AI native as we could have or should have been' at the start, but went all in over the last six months to make sure they were leading on the front lines.

Critically, this is not a tooling problem. As one Lemlist operator describes it, 'it's not really a tool question and a tooling problem. It's much more of a people and organization questions' — leadership has to create the conditions for teams to work differently.

Claude Code has become a daily driver for non-engineering roles in AI-native companies. At Lemlist, the shift from Cursor to Claude Code for all developers was significant enough that tech management rolled it out broadly — and product managers followed.

At Lemlist, all PMs now have a dev setup 'exactly the same as if we were developers in the tech team' with access to the entire codebase. The most transformative workflow is what one operator calls 'chat with codebase' — simply asking questions to understand how ten years of software legacy have been compounding.

Anchor Browser's team describes a similar shift over three to four months, leveraging their own product through Claude Code to drive growth workflows.

This only works when leadership unlocks the right capabilities. As one guest notes about Lemlist: 'you have access to cloud code, you have access to the read MCP of GitHub so that you can review the code base, and you have the ability to also push code into production' — without those capabilities, the speed isn't possible.

Lean teams keep pace by leading from the front and building structure around the LLM — not by adding headcount. Truffle's Sean argues there has to be a 'lead from the front here for sure', contrasting AI-native posture with larger organizations where CEOs still use AI 'in a way that is very much like check my email'.

The second lever is structure. Abraham Gomez of Google describes it as building a harness — not just for the model, but for the company itself:

• Plan more than you build. Great vibe coders 'spend so much more time on planning than actually vibe coding' — defining purpose, evaluation criteria, and good samples before attacking the problem.
• Surround the team with resources. Treat your team the same way you'd constrain an LLM — give them the context they need so work doesn't go off on a tangent.
• Monitor the feedback loop. Iterate on traction and product feedback rather than chasing a fixed KPI on day one.

David Arnoux frames the resourcing decision as a simple build / buy / hire framework: buy when the workflow is proven and the team isn't technical (Clay, Gamma, HubSpot AI); build when it's a core differentiator with proprietary data and feedback loops; and hire only for long-term strategic roles — 'one AI architect, fractional or full time, not 10 prompt engineers'. This is closely tied to how companies drive real AI adoption through internal champions before broader rollout.

Abraham Gomez of Google argues founders should see AI development as an experiment rather than a KPI hit: 'through the experiment alone, you'll learn a lot.' The cultural goal is simple — 'you don't want your company to be scared of AI'.

The barrier to entry is low. Testing how AI handles your own documents is described as 'a five minute exercise' you might repeat every two months to see how far the models have improved, until something hits the bar to become a real product feature.

Anchor Browser's team frames the difficulty as a feature, not a bug: 'if it's hard, it's good' — working on hard problems creates an iteration-cycle moat that compounds even as models get smarter.

The competitive picture differs by complexity. VanMoof's Eliott Wertheimer describes a 'ladder of complexity': at the lower end, 'it's easier to outsource most of the work to a supportive AI in a small team', so competition shifts to brand, feelings, and specific use cases.

At higher complexity — deeply integrated hardware, electromechanical systems, embedded electronics, and connected services — a 'great talented engineering team really differentiates'. AI-native lean teams dominate the lower-complexity rungs of the ladder; in deeply integrated domains, engineering depth still wins, and AI augments rather than replaces it.