1 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • サポートが終了した Java 1.0 の数学アプレット約24本を、現代の AIコーディングエージェントで JavaScript に移植し、過去には実装できなかった可視化ツールまで完成させた
  • 既存のアプレットは数時間で復元され、Besicovitch 集合のカラー表示といった グラフィック改善や、1999年に Allen Knutson と作った honeycomb アプレットの再実装も行われた
  • 移植過程でエージェントが作ったバグはドラッグ処理に関する軽微な問題1件で、逆に既存コードの未確認バグ2件を見つけ、全体のコード品質は同程度に保たれた
  • 複雑さのため1999年に断念した「Minkowski 空間の Inkscape」という構想を、数時間の バイブコーディングで特殊相対性理論の可視化アプリのアルファ版として実装し、Gilbreath 予想の可視化も新たに制作した
  • 数学的論証の中核ではない 補助的な可視化では、LLM 生成コードのバグが及ぼすリスクは相対的に低く、今後の論文のインタラクティブな補足資料として活用できる

Java 1.0 アプレットの始まりと中断

  • 1999年から、機械を使って数学を研究・教育する方法に関心を持ち、複素解析と線形代数の講義向けに 複数のアプレットJava 1.0 で開発した
  • 講義だけでなく、honeycomb や Besicovitch 集合をはじめとするさまざまな数学的対象の可視化にもアプレットを活用した
  • ある程度の成果は得られたものの、自分でプログラミングするには多くの時間が必要で、Web標準がその Java バージョンをサポートしなくなったことで、アプレットが動作しなくなった

AIを活用した JavaScript への移植

  • 既存のWebページとブログデータを保守しやすいリポジトリへ移す際に、現代的な AI支援を活用した
  • 実験として、エージェントに既存アプレットを現在サポートされている言語へ移植するよう依頼し、最終的に JavaScript を選択した
  • 約24本の既存アプレットが数時間で再び動作するようになり、一部のグラフィックも改善された

新たなバグと既存コードの誤りの発見

  • LLMベースのコーディングエージェントは明白なものから微妙なものまでバグを作り得るが、今回の移植で新たに見つかった問題は 軽微なバグ1件だった
    • 複素解析アプレットの1つで、主領域の外へドラッグしたときに意図しない動作が発生した
  • 逆にエージェントは既存コードに潜んでいた 未確認バグ2件を見つけており、これを合わせて考えると全体のコード品質は同程度である
  • これらのアプレットは数学的論証の中核要素ではなく補助的な視覚資料であるため、バグが発生してもそれに伴うリスクは相対的に低い

1999年に断念した特殊相対性理論ツール

  • 既存アプリの移植が無理なく進んだため、新しいアプリの制作も試みた
  • 1999年に特殊相対性理論の可視化ツールとして「Minkowski 空間の Inkscape」のような構想を立てたが、当時は Inkscape もまだリリース前だった
  • Java コードの作成を始めたものの、複雑さを扱いきれずプロジェクトを断念した
  • AIエージェントと数時間バイブコーディングした結果、当時の構想に沿った時空図アプレットを実装した
  • 制作対話の要約も公開しており、反復的な技術実装の報告は編集過程で多く削除した
  • 現在のアプリは一部のプレイテストを終えただけの アルファ版で、LLM生成コードの性質上、未解決のバグや粗い部分が残っている可能性があり、追加のフィードバックが必要である

Gilbreath 予想の可視化

  • Gilbreath 予想の論文に関するブログ記事を書いた後、論文と投稿に添付する 可視化ツールもエージェントに依頼した
  • 数時間の対話を経て、Gilbreath 予想の可視化を完成させた
  • 制作過程の対話ログもあわせて公開しており、開発は大きな困難なく進んだ

論文のインタラクティブな補足資料としての活用

  • 今後の論文に インタラクティブな可視化を補足資料として追加することを検討している
  • こうした可視化は論文の核心部分に不可欠なものではないため、LLMエージェントとの誘導されたやり取りで生成したとしても、誤りによるリスクは許容できる水準である

1件のコメント

 
GN⁺ 4 시간 전
Hacker Newsのコメント
  • LLMで可視化資料を作ることで、コンピュータサイエンスの授業が大きく改善された: https://htmx.org/essays/universities-and-ai/#demos-visualiza...
    ずっと欲しかったが時間がなくて作れなかった資料を、今では用意できるようになり、Claudeの助けを借りて既存の16ビット教育用コンピュータを補完するシンプルな8ビットコンピュータも数日で設計した: https://bdp.cs.montana.edu/

    • ずっと欲しかったが時間がなかった追加機能を実装するのは、LLMの優れた活用先。特に可視化コードは完璧な構造や保守性を備えている必要はなく、正しい視覚的結果さえ出せばよく、LLMは望む見た目になるまで反復修正するのに非常に向いている
    • 数学論文を読むときにLLMで可視化を作っている。「この文章の各部分を、3Blue1Brownの動画スタイルでmanimを使って可視化せよ」と頼むと、印象的な結果が出る
      そのおかげで内容をより速く消化でき、以前より多くの論文を読めるようになった
    • LLMでPILコマンドとパラメータを書いたり修正したりして、何時間も節約している
    • 成績への反映比率を変えた記事を見ると https://acbart.github.io/2026/04/19/proctored-grades/ おおよそ50対50の配分に見える。だとすると、すべての小テストで40%を取った学生でもC-で科目に合格できるということなのか?
    • マイクロコントローラの授業で、講師が黒板に8ビットコンピュータのレジスタ、メモリ、命令を自分で描きながら説明していたが、内部動作を理解するのがとても面白かった
      教えた内容をもっと多くシミュレーションできればよいと思った。教育とは対象を構成要素に分解し、相互作用を見る過程なので、バイブコーディングしたシミュレーションは優れたツールになり得る
  • Terry Taoがコーディングエージェントでアプリを作るなら、フィールズ賞受賞者も我々と同じように、LLMにDockerコンテナがなぜ起動しないのかを尋ねるところまであと一歩だ

    • LLM以前にも、専門ソフトウェアを作るフィールズ賞受賞者のMartin Hairerがいた: https://en.wikipedia.org/wiki/Martin_Hairer, https://www.hairersoft.com/
    • AIは全員を最高水準まで引き上げるものだと思っていたが、むしろ最高峰の人々を我々の手が届く水準まで下ろした形だ
    • 逆に、コーディングエージェントがTerry Taoに、自分が取り組もうとしている証明がフィールズ賞に値するか尋ねる日を待っている
  • 特に従来のソフトウェア分野の外には、潜在的なソフトウェア需要が事実上無限にある。LLMの進歩が今日止まったとしても、新たに生まれたソフトウェア作成能力をすべて活用するには10年はかかるだろうし、今回の事例はそれをよく示している

  • 「LLMで作った対話型補助資料は論文の核心に必須ではないため、エージェントとの誘導された相互作用でこうした可視化を生成するリスクは受け入れられる」という結論はバランスが取れている
    LLMは道具なので、向いている仕事とそうでない仕事があり、一般に結果をそのまま信じるべきではない

    • LLMエージェントの結果は常に検証すべきだが、AIを擬人化するなと言いながら信頼という擬人化された表現を使うのは少し面白い。モデルと実行ツールが改善され、有効なワークフローが確立されるにつれて、AIへの信頼は急速に高まっている
      ハンマーは釘には信頼して使うが、ネジには使わない。だからといってハンマーを一般に信頼できないとは言わない。AIの難しさは、何が釘で何がネジなのかをまだ分かっていないことにある
      単に信じるなと言うより、以前より計画・反復・レビューに多くの時間を使うべきであり、技術・文脈・サブエージェントの使い方を学び、まずは非本番・低リスクのプロジェクトで練習するよう案内するほうが有用だ。良いワークフローと適切な用途を理解しながら信頼を築くことを目標にすべきだ
    • この文脈で信頼とは何なのか分からない。Donald Knuthを雇ってすべてのコードを書かせたとしても、バグがないとか、自分の要求に適しているとは信じないだろう
    • AI楽観派の中には、Taoが数学的証明でLLMを活用した発言を根拠に、すでにシステムは非常に発展していて自律的に動作すると強く見る人が多い
    • LLMは保守しにくく信頼できないひどいコードを生成する。個人用のおもちゃのような低リスクプロジェクトをバイブコーディングするのはよいが、リスクの高いコードには明らかに適していない
  • Terry Tao がコーディングエージェントを使っている様子は、ミシュラン星付きシェフが電子レンジ用の即席食品を見つけて本気で興奮している場面のように見える

    • 昔の料理本を見ながら、電子レンジ調理を真剣に発展させていたらどうなっていたかを扱った記事が興味深かった: https://malmesbury.substack.com/p/my-journey-to-the-microwav...
    • ミシュラン星付きシェフも実際に電子レンジを高く評価している。Marco Pierre White は電子レンジを「驚くべきもの」と呼び、ニシン料理には茹でたり焼いたりするより優れていると述べている: https://www.independent.co.uk/life-style/marco-pierre-white-...
      José Andrés も電子レンジのオムレツを最も失敗しにくい料理に挙げ、「人類史上最高のふわふわオムレツ」と呼んでいる: https://www.tasteofhome.com/article/jose-andres-microwave-om...
    • より正確なたとえは、Charles と Henry Greene が Gamble House に入れる繊細な宝石箱の継ぎ目を固定するため、技術で精巧な専用治具を作っている姿だ。手でも作れるが、作るものが多い人にとって時間は貴重だ
      Tao のような巨匠たちは、技術がその治具を作れることを示し、機械製作者たちは宝石箱用の治具だけでなく、治具を作る機械を作るための治具まで作れることを段階的に証明している
    • 初期の電子レンジ用即席食品に触れた当時の偉大なシェフたちが残した文章や反応があるのか気になる
    • 電子レンジが最初に登場したとき、シェフたちも本気で興奮したのではないかと思う。少なくとも初めて見れば、ほとんど魔法のように感じられる
  • 数学・物理学分野の古い教育用 Java アプレットを動かすことは、WebAssembly を通じてブラウザ上で Java バイトコードを実行する CheerpJ Applet Runner の長年人気の用途だった
    エージェントがきちんと現代化してこの問題を解決する状況を、どう受け止めればよいのか複雑な気持ちだ。学生が現代的でアクセシビリティの高い方法でコンテンツとやり取りできるのは明らかに良いことだが、商業的に重要でなくても教育分野での活用は常に誇りの源だった: https://chromewebstore.google.com/detail/cheerpj-applet-runn...

  • その分野の専門家が AI で自分の分野の何かを面白く作る記事はいつも楽しいが、常に趣味プロジェクトであって真剣な作業ではないように見える

    • Terry Tao は、最先端の数学的発見に AI を活用する方法を探ってきた数学界の代表的な人物の一人だ。今回の記事は軽めだが、中核的研究における AI 支援についても多く書いている
      https://terrytao.wordpress.com/tag/artificial-intelligence/, https://academy.openai.com/public/blogs/terence-tao-ai-is-re...
    • 大学教授にとって教材開発は仕事の一部なのに、なぜこれを趣味プロジェクトと見るのか分からない
    • 仕事で Claude Code を使い始めてみると、長くても5年以内に現在の形のコーディングはキャリアとして消える可能性が高そうに見える
      私は年齢も高く、必要ならぎりぎりながら明日引退することもできるが、まだ働かずに持ちこたえられる資産を築けていない25歳の甥のような若い開発者たちが心配だ。コードを直接書く仕事は、手で平方根を計算したり活字を鋳造したりする作業のように、ごく少数だけが行う専門領域になるだろう
    • 「いつも」と「絶対」は強すぎる表現だ。来年の今ごろにはかなり本格的な AI 活用を見ることになり、もうそうは言いにくくなると予想している
      AI コーディングの広範な活用は始まったばかりで、モデルも最近になってようやく真剣な作業が可能な水準に達した。すでに実際の活用例は見ているが、組織の方針・非公開コード・営業秘密のため、個人ブログで本番コードでの活用を公開しにくい理由も多い
    • Tao は AI を形式検証された数学や数学問題を解くアイデアにも使っている。補助資料だから問題ないというのは、その可視化が形式検証されておらずバグがあるかもしれないという意味であり、論文の中核ではないので AI を別途貢献者として記載しなくてもよいという意味でもあるのだろう
  • 「コードの複雑さが手に負えないほど大きくなり、プロジェクトを諦めた」というくだりで笑った。Terry Tao でさえ複雑すぎて書けないコードがあるのだ
    特定分野では非常に賢いのにコーディングには入ってこられなかった多くの人まで、LLM がソフトウェア開発に参加させるようになることを大いに期待している

  • Claude で30年前の高校ドイツ語の Java アプレットゲームを JavaScript に移植し、偽の Git 履歴まで作った: https://github.com/bradfitz/koffer#der-verloren-koffe
    オンラインでも実行できる: https://bradfitz.github.io/koffer/js/
    約30年前のコードが再び動き出す様子は素晴らしい

  • 文章のぎこちない最初の一文こそ、AI が書いたものではない証拠だ。「1999年に Java 1.0 で複素解析学と線形代数学の授業用アプレットを作り、ハチの巣構造や Besicovitch 集合のような数学的対象を可視化した頃から、機械の助けを借りて数学を研究し教える方法に関心を持ってきた」という文だ

    • とてもTerence Tao らしい文体だ。短く分けられる文を長くつなげて書くが、読解には特に影響しない
    • こういう文体は、Claude が滑らかに書き直した無味乾燥な成果物より常に良い