Why I Stopped Using nbdev – Hamel’s Blog - Hamel Husain

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 maintain¹. I created hundreds of projects with it and was one of its biggest proponents.

У меня был такой опыт с nbdev — средой разработки для literate programming, которую я помогал создавать и поддерживать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.

Этот workflow идиосинкразичен. 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.

Центральное обещание literate programming — лучшая документация. Держа код и документацию в одном месте, ты снижаешь вероятность того, что они устареют.

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.

Этот workflow к тому же стал менее убедительным. 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 победил, потому что казался привычным и позволял разработчикам менять привычки постепенно, а не требовал нового workflow с первого же дня.

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 door².

Поскольку я вложил в 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 production³. Even Jane Street, famous for its OCaml-heavy infrastructure, now uses Python for machine learning and data work.

Это не произвольное предпочтение. AI лучше всего работает с кодом, для которого в конкретной области много обучающих данных. TypeScript недавно обогнал на GitHub и Python, и JavaScript, отчасти за счёт того, что типизированные языки делают сгенерированный 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

Сноски

Я присоединился к проекту 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.↩︎