In Today’s Issue:

🎙️ DataCamp’s CEO and Chief AI Officer on what AI tutoring really costs at scale

💸 Why an open 31B model wins their own evals and still is not in production

🛡️ How you stop a tutor from confidently teaching something false

Dear Readers,

DataCamp is one of the few companies that can put real numbers on AI tutoring. More than 18 million people have learned data and AI skills on the platform since 2013, and it logged more than 10 million hours of learning last year. The plan is to move all of that onto a personal AI tutor, built on the technology DataCamp acquired with Optima in November 2025, when Optima founder Yusuf Saber became its Chief AI Officer. The catch sits in the arithmetic: one hour of AI tutoring can cost several dollars in model fees. Jonathan Cornelissen does that math out loud in this interview, and it ends at "10, 20, 30, $40 million on a $100 million run rate."

That number explains the most interesting fact in this conversation. On DataCamp’s own evaluation suite, Google’s open Gemma 4 31B beats the frontier models the tutor runs on today, at a far lower theoretical price. And yet 100% of live tutoring still runs on frontier models. The bottleneck is not model quality. It is the infrastructure layer: the speed, reliability and caching that closed-model APIs bundle, and that open weights leave you to build or buy.

Along the way, the two of them open the machine room: over 100 tutor behaviors selected at runtime, because stuffing them all into one prompt would cost 120,000 tokens; an eval suite whose expectations were mostly discovered by a friction-detection system called Sentinel; and guardrails built on a principle worth stealing: use the model’s intelligence, not its knowledge.

All the best,

Kim Isenberg

🎬 Watch the full conversation:

DataCamp has taught data and AI skills to more than 18 million learners since 2013, first with interactive courses, now with an AI tutor it wants every learner to use. In November 2025 the company acquired Optima, the AI-native learning startup Yusuf Saber founded in 2023, and made him Chief AI Officer. The tutor his team built has since reached over 300,000 learners, and DataCamp wants that to be millions within a year.

We asked the two of them what it really costs, what really breaks, and what a company should choose when frontier and open models are both on the table. Jonathan answers for strategy, Yusuf for the technical details. The conversation has been edited for length and clarity; the questions came from Kim Isenberg and co-host Peter Thum. Answers are marked Jonathan and Yusuf.

AI agents are doing the work of full GTM teams. Pipeline, content, customer service. The startups using them aren't waiting for headcount approvals.

Get the free Practical Guide to Agentic GTM for Startups and see exactly where to start.

Unlock the Playbook

Jonathan, in early 2024 you warned that AI in production brings three key problems: you cannot control the costs, it is hard to switch once you depend on a provider's models, and it is hard to keep control of your systems. Now that you are running a tutoring business at scale, which of those has proven the most difficult in reality?

Jonathan: It's a very good question. I would add one thing in the context of the tutor. This is mostly the Optima team and Yusuf who went through that phase, but getting to a high enough level of quality, to excellent teaching, is the first breakthrough: can AI actually solve this use case? That still remains a priority. How do we build the absolute best AI teacher out there? But for us, the priority has shifted towards cost quite a bit. Just to give you a sense, there were more than 10 million hours of learning happening on DataCamp last year. If you do the math and realize that one hour of AI tutoring can cost several dollars, you quickly see that means 10, 20, 30, $40 million on a $100 million run rate, just in AI costs for the tutor. It paints a picture of how important cost becomes. And just to be clear, we don't yet have 10 million hours of learning on the tutor; that's the platform as a whole, and a lot of that engagement is still on the original DataCamp experience. But our goal is to shift all of that engagement to the AI tutor, so cost is a huge bottleneck to making that happen. It's one of the reasons we started looking at open weight models, and I've always been a huge proponent of open source. Cost is the focus right now, but control is a close second, for the simple reason that this is so strategically important to us that it creates all types of issues not to have ultimate control over the model side of the house.

For people who don't know the product: what is the AI tutor, and how is it different from normal online courses with videos and exercises?

Jonathan: There have been three phases in online education. The first was the MOOCs, the massive open online courses, where static video content was brought online. Think Coursera or Udemy; they did an amazing job just bringing static content online. The second wave, companies like Duolingo, DataCamp, Codecademy and many others, was all about using traditional software engineering to build more engaging learning experiences. For DataCamp, that meant learners spending 70, 80, 90% of their time actively learning, doing exercises. But conceptually, those learners still went through the exact same content. What's different with the tutor is that we no longer create an actual completed course.

We have experts who create the ingredients of a course, and the tutor adapts the course to the individual learner, or to the organization that learner is part of. That enables so many things. If the tutor notices somebody is new to the subject and struggling a little, it can slow down. If it notices somebody really gets it, it can speed up. It can make the material relevant to that individual by understanding their role, the country they're in, and so on. It becomes a super personalized experience. There has been an enormous amount of research over the years on what delivers the best educational outcomes, and it's fairly well established that one-on-one tutoring is the best way to learn. It just wasn't available to the vast majority of people. That's what makes me super excited: it brings very high quality education to millions or hundreds of millions of people.

Yusuf, you built the system at Optima. Explain it step by step: a student gives an answer. What happens inside the system before the tutor decides what to say back?

Yusuf: If you look at a great tutor, and we all had great teachers over time, they do an incredible number of things really well: the way they explain, the way they choose the right example for the person they're talking to, which questions they choose to answer now versus hold onto, how they decide when to step in and help versus step back and let the learner keep trying. If you think of building that into an AI system, you think of these things as behaviors. We call them tutor behaviors, and we have over 100 of them today. At every moment of the teaching process, the system has to decide which behaviors are relevant right now, because if we crammed all behaviors into the model at one time, that's over 120,000 tokens. It's massive, and the model just can't compose all those instructions.

There are three tiers. Persistent behaviors are always active: how to address the learner, how to communicate. Triggered behaviors are only needed when their trigger has happened: how to respond to a question is only relevant if the learner is asking one, and if a learner shows they know something well, a behavior we call adaptive coverage decides to speed up and maybe skip some material. And third, content-driven behaviors depend on the nature of what is being taught: teaching something and helping them practice something need very different behaviors. So once the learner responds, a process runs and decides the subset of behaviors most relevant for this very moment.

Then there is a layer that people who use systems like Claude Code will recognize. We call them system reminders: the system knows where the tutor is likely to make a mistake, reads certain clues from the session so far, and triggers a set of reminders that keep it on track. It composes that with the learner's profile and the content currently being taught, and out of all that, the tutor returns a response to the learner.

Two terms are often used as if they mean the same thing. When DataCamp says open source AI, do you mean fully open source systems, or open weight models?

Jonathan: The answer is open weights, mostly, but open source models are definitely on the table too. Open weights is mostly where the tier of performance we look for tends to be.

Which models are actually running in production today? Roughly, how much runs on open weight models and how much on frontier models?

Yusuf: At the moment, the actual learning that's running in production with actual learners is completely, 100% frontier models from the top labs. We still haven't put open weight models in production with actual learners.

Which open weight models have you tested for the tutor recently? There is a huge debate around all the new releases. Gemma, Llama, Qwen, Mistral? Where were they better than the models you already use, and where worse?

Yusuf: We have actually tested all of those. So far, Gemma has outperformed: the 31 billion parameter dense model. It's a very interesting model. 31 billion parameters is tiny compared to the multi-trillion models you have now, like the 1.6 trillion of DeepSeek, which was one of the models we tested. But it's a dense model, so all 31 billion parameters are always active, as opposed to DeepSeek, the V4 version we tested: 1.6 trillion parameters, but only about 50 billion active at any one time. The Gemma 31B is significantly easier to host, and all its parameters are active, so we get comparable performance to some of the very heavyweight models, especially for our use case.

Editor's note: Google released Gemma 4 on 2 April 2026; the 31B model is the line's dense flagship. DataCamp's quality comparison is against its own internal evals, not this public leaderboard.

Do you send different learner questions to different models, say a cheaper open weight model for simpler cases and a frontier model for difficult ones, with a router in between?

Yusuf: Today, all our usage of open models is internal testing. We have a simulated environment where we can play back a lesson: we take what happened in real life with actual learners and rerun it as if it's happening now. In essence it's doing real teaching, with real data, exactly the responses we got from real learners, just not with a live learner on the other side. Our aim is that sometime at the end of this year, we will start to have some of that running in production. But as of today, 100% of the actual learning is on frontier models.

Jonathan: Maybe a little context on the why. If we look at our evals from a quality perspective, Gemma is actually beating the frontier models that we are using today. So if we could, we would switch over, if only for the quality. On top of that, the theoretically achievable price would be way lower for Gemma, relative to what we're using today. The big challenge, the bottleneck for switching towards fully open weight models, is the infrastructure layer. Unless we built this ourselves, we can't get to the combination of speed, reliability and caching that we need. We've been in touch with several vendors who are figuring this out; we would rather not build it ourselves, because eventually this is probably not going to be a core competency. We want to rely on infrastructure-focused vendors in all likelihood. There are also some questions from some enterprise clients, but the vast majority of our engagements would be comfortable with a Gemma 4 as long as it's hosted in certain regions. The bottleneck really is the infrastructure layer. It's not the model quality. If we could, I think we would switch tomorrow.

When you say "we'd switch tomorrow," what does that mean operationally? Is evaluating a new model a one-week process, a six-week process, a quarter? How long does switching actually take?

Yusuf: The first line is evaluation. If a team has a solid, comprehensive, reliable evaluation setup, switching over can be a matter of hours or days, not longer. Our eval system is deeply comprehensive. Each of the hundred-plus behaviors we mentioned has what we call a set of expectations; if the model meets them, it passes the bar for us. Then we have hundreds of what we call fixtures: fixed instances from actual lessons where we know what the correct behavior was. For instance, when a learner asks a question, the tutor should do one of four things. If it's completely irrelevant, a political question, the weather, it should not engage; it stays on topic. If the question is super relevant to this moment, it has to address it now, because otherwise the learning is impaired. If it's something coming later in the lesson, it should appreciate the curiosity and give them something, but not derail the lesson. And if it's relevant but beyond the scope of the course, it gives them something to keep them curious without derailing too much. A model can easily mistake one case for another, so we have about 50 test cases making sure these four expectations are all met, and each is run five times. Passing all five runs is the standard. Multiply those numbers and they quickly get into the thousands. We run all of them, for all of the models, in maybe a few hours, and we get an estimate of how a model performs and where it fails.

We love Gemma. It's been outperforming, but on certain things it's underperforming, and some of them are quite important. And remember, our prompts were optimized for the frontier models. They were never optimized for Gemma, and it's still winning on many cases. So you run the suite, the model passes, and you quickly get a sense of cost and speed on top of task performance. Internally, our admins already have a dropdown on the platform where they can switch to any model and continue learning. It's already in production, integrated, in the infrastructure. Switching is a config change, and learners would be learning on a new model in a few minutes.

Jonathan: One more thing: it's also strategically important to us that switching between models is fairly easy. We're still in the rollout phase, but we are live with some of our enterprise customers with the AI tutor, and it's getting enabled very fast across our enterprise customer base. Some very large organizations, think financial institutions and governments, have a list of approved models they're allowed to work with, and the optimal model we choose for our broader audience might not be on that list. So the ability to switch the model layer between different clients, and over time, is core functionality in our mind.

Let's focus on the product itself. How do you measure whether the tutor is actually good? By good, I mean four things: is the answer factually correct, is it didactically good, is it personalized, and did the learner actually understand? How do you test each of these factors?

Yusuf: The evaluation system we just discussed is the core mechanism. We look at teaching as a set of behaviors, and for each behavior we define expectations, anywhere from five to twenty: what do we expect to happen so we can say the model truly exhibits this behavior? Then come the actual test cases, from actual learning. One of our behaviors, for example, is that the model manages practice right. Models are trained to be very helpful, so when giving a practice question to the learner, a model will often add a paragraph after the question that essentially gives away the answer and spoils the opportunity to practice. That fails the expectation: deliver the question without any spoilers. On the other side, a model that lets the learner struggle way beyond the point of productive struggle is also failing; at some point it needs to start providing hints. And some learners want to keep trying while others would rather get help, so the learner makes the choice: the model doesn't just volunteer the solution, it asks, "You have tried this long enough. If you'd like, I can share the solution with you." That prevents the learner who was almost there from feeling the exercise was spoiled.

There are over a thousand expectations tested, each with three to five different tests, and we run each up to five times, because sometimes the model gets it right by chance. We always have a baseline, overall and per expectation, and every change we make runs against the whole suite. There are three tiers: the first runs only the critical expectations, takes a few minutes and costs a few dollars. If that fails, we can't proceed. If it passes, we run the next tier, and before full deployment, the complete suite.

Jonathan: Two more things worth mentioning. Once the tutor is teaching live in production, and this is one of the things we're super excited about, we now have over 300,000 learners who have already spent quite a bit of time with the tutor, and we expect that to scale to millions in the next six to twelve months. That's an enormous amount of interaction data, and we already have review systems that understand when there is friction: when something is happening that may be deliberate, where the learner is struggling productively, and when it's an opportunity to understand what could have been done better. Over time I think there's going to be a massive data advantage there, because we see what works and what doesn't in near real time, and we can adapt the tutor system or sometimes the underlying content. The last part, which we don't do yet, is external benchmarks: standardized tests or certifications at the end of these programs. There's a tremendous amount of academic research that would be incredibly interesting and valuable, so if there are any academics listening or reading this, we'd love to set up collaborations.

Yusuf: One tiny thing to add: about 60% of those expectations were not things we came up with. They were discovered through the mechanism Jonathan just described. We have a system called Sentinel, and its job is to detect any friction in the process; the bigger majority of our expectations came from that. Any engineering audience would relate to test-driven development. We like to think of this as evaluation-driven development: the tutor drops the ball somewhere, we see it through the friction lens, we create an expectation for it, we fix it, and the tutor doesn't lapse that way again.

300,000 learners is a lot. How has the feedback been so far? What was the most positive, and where were they critical?

Jonathan: The feedback overall has been very positive. We're a very data-driven company, as you can imagine, so we've done A/B tests and looked at the data in every possible way. A couple of data points are the most convincing. On the consumer side, DataCamp has a freemium model; the first 20 to 60 minutes of every learning experience is free. If you compare those first 20 to 60 minutes spent with the tutor versus the old experience, the conversion rate to become a subscriber is significantly higher for the tutor experience. Satisfaction ratings are also higher. And the thing I found really fascinating: engagement tends to be higher, but the distribution shifts. Learners who already know the topic move through faster and get to the learning objectives sooner. Learners who struggle with the material, or who are very curious, ask a lot of questions, go back and forth, spend way more time, and end the course deeply understanding what they set out to learn. We don't have formal academic research yet that this is actually better, but we have enough data to be strongly convinced that, didactically, this is not just more satisfying and more engaging, but also more effective.

One of the motivations, both for myself and for Yusuf, is the frustration with the educational system: it's like a factory system. You move through it at the same pace as everyone else. Sometimes you're bored, a lot of times you're bored, sometimes you're lost. That's frustrating as a learner, and honestly also as a teacher, watching some students get lost while others are bored. It often even kills the curiosity and excitement of going to school.

There is usually a trade-off around speed: bigger models are slower, smaller models answer more quickly, and it also depends on the underlying inference hardware. How do you handle speed versus quality?

Yusuf: If I zoom out, you can think of three major parts to this framework. First, what you said: a model with a larger number of active parameters needs more time to respond, so your time to first token is slower. But in a real production system, that's usually the smaller piece. Two other pieces contribute much more to latency. The second is your own back end: your basic database reads, how your infrastructure is set up, how you process the structured output from models. And the third is the architecture of your AI engineering system. One simple example: if your model makes many tool calls, that significantly increases the time, since every tool call is essentially one full round trip you have to wait for. Roughly, for us, about 50% of the latency is in our own software, and 50% is with the model, and the biggest gains are on the AI engineering side. For example, we now have no tool calls where the model has to wait for a tool's response. We replaced that with a mechanism we call system requests: if the model needs something done, it triggers a system request and moves on.

And there is an asymmetry in how time works for our learners. The couple of seconds waiting for a response is extremely time sensitive. Then the learner takes twenty, thirty seconds to process and write their answer, when no one is waiting on anything. We use that window to do the heavy work: we cache what the learner will likely say and pre-prepare responses. In most cases you can guess with very high reliability. Most of our learners also have audio on, so they hear as well as read, and generating text-to-speech adds latency too. So we take the shortest complete sentence, convert it with very fast systems so the learner starts hearing, and the rest streams and transcribes in lockstep. No delay, no waiting. The architecture of the system is where most of the latency gains are, so you can still use a very powerful model and iterate there to bring the latency down.

Most people outside the AI bubble worry about hallucinations, and in education that would be the biggest fear. In most products, a wrong AI answer is only annoying. In a tutor, it means a student learns something that is false. What do you do to stop the model from explaining something incorrectly but confidently?

Jonathan: The high-level answer: we mentioned in the beginning that there are ingredients to the course. You can think of that as the factual reality, the ground truth. The tutor has quite strong guardrails to go back to the ground truth and be quite cautious about explaining anything beyond it. We put a lot of thought into making sure we understand what should be in there.

Yusuf: That was problem number one, the first problem we had to solve, because a learner is vulnerable. The fact that they're taking the course means they most likely don't know the material. When you're using Claude or ChatGPT, a lot of the time you're working within a space you know, so you can quickly detect if something is off and push back. A learner has far less ability to do that. So we had to be very confident we are not putting a vulnerable learner in a place where they're being misled. The first part concerns the model: we wanted to use its intelligence, but not its knowledge. We use the intelligence it has to be a good teacher, but all knowledge comes from what we provide. Given the very short latency window and a bunch of other concerns, it's not allowed to search the web, and it's not allowed to use its own knowledge, so we provide everything upfront: the core knowledge for the lesson, plus a repository of supplementary knowledge for the curious learner who wanders into the surrounding space. It can also request additional knowledge from the system, say for something that comes later in the course. But the second and more important thing, in our opinion: it will actually say "I don't know." It has to check: do I have a reliable answer to this? If not, it says so. That is actually one of the expectations we still need to work on with Gemma; it was slightly less likely to say "I don't know" than the frontier models we were using.

Your website makes a bold claim about how much faster people learn. Say I'm a buyer: how is that number calculated? And when I finish in a fraction of the time, am I actually learning more, or just processing more?

Jonathan: I think you're referring to the claim we make, which is that our course completion rates are three to six times higher than the traditional learning platforms. The fundamental problem in online education has historically been that passively consuming information, just watching videos, tends to be quite boring and not very engaging. The key problem is really engagement, and the key challenge is: how do you make it really engaging while ensuring people are still learning? Some companies take gamification so far you're barely learning; that's not us. We have a lot of enterprise clients who actually care about the skills, and a lot of consumers who come to DataCamp to advance their career, get a new job or a promotion, so the actual learning really matters to us. The fact that it's interactive and people go back and forth was always part of what DataCamp does, and that was creating the lift of anywhere between three and six. The exciting thing is that with the AI tutor it feels like you can go further, and for fast learners who already know something about a topic, you can also reduce the time to their learning objectives. You can have the best of both worlds due to personalization. Before generative AI entered the scene we thought about this and tried a lot of things, and the technology just wasn't there. Now it is.

A lot of corporate training is really an insurance policy: the motivation is compliance, not learning.

Jonathan: Totally. And I think it has never mattered more than today, because AI is changing the skills people need faster than probably any technology in history. There's a tremendous amount of reskilling and upskilling that needs to happen, and it's not about ticking a compliance box. It's about whether you can create a behavior change, get people to the other side, and make them more productive and more competitive as an organization.

To close with a practical view: what is the worst mistake the tutor has made in production, and what did you change afterwards?

Yusuf: For us, the worst mistakes are the ones that derail the learning process. For instance, we have courses where a virtual machine needs to start. Say you want to learn a tool like Power BI: we want the learner to experience the actual tool, not just watch videos of it, so we start a virtual machine and run the actual tool in it. We trust the AI tutor to do a lot of things here. It triggers when the virtual machine should start, it decides what files to load on your behalf so the tool opens with the right files, and it gets constant screenshots of the virtual machine to check you're learning the right thing. One of the worst failures: it says "Now let's do X" and then opens a file that does Y. Or the virtual machine needs to start now, the tutor says "Here's the virtual machine", and it doesn't actually start. The learner sits there asking, okay, where is it? These are especially painful because they break the learning. The good thing is it adapts immediately: once the learner says "I don't see it," it quickly self-corrects. But we don't want it happening in the first place.

This is where we rely heavily on what is perhaps one of the most powerful techniques in all of AI engineering: system reminders. The system knows the virtual machine should come now, and it reminds the model to actually open it. In cases where we know with high certainty, the system opens it automatically. In cases where it's only highly likely, we still need intelligence, we need the model to make the call, so we tell it: it is very highly likely the virtual machine should be started now. With that reminder, it's exceptionally less likely to make this sort of mistake. There's a clue in the session that code can detect, but you can't do it with code only, because it's not 100%. A system reminder bridges the gap.

One last question: what was the best feedback you ever got, and where do you see the company in one to two years?

Jonathan: The thing that excites me the most is when people say, "This feels like a real teacher sitting next to me. It's the best educational experience I've ever had." That's what we set out to do. The vision: we are very focused on data and AI skills right now, because that's where the big gap is. But fundamentally, we're building the best AI teacher. Our goal for the next few years is building the system that can teach any type of skill, for professionals initially, and then beyond. That's an incredibly exciting thing to work on.

Stay connected on every trip with Saily eSIM plans. From beach vacations to business travel, access data in 200+ destinations.

VIP perks available.

Activate instantly upon arrival.

Download SAILY in your app store and use code newsletter15 at checkout to get an exclusive 15% off your first purchase.

Get 15% off now

^{Chat support available 24/7. Get a full refund if your device isn’t eSIM compatible.}

The number that organizes the whole conversation is Jonathan's: one hour of AI tutoring can cost several dollars, and at DataCamp's scale, over 10 million learning hours a year, that projects to $10 to $40 million in model costs on a $100 million revenue run rate. At those ratios, model choice stops being an engineering preference and becomes a margin question.

The finding worth repeating: on DataCamp's own eval suite, Gemma 4's 31B dense model beats the frontier models actually serving learners, with prompts that were never optimized for it. What keeps it out of production is the missing inference layer: the speed, reliability and caching that closed APIs bundle, and which DataCamp refuses to rebuild in house.

The transferable craft is what Yusuf calls evaluation-driven development: more than 100 tutor behaviors, over a thousand expectations, roughly 60% of them discovered by the Sentinel friction system, and a three-tier test suite that turns switching models into a config change. That is what "we would switch tomorrow" actually requires.

Jonathan Cornelissen co-founded DataCamp in 2013 and has led it as CEO to more than 18 million learners and thousands of enterprise customers. He holds a PhD in financial econometrics from KU Leuven, where the frustration of teaching the statistics language R without interactive tools produced the first version of DataCamp. He has argued since early 2024 that AI in production stands or falls with cost, switchability and control, the framework this interview tests against his own company.

Yusuf Saber is DataCamp's Chief AI Officer and the architect of its AI tutor. An ETH Zurich graduate, he built and led data teams at the Middle East delivery platform talabat, most recently as VP of Data, before founding Optima in 2023, the AI-native learning startup DataCamp acquired in November 2025. He leads DataCamp's global AI operations from the UAE.

Sources:

🔗 The full video interview on our YouTube channel: https://www.youtube.com/watch?v=UFQYuy2KIXE

🔗 DataCamp, "DataCamp Has Acquired Optima. And We're Changing Learning Forever.": https://www.datacamp.com/blog/datacamp-has-acquired-optima

🔗 Business Wire, "DataCamp Extends Market Leadership With Acquisition of Optima" (12 November 2025): https://www.businesswire.com/news/home/20251112410509/en/DataCamp-Extends-Market-Leadership-With-Acquisition-of-Optima-Creating-the-AI-Learning-Engine-of-the-Future

🔗 Google, "Gemma 4: Byte for byte, the most capable open models" (2 April 2026): https://blog.google/innovation-and-ai/technology/developers-tools/gemma-4/

🔗 Wamda, "DataCamp enters the Middle East with Optima acquisition" (November 2025): https://www.wamda.com/2025/11/datacamp-enters-middle-east-optima-acquisition

🔗 DataFramed podcast, "Data Trends & Predictions 2024" (25 January 2024), where Jonathan made the costs-lock-in-control warning Kim references: https://www.datacamp.com/podcast/data-trends-and-predictions-2024-with-datacamps-ceo-and-coo-jo-cornelissen-and-martijn-theuwissen