私がnbdevの使用を止めた理由
nbdev の共同開発者であるハメル・フサインは、AI コーディングツールの台頭により、リテラプログラミングのワークフローが逆効果になることを指摘し、従来のツール至上主義から「AI と協働しやすい環境」へのパラダイムシフトを提唱している。
キーポイント
AI ツールとの競合によるワークフローの非効率化
nbdev のような特殊なノートベースのワークフローは、従来のソースコードで訓練された AI ツールに混乱を与え、開発者が AI と対立する結果を招く。
ドキュメント統合への依存低下
AI がコードベースから即座に文脈を理解・要約できるため、コードとドキュメントを一体化させる必要性が以前より薄れている。
学習コストと採用の壁
新しいワークフローへの移行を強制するツールは、開発者の習慣を変える難易度が高く、AI ツールとの協働という文脈では採用が阻害される。
AI と型システムの重要性
AI はトレーニングデータが豊富な特定ドメインのコードで最も効果的であり、TypeScript のような型システムを持つ言語は生成されたコードの信頼性を高めるため、Web 開発などでは Python よりも好まれる傾向にある。
ツールの目的別使い分け
nbdev はデータ分析や機械学習のような探索的ワークフローには適しているが、Web 開発には Next.js スタックなどの標準的なツールチェーンの方が複雑さを減らし効率的である。
生産性最大化のための妥協
特定の言語やツールから得られる「喜び」も価値があるが、現在は問題解決とレバレッジの最大化を優先し、AI の支援が受けやすい従来のツールを採用している。
影響分析・編集コメントを表示
影響分析
この記事は、生成 AI の進化によってソフトウェア開発のツール選定基準が根本から変わりつつあることを示唆しています。かつて「最強」とされた特殊なワークフローも、AI ツールの特性と相容れない場合、むしろ開発速度を阻害する要因となり得るという重要な警鐘です。今後の開発環境設計においては、AI の推論能力を最大限に活用できる汎用性の高い基盤が重視されるようになるでしょう。
編集コメント
開発者の「道具への愛着」が AI の特性によって相対化される現象を、現場の経験則に基づき鋭く指摘した貴重な分析です。
プログラマは自分が最高のツールを見つけたと主張することを好みます。ポール・グラハムは Lisp を彼の「秘密兵器」と呼びました。DHH は Ruby を「私の脳に完璧にフィットする魔法の手袋」だと表現しました。ピエーター・レベルズはバニラ PHP と jQuery で数百万ドルの製品をリリースしています。
これらの声明は言語そのものに関するものではありません。それは、開発者が自分の思考スタイルに合うツールを見つけることについてのものです。環境が噛み合ったとき、あなたは速く動けます。
私は nbdev においてそのような体験をしました。これは私が構築と維持を手伝ったリテラシープログラミングのための開発環境です1。私はそれを使って数百のプロジェクトを作成し、その最大の支持者の一人でした。
今日、私はもはやそれを使用していません。AI コーディングツールの登場がトレードオフを変えました。
AI との戦い
nbdev の美しさはそのワークフローにあります。コード、ドキュメント、テストを一つの真実源である Jupyter ノートブックに記述します。その後、これらのノートブックは Python ライブラリとドキュメントウェブサイトにトランスパイルされます。
このワークフローは特異的です。膨大な量の従来のソースコードで訓練された AI コーディングツールは混乱します。ノートブックの編集と最終的なソースコードの編集を区別することに苦労します。AI と協力して作業するのではなく、AI と戦っているような感覚になります。
私は問題を解決するためにソフトウェアを書くのであって、コードを書くために書くわけではありません。AI が成功する確率が最も高い環境で働きたいのです。nbdev では、私は上流に向かって泳いでいました。
AI ツールは怠惰な思考を促すという主張があります。ガードレールがないと、開発者は問題を段階に分解するという困難な作業を省略してしまうからです。しかし、ステップバイステップで考えることは人間のスキルです。ノートブックがクリーンなコードの記述を強制するわけではありません。AI ツールも注意深く考えることを強制するものではありません。規律は環境からではなく、開発者自身から生まれるものです。
ツールは私が思っていたほど重要ではない
リテラプログラミングの中核的な約束の一つは、より良いドキュメント作成です。コードとドキュメントを一つの場所に保つことで、それらが陳腐化する可能性を減らすことができます。
奇妙なことに、多くの nbdev プロジェクトは私の好みには十分なドキュメントを持っていませんでした。時には、ドキュメントへの貢献を通じてコードベースを学ぶのに役立ちました。しかし、他の時には非常に苛立たしいものでした。これは、優れたドキュメント作成はツールではなく努力から生まれるという私の信念を強化しました。
このワークフローも今では以前ほど魅力的ではありません。AI はドキュメントなしでコードベースを読み込み、その場で概要を提供できます。また、コードとは別に維持されるドキュメントの保守を手伝い、退屈な部分を処理することも可能です。コードとドキュメントを一緒に保つことは、かつてのような売り文句ではなくなりました。
コラボレーションと採用率
nbdev は開発者に異なるシステムを採用するよう求めます。それは開発者が現在いる場所には寄り添いません。Cursor が勝ったのは、それが親しみやすく感じられ、開発者に習慣の変化を徐々に促したからです。一方で、初日から新しいワークフローを要求することはしませんでした。
以前はコラボレーションについてそれほど心配していませんでした。しかし、AI とのコラボレーションは必須の条件です。人間とのコラボレーションを妨げる同じ障害が、AI とのコラボレーションも妨げることになります。
今日、開発者の活動範囲はますます広がっています。バックエンド担当者がフロントエンドを担当し、PM がプロトタイプを作成します。誰もが多言語に対応するようになっています。独自性の強いフレームワークは、かつてないほどチームからあなたを孤立させる要因となっています。独自性の強いツールにはかつて隠れたメリットがありました：特定の種類の貢献者を選別できる点です。しかし今では、それはむしろ負債だと考えています。
私が現在使っているもの
nbdev には何千時間もの投資をしてきたため、望む成果に対してより良いツールがあることを認めるのは難しいです。しかし、自分のエゴは置いておく必要があります2。
私の日常の主力ツールは now Amp, Cursor, Claude Code です。まだノートブックも楽しんでいますが、反復的で視覚的な性質が光るデータ分析、機械学習、その他の探索的ワークフローに限定しています。
より重要なのは、AI が私を以前の「何でも Python」というマインドセットから押し出したことです。今は異なるタスクには異なる言語を使っています。Web 開発については Next.js スタックを好みます。ノートブックを Web 開発に使うこと（専用ツールを使っていても）は、私にとって不必要な複雑さを追加するだけです。
これは単なる好みの問題ではありません。AI は、特定のドメインに対して豊富なトレーニングデータを持つコードにおいて最も高い性能を発揮します。TypeScript は最近、GitHub 上で Python や JavaScript を抜いて首位に立ちました。その背景には、型付き言語が本番環境における AI 生成コードの信頼性を高めるという事実も一部関係しています3。また、OCaml に依存したインフラで有名な Jane Street でさえ、機械学習やデータ処理には Python を使用し始めています。
喜びのための場所
これらは、個性的なツールが無価値であるという意味ではありません。Lisp、Haskell、APL はそれぞれ、計算について異なることを教えてくれます。喜びは言語を選択する正当な理由となり得ます。AI のサポートが少なくてもです。しかし、それが私の現在の焦点ではないだけです。私の喜びは問題を解決することにありますし、最大のレバレッジを発揮できるツールを求めています。その点では、従来のアプローチが勝ります。
脚注
私は 2020 年に GitHub に在籍中に nbdev プロジェクトに参加しました。同年にノートブックベースのブログシステム「fastpages」を構築し、これが nbdev のドキュメント作成アプローチに影響を与えました。その過程で、ghapi や fastcore といったツールにも貢献しました。2022 年には、nbdev の完全な書き換えを主導する役割を果たしました。この作業の背後にある哲学については、「Vanishing Gradients Podcast」や「Data Council」で議論しました。一時期は nbdev の商用化に興味を持ちましたが、追求しないことを決めました。↩︎
Sylvain Gugger、Wasim Lorgat、Isaac Flath、Zach Mueller、Wayde Gilliam といった他の主要な nbdev メンテナーやパワーユーザーも同様の動きを見せています。↩︎
研究によると、TypeScript における LLM のコンパイルエラーの 94% が型違反に起因しており、これは型システムがより良いコード生成を導く手助けとなる可能性を示唆しています。Mündler ら、2025 年参照。↩︎
原文を表示
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 contributing to the docs. Other times, it was frustrating. This reinforced my belief that good documentation comes from effort, not tooling.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.↩︎
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み