Skip to content
ClaudeClaude

Building AI-native at enterprise scale: monday.com, Doctolib, and Delivery Hero

Three of Europe's fastest-scaling tech companies made three different bets on Claude: Delivery Hero built an autonomous agent that now merges 100+ PRs a day, Doctolib governs Claude Code across its entire healthcare engineering org, and monday.com ships it inside the product to users who've never written code. Hear what they built, where it broke, and how they stay ahead of a model that changes every few months.

May 20, 202629mWatch on YouTube ↗

CHAPTERS

  1. 0:18 – 1:10

    Why legacy startups are pivoting to AI-native enterprises

    Rebecca sets the stage for a panel with leaders from monday.com, Doctolib, and Delivery Hero—companies founded pre-LLM that now need to become AI-native without starting from scratch. The focus is on how they’re adapting real, existing products and engineering orgs to agentic and Claude-powered workflows.

    • All three companies predate the LLM era (2011–2013 founding window)
    • Theme: evolving from successful legacy products into AI-native enterprises
    • Constraint: large customer base + existing orgs + years of code to work with
    • Goal: share practical integration journeys, not greenfield theory
  2. 1:10 – 4:03

    Panelist intros: what Claude powers today, and the reality of old codebases

    Each leader introduces their company, role, and the Claude-enabled systems that have become critical. They also describe the underlying technical reality: monoliths, partial migrations, and the challenges of modernizing while shipping.

    • monday.com: moving from managing work to executing work via agent teams; monolith history
    • Doctolib: broad internal adoption across engineering, product, and beyond; half monolith/half services
    • Delivery Hero: global delivery platform; rolling out Claude Code and building HeroGen
    • Common constraint: long-lived codebases with imperfections and fragmentation
  3. 4:03 – 4:33

    Delivery Hero’s HeroGen: from ticket to production-ready pull request

    Ulrich explains HeroGen, an autonomous software delivery system designed to take a Jira ticket/GitHub issue and produce a production-ready PR. The system was built with the expectation that models would rapidly improve, and it’s now seeing strong adoption.

    • Design goal: agent takes a ticket/issue to a PR ready for merge
    • Built proactively for “next model,” not only current capabilities
    • Developed over two quarters, launched in Q1
    • Rapid adoption across engineers and group subsidiaries
  4. 4:33 – 5:28

    HeroGen traction and scale metrics

    Concrete operational metrics show the system is not experimental—it’s being used at significant volume. Ulrich shares daily throughput, cumulative PR counts, and the exponential growth trajectory.

    • ~173 merged PRs per day (10-day average)
    • ~7,000 merged PRs since February launch
    • Usage is accelerating exponentially
    • Focus on production impact rather than demos
  5. 5:28 – 6:28

    Doctolib’s adoption strategy: enable the whole org, not just platform teams

    Alex describes how Doctolib scaled Claude usage by treating enablement as a platform responsibility and innovation as a company-wide responsibility. They emphasize sharing practices and reducing bottlenecks rather than centralizing all AI work.

    • Goal: widespread effective usage, not isolated expert teams
    • Platform teams focus on enablement, best-practice discovery, and scaling
    • Leverage engineers’ creativity to find high-value workflows
    • Adoption extends beyond engineers to PMs/designers and broader staff via Claude Cowork
  6. 6:28 – 6:59

    Skills marketplace + developer environment: operationalizing reusable AI “skills”

    Doctolib built a discoverable “skills marketplace” and a standardized developer environment with preconnected tools. This helps onboarding, reuse, and experimentation while making successful patterns easy to replicate.

    • Skills marketplace: discoverability, usage signals, trends
    • Standard dev environment ships with tools and packaged skills by default
    • Onboarding includes immediate access to a library of proven skills
    • Plugins support experimentation without disrupting core workflows
  7. 6:59 – 7:42

    Community learning loop: ‘Build with AI’ as the scaling mechanism

    A strong internal community channel became the hub for sharing learnings, questions, and new skills. The intent is to learn together and compress the organizational learning curve.

    • Company-wide channel for sharing workflows, lessons, and questions
    • Promotes skills and patterns organically across teams
    • Reduces siloed experimentation and duplicated effort
    • Explicit goal: “go down the learning curve together”
  8. 7:42 – 8:43

    monday.com’s customer-facing AI: monday Vibe turns prompts into working apps

    Ruslan explains monday’s focus on product implementation and customer-facing AI. monday Vibe converts a simple prompt into a detailed PRD and then builds a working application in minutes, driving strong user adoption.

    • monday Vibe: prompt-to-PRD-to-app experience
    • High adoption and described as one of monday’s biggest successful releases
    • Part of a broader mission: agents that help execute customer work
    • Brings new demands: identity, permissions, and agents as first-class citizens
  9. 8:43 – 10:00

    Why monday’s early open platform investment accelerated Vibe

    Vibe was able to ship a fast proof-of-concept because monday had already invested in an external developer platform (APIs/SDKs/deployment). The system could behave like an external developer—contained from legacy monolith complexity—while still leveraging the product surface area.

    • Open platform enabled a rapid POC in days
    • Vibe uses the same public APIs/SDKs and deployment/publishing flow as external devs
    • Containment strategy helped work around legacy codebase limitations
    • Long-term unlock depends on making more features API-accessible
  10. 10:00 – 13:22

    Model upgrades in practice: excitement, evals, and rollout discipline

    The panel compares what happens when Anthropic ships a new model: from engineering excitement to formal eval pipelines. They distinguish between customer-facing product eval rigor and more informal (“vibes”) workflows for developer productivity—while noting the need for better verification over time.

    • Delivery Hero: Opus models were a step-change that made HeroGen viable
    • Doctolib: strict evals for AI products; dev workflows more informal today
    • monday: end-to-end evaluation matters in multimodal/orchestrated systems
    • Rollouts often require AB tests and prompt/workflow retuning, not drop-in swaps
  11. 13:22 – 15:27

    monday’s orchestrated architecture: model changes can break prompt optimizations

    Ruslan details Vibe as a multi-component system: an Opus-powered orchestrator plus deterministic steps and smaller models. A major model migration required rethinking prompt techniques and collaborating closely with Anthropic solution engineers to regain performance.

    • Vibe uses an orchestrator model plus deterministic tooling and smaller sub-models
    • Model releases often affect only parts, but must be validated end-to-end
    • Migration example (Opus 4.5 → 4.6) required prompt/workflow re-optimization
    • Treat major model changes as non-compatible system upgrades with AB testing
  12. 15:27 – 22:17

    Architectural lessons: integrate into existing tools, standardize services, and go API-first

    Each leader shares what they’d do differently if starting today. Delivery Hero emphasizes deep integration with existing engineering systems; Doctolib highlights opinionated standardization and the cost of old automation bottlenecks; monday stresses API-first design and agent-ready identity/permissions.

    • Delivery Hero: keep the interface in Jira/GitHub; integrate CI, security workflows
    • HeroGen: ‘council of agents’ multi-model review improved success rate to ~85%
    • Doctolib: opinionated patterns + smaller services outperform monolith for agent effectiveness
    • monday: earlier investment in consistent APIs and agent-first auth/identity would accelerate progress
  13. 22:17 – 25:57

    Lightning round: specialists vs generalists, new engineer workflows, and KPIs

    In rapid-fire answers, the panel aligns on specialized agents orchestrated by a generalist. They describe how principal engineers and even non-engineers are becoming more hands-on, and they share the daily metrics they monitor to ensure speed doesn’t erode quality.

    • All prefer many specialists, often orchestrated by a generalist
    • Principal engineers shift from mostly reviewing to generating more code hands-on
    • Teams increasingly orchestrate multiple agents (e.g., prompt optimization via genetic algorithms)
    • Daily metrics: merged PR volume + success ratio; reliability/quality controls; deep dives into failure cases
  14. 25:57 – 29:10

    What to do Monday morning: stop waiting, mandate usage, and start with real toil

    Closing advice centers on immediate, practical adoption rather than waiting for perfect conditions. Recommendations include mandating end-to-end AI-built features, having agents assess the codebase and propose improvement plans, and targeting repetitive engineering toil for early wins.

    • Delivery Hero: mandate every team builds a feature end-to-end with AI to break resistance
    • Doctolib: ask an agent to inspect the codebase and propose an improvement execution plan
    • monday: don’t wait for monolith splits/refactors—start now with repetitive toil
    • Consensus: iteration and hands-on experimentation are the fastest path to competence

Get more out of YouTube videos.

High quality summaries for YouTube videos. Accurate transcripts to search & find moments. Powered by ChatGPT & Claude AI.