Huzzah - Declarative pseudocode editor for AI coding
Show HN: Huzzah – a novel approach to coding with AI
Huzzahは、AIコーディングの新しいパラダイムを提案する実験的なエディタです。長文の自然言語プロンプトの代わりに、簡潔な疑似コードで意図を記述し、ファイルを保存するたびにAIがコードを生成・更新します。プロンプトが永続化されるため、開発の履歴が明確になり、トークン消費も削減。コードの設計に集中でき、ドキュメントとしても機能します。既存のコーディングエージェントに疲れたエンジニアに、新たな選択肢を提供します。
コーディングエージェントでは、プロンプトは（a）長文で、（b）命令的で、（c）一時的です。Huzzahでは、プロンプトは（a）疑似コードで、（b）宣言的で、（c）永続的です。
HNでの議論
206- reticulates
疲れる理由を見落としているかもしれない。問題は英語を書くことではなく、変化の速さだ。プログラミングは瞑想的で、思考のプロセスであり、出力されるコードは思考の産物だ。エージェントベースの開発には…思考も瞑想もなく、思考を機械に委任し、ただ絶え間なく無限に望むことを叫んでいるだけだ。
ビジネスにとっては、プログラミングを放棄して、より短時間で多くのことをこなせるエージェントに委任するのは理にかなっているが、プログラマーにとっては損失だ。プログラマーとしてコードを書くか、委任者として委任するか、どちらかだ。自分がプログラミングしていると思い込もうとしても、委任者の生活が楽になるわけではない。
- avaer
逆の方向の方が重要だと思う：巨大で複雑な問題やコードベースを、短い擬似コードに分解すること。そうすれば、擬似コードを編集して、システムにコンパイルし直すことができる。
大規模プロジェクトに取り組むソフトウェアエンジニアは、実際にそのように働いている：まずシステムの状態に関するコンテキストを収集し、理解できるレベルで読む。次に、簡略化された表現に対する変更を提案し、その後、機械実行可能な形式（「実装」）を全体的に更新する。
このプロセスをより形式化・自動化するツールに興味がある。
- quasarj
混乱している。新しい簡潔な言語を書いて、それをコンパイルするのにお金がかかるようになった、ということだろうか？
- smicallef
しばらく前から、これに似たことを考えていた。この方向性はとても気に入っている。
私がより広く見ている課題は、（LLMに力を与えられたエンジニアとして）私たちが操作するのに適切な抽象化レベルを見つけようとしていることだ。長文の文章を書き、（時には）出力をレビューするのは、遠すぎる感じがする。しかし、LLMがIDEで直接一緒に作業するのは、「昔ながらの方法」に近すぎる感じがする。
個人的には、このアプローチはまだ低レベルの昔ながらの方法に少し近すぎる感じがするが、上記の2つのアプローチよりはましだ。
今後の展開が楽しみだ！
- leobg
愚かな質問：
お気に入りのハーネスのシステムプロンプトに、単に指示を入れればいいのでは？「私が擬似コードを渡したら、私の意図を明確にして、実際のコードで書いてテストして。」
- broken-kebab
私の見方では、少し内部矛盾がある：宣言された意図はコードを書かないことだが、人間の英語は（プログラミング言語と比較して）不正確なので、コード（より緩く曖昧ではあるが）に戻らざるを得なかった。しかし、擬似コードはそれからそれほど遠くなく、まだ厳密ではなく、LLMは依然として確率的生成器だ。だから、あなたが望むことからランダムに逸脱し続けるだろう。強化にはなるかもしれないが、誰にもわからない。もしかしたら1年後には、擬似コードが正確でないことにうんざりして、コードを書きに戻るかもしれない😉
- wyum
擬似コードアプローチには納得していないが、宣言的側面には同意する。宣言的仕様は私のプロセスの中心になり、これをサポートするツールを構築した：
https://github.com/spekk-ai/spekk-cli
網羅的な仕様を書く代わりに、意図と真でなければならないことだけを個別のアサーションとして保持する。これにより、LLMから得られるレバレッジが維持される：確実に推論できるものは何も指定する必要がない。また、（ほとんど）意図をコードやアーキテクチャの決定から分離するため、仕様を柔軟に保つことができる。
- PaulRobinson
ここでやったことは、軽量な擬似コード表現を別の言語の具体的で実行可能な形式に変換するトランスパイラを構築したことだ。
これを行う正当な理由はある：Rubyで何かを書きたいかもしれない（問題の考え方がその言語に最も合っているかもしれない）が、チェックインする成果物をPythonにしたいかもしれない（同僚が好むかもしれない）、そしてビルドパイプラインでCにトランスパイルして、最適化の山を通してコンパイラに投げて、元のコードがRubyで実行できるパフォーマンスの100倍で動作させたいかもしれない。
いっそ、RubyインタプリタをLLMへの呼び出しにして、バイトコードに変換してもらうのはどうだろう？
もちろん、これはすべて少し馬鹿げているように聞こえ始めている。なぜなら、実際に馬鹿げているからだ。私たちは、数十年にわたる研究がある領域を、高価で遅く、確率的なブラックボックスを使って再発明している。
有用性があるのは、少し曖昧でも構わないが、自然言語のような意味論的な混乱がない言語だ。しかし、それを形式文法として定義しなければ（そして、LLVMやJVMなどで実装可能にしなければ）、最悪の両方の側面を得ることになるかもしれない。