Two major notebook products died in 2026. Both companies blamed AI. Neither explanation holds up under scrutiny, and the numbers tell a different story entirely.
In June, JetBrains sunset Kotlin Notebook, the interactive coding plugin it built to bring Jupyter-style workflows to Kotlin developers. In February, Microsoft deprecated Polyglot Notebooks, its VS Code extension that let C# and .NET developers work inside notebook cells. Both products had been positioned by their creators as the future of interactive coding for their respective ecosystems. Both are now dead, with their corporate sponsors pointing to AI-assisted coding as the inevitable replacement for the notebook format itself.
Jupyter, the open-source project that started it all nearly a decade ago, is not just surviving — GitHub’s most recent Octoverse report shows Jupyter Notebook repositories grew 75 percent year-over-year, from 1.4 million to 2.42 million. Nearly half a million of those are in AI-tagged projects. There is a story here about what makes a developer tool stick, and it has less to do with AI than the companies killing their notebook products would like you to believe.
In June, JetBrains announced it was sunsetting Kotlin Notebook, the interactive coding plugin it launched in July 2023. The plugin will be unbundled from IntelliJ IDEA starting with version 2026.2, its source code released under Apache 2.0 for the first time — and JetBrains will not publish a compatible version for 2026.3 or beyond. Anyone picking up the project faces an immediate compatibility cliff.
Marco Behler, head of the JVM ecosystem at JetBrains, was direct about the reason: “Kotlin Notebook didn’t reach the level of adoption we expected.” He also pointed to AI as a factor. “AI tools have changed how developers explore code, prototype, and iterate, and many of the workflows that originally drove notebook adoption have evolved along with that shift.”
Microsoft made a nearly identical move in February, deprecating Polyglot Notebooks — its VS Code extension for running C# and other languages inside the Jupyter format — with barely a month’s notice. The extension had drawn more than 1.8 million installs and a four-star rating. Microsoft’s messaging was essentially the same as JetBrains’s: go use AI-powered coding experiences instead.
The Python Problem Nobody Wanted to Say Out Loud
The AI explanation is convenient but incomplete. The deeper reason both products failed is that notebooks are a Python-native habit. They always have been.
The Jupyter format — the open standard both Kotlin Notebook and Polyglot Notebooks built on top of — originated in the Python data science world. Its kernel protocol is language-agnostic by design, which made it technically straightforward for JetBrains and Microsoft to plug their own languages into it. But the working culture that makes notebooks genuinely useful — exploratory analysis, inline visualization, sharing results as a living document — belongs substantively to data scientists working in Python, not to application developers working in Kotlin or C#.
A Kotlin developer at JetBrains does not think the way a data scientist at a research lab thinks. The Kotlin developer writes application code in an IDE, runs tests, commits to version control, ships a build. The data scientist loads a CSV, plots a histogram, tweaks a model parameter, plots again, shares the notebook with a colleague. These are fundamentally different workflows, and grafting one onto the other requires not just a plugin but a cultural shift. Neither JetBrains nor Microsoft managed to pull that off. AI did not kill their notebook products. The absence of a user base that already worked that way did.
Jupyter’s Quiet Dominance
The numbers tell the real story. GitHub’s Octoverse data puts Jupyter Notebook growth at 75 percent year-over-year. Within AI-tagged repositories specifically, Jupyter Notebook usage nearly doubled. Over 400,000 AI projects on GitHub use Jupyter Notebooks. The format is not going anywhere.
Google Colab, built from the ground up as a Python-first environment for data scientists and machine learning researchers since 2017, never had the audience problem that sank Kotlin Notebook and Polyglot Notebooks. It was always serving the community for whom notebooks are a daily tool — the people who reach for a notebook before they reach for an IDE because the task is exploration, not software engineering.
Google’s approach to AI integration in Colab is instructive. Rather than treating AI as a reason to abandon notebooks, Google baked agentic capabilities directly into the format. The “AI-first” version of Colab, rolled out in June 2025, added code generation, explanation, and debugging features inside the notebook interface. The pitch was not “stop using notebooks and start using AI.” It was “here is AI inside the tool you already use.” That is a fundamentally different bet about the future of developer tools, and the adoption numbers suggest it was the right one.
What This Means for Python Developers
For Python data scientists and ML engineers, the takeaway is straightforward: Jupyter is not going anywhere. The format has survived two well-funded attempts by major platform companies to transplant it into other language ecosystems, and both attempts failed for the same reason — the notebook workflow is not a general-purpose development paradigm. It is a data science paradigm, and Python owns data science.
That does not mean notebooks are immune to change. The Colab model — AI integrated into the notebook rather than replacing it — is likely where the format is heading. Writing every line of code by hand in a notebook cell is already starting to feel slow compared to describing what you want and getting a working cell back. But the notebook itself, as a document format for mixing code, output, and narrative, persists because it solves a problem that IDEs were never designed to solve: communicating exploratory analysis to other humans.
The practical implication for Python developers is that investing in Jupyter fluency still pays off. Knowing how to structure a notebook so it tells a clear story, how to use widgets for interactive parameter tuning, how to export results to shareable formats — these skills have not been obsoleted by AI coding assistants. If anything, the AI features arriving in Colab and VS Code’s Jupyter extension make these skills more valuable, because the person directing the AI still needs to know what a good analysis looks like. The AI can generate the cell. The human still needs to know whether the output makes sense.
There is also a less obvious lesson in the Kotlin Notebook and Polyglot Notebook failures: platform companies do not always understand the tools they are trying to replicate. JetBrains built a notebook plugin for IDE users who had never asked for one. Microsoft built a polyglot notebook extension for a developer community that mostly wanted better C# tooling, not a Python data science workflow in a different language. Both assumed that if they built the technical integration, the cultural adoption would follow. It did not, because tool adoption is cultural before it is technical.
For the open-source Jupyter project itself, the competitive landscape is clearer than it has been in years. The two most credible attempts to bring notebook workflows to non-Python ecosystems have been abandoned by their corporate sponsors. The remaining competition comes from within the Python ecosystem — Google Colab, VS Code’s notebook support, and emerging AI-native notebook interfaces. That is healthy competition. It pushes the format forward without fragmenting the user base across incompatible language ecosystems.
The Bigger Picture: Developer Tools That Stick
JetBrains’s Mellum2 release in the same month as the Kotlin Notebook sunset tells a broader story about where developer tool investment is heading. Mellum2 is a 12-billion-parameter coding model designed for on-premises deployment — a bet that the future of developer productivity is not about adding more features to editors and IDEs, but about the intelligence layer that sits behind every developer interaction. That is a defensible strategic bet. It also implicitly concedes that the notebook format, as a user interface paradigm, is not worth fighting for outside of the Python data science community.
Microsoft’s Polyglot Notebook deprecation points in the same direction. The company’s developer tool strategy is increasingly converging on GitHub Copilot and AI-assisted coding across VS Code and Visual Studio. A niche notebook extension for C# developers does not fit that strategy, even with 1.8 million installs. The install count says the extension was discovered. The sunset decision says it was not adopted deeply enough to justify continued investment. Discovery without retention is the signature of a tool that solved a problem nobody urgently had.
For the Python data science community, the net result of all this corporate repositioning is a stronger, more focused notebook ecosystem. Jupyter and Colab are not fighting off corporate alternatives anymore. They are improving the core product — better collaboration, better AI integration, better performance with large datasets — without the distraction of cross-language compatibility battles. The format won by virtue of being native to the workflow it serves. That is a harder thing to replicate than any technical integration, and both JetBrains and Microsoft just proved it by walking away.
Discussion
Leave a comment
No comments yet
Be the first to start the conversation.