AIコーディングに疲れた人へ。擬似コードから実装を自動生成する新エディタ「Huzzah」を公開しました

皆さん、こんにちは。現在、実験的なコードエディタ「Huzzah」を開発しています。今年の1月からほぼ全てのコーディングをAIエージェントに頼ってきましたが、ここ数ヶ月で完全に燃え尽きてしまいました。AIは強力ですが、修正のたびに詳細な指示を文章で書く作業に辟易としています。さらに、コードベースが複雑になるとAIが自己矛盾を起こし始めるという限界も感じていました。そこで、「フルマニュアルに戻るのは嫌だが、今のAI主導の開発にも限界がある」という状況を打開するため、新しい対話パラダイムを考案しました。手順は以下の通りです。1. 自分の書きやすい形式で擬似コードを書く。2. 保存時にエディタが擬似コードを実際のソースコードへ同期する。3. 擬似コードは生成されたコードと共に保持されるため、あなたのプロンプトがそのまま「意図の記録」として残る。あらゆるケースで万能とは言えませんが、初期段階のテストでは非常に快適な開発体験が得られています。現在は概念実証（PoC）段階です。インストール手順はGitHubのReadme（https://github.com/danielvaughn/hz ）をご確認ください。動作デモ動画はこちら（https://x.com/danielvaughn/status/2090456808431165715 ）からご覧いただけます。ぜひ試してみてください！

前々からこの手のことを考えてたんだよね。この方向性はかなり好き。個人的に課題だと思うのは、LLMの力を得た今のエンジニアにとって、どのレベルの抽象度で作業するのが最適かという点。長文を書いて、たまにその出力をレビューするようなスタイルだと、何か遠すぎる気がする。かといって、IDEでLLMと直接やり取りするのも「昔ながらのやり方」に近すぎて違うかなと。今回の手法は、まだ低レイヤーで昔ながらのやり方に近い感じはするけど、それでも前に挙げた2つよりはずっといいと思う。これからどう進化していくのか楽しみ！

素朴な疑問なんだけど、お気に入りのツールやフレームワークのシステムプロンプトに「疑似コードを渡したら、意図を汲み取ってから、実際のコードを書いてテストしてくれ」って指示を組み込むだけじゃダメなの？

よく分からないな。これって結局、新しくて簡潔な言語を作っただけで、コンパイルするたびにお金がかかるようになったってことじゃないの？

個人的には逆の方向性の方が重要だと思う。巨大で複雑な問題やコードベースを分解して、短い疑似コードに落とし込む。その疑似コードを編集して、再びシステムにコンパイルして反映させるようなイメージ。実際のところ、大規模プロジェクトに関わるソフトウェアエンジニアって、まずはシステムの現状を把握して理解可能なレベルまで読み解くよね。その後、簡略化した表現で修正案を考えて、全体を見ながらマシン実行可能な形式（実装）にアップデートする。このプロセスをより形式化・自動化してくれるツールがあれば興味あるな。

何がそんなに疲れるのか、本質を見落としてる気がする。問題は英語を書くことじゃなくて、変化のスピードだよ。プログラミングは瞑想的で、思考のプロセスそのものだ。出力されるコードは、君の思考の結果なんだよ。エージェントベースの開発っていうのは……思考も瞑想もない。ただ機械に思考を丸投げして、ひたすらエンドレスに指示を浴びせ続けているだけだ。ビジネスの観点なら、プログラミングを捨ててエージェントに任せて時間を短縮するのは合理的かもしれない。でもプログラマにとっては損失だ。プログラマとしてコードを書くのか、それとも指示出し係として振る舞うのか。自分がプログラミングをしていると思い込もうとしても、指示出し係のストレスが減るわけじゃないよ。

まだ言及されてないのが意外だけど、コンセプト的に「codespeak」とかなり似てる気がする。
https://news.ycombinator.com/item?id=47350931 (https://news.ycombinator.com/item?id=47350931)
ただ、あのプロジェクトの現状を追ってみると、初期の頃の疑似コード駆動のバージョンからかなり進化して、ずっとハイレベルなものになってるみたいだね。

疑似コードのアプローチには懐疑的だけど、「宣言的（declarative）」な側面には同感。最近の私のプロセスでは宣言的な仕様記述が中心になっていて、それをサポートするためのツールも作ってみたよ。
https://github.com/spekk-ai/spekk-cli (https://github.com/spekk-ai/spekk-cli)
網羅的な仕様を書くのではなく、意図と「何が真でなければならないか」だけを離散的なアサーションとして保持するようにしてる。これならLLMの恩恵も受けられるし、LLMが確実に推論できることは明示的に書かなくて済む。それに、意図をコードやアーキテクチャの決定から（概ね）切り離せるから、仕様の柔軟性を保てるんだ。

このアプローチには少し内部矛盾があるように見えるな。コードを書かないという意図を宣言しているのに、結局はコード（より緩く曖昧なものではあるけど）に戻ってきている。なぜなら、人間の使う言語はプログラミング言語に比べて不正確だから。でも、疑似コードだって結局は同じようなものだし、厳密ではない。それにLLMは依然として確率的な生成器だ。だから、君が意図したことからランダムに外れるという問題は残り続けるだろうね。改善にはなるかもしれないけど、1年後くらいに「疑似コードじゃ精度が足りない」と疲弊して、また元のコードを書くスタイルに戻っている……なんてこともあるかもよ？ ;)

投稿を読んでデモ動画を見ながら、君が「Caveats（注意点）」のセクションで答えていたのと同じ疑問を抱いていたよ。
何かを試してこうして共有してくれるのは素晴らしいし、疲労感の部分以外はかなり共感できる部分も多かった。まあ、私は普段から喋り倒すタイプだから、プロンプトを書くのは苦にならないのかもしれないけどね！
私もAIを使った開発を改善しようと自分なりに色々試したことはあるんだ。まあ、自分で書いたコードであれAIに書かせたコードであれ、プロジェクトを最後までやり遂げるのが苦手な性分なんだけど！
1年くらい前にこんなの（https://github.com/ramigb/promachos ）を試してみたり（spec kitとかの存在を知る前ね）、最近ではレビュープロセスを助けるためにこんなの（https://github.com/ramigb/groundcheck ）を使ってみたりしてる。特にADR（アーキテクチャ決定記録）みたいな意図のドキュメントがある時に役立つんだ。
今回の投稿のおかげで、また違った角度から試してみようという気になった。ありがとう。

疑似コードのアプローチは面白いし、何か宝が眠ってる気がする。自分でも深く考えてたんだけど（https://www.generativenetworks.com/blog/do-we-still-need-to-learn-programming/ ）、小さなアプリを作ってる時は必要性を感じないんだよね。大規模なアプリや、プロンプトにもう一段階の精度が必要な時くらいかな。