Why I Stopped Using nbdev
Hamel Husain, один из создателей и главных сторонников nbdev — среды для литературного программирования на базе Jupyter-ноутбуков, — объясняет, почему перестал ей пользоваться. AI-инструменты для написания кода плохо справляются с нестандартным форматом nbdev, путая редактирование ноутбука и итогового исходного кода. Главное обещание литературного программирования — лучшая документация — оказалось зависимым не от инструмента, а от усилий разработчика, а AI теперь умеет сам читать и поддерживать документацию. Нестандартные фреймворки всё больше изолируют разработчика от команды и от AI-ассистентов. Сейчас автор использует Amp, Cursor и Claude Code, а ноутбуки оставил только для анализа данных и ML-экспериментов. Он также отмечает тренд на TypeScript и типизированные языки, которые делают AI-генерацию кода надёжнее.
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.
Программисты обожают заявлять, что нашли лучший инструмент. Paul Graham назвал Lisp своим «секретным оружием». DHH описал Ruby как «волшебную перчатку, которая идеально легла на мой мозг». Pieter Levels выпускает продукты на миллион долларов на чистом PHP и 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.
У меня был такой опыт с nbdev — средой разработки для литературного программирования, которую я помогал создавать и поддерживать1. Я создал с её помощью сотни проектов и был одним из её главных сторонников.
Today, I no longer use it. AI coding tools changed the trade-offs.
Сегодня я больше им не пользуюсь. AI-инструменты для написания кода изменили расклад.
Fighting the AI
Борьба с 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.
Красота nbdev — в его рабочем процессе. Вы пишете код, документацию и тесты в одном источнике истины: Jupyter-ноутбуках. Затем эти ноутбуки транспилируются в Python-библиотеку и сайт с документацией.
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.
Этот рабочий процесс нестандартен. AI-инструменты для написания кода, обученные на огромных объёмах обычного исходного кода, теряются. Они не могут отличить редактирование ноутбука от редактирования итогового исходного кода. Возникает ощущение борьбы с AI, а не совместной работы.
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.
Я пишу софт, чтобы решать задачи, а не ради самого кода. Мне нужна среда, где AI имеет максимальные шансы на успех. С nbdev я плыл против течения.
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.
Некоторые утверждают, что AI-инструменты поощряют ленивое мышление: без ограничений разработчики пропускают тяжёлую работу по декомпозиции задач. Но пошаговое мышление — это человеческий навык. Ноутбуки не заставляют писать чистый код. AI-инструменты не заставляют думать тщательно. Дисциплина исходит от разработчика, а не от среды.
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 contributing to the docs. Other times, it was frustrating. This reinforced my belief that good documentation comes from effort, not tooling.
Как ни странно, во многих проектах на nbdev документация была недостаточной на мой вкус. Иногда это помогало мне изучить кодовую базу, внося вклад в документацию. В других случаях это раздражало. Это укрепило мою убеждённость в том, что хорошая документация — результат усилий, а не инструмента.
This workflow is also less compelling now. AI can read a codebase without documentation and give you an overview on the fly. It can help maintain documentation that is separate from the code, handling the tedious parts. Keeping code and docs together isn’t the selling point it used to be.
Этот рабочий процесс теперь менее убедителен. AI может прочитать кодовую базу без документации и дать обзор на лету. Он может помогать поддерживать документацию, отделённую от кода, беря на себя рутинную часть. Хранение кода и документации вместе уже не такое преимущество, как раньше.
Collaboration and Adoption
Совместная работа и принятие
nbdev asks developers to adopt a different system. It does not meet them where they are. Cursor won because it felt familiar and let developers change their habits slowly, rather than demanding a new workflow on day one.
nbdev требует от разработчиков освоить другую систему. Он не встречает их там, где они есть. Cursor победил, потому что ощущался привычным и позволял менять привычки постепенно, а не требовал нового рабочего процесса с первого дня.
I didn’t worry about collaboration as much before. But collaborating with AI is table stakes. The same impediments that get in the way of collaborating with humans tend to get in the way of collaborating with AI.
Раньше я не так беспокоился о совместной работе. Но сотрудничество с AI — это необходимый минимум. Те же препятствия, которые мешают совместной работе с людьми, мешают и совместной работе с AI.
Today, developers increasingly span greater scope. Backend people do frontend. PMs create prototypes. Everyone is more polyglot. Idiosyncratic frameworks isolate you from your team to a greater extent than ever before. Idiosyncratic tooling once had a hidden upside: it filtered for a certain kind of contributor. Now I believe it’s more of a liability.
Сегодня разработчики всё чаще охватывают более широкий спектр задач. Бэкендеры делают фронтенд. PM'ы создают прототипы. Все стали более полиглотами. Нестандартные фреймворки изолируют вас от команды сильнее, чем когда-либо. Раньше у нестандартного инструментария было скрытое преимущество: оно фильтровало определённый тип контрибьюторов. Теперь я считаю это скорее обузой.
What I’m Using Now
Что я использую сейчас
Because I have invested thousands of hours into nbdev, it’s difficult to admit there are better tools for the outcomes I want. But I must check my ego at the door2.
Вложив тысячи часов в nbdev, трудно признать, что есть инструменты лучше для тех результатов, которых я хочу. Но нужно оставить эго за дверью2.
My daily drivers now include Amp, Cursor, and Claude Code. I still enjoy notebooks, but only for data analysis, machine learning, or other exploratory workflows where the iterative, visual nature of notebooks shines.
Мои основные инструменты сейчас — Amp, Cursor и Claude Code. Я по-прежнему люблю ноутбуки, но только для анализа данных, машинного обучения и других исследовательских задач, где итеративная, визуальная природа ноутбуков раскрывается в полной мере.
More importantly, AI has nudged me out of my previous “Python for everything” mindset. I now use different languages for different tasks. For web development, I prefer the Next.js stack. Using a notebook for web development (even with specialized tooling) adds unnecessary complexity for me.
Что важнее, AI вытолкнул меня из прежнего мышления «Python для всего». Теперь я использую разные языки для разных задач. Для веб-разработки я предпочитаю стек Next.js. Использование ноутбука для веб-разработки (даже со специализированным инструментарием) добавляет мне ненужную сложность.
This isn’t arbitrary preference. AI performs best on code with abundant training data for specific domains. TypeScript recently overtook both Python and JavaScript on GitHub, driven partly by the fact that typed languages make AI-generated code more reliable in production3. Even Jane Street, famous for its OCaml-heavy infrastructure, now uses Python for machine learning and data work.
Это не произвольное предпочтение. AI лучше всего работает с кодом, для которого есть обильные обучающие данные в конкретных доменах. TypeScript недавно обогнал и Python, и JavaScript на GitHub, отчасти потому, что типизированные языки делают AI-сгенерированный код надёжнее в продакшене3. Даже Jane Street, известная своей инфраструктурой на OCaml, теперь использует Python для машинного обучения и работы с данными.
A Place for Joy
Место для радости
None of this means idiosyncratic tools are worthless. Lisp, Haskell, and APL each teach you something different about computing. Joy is a valid reason to choose a language, even with less AI support. It’s just not my focus right now. My joy resides in solving problems, and I want tools that maximize my leverage. For that, conventional wins.
Всё это не значит, что нестандартные инструменты бесполезны. Lisp, Haskell и APL учат разным аспектам вычислений. Радость — вполне обоснованная причина выбрать язык, даже при меньшей поддержке со стороны AI. Просто сейчас мой фокус не на этом. Моя радость — в решении задач, и мне нужны инструменты, максимизирующие мой рычаг. Для этого побеждает мейнстрим.
Footnotes
Примечания
I joined the nbdev project in 2020 while at GitHub. That same year I built fastpages, a notebook blogging system that informed nbdev’s documentation approach. Along the way I contributed to tools like ghapi and fastcore. In 2022, I helped lead a complete rewrite of nbdev. I discussed the philosophy behind this work on the Vanishing Gradients Podcast and at Data Council. I was briefly interested in commercializing nbdev, but decided not to pursue it.↩︎
Other top nbdev maintainers and power users like Sylvain Gugger, Wasim Lorgat, Isaac Flath, Zach Mueller, and Wayde Gilliam have made similar moves.↩︎
Research shows 94% of LLM compilation errors in TypeScript come from type violations, suggesting type systems can guide better code generation. See Mündler et al., 2025.↩︎
Я присоединился к проекту nbdev в 2020 году, работая в GitHub. В том же году я создал fastpages — систему блогинга на ноутбуках, которая повлияла на подход nbdev к документации. Попутно я внёс вклад в такие инструменты, как ghapi и fastcore. В 2022 году я помог возглавить полную переработку nbdev. Я рассказывал о философии этой работы в подкасте Vanishing Gradients и на конференции Data Council. Одно время я рассматривал коммерциализацию nbdev, но решил этого не делать.↩︎ Другие ведущие мейнтейнеры и опытные пользователи nbdev — Sylvain Gugger, Wasim Lorgat, Isaac Flath, Zach Mueller и Wayde Gilliam — сделали аналогичный переход.↩︎ Исследования показывают, что 94% ошибок компиляции LLM в TypeScript связаны с нарушениями типов, что указывает на способность систем типов направлять более качественную генерацию кода. См. Mündler et al., 2025.↩︎