エージェントに任せると、同じファイルが一日に何十回も書き換わります。人のレビューが入るのは、その連続のあとです。ここで効いてくるのは、モデルが一発で正しく書けるかどうかより、書き換えを重ねたあとでもコードが通り続けるかどうかになります。
Aid-Onが開発している言語Almideは、その一点だけを見て設計しています。
指標をひとつに絞る
言語の良し悪しを語る切り口はいくらでもありますが、追う数字はひとつに決めました。AIの編集を経ても通るコードの割合です。速度でも記述量でもありません。
数字がひとつだと、設計の議論が短くなります。ある構文を入れるか迷ったとき、それがこの割合を上げるのか下げるのかだけを見れば決まります。測り方は修正生存率の記事にまとめました。
エラーは、直し方をひとつに絞って出す
コンパイラのエラーに候補を三つ並べると、モデルは間違ったほうを選ぶことがあります。人なら文脈から選べますが、モデルは並んだ選択肢に対して確率的に振る舞います。
Almideのエラーは、直し方をひとつに絞って示します。親切さより、迷わせないことを優先しています。
同じことを二通りで書けないようにする
書き方の自由度は、人には便利でモデルには不利に働きます。同じ処理に複数の書き方があると、生成のたびに揺れます。揺れたコードが混ざったファイルは、次の編集でさらに壊れやすくなります。
暗黙の型変換を置かない。ループの構文を増やさない。省略記法を足さない。書けることを減らすほうが、書き換えに耐えます。
出力がバイト単位で一致する
AlmideはRust経由のネイティブと、WASMの両方に出力できます。同じソースからの出力は、どちらもバイト単位で一致します。
ここが揃っていると、同じコードを手元では素のプロセスとして、本番ではWASMサンドボックスの中で動かす、という選び方ができます。権限の閉じ方を環境ごとに変えても、挙動は変わりません。
学習データに無い、という不利
新しい言語はモデルが知りません。ここは設計では埋まらないので、書き方をAGENTS.mdで渡します。手引きを足したら割合がどう動いたかを見て、効かなかったものは消します。
言語から始めた理由
AIに任せられる範囲を広げるには、壁が二つあります。何を触らせるかという権限の壁と、書いたものが壊れないかという壁です。
前者はWASIのcapabilityやサンドボックスで閉じられます。後者は実行環境では閉じられません。言語のほうで引き受けるしかない、というのがAlmideを書き始めた理由です。
自社でAIにコードを書かせている場合、同じ問いは既存の言語でも立ちます。生成されたコードがどれだけ手直しされているか、一度数えてみると、投資すべき場所が見えてきます。
