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

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

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

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

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

Борьба с AI

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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