- LLMを基盤とする次世代プログラミング言語で、コードベースを5〜10分の1に縮小できる
- 開発者はコードの代わりに**簡潔な仕様（spec）**を書き、
codespeak buildコマンドでコードが自動生成される
- 仕様が変更されると、システムが**仕様差分（diff）**をコード差分に変換して反映する
- 手書きコードと生成コードが混在するプロジェクトもサポートし、実際のオープンソース事例でテスト通過率の向上が確認されている
- 複雑なソフトウェアを扱うチーム単位のエンジニアリングに焦点を当て、仕様中心の保守を通じて人間にやさしい開発環境を目指す
CodeSpeak 概要
- CodeSpeakはLLMが駆動する次世代プログラミング言語で、コードベースを5〜10分の1に縮小することを目標としている
- サイトの説明によれば、「Shrink your codebase 5–10x」という文言で効率性を強調している
- この言語はプロダクション級システム構築のためのツールであり、単なるプロトタイプではなく長期プロジェクト向けに設計されている
- 複雑なソフトウェアを開発するエンジニアチームを主な利用者として想定しており、個人開発者中心の実験的コーディングではなく協業中心の開発を志向している
仕様ベースの開発方式
- CodeSpeakの核心は**「Maintain Specs, Not Code」**という哲学
- 開発者は簡潔な仕様（spec）を書き、
codespeak buildコマンドでコードが自動生成される
- 仕様が修正されると、システムが**仕様の変更（diff）をコード変更（diff）**へ自動変換する
- このアプローチは、コードより仕様を維持・管理する方が人間にとって容易である点を強調している
混在プロジェクトのサポート
- CodeSpeakは既存の手書きコードと生成コードが共存するプロジェクトをサポートする
- 例として、MicrosoftのMarkItDownリポジトリをフォークした事例を紹介
- 混在プロジェクトを段階的に扱う**チュートリアルガイド**を提供
コード → 仕様変換機能（予定）
- CodeSpeakは既存コードを分析して仕様へ変換する機能を準備中
- これにより既存コードの一部を5〜10分の1の小さな仕様に置き換えられる
- 仕様の保守がコードより人間にやさしいことを強調している
実際の事例研究（Case Studies）
- CodeSpeakは複数のオープンソースプロジェクトのコードを仕様に変換してテストした
- yt-dlpのWebVTT字幕サポート: 255 LOC → 38 LOC、6.7倍縮小、テスト37件追加
- FakerのイタリアSSN生成器: 165 LOC → 21 LOC、7.9倍縮小、テスト13件追加
- beautifulsoup4のエンコーディング自動検出: 826 LOC → 141 LOC、5.9倍縮小、テスト25件追加
- markitdownのEML→Markdown変換器: 139 LOC → 14 LOC、9.9倍縮小、テスト27件追加
- 各事例でテスト通過率が維持または向上しており、仕様ベースのアプローチの実効性を示している
まとめ
- CodeSpeakは仕様中心のAIプログラミング言語で、自動コード生成と保守効率を組み合わせる
- LLMベースのコード生成、仕様とコードの同期、混在プロジェクトのサポートが主な特徴
- 実際の事例でコード削減とテスト改善が実証されており、チーム単位のソフトウェアエンジニアリングの生産性向上の可能性を示している
4件のコメント
これを言語と呼ぶのが釣りなのか、そういう時代になったのか
> Joel Spolskyがイェール大学の講演で述べたように、「仕様（spec）からプログラムを生成する」試みはこれまで常に失敗してきた。
> 仕様がプログラムを完全に定義できるほど詳細であるなら、その仕様を書くこと自体がプログラムを書くのと同じくらい難しい、という話だ。
原則としては同意しますが、そもそも完全なものは存在しないというゲーデルの証明のように、完全なプロダクトがあり得るという前提でこうした試みを批判しているようにも見えます。
MDD（Model Driven Dev.）を思い起こさせます。
Hacker Newsのコメント
Joel Spolskyがイェール大学の講演で述べたように、**「仕様（spec）からプログラムを生成する」**試みはこれまで常に失敗してきた
仕様がプログラムを完全に定義できるほど詳細なら、その仕様を書くこと自体がプログラムを書くのと同じくらい難しいという話
講演原文リンク
今は不完全なプロンプトでもプログラムを生成でき、プロンプトを体系的に扱う研究には価値があると考える
機能追加よりも、振る舞いの制約と構造的な不変条件を定義する方向へ拡張性が移っている
「1. ユーザーに情報を入力してもらい、2. HTTPリクエストを送り、3. エラーが出たら報告する」といった具合だが、
それなら単にスクリプトを書いたほうがずっと速くて決定的だと思う
これは新しい言語ではなく、LLMベース開発のためのワークフローとツールだ
コードの代わりにMarkdownの仕様ファイルを保守し、
codespeakが仕様のdiffをもとにコードを修正する利点はプロンプトがコードと一緒にバージョン管理される点で、欠点は仕様がコードのあらゆる細部を反映できない点だ
codespeak takeoverというツールでコードを仕様に変換し、エージェントセッションのプロンプトを反映させる実験を進めている短期的な「スプリントモード」から長期的な「マラソンモード」へ切り替える発想だと説明している
関連ブログリンク
アイデアが単純なので誰でもすぐ再実装でき、オープンソース版がすぐ代替するだろうと予想する
「小さな変更」許容ポリシーが必要だと提案している
全体としては漸進的な疑似コードコンパイラという概念が興味深い
5年後にはこんな形でコードは書かず、英語レベルの技術仕様で十分になっていそうだ
このアプローチは言語というより、仕様をコードへマッピングするツーリングだ
ただしモデルは非決定的なので、同じ仕様でも毎回違う結果になる可能性がある
仕様は本質的に情報損失の大きい要約なので、大規模コードベースでは一貫性の維持が難しい
私が見たいのは、テキスト仕様 → 形式仕様（formal spec） → コードへとつながる検証可能なパイプラインだ
重要なのはコードそのものより振る舞いの結果の一貫性だ
仕様がコードより抽象的であるほど多様な実装が可能になるため、決定性は依然として保証されない
自動テストこそが本当の仕様の役割を果たすべきだと思う
**シード（seed）**を固定すれば、同じ入力に対して同じ出力が得られると考えている
CursorやAntigravityは人間中心の「vibe coding」に最適化されているが、Kiroはエージェント中心の仕様ベース開発に特化している
EARSやINCOSEのような構造化フォーマットを使い、自動一貫性チェックと**プロパティベーステスト（PBT）**を生成する
仕様がしっかりしていれば、実装はほぼ自動的についてくる
複数のCLIエージェントを並列で動かして、完成度の高い結果を得ている
形式的なプロンプト言語の問題は曖昧さではなく、モデルの文脈理解力不足だ
同じプロンプトでもコンテキストによって結果が変わる
プロンプトを形式化しても、モデルがコードベースを誤解していれば意味がない
モデルは対話言語に最適化されているので、形式言語を直接書くより必要なときだけ使うほうがよいと思う
単に決定的で形式的な方法でコンピュータに意図を伝えられたらいいのに、という願いを述べている
この概念はLLMの内部構造を誤解した前提から出発している
最近の研究によれば、LLMにはエンコーディングとデコーディングの間に別の処理段階が存在し、
学習後は言語自体がそれほど重要でない可能性もある
関連研究リンク
人間が望むことを明確に表現できるよう支援するのが目的だ
そもそもこんなツールが必要なのか分からない
単にMarkdownの仕様を直接書いて、エージェントにコードを生成させれば十分だ
チュートリアルの「Prerequisites」にAnthropic APIキーが必要だと書かれている
アルファ版なので暫定対応なのかもしれないが、なぜわざわざAPIを使う必要があるのか気になる
Claude Codeのようなセッションに直接プロンプトを注入してもよさそうだ
参考リンク
このプロジェクトは、私が進めているLLM実行系言語仕様と非常によく似ていて興味深い
私のプロジェクトAILはYAMLベースでプロンプトチェーンを定義・実行する
中核は**「プロンプト精製エンジン」**を置き、ユーザーの自然言語を構造化された命令へ変換することだ
たとえばユーザーの意図を分析して段階的に分解し、現代のプロンプトエンジニアリング標準に合わせて最適化する
こうしたインターセプターがあれば、「今言ったことをCodeSpeak形式に変換して」といった流れも可能になるはずだ
本当に素晴らしいアイデアなので、ぜひ深く掘り下げてみたいと思う