Huzzah: AI支援コーディングへの宣言的擬似コードアプローチ

HuzzahはAIコーディングに宣言的パラダイムを導入する

Huzzahは、AI支援によるソフトウェア開発を、長文の命令的なチャットプロンプトから、永続的で宣言的な擬似コードモデルへと移行させるために設計された実験的なエディタです。一連の過渡的なチャットメッセージを通じてコードベースへの変更を記述する代わりに、開発者は.hzファイルに擬似コードを用いて自身の意図を記述します。エディタはそれを使用して、対応するソースコードを自動的に生成および更新します。

このアプローチは、現在のAIコーディングエージェントのワークフローにおける3つの主要な摩擦に対処します：

人間の意図の喪失: 従来のエージェント型ワークフローでは、プロンプトはしばしば破棄され、なぜ特定の変更が行われたのかという信頼できる記録が残りません。
命令的な非効率性: チャットベースの指示は、アプリケーションのdesired state（望ましい状態）ではなく、changes（変更内容）を記述するため（例：「ループを、入力を受け取るように変更して」）、繰り返しの指示やトークンの浪費につながります。
文章による疲労: すべての技術的な変更に対して詳細な自然言語による記述を書くことは煩雑であり、実際の情報内容よりも社会的なフィラー（埋め草）が多く含まれることがよくあります。

Huzzahのワークフロー：ソースとしての擬似コード

Huzzahのパラダイムでは、プロンプトはもはや過渡的なメッセージではなく、永続的なファイルとなります。ワークフローは会話から設計プロセスへと移行します：

宣言的定義: 開発者は.hzファイルを作成し、ロジックの擬似コード表現を作成します。例えば、AIに「100回ループしてfizz/buzzを表示する関数を作成して」と頼む代わりに、開発者はロジックを定義する簡潔で構造化された擬似コードブロックを記述します。
自動生成: .hzファイルを保存すると、Huzzahは実際の実行可能なコードを生成します。
永続的な反復: 動作を変更するには、開発者は擬似コードファイルを更新します。Huzzahは擬似コードのdiffをキャプチャし、それを使用して影響を受けるソースコードを再生成します。

この手法により、擬似コードはプロンプティング・インターフェースと永続的な開発者ドキュメントの両方の役割を果たすことができます。なぜなら、それは人間の意図を、読みやすく、言語に依存しない形式で明示的に表現するからです。

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

Huzzahは意図を表現するより簡潔な方法を提供しますが、いくつかの技術的な課題も導入します：

スケーラビリティ: 大規模で複雑なコードベースに対するこのアプローチの有効性は、まだ証明されていません。
依存関係の管理: 擬似コードにおいて、ファイル間の依存関係や複雑なimport/exportを表現することは、標準的なプログラミング言語よりも困難です。
ツールの欠如: 標準的なLanguage Server Protocol (LSP) の機能（オートコンプリートや定義への移動など）は、擬似コードにはネイティブで利用可能ではありませんが、著者はそれらが生成可能である可能性に言及しています。
ドメイン知識の必要性: このアプローチは、ユーザーが構造化された擬似コードを書くための十分なドメイン知識を持っていることを要求します。この知識が不足しているユーザーは、自然言語による文章の方が簡単だと感じるかもしれません。

コミュニティの視点と批判

ソフトウェアエンジニア間の議論は、Huzzahを抽象化の必要な進化と見るか、既存の慣習を再発明していると見るかで分かれています。

アプローチに対する賛成意見

一部の開発者は、「マシン・ヒューマン・パトワ（機械と人間の混成語）」が台頭していると主張しています。これは、形式的なコードと曖昧な記述の間の、中間的な領域です。支持者は、意図をなるべく永続的な成果物として残すことで、AIが書いたコードベースを監査や保守が容易になると示唆しています。

"I’d feel much more confident to use a vibe-coded library where I can read the human-written intentions than one where I just see a lot of AI-written code."

アプローチに対する反対意見

批判的な人々は、Huzzahが既存のソフトウェアエンジニアリングの規律を再発明している可能性があると主張しています。一部の人は、Behavior Driven Development (BDD) や Gherkin syntax を、テストを通じて実行可能な宣言的挙動を定義するための確立された方法として指摘しています。

また、他の批判者は、このアプローチは本質的に「コンパイルするために費用がかかる簡潔な言語」であると示唆しています。なぜなら、確率的なLLMを使用してトランスパイラとして機能させるからです。また、プログラマーが、困難なロジックエラーを解決するために必要な批判的思考から、さらに遠ざかるという懸念もあります。

"The problem is not writing English, it’s the rate of change... you’re delegating the thinking to a machine, you’re just barking what you want to what it, incessantly, endlessly."

代替案の提案

複数の貢献者は、新しいコードを生成するために擬似コードを使用するよりも、既存の巨大なコードベースを短い擬似コードの要約に分解すること（逆方向のアプローチ）の方が、レガシーシステムの管理においてより価値があるのではないかと提案しました。