開発者がAI生成の「ゴミ」を排除するため音楽プレイヤーのコードベースを書き直す

カスタム音楽プレイヤー「AMP」を構築しているある開発者が、大規模言語モデル（LLM）によって導入された複雑さを排除するため、最近コードベースのほぼ半分を削除しました。Zigプログラミング言語で書かれたこのプロジェクトは、当初、機能を迅速に生成するためにClaude Max 20xのサブスクリプションを使用して開発されましたが、著者は生成された数万行のコードをレビューし、メンテナンスすることが困難であることに気づきました。

この画像は、大規模な手動リファクタリングが行われる前のプロジェクトの初期開発段階を表しています。

カスタムプレイヤーへの動機

このプロジェクトは、イランでのインターネット遮断への対応として始まりました。制限の厳しい体制下では、オンラインでの音楽ストリーミングは信頼できないためです。開発者は、既存のプレイヤー（Strawberryなど）には適切な行同期歌詞が欠けていると感じ、オフラインの代替手段を求めました。

新しいプレイヤー「AMP」の目標は、最小限の機能セットを持ち、C++への依存がない、ネイティブ感のあるアプリケーションを作成することでした。開発者は、一貫したシステムプログラミングのアプローチを維持するため、UIシェーダーを含むスタック全体にZigを使用することを選択しました。

「自分自身の無知と、LLMがいかに物事を複雑にするかということに驚かされました。」

— How Not to Build a Music Player

AI支援開発への移行

接続が回復した期間中、開発者はプロジェクトを加速させるために最先端のLLMを試行し始めました。彼らはClaude Max 20xのサブスクリプションを使用してアプリケーションコードの大部分を生成しましたが、著者はこのプロセスを「バイブコーディング」と表現しました。

このアプローチは初期の急速な進歩をもたらした一方で、著者が監査する際に精神的に圧倒されるようなコードベースを生み出しました。開発者は、LLMが単純なタスクを複雑にし、以前のイテレーションの明確な履歴がないと管理が困難なコードの「ゴミ（slop）」を作り出すことが多いと指摘しました。

ポリシーの制約と手動のリファクタリング

Anthropicが開発者のアカウントを停止し、CodebergがAI禁止ポリシーを発表したことで、プロジェクトは転換点を迎えました。これにより、開発者はリポジトリを移動するか、すべてのAI生成コンテンツを削除するかの選択を迫られました。

開発者は、AIが生成したセクションのすべての行を手動で書き直すことを選択しました。4ヶ月以上の期間をかけて、コードベースのほぼ半分を削除しながら、実際にはアプリケーションの堅牢性を高め、新しい機能を追加しました。著者は、LLMは単純なコマンドに対しては「高度なIDE機能」として機能する可能性があるものの、大規模なプロジェクトでは過度な複雑さを導入する可能性があると結論付けました。

技術的なトレードオフと制限

この移行における大きな制限の一つは、書き直し前の履歴がないことです。開発者が元のAI生成状態を保存するためにバージョン管理（Gitなど）を使用しなかったため、彼らは「ゴミ」を新しい手動コードと客観的に比較することができません。

AMPの最終バージョン（v0.1）には、Zigで書かれたブラーシェーダーが含まれています。開発者は現在、趣味のプロジェクトに対して、コードの保守性と理解可能性を確保するために手動の監視を優先する「オールドスクール」なアプローチを推奨しています。

この画像は、開発者の手動による書き直しの最終製品を示しており、アプリケーションのUIと機能を強調しています。