Building AI that teaches: What nine years at Coursera taught me about scaling learning systems
I’ve spent nine years building learning infrastructure at Coursera, the world’s leading online education platform. During that time I’ve gone from staff engineer to founding member of our first artificial intelligence engineering team, and along the way I’ve come to believe that educational AI is a fundamentally different engineering discipline than the consumer AI most people read about.
The difference starts with feedback loops. A recommendation engine at a streaming service recovers from a bad suggestion in seconds; the user just picks something else. When an AI-driven learning system steers someone toward the wrong skill path or fails to surface a gap in their understanding, the consequences may not surface for months. Career changers invest weeks, if not months, in a credential. Enterprise teams plan quarterly around upskilling programs. The cost of getting it wrong is measured in wasted human time, and often in lost confidence. That asymmetry should shape every architectural decision in educational AI systems.
A second constraint comes from learning science itself. Chi and Wylie’s ICAP framework, introduced in Educational Psychologist in 2014 and validated across 225 studies, demonstrates that interactive and constructive engagement produce deeper learning than passive consumption. On a hands-on learning platform, that active engagement happens inside the lab environment itself, which means the infrastructure provisioning a workspace isn’t supporting the learning — it is the learning moment. And when the learning moment depends on infrastructure, an infrastructure failure becomes a learning failure.
One incident made this clear: A large programming course scheduled a graded lab with a submission deadline. A surge of concurrent launches briefly overwhelmed the provisioning system, leaving some learners unable to start their workspace. It was only a minor infrastructure delay, but it disrupted a key learning moment, when thousands of learners were completing an assignment. That experience reinforced that the compute environment was part of the instructional experience, not just infrastructure.
That lesson carried forward when I moved into AI-native platform work. Personalization at scale sounds straightforward until you confront the filter bubble problem. Eli Pariser coined this term in 2011. It describes how systems that keep showing people what they already like slowly narrow what they see. In a learning context, a career-changer might never discover the adjacent discipline that would actually unlock their next step. For example, a data analyst might spend all their time going deeper into SQL and dashboards, and never get shown basic statistics or machine learning concepts. These skills are typically required for data science roles. Learning them early can help a data analyst stand out from their peers, or even move into a data scientist career path.
To keep learners from getting stuck on one path, our systems surface multiple recommendation types simultaneously. Some are optimized for relevance to the learner’s current trajectory, while others intentionally expand their horizon by introducing adjacent skills. When a recommendation is intended to broaden a learner’s path, the UI makes this explicit. Architecturally, the system does not produce a single ranked list but diversified recommendation sets, where different slots are optimized for different objectives: relevance, progression and discovery. The result is that a learner keeps making progress on their current path while still being shown the adjacent skills that could open a better one.
Building an AI-native learning platform also requires rethinking content delivery, assessment and learner support as a single integrated system. Most platforms still treat these as separate products. Content is served. Quizzes are appended. Support is reactive. When these components operate under a shared learner model, the system can do things none can do independently: adapt the difficulty of a hands-on lab based on assessment signals, or trigger a coaching intervention when engagement patterns indicate a learner is about to drop off.
The learner population itself imposes constraints that no synthetic dataset can replicate. Serving an enterprise workforce team on a mandated upskilling track demands different architecture than serving a first-generation learner on a mobile device in a bandwidth-constrained region. One example: supporting mobile-first learners. Coding labs work well on laptops but are difficult on smartphones, which many global learners rely on. Rather than forcing the same experience onto smaller screens, we surface alternative hands-on activities for mobile users: Socratic dialogue with an AI tutor, role-play simulations or small-code execution blocks instead of full project labs. Architecturally, this meant treating hands-on learning as multiple interchangeable activity types.
You can expect to see more progress in richer learner models that unify signals across content consumption, hands-on practice and assessment. Most platforms today personalize within individual components, but the real opportunity lies in architectures that treat learning as a continuous feedback system. You can also anticipate that AI will move away from acting primarily as an answer engine and toward functioning more like a coach, proactively surfacing questions, guiding practice and helping learners connect concepts across domains.
Rohan Benkar is a software architect at Coursera and a founding member of the company’s first AI engineering team.
