# Why I Stopped Using nbdev

DevFeed: [Why I Stopped Using nbdev](<https://devfeed.tech/articles/why-i-stopped-using-nbdev-18783.md>)

Original publisher: [Read original article](<https://hamel.dev/blog/posts/ai-stack/>)

Author: Hamel Husain

Published: 2026-01-18T08:00:00Z

Content type: opinion

Language: en

Sources: [Hamel Husain](<https://devfeed.tech/sources/hamel-husain.md>)

Topics: [Artificial Intelligence](<https://devfeed.tech/topics/ai.md>), [ai-coding](<https://devfeed.tech/topics/ai-coding.md>), [jupyter](<https://devfeed.tech/topics/jupyter.md>), [Python](<https://devfeed.tech/topics/python.md>), [Development](<https://devfeed.tech/topics/development.md>)

Tags: [ai](<https://devfeed.tech/tags/ai.md>), [ai-coding](<https://devfeed.tech/tags/ai-coding.md>), [developer](<https://devfeed.tech/tags/developer.md>), [jupyter](<https://devfeed.tech/tags/jupyter.md>), [jupyter-notebooks](<https://devfeed.tech/tags/jupyter-notebooks.md>), [nbdev](<https://devfeed.tech/tags/nbdev.md>), [python](<https://devfeed.tech/tags/python.md>), [software](<https://devfeed.tech/tags/software.md>), [tools](<https://devfeed.tech/tags/tools.md>)

## AI overview

The author explains why they stopped using nbdev, a literate-programming development environment built around Jupyter notebooks. They argue that AI coding tools work less effectively with nbdev's notebook-to-library workflow, while AI can now help understand and maintain documentation separately from code. The author concludes that disciplined development and documentation depend more on developer effort than on the tooling environment.

## Source excerpt

Programmers love to proclaim they've found the best tool. Paul Graham called Lisp his "secret weapon." DHH described Ruby as "a magical glove that just fit my brain perfectly." Pieter Levels ships million-dollar products with vanilla PHP and jQuery. These declarations aren't about the languages themselves. They're about developers finding tools that fit how they think. When the environment clicks, you move fast. I had that experience with nbdev, a development environment for literate programming that I helped build and maintain1. I created hundreds of projects with it and was one of its biggest proponents. Today, I no longer use it. AI coding tools changed the trade-offs. Fighting the AI The beauty of nbdev is its workflow. You write code, documentation and tests in one source of truth: Jupyter notebooks. Afterwards, these notebooks are transpiled into a Python library and documentation website. This workflow is idiosyncratic. AI coding tools, trained on vast amounts of conventional source code, get confused. They struggle to differentiate between editing the notebook and editing the final source code. It feels like fighting the AI instead of working with it. I write software to solve problems, not to write code. I want to work in an environment where AI has the highest chance of success. With nbdev, I was swimming upstream. Some argue that AI tools encourage lazy thinking: that without guardrails, developers skip the hard work of breaking problems into steps. But thinking step-by-step is a human skill. Notebooks don't force you to write clean code. AI tools don't force you to think carefully. Discipline comes from the developer, not the environment. Tools Don't Matter As Much As I Thought A central promise of literate programming is better documentation. By keeping code and docs in one place, you reduce the chance they become stale. Strangely, many nbdev projects lacked sufficient documentation for my taste. Sometimes, this helped me learn a codebase by contributin