Why I Stopped Using nbdev

Программисты обожают заявлять, что нашли лучший инструмент. Paul Graham назвал Lisp своим «секретным оружием». DHH описал Ruby как «волшебную перчатку, которая идеально легла на мой мозг». Pieter Levels выпускает продукты на миллион долларов на чистом PHP и jQuery.

Эти заявления не о самих языках. Они о том, как разработчики находят инструменты, соответствующие их мышлению. Когда среда «щёлкает», ты двигаешься быстро.

У меня был такой опыт с nbdev — средой разработки для литературного программирования, которую я помогал создавать и поддерживать1. Я создал с её помощью сотни проектов и был одним из её главных сторонников.

Сегодня я больше им не пользуюсь. AI-инструменты для написания кода изменили расклад.

Борьба с AI

Красота nbdev — в его рабочем процессе. Вы пишете код, документацию и тесты в одном источнике истины: Jupyter-ноутбуках. Затем эти ноутбуки транспилируются в Python-библиотеку и сайт с документацией.

Этот рабочий процесс нестандартен. AI-инструменты для написания кода, обученные на огромных объёмах обычного исходного кода, теряются. Они не могут отличить редактирование ноутбука от редактирования итогового исходного кода. Возникает ощущение борьбы с AI, а не совместной работы.

Я пишу софт, чтобы решать задачи, а не ради самого кода. Мне нужна среда, где AI имеет максимальные шансы на успех. С nbdev я плыл против течения.

Некоторые утверждают, что AI-инструменты поощряют ленивое мышление: без ограничений разработчики пропускают тяжёлую работу по декомпозиции задач. Но пошаговое мышление — это человеческий навык. Ноутбуки не заставляют писать чистый код. AI-инструменты не заставляют думать тщательно. Дисциплина исходит от разработчика, а не от среды.

Инструменты значат меньше, чем я думал

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

Как ни странно, во многих проектах на nbdev документация была недостаточной на мой вкус. Иногда это помогало мне изучить кодовую базу, внося вклад в документацию. В других случаях это раздражало. Это укрепило мою убеждённость в том, что хорошая документация — результат усилий, а не инструмента.

Этот рабочий процесс теперь менее убедителен. AI может прочитать кодовую базу без документации и дать обзор на лету. Он может помогать поддерживать документацию, отделённую от кода, беря на себя рутинную часть. Хранение кода и документации вместе уже не такое преимущество, как раньше.

Совместная работа и принятие

nbdev требует от разработчиков освоить другую систему. Он не встречает их там, где они есть. Cursor победил, потому что ощущался привычным и позволял менять привычки постепенно, а не требовал нового рабочего процесса с первого дня.

Раньше я не так беспокоился о совместной работе. Но сотрудничество с AI — это необходимый минимум. Те же препятствия, которые мешают совместной работе с людьми, мешают и совместной работе с AI.

Сегодня разработчики всё чаще охватывают более широкий спектр задач. Бэкендеры делают фронтенд. PM'ы создают прототипы. Все стали более полиглотами. Нестандартные фреймворки изолируют вас от команды сильнее, чем когда-либо. Раньше у нестандартного инструментария было скрытое преимущество: оно фильтровало определённый тип контрибьюторов. Теперь я считаю это скорее обузой.

Что я использую сейчас

Вложив тысячи часов в nbdev, трудно признать, что есть инструменты лучше для тех результатов, которых я хочу. Но нужно оставить эго за дверью2.

Мои основные инструменты сейчас — Amp, Cursor и Claude Code. Я по-прежнему люблю ноутбуки, но только для анализа данных, машинного обучения и других исследовательских задач, где итеративная, визуальная природа ноутбуков раскрывается в полной мере.

Что важнее, AI вытолкнул меня из прежнего мышления «Python для всего». Теперь я использую разные языки для разных задач. Для веб-разработки я предпочитаю стек Next.js. Использование ноутбука для веб-разработки (даже со специализированным инструментарием) добавляет мне ненужную сложность.

Это не произвольное предпочтение. AI лучше всего работает с кодом, для которого есть обильные обучающие данные в конкретных доменах. TypeScript недавно обогнал и Python, и JavaScript на GitHub, отчасти потому, что типизированные языки делают AI-сгенерированный код надёжнее в продакшене3. Даже Jane Street, известная своей инфраструктурой на OCaml, теперь использует Python для машинного обучения и работы с данными.

Место для радости

Всё это не значит, что нестандартные инструменты бесполезны. Lisp, Haskell и APL учат разным аспектам вычислений. Радость — вполне обоснованная причина выбрать язык, даже при меньшей поддержке со стороны AI. Просто сейчас мой фокус не на этом. Моя радость — в решении задач, и мне нужны инструменты, максимизирующие мой рычаг. Для этого побеждает мейнстрим.

Примечания

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