Going AI-Native at Enterprise Scale Is an Org Design Problem
The panel brings together engineering leaders from monday.com, Doctolib, and Delivery Hero to talk about going AI-native at scale. My read on the framing is that the technical questions are mostly solved. What is not solved is the org design that has to surround the technology, and that is where every large company succeeds or stalls. The interesting parts of this conversation are about rollout patterns, governance, and what changes in the engineering ladder, not about which model anyone picked.
Three key takeaways
- Rollout pattern has to match company culture. The right answer at monday.com may fail at Doctolib because the cultural starting point is different. Copy the playbook of someone else's company and you will hit invisible friction that kills adoption.
- Governance is a function of enablement, not control. Lightweight rules that let engineers move fast beat heavy rules that engineers route around, and the route-around is what creates the compliance risk you were trying to prevent.
- Measurement is the work you keep doing for a year. Lines of code is not a serious metric. The companies that figure out what to measure, and accept that the first version of the metric will be wrong, are the ones that get to keep investing.
Three companies, three risk shapes
The panel pulled from three companies that look different on the surface but share the same underlying problem. monday.com lives in B2B SaaS where reliability and integration breadth are the dominant pressure. Doctolib operates in healthcare where regulatory and patient-trust constraints are severe. Delivery Hero runs a logistics platform where latency and operational stability are paramount. Three companies, three risk shapes, one shared question: how do you put agentic tooling into the daily flow of thousands of engineers without breaking the business?
The reason this matters is that most AI-native stories you read are about small teams shipping new products. The much harder problem is retrofitting a large existing org with legacy systems, regulatory pressure, and internal politics. The lessons from a five-person team using Claude Code to build a side project do not transfer cleanly. The lessons from three companies that have actually done the work at scale do.
If your company has more than five hundred engineers and you are trying to make AI tooling a default rather than a curiosity, the conversations these leaders have had with their own boards and steering committees are the closest thing the industry has to ground truth.
Rollout patterns and the adoption curve
Every large company that has rolled out AI tooling chose one of three patterns. Top-down mandate, where leadership picks a tool and tells engineers to use it. Bottom-up adoption, where enthusiasts try things and the org follows when something sticks. Center of excellence, where a small team owns the rollout, builds evals, and seeds adoption deliberately.
Each pattern works in some cultures and fails in others. Top-down works in companies where engineers trust leadership's technical judgment and follow direction quickly. It fails in companies where engineers route around any mandate they did not help design. Bottom-up works in companies with strong internal communication and a willingness to let multiple tools coexist for months. It fails in companies where internal silos prevent any tool from reaching critical mass. Center of excellence works in companies that already have a strong platform team. It fails when the center becomes a bottleneck instead of an enabler.
The pattern that worked is almost always a function of company culture more than tooling. The interesting takeaway from a panel like this is the disagreements: where the three leaders chose different paths, and what that says about their respective cultures. Pay attention to those disagreements, because they reveal where the field has not yet converged.
If you are running this rollout in your own org, start with a cultural audit. How does any new tool actually spread inside your company? Who has the authority to mandate, and how seriously is that authority taken? Where does enthusiasm come from, and where does it die? The answers to those questions will pick your rollout pattern for you. Forcing a pattern that does not match the culture is the most common reason these initiatives stall in their first year.
Governance without strangulation
At enterprise scale you need governance. Who can use which models. What data can be sent where. How outputs are logged. Who is accountable for an agent-caused incident. These are real questions, and ignoring them produces real risk. But the trap, and almost every enterprise falls into it, is governance that strangles adoption.
The pattern that strangles is heavy front-loaded approval. Every new use case has to be reviewed by a committee. Every model has to be approved before it can be used. Every output has to be logged and audited. Engineers respond by routing around the system: using personal accounts, running models on their laptops, copy-pasting code into a public chatbot. The governance regime makes the company less safe, not more, because it pushes activity into the shadows.
The pattern that works is lightweight rules that let engineers move fast. A short list of approved tools that engineers can use immediately. A simple data classification that says what cannot leave the boundary. A logging system that runs by default and does not require engineer effort. An incident response process that treats agent-caused incidents the same way it treats human-caused incidents.
The leaders on a panel like this will likely admit they got the balance wrong at some point, in one direction or the other. That admission is the most useful part of the conversation. The right balance is not knowable in advance. It is found by shipping, watching what happens, and adjusting. Companies that treat governance as a one-time policy document fail. Companies that treat it as an evolving system succeed.
Measuring impact when the obvious metrics lie
Lines of code shipped is not a serious metric. It never was, and it is worse now. With agents in the workflow, an engineer can ship ten times the lines of code and produce something worse than the version they wrote by hand. The volume metrics tell you nothing.
The metrics that matter at enterprise scale fall into three categories. Cycle time and delivery metrics: how long does it take an idea to ship, how often do deploys roll back, how stable is production. Defect and quality metrics: how often do PRs get rejected, how many incidents per quarter, how is customer-reported quality trending. Developer-reported metrics: do engineers feel like they are doing work they value, do they trust the tools, where do they feel friction.
The honest answer from any leader running this at scale is that they are still figuring out what to measure. The first version of the metric is always wrong. The second version is less wrong. By the third version the team has a defensible story to tell the board. The companies that get to keep investing are the ones that show real impact on metrics that matter to the business, not the ones that show impressive AI-specific metrics that do not translate.
If you are leading this work, invest in measurement early even if the metrics are imperfect. The cost of starting late is much higher than the cost of starting with the wrong metric. You can always iterate on the metric. You cannot recover lost months of data once the rollout is underway.
The talent question
Senior engineers using agents look very different from junior engineers using agents. Senior engineers use the agent to amplify judgment, scoping work, reviewing output, integrating across systems. Junior engineers, if they are not careful, end up watching the agent work without learning what is happening underneath. The talent question for an enterprise org is how to manage this gap.
The hiring loop has to change. Asking a candidate to solve a coding problem in isolation is now testing a skill that matters less than it used to. Asking a candidate how they would review an agent's work, where they would push back, what they would refuse to ship, tests the skill that is becoming central. The interview process most companies use is still calibrated to the old shape of the job. Updating it is uncomfortable and slow, but the companies that do not update it will end up hiring for skills that are decreasingly relevant.
Performance review changes too. The most valuable engineers are no longer the ones who write the most code. They are the ones who design the cleanest systems, who catch the agent's mistakes, who mentor others on how to work with agents effectively. Performance criteria have to reflect that shift. Companies that still grade engineers primarily on code volume are going to lose their best people, who will go to companies that recognize the new shape of the work.
This is one of the more uncomfortable conversations in enterprise AI, and it is often the one leaders are least prepared to have honestly. The panel format gives them room to be candid about it. The honest answer is that nobody has fully figured this out, and the companies that experiment fastest are getting the most signal.
Vendor strategy and the lock-in question
Every large company has to decide how deeply to bet on a specific model provider and a specific agent runtime. Adopting Claude Code at scale implies a real bet on Anthropic. The panel will likely cover how each leader thinks about diversification, abstraction layers, and the cost of switching.
The dominant pattern I have seen work is a thin abstraction layer that lets the company switch models or runtimes at the platform level without rewriting every use case. The bet on a specific provider is real, but the cost of being wrong about that bet is bounded. The platform team owns the abstraction. The product teams use the platform. When a competitor pulls ahead, the platform team can swap underneath without product teams noticing.
The trap is over-engineering the abstraction. A thick abstraction that supports every possible model perfectly is a project that never ships. A thin abstraction that covers the most common cases and accepts some duplication for edge cases is the pattern that survives. The platform team's job is to draw that line correctly.
What this means for the next year
Three concrete moves come out of this for anyone leading AI adoption in a large engineering org.
Pick a rollout pattern that matches your culture, even if it is slower than a pattern that worked elsewhere. The cultural fit dominates the tooling fit at this scale.
Invest in measurement before you invest in features. The first version of the metric will be wrong. Ship it anyway and iterate.
Treat governance as enablement. The goal is to let engineers move faster while staying inside the lines. If your governance is making engineers slower, you have the wrong governance, regardless of how much it satisfies your legal team.
The panel format also makes one larger point. The companies that get this right will not look like each other when they are done. The right answer at monday.com will not be the right answer at Doctolib or Delivery Hero, because the constraints are different. The shared lesson is the meta-lesson: respect your constraints, design for your culture, and measure what matters. Everything else is local.
Marco Kotrotsos, specializing in practical AI implementation for organizations ready to close the gap between AI hype and AI value. With 30 years of IT experience now focused purely on AI deployment, he works hands-on with companies to turn AI potential into measurable business outcomes.
This article is published in Autocomplete, a Medium publication about real-world AI for practitioners and decision-makers.
My free Substack newsletter, also called Autocomplete, can be found here: https://acdigest.substack.com.
Source talk: Building AI-native at enterprise scale (monday.com, Doctolib, Delivery Hero panel) at Code with Claude London 2026. https://youtu.be/XFaeIbL-lvE