AI Will Write Ten Times More Code. Someone Still Has to Keep It Running.

Olivier Pomel, co-founder and CEO of Datadog, tells Sarah Guo and Elad Gil that he is an engineer who got into computers through graphics and Europe's demo scene — real-time 3D done for the love of it. That path made him one of the first authors of VLC, the media player he jokes is "mostly used for viewing illegally downloaded videos." The people who made it actually successful, he is careful to add, came in after he left for the United States. He arrived in 1999 thinking he would stay six months, landed at IBM Research in upstate New York, and then spent about eight years at a New York education-software company doing SaaS for schools — right through the tail of the boom and into the bust.

That education company is where the Datadog idea formed. Pomel ran the development team; his co-founder ran ops. They had known each other since the IBM days, they tried hard not to hire jerks, and they were close friends. They still ended up with developers and ops pointing fingers all day and fighting. "The starting point for Datadog was not monitoring. It was not even the cloud initially." It was getting Dev and Ops on the same page: a platform where they could work together and see the world the same way. Guo notes how different that is from the ticketing, siloed relationship most people assume, or from a founding myth that simply saw the cloud coming.

Staying in New York was obvious to him — he loved the city, met his wife there, and knew engineers he could hire — and much less obvious to investors. Starting an infrastructure company in New York, especially without a systems-management pedigree, was treated by many Bay Area investors as "some form of mental impairment." The fear of getting it wrong, and of not being able to raise again, pushed them to double down on the product and to run the company efficiently from day one, hovering near profitability for most of its existence. New York also sat outside the Bay Area echo chamber: plenty of non-tech companies to sell to, and less of the loop in which an idea sounds better after three friends repeat it back. Recruiting is harder than in the Bay Area, but retention is higher. Looking at when individual engineer accounts churn at customer companies, Pomel says it is not rare in the Bay Area to see engineers turn over every 18 months. "It's really hard to build a successful company that way."

The name is an inside joke, not a branding exercise. Pomel is not even a dog person. At the previous company they named production servers after dogs; Datadog 17 was a horrible Oracle database that had to double in size every six months, could not go down, and that everybody lived in fear of. It was "the name of pain," the old world they were coming from, so they used it as a code name — Datadog 17 — and everybody remembered it. They dropped the 17 so it would not sound like a MySpace handle. A designer proposed a puppy against a field of alpha dogs and hunting dogs. Keeping the name and the puppy, he says, was the smartest branding decision they made. By the time of this conversation Datadog was approaching a $2 billion run rate, with 26,000 customers, some of them spending more than $10 million a year.

What Datadog actually sells, Pomel says, is an end-to-end picture: the infrastructure customers run, the applications on it, how those applications change, what developers are doing to them, how users click through, and what the systems log about themselves. The buyers are typically ops or DevOps teams; the vast majority of users are developers and engineers, with product managers and security engineers around the edges. Guo asks how those products translate into the generative-AI world, noting that cloud spend is already being reshaped and that this LLM wave is still extremely early.

He splits the opportunity into demand and product. On demand, the highest-level story is that many more people will write many more applications. Imagine one person becoming ten times more productive: they write ten times more stuff, and they understand what they write ten times less, because they do not have time to see and understand everything they do. "As a result, we think it actually moves a lot of the value from writing the software to then understanding it, securing it, running it, modifying it when it breaks." That is Datadog's job. Workloads are already exploding on both the provider and consumer sides of AI, because training and running models eat infrastructure.

He is less sure that every product should grow a chatbot. Six months or two years from now, that may not be how people want to interact with everything. "When you start your car you don't want to play 20 Questions with it. You just want to start it." What he does think is certain is an expansion of use cases and workloads, and an acceleration of digital transformation and cloud migration. If you want to adopt AI, your data has to be digital — still not true for most companies — and you pretty much have to be in the cloud, because if you try to build on-prem today you would not even know what to buy. The technology is changing too fast.

Gil notes that enterprise buyers are changing their minds monthly about LLMs, vector databases, and the rest of the new stack. Pomel says Datadog is in an unfamiliar position. For ten years the company was good at seeing which platforms would win: VMs to cloud instances, instances to containers, containers to Kubernetes, then serverless. Each step took a year, two, or three to reach mass adoption, and the killer apps and winners were clear. Generative AI is not like that. Everybody is exploring every permutation at once, and it is genuinely hard to know what will stick.

The surprise, if he has to guess, is the speed of the open-source ecosystem. Nobody has quite caught OpenAI on frontier models and maximum performance, but open-source models already match or beat it on smaller, more identified use cases, and he expects more of that. Datadog serves both the largest AI providers and the largest consumers. What he sees today is everyone prototyping on the best API-gated models — typically OpenAI, with a few others — while keeping in the back of their minds which pieces they can later bring in-house on an open-source model they train and host themselves. Gil adds that the most sophisticated users are already asking when they can fall back to the cheapest solution, when they need the most advanced model, and how to route a given prompt.

There is an observability stack needed, period, because this is one more component in the application. If you call a frontier API, you need to see what goes in, what comes back, whether the response is right or wrong, and how it interacts with the rest of the app. If you host a model yourself, you also have GPUs and the rest of the compute to instrument. The collection methods are still metrics, traces, and logs. What is newer is the use-case layer that used to be called MLOps. Datadog watched that market from afar: a hundred companies, little traction, use cases all over the map, and users who were small groups of data scientists who preferred to build things themselves. That has changed. LLMs are the killer app everybody is trying to use. The users are no longer a handful of data scientists; they are pretty much every developer, and they care less about building the model than about using it in an application that is reliable and can run day in and day out.

Guo asks how Datadog splits resources between the unified platform and new bets such as LLMs. The rule of thumb, Pomel says, is about half the team on the platform, because that is what they sell, and the other half on specific products. Even then the internal teams are more forward-looking — pointed at where the market is going — while what they sell is aligned with the 12, 15, or 20 backward-looking categories customers have been buying for decades, each with its own acronym. Observability is already emerging as a super-category that swallows infrastructure monitoring, APM, and log management. Datadog still sells those as different SKUs. Five or ten years from now, he thinks, people may not treat them as separate categories at all.

Acquisitions have to survive what happens after the wire. Signing paper and sending money is easy; integrating two things is the job. They only buy into product areas they already want to cover, and only when a company can buy two or three years of head start. They select for founders who want to stay and build, not founders who are tired and want to sell. "It's a fine reason to sell your company. It's not a great reason for us to buy." After close they run a short fuse: ship something together within three months. They do not much care what ships. Shipping forces everyone to find a way of working, lets the acquired team show value, and protects against the real risk — not wasted purchase price, but demoralizing everyone else in the company who wonders why the newcomers got so much money. Sqreen, the security startup Guo had served as a board member for, was rebuilt onto the unified platform in the first year. That extra cost is how they keep delivering end-to-end integration.

The first product took six or seven years, both because demand was hard to catch and because they had lucked into the cloud re-platforming window: a sticky market, everyone new, room to start smaller and expand as customers themselves grew into the cloud. Expansion after that was guided by what customers built themselves. Before Datadog built APM, a number of customers had already assembled a homemade version on top of the product; it was open-ended enough to script around. If they would go to that trouble, it was worth building for them. The first real threshold was going from one successful product to two. That gave them the confidence to take the company public, and it opened the question of what other problems they could solve. The secret weapon is surface area: they start with infrastructure monitoring, so they are deployed on every server and touched by every engineer every day.

Datadog has more than 5,000 security customers, still a newer effort relative to the core base. Guo notes the conventional wisdom: security is a different audience, even when the data and the architectural case for consolidating tools are the same, and investors may see this as a bigger jump than prior monitoring products. Pomel agrees it is a bigger jump. Most of the other new products still lived inside observability, with the same users and the same buyers. Security brings new users and new buyers.

His reading of the industry is blunt. There is no shortage of security solutions. There is tons of technology, typically sold very well, top-down, to the CISO. What it is not doing well is producing great outcomes. "Everybody's buying security software. Nobody is more secure as a result." Sell a very sharp point solution to a CISO, and you will not get those outcomes. Rely on large numbers of developers and operations engineers, and deploy security everywhere on the infrastructure and in the application at every layer, and you have a chance.

The analogy he offers is medical. There are great medicines for this, but for them to work you would need to inject them into every organ, every day, and nobody is doing that. Datadog's bet is to deliver the drug as an IV: always on, sitting on top of usage and ubiquity rather than on great sales performance at the top. Later they may need that top-level sales motion, because that is how larger deals get done. For now the focus is better outcomes, not a sharper pitch to the CISO.

Gil asks how to rank the AI opportunity inside Datadog's own products, given that anomaly detection on logs, metrics, and security data has existed for a long time, including Datadog's Watchdog layer. Pomel is careful about over-marketing AI, because it is easy to disappoint customers and because expectations in the current explosion have gone "completely wise" — he clearly means wild — which he thinks will bring some disillusionment. He still believes the new models can deliver things that were impossible a few years ago. The old methods are not going away. Watchdog watching every metric for statistical deviation is a job numerical methods already do fantastically well, without language models, and those methods are a lot more precise than LLMs.

Ask a customer whether they would rather have a false positive they can judge, or silence unless the system is sure, and they will all say: give me the false positive. The reality is you send them two false alarms at night and they turn you off forever. Operational workflows make judgments a thousand times a minute; wrong even two percent of the time becomes painful very quickly. The bar has to be extremely high, which is why classical numerical methods stay. What LLMs open is a different door: knowledge bases, email threads, and other language that used to be off limits can now put numerical information in context. Someone described LLMs as "calculators on language," a phrase Pomel finds astute. You can bring together metadata from many places, outputs from numerical models, and internal wikis, and combine data in ways that were impossible before. New intelligence will come out of that — if you can still be correct.

The debugging example is the one he keeps. An engineer sees an error in production, has a GPT window open, pastes the stack trace, and asks what is wrong. It works in the sense that 100 percent of the time the model gives an answer. In more than the majority of cases the answer is wrong, for a good reason: without program state, it cannot know. Combine the stack trace with the actual program state — the variables and their values when it blew up — and you get a very precise answer pretty much all of the time. At least in the short term, he says, the magic is going to come from combining language models with other data sources and more traditional numerical models.

An AI SRE co-pilot, or more automation, is on the cusp and still not there. The test he uses is Google: even in extremely uniform, large-scale environments, the level of automation is still fairly low. If you use the self-driving metaphor, Google is a highway. If that cannot be fully automated, most other companies cannot either, because most companies are downtown Rome. Debugging a complex production environment is not like driving, which anyone over 15 can do; it takes a team of PhDs who will take time and disagree. ChatGPT was six months old and GPT-4 three months old when they recorded. His rocket analogy: ignition has happened, innovation is everywhere; liftoff with real production use cases might come in about a year, because most of what exists is still demo-ware; the open question is whether you need a second stage, and that will not be clear for a couple of years. Generating images and copy is already good enough, because a five-legged dog is obvious and you re-roll. Writing code and debugging production is the unsolved part, because when the system is wrong it is less obvious.

Near-term productivity gains are already visible, Pomel says, in authoring, writing, and drafting — good enough, even if they have not yet rewritten anyone's process. Developer productivity is next: a class of tasks such as learning a new API used to eat an afternoon of docs and now takes a few minutes with a model showing you how. Some whole channels will be rewritten, not because new things become possible, but because they become inefficient once everybody does them. Email marketing is the example: you no longer need a human to send a message, a machine can send a million, and everyone is doing it. Guo asks if they just killed the channel. It will have to take a different shape, he says. Someone will have to get through the noise a different way.

Guo turns to leadership. Datadog delivered 30 percent revenue growth in a tighter macro and shipped a cloud-cost optimization product. What else is changing? Not the operating system, Pomel says. They have always run with profitability in mind, building systems from the ground up to be sustainable and efficient, never "get it to work and then we will optimize." They were scared they could not finance the business, and they have seen that bad habits are hard to shed. Two tunings, though: customers are more careful about what they buy, so Datadog has to recalibrate how it reads customer value and product-market fit, and generative AI is moving too fast for the usual three or four quarters of filtering noise. The noise is part of the field being developed. Teams have to accept being wrong a little more and iterate with the market.

Talent has not changed much. The people they want are entrepreneurial builders who "obliterate problem areas" — "black holes for problems: you send problems, they disappear." You find them by following the work. Work avoids people who are not performing and finds people who are fantastic. The customer mix is another unusual choice: tiny engineering teams through the Fortune 100, for a long time. The starting point was the same humans. Developers and ops are wired the same at a five-person company and at a multinational, and in the cloud-and-open-source generation the tooling is the same too. Fifteen years ago startups built on open source and large companies bought Oracle and Microsoft. Today everybody is building on AWS with open source, the same components up and down the stack. That breadth creates network effects you do not usually get in enterprise software, and it is hard to copy because you have to copy the company, not just the product. The cost is commercial leakage: when the news reports customers paying tens of millions a year, individual users find it outrageous, while the high end knows the bill is commensurate with infrastructure and still saves them money.