世界を動かす技術を、日本語で。

Show HN: Huzzah – AIを活用した新しいコーディングアプローチ

2026年8月21日原文(danielvaughn.dev)

概要

2026年初頭、 コーディングエージェント の進化で手動コーディングが不要に。 しかし、 長文英語プロンプト への疲労感が発生。 コード品質と 人間の意図の記録 への課題意識。 新パラダイム「 Huzzah」エディタの提案。 擬似コードによる宣言的・永続的なプロンプト で効率と可読性を向上。

コーディングエージェント時代の疲労と課題

  • 2026年初頭、 AIコーディングエージェント の性能向上による手動コーディング不要化
  • 初期は 効率化と新鮮さ で高揚感
  • 数ヶ月後、 長文英語プロンプト 作成の反復作業による疲労感
  • 手動コーディング には戻りたくないが、AI任せも不安
  • コードの品質担保プロフェッショナルとしての自信 の維持が課題

人間の意図とプロンプトの問題点

  • 現状のAIチャットは 人間の意図の記録が残らない 問題
    • プロンプトが一時的で、コードがAI生成か人間作成か不明瞭
    • 中央集権的な意図の表現手段 の消失
  • AIチャットは 命令的・逐次的な長文 で指示
    • 指示の 重複トークン消費 の非効率
    • 自然言語の情報密度の低さ社会的冗長性 が機械相手には不向き
    • 機械への長文指示 が煩雑

新たなアプローチ「Huzzah」の提案

  • Huzzah エディタの開発
    • AIプロンプトを (a) 擬似コード (b) 宣言的 (c) 永続的 な形で記述
    • 従来のエージェント :長文・命令的・一時的
    • Huzzah :擬似コード・宣言的・永続的
  • 例:Fizz Buzz実装
    • 従来 :チャットで逐次指示・修正
    • Huzzahfizz_buzz.hzファイルに擬似コード記述、保存時に自動で本コード生成、修正も擬似コードで容易

擬似コード記述の具体例

  • Fizz Buzz
    • fizz_buzz() loop 100 modulo 3 ? "fizz" 5 ? "buzz" both ? "fizz buzz"
    • 修正も擬似コードで即反映
  • ショッピングカート
    • add_item(id)remove_item(id)など操作を簡潔に記述
  • Todoリスト
    • add_todo(text)toggle_todo(id)など状態変化を宣言的に表現

Huzzah方式のメリット

  • 簡潔で可読性の高い擬似コード によるプロンプト
  • 設計への集中 が促進され、思考が活性化
  • 人間の意図が明確なドキュメント として機能
  • 言語非依存の擬似コード で複数環境対応も可能
  • 複雑なアルゴリズム設計 にも応用可能

注意点・課題

  • 大規模開発 や既存コードベースへの適用には課題
  • ドメイン知識が浅い場合 は従来の自然言語指示が簡便
  • クロスファイル依存 の表現やLSP機能の不足
  • あくまで 新規プロジェクト向き、現状は実験段階

Huzzahの現状と利用案内

  • Huzzah は現在 実験的開発中

  • ソースコード・セットアップ手順 はGitHubで公開

  • フィードバック歓迎、利用体験を共有希望

    • GitHub: https://github.com/danielvaughn/hz
    • デモ動画: https://x.com/danielvaughn/status/2090456808431165715

追記:開発者からのメッセージ

  • 2026年1月からコーディングエージェント中心 の開発を経験
  • 長文命令の反復作業 に疲弊し、 コードベースの複雑化 でAIの混乱も実感
  • 完全手動コーディングに戻りたくない との思いから新たなパラダイムを模索
  • 好きな形式で擬似コード記述→保存で本コード同期、意図の永続記録
  • 全てのユースケースに最適ではない が、初回利用では非常に楽しい体験
  • インストール方法はREADME参照、動画デモも公開中
  • フィードバックや意見を歓迎

Hackerたちの意見

こういうことをずっと考えてたんだ。これの方向性、すごくいいと思う。もっと広い視点で見ると、我々(今はLLMに力を与えられたエンジニア)が、どのレベルの抽象化で動くべきかを見つけようとしてるのが課題だね。長文を書くのや(時々)出力を見直すのは、ちょっと遠すぎる感じがする。でも、LLMがIDEで直接作業するのは「昔のやり方」に近すぎる気がする。個人的には、ここでのアプローチはまだ古いやり方にちょっと近いけど、上の二つのアプローチよりはマシだね。これからどう進めていくのか楽しみだ!

「適切な抽象化レベル」という表現、いいね。基本的にはカスタムDSLを作るようなもので、LLMの柔軟性のおかげでDSLがアドホックにできるんだ。どのタイミングで正式な厳格な構文が必要になるの?それとも、厳格な構文がないことがポイントなの?もし後者なら、「DSLコンパイラ」が混乱する前に、どれくらいの「情報ノイズ」や曖昧さを注入できるのかな?スケーリングもまた別の話だね。変換可能な擬似コードは関数を書くのにいいパターンだけど、モジュールを書くのには役立つのかな?関数の動作を変えるために段落を書くなら、LLMを使いこなせてないかも。段落はモジュールの仕様を書くのに最適で、LLMはすでに空白を埋めてくれるし。モジュール全体を擬似コードにする方が早いかどうかはわからないけど、インターフェースだけならちょうどいいかもね。

ちょっとバカな質問だけど、好きなハーネスのシステムプロンプトに「擬似コードを渡したら、意図を明確にして、実際のコードで書いてテストして」って入れればいいんじゃないの?

バカな質問じゃないよ、全然できるよ。実際、しばらくそうしてた。Claude Codeが本格的に普及する前は、これがCursorを使う主な方法だった。擬似コードを書いてハイライトして、「リアルにして」ってAIに言うだけ。すごくうまくいくよ。ただ、大きなコードベースや複雑なものになると、AIが生成した部分と人間が書いた部分を忘れがちなんだ。それに、AIが生成したコードは読みにくくて、すごく面倒だし。だから、複雑なコードを理解したいときは、エージェントに要約してもらうのが自然な流れなんだ。これも機能するけど、問題も多い。実際に求めているのは、自分の意図と実際のソースコードの両方を保持するシステムだね。それらの間にソースマップを提供して、どの部分の人間の擬似コードがどの部分の生成コードに対応しているのかを理解できるようにしたい。真の価値は、自分の意図を持続させることにあるんだ。

それは、承認する前に理解しなければならない不要な抽象レベルを追加するだけだと思う。前に進む前に半歩後退するような感じがする。

ちょっと混乱してるんだけど、新しい簡潔な言語を書いたってこと?それが今はコンパイルにお金がかかるの?

確かに言語はないよ。擬似コードは好きなように書けるし、コンパイルにお金がかかるって?LLMにプロンプトを送ってる時点で、すでにそれをやってるよ。ただし擬似コードじゃなくて文章でね。このアプローチがいいアイデアかどうかはわからないけど、試してみる価値はあると思う :)

技術的に言うと、すべてのコンパイルには電気という形でお金がかかるんだ。これはただの…非効率なコンパイルだね。

正直、この記事が何かのパロディなのかよく分からない。

逆の方向の方が重要だと思うな。大きくて複雑な問題やコードベースを短い擬似コードに分解することだね。そしたら、その擬似コードを編集して、システムに戻してコンパイルできる。大規模プロジェクトで働くソフトウェアエンジニアは、まずシステムの状態についてのコンテキストを集めて、自分が理解できるレベルで読むんだ。次に、簡略化された表現で変更を提案して、全体的にマシン実行可能な形式(「実装」)を更新する。もっとこのプロセスを形式化・自動化するツールに興味があるな。

うまいね! :) 難しい! :(

これの双方向バージョンに取り組んでるよ!大きな課題は、編集を通じて様々なバージョンを同期させることだね。

Hacker Newsで議論の続きを見る