Grok 4.7でたが、そこまでこれまでのモデルの使い分けと変えなくてもいいという印象 ベンチマーク上だと、Opus 5クラスでコストと速さはGrok 4.6と同じ ただし、他の指標も見ると、コーディングとかは他のモデルが良かったりするから、コーディネーターエージェントとしてCursor Projectsなどで軽めの計画機、オーケストレーターとしての使い方が良さそう DeepSWEは他のモデルが良かったり、バグ修正についてもMuse Spark 1.3 MaxやGPT 5.6 Solなどのモデルのほうが良かったりする

LLMはコードを書くとき、積極的に複雑さを足してくる これは何もプログラムだけじゃなく、コメントに対してもそうで、いわゆるAIスロップというものだ これはモデルの癖もあり、実装エージェントに「シンプルにして」と言っても直るものでもない それにも関わらず、これを放置するとバグや報酬ハックの温床になるリスクも含んでいるから、直す必要性はある ここでよく見るのが、オレオレハーネスなんだけど、pstack使えば一発解決だ /unslop /no-comment でAIスロップ対策、無意味なコメントが残らない仕組みになっている 規約はレビュー側に持たせ、実装側にはドキュメントなど必要なコンテキストやそのインデックスを渡して適宜参照させる方式が望ましいだろう

今後のトレンドは「検証」と「速度」だ Linterや型システムは決定論的なな検証機構で、Jevはこれまでできなかった非決定論的な検証機構を担う pstackなどで作る検証Skillがアプリの動作を検証する機構になる これらが整うとほとんどレビューをしなくても済むようになる つまり、重要なのはやはりAIスタックも含む技術スタックの選定と言える 例えば、BendのようなAIエージェント向けプログラミング言語であれば、言語に検証機構が付属しているからLintや型システムは不要になり、非決定論的な部分をJevが、動作確認をpstackが担うなど薄くできたりする 速度は、各ツールのパフォーマンスと開発速度という2つの意味でトレンドになる 最近のLinterはどれも速いし、JevもBendも驚くほど速い そして、開発速度だが、ソフトウェア開発ではこれが保てるかどうかで優位性がかなり異なってくる 検証機構を持つスタックを選定するのは前提だが、各レイヤーで適切に持つことで、この優位性を築くことができる これができたら、本番に上げるまでは動作だけ見て、PRマージどんどんしていいのでは、と思っている

企画の途中でエージェントを入れると、思考が潰される 関係ない質問、早すぎる結論、勝手に複雑なアセット、大量の解説 しかもこれらはAIスロップを伴う可能性も全然ある 思考が汚され、狭められる 企画の段階では、思考の拡散・収縮の両方が必要で、紙とペンはいい感じに拡散してくれる これはやってみるとわかるが、「いい感じに」としか言えない おそらく、AIの速度、キーボード打鍵する速度は思考を彷徨わせるよりも速いが、紙とペンであれば、速度がでないから思考の猶予・余白が生まれるのではと考えている デジタルとアナログ、AIと人間、どちらも適材適所で使っていくことが非常に重要だ 要件が固まる前は紙で、アイデア・その概要・ユーザーの利用方法・解決したい課題を決めるのが良いだろう その後の設計フェーズでは、より具体の利用方法 → grill-with-docsで設計を具体に落としていくという順が正解だ

将来伸びるのは後者 実装や書けることに価値はさほどなく、基礎から全部書く過程で調べて学んだ知識が将来の資産になるから 現時点でも、ある程度実装のレイヤーはAIに置き換わりつつあるので、これからは「なぜそのスタックを選択したのか」を説明できたり、上流の仕様とその仕様を満たすための完了条件と検証の設計で「なぜそうしたのか」を説明できる力が重要になる フロンティアモデルが賢いので、AI使いこなすことにもいずれ価値はなくなるのと、AI使いまくっただけの人が技術選定の理由とかを合理的な理由とともに言語化できるとは考えづらい

どんなことでも最初はスモールスタートが重要だ こと、ソフトウェアファクトリーに限っては特に重要で、最初から大きくしないほうがいい 1日1issueからはじめよ 出力を見て直して、仕事を続けてみる その後、判断・結果を評価し、信頼できてからスケールするのが正だ 最初から全issueをトリアージさせると、観測も修正も追いつかなくなる

Routineやイベント駆動で起動するGrok Botなどのエージェントは人がトリガーしなくても、自分で再トリガーできる形を先に作るとよい だから、別エージェントでの検証結果の確認が重要になる 別エージェントが検証結果を確認できなければ、作業エージェントを起こしに行けるでしょ？ 作業エージェントには検証をやらせて、失敗したら成功するまでloop 成功後は、別エージェントが結果を確認し、判定する

「Jevってそんなすごいの？」ってまだ思っている人は、このどちらかだろうね ・JevやLLMの理解が足りない ・AIアプリ（AIを組み込んだアプリ）の設計の理解が足りない 事例だけ見て、何ができるかわかった気になるのは、もったいないですよ！ 特に自分でツール作る、AIアプリ作る人はJevのようなモデルを使用することは、必須になる JevがないAIアプリは高級なカップ麺、速く提供されない牛丼と同じで、多くの人はそんなもの望んでないだろう 速い、安い、それなりに美味く、品質（出力）が安定している こういうものがAIアプリにおいても求められるのではないだろうか わかりやすいのがGenerative UIだが、UI生成遅いわりに、質が低く、料金もそこそこするって大分ストレスじゃないですか？ Linterもそうで、LLMで頑張ってやっても、遅いし、質が安定しないし、料金結構かかると思いませんか？ 「優れたAIソフトウェアには、小型でモジュール化された概念が必要」ということで、Jevがまさにそれになってくれるんだ これは驚かないわけにはいかなくない？！ LLMの判断は遅く、高くつくこともある、出力の形式も安定しないが、Jevはそれが得意領域だ > The fastest way I've seen for builders to get good AI software in the hands of customers is to take small, modular concepts from agent building, and incorporate them into their existing product

かわいいけど、羊じゃん😂 1枚目はワンショット、2枚目は犬っぽくするようお願いした 確かに、我が家の愛犬は白いトイプードルで羊カットなので、間違いではない、、？

私の場合はこのスタックで大体やっている リアルタイムリサーチ → Grok Bot 計画立案 → Claude Code Fable 5.1 オーケストレーション → Cursor Projects（開発）/ Grok Bot（日常タスク）with pstack コーディング/デバッグ/テスト/検証 → Cursor Projects with pstack 保守・運用・QA（フィードバック受付など）→ Grok Bot with pstack タスク管理 → Grok Bot・Notion レビュー → Cursor Projects thermos with GPT 5.6 Sol フロントエンド → Cursor ローカルでDesign Mode Composer 2.5 画像生成・文章校正 → GPT 5.6系

どうしても、AIエージェント用のプログラミング言語が未来だと思ってしまう Bendはその先駆けで、「人がコードを書かなくなっても、AIへ意図を正確に伝える言語は要る」という考えのもと開発された言語だ 人は意図・目的をプログラムに守ってほしい条件として設計し、AIが実装、言語側でそれを検証するという役割分担で、AIと人の中間層として開発・検証器として機能するのがBendだ 今回はそんなBendについて記事を書いてみた！ Bendって何？どんな課題を解決するの？を知りたい方はぜひ読んでみてください！ 私としてはpstackとともに推していきたい技術の1つとなりました！ #zenn#

Bend + JevはAIアプリでかなり強い構成だと思うし、開発でも非機械的なlinterとしてスタックに組み込むのはありだと思う ・バックエンド: Bend ・AI ライブラリ: Vercel AI SDK 　・Generative UI: json-render 　・判断: Jev 　・出力: LLM ・フロントエンド: TanStack Start（React） ・Linter: oxc + jev-lint 例えば、Generative UIとか「どんなコンポーネント表示するか」の判断に使えるし、チャットアプリでも判断のレイヤーはJevにするのが綺麗かな

SDDもそうだけど、トレーサビリティや整合性を持ち込むのも個人的にはイマイチなソリューションだと感じている 確かに、トレーサビリティという概念を持ち込めばSDDの課題を解決したうえで開発ができる、という発想は合理的に感じるし、実際に仕組み化できるのは素晴らしいことだと思う なので、これはあくまでも、個人の一意見としてツールを批判するものでは全くないということは留意していただきたい SDD with トレーサビリティは要件定義書・基本設計・詳細設計・実装・コミット・ブランチ名・PR・etcとトレーサビリティを担保しないといけない範囲が明らかに大きすぎる 成果物が増えるほど、それらを結び付け、更新し続けたり、整合性をチェックするための仕組みや、保守し続けるという管理コストがかかる これだけでも、SDD関連のSkillとトレーサビリティのSkillやSubagensなど、どれくらい必要になるのだろうか 最終的には、ソフトウェアを作るためではなく、トレーサビリティを維持するための開発になっても不思議ではないだろう 私はSDD自体が悪いとは思っていない ただし、開発全体を一つの巨大な仕様体系で覆うのではなく、何を仕様の中心にするかを決め、その周辺だけを小さく整合させるべきだと思っている 私の場合、その中心に置くのがREADMEだ READMEやチュートリアルを実装より先に書き、利用者がどのように機能を使うのかを具体化する そこからAPIや内部設計を考えることで、人間は完成形を理解でき、エージェントも「何を実装し、何を確認すれば完成なのか」という基準を持てる 私が最近行っているのは、このREADME駆動開発と、/grill-with-docsを組み合わせる方法だ ・READMEにユーザーの利用方法を記載する ・/grill-with-docsでREADMEから内部設計を作成する → 合わせてADRとドメイン用語集を残す ・READMEに記載されたユーザーの利用方法を検証する → 実装後に、pstackの/create-verification-skillでfeature mapと検証skillを作成し、検証する ・READMEに、利用者がどのように機能を使うのかを書く ・/grill-with-docsでREADMEの内容を掘り下げ、内部設計を作る → この時に、ADR、プロジェクト固有の言葉をドメイン用語集に残す ・実装後に、READMEに書いた使い方が本当に成立するかを検証する ・検証にはpstackの/create-verification-skillで作られる検証Skillを利用する → feature mapと検証Skillを作り、繰り返し検証できる形にする すべての成果物をトレーサビリティでつなぐのではなく、READMEに書かれた利用者の体験を起点に、設計、実装、検証をつなぐ READMEを外側の契約、/grill-with-docs を内側の設計、検証Skillを完成条件にする これにより理解負債も蓄積されずに、検証も付けられ、最低限のレビューで開発を進められている

BendのようなAIエージェント用の言語は追っておいたほうがいいよ Jevもそうだけど、JevでできるLint・レビュー周りのユースケースを全て言語側で担えるから 簡単に言うと、検証機構が言語にあるってことだ 一時期IDD（意図駆動開発）が話題になったけど、Bendは、これのWhatに当たる いうなれば、目的駆動開発（Purpose Driven Development）の仕組みが言語に搭載されているものだ ■ IDDのIntent（意図）の構成 Why -- この機能・変更がなぜ必要なのか。ビジネス上の動機、ユーザーの課題 What -- 外から見たときに何を満たすべきか。入出力の契約、成功・失敗の条件、制約

jevで思いつくユースケースがエンジニアがターゲットのユースケースが多いからそう言える ただい、Linter・バリデーション・レビューなどのユースケースって最終AIエージェント向けの言語やフレームワークが吸収すると思う Bend 2が発表されて、それが確信に変わっている そうなると、AIアプリの設計とかになるが、ここはまだ優位性があるだろうね どこをLLMにして、どこにjevを挟むか、そしてどこをプログラム的に制御するか、LLMやjevがコケた時、プログラム的な制御をどこまでするべきか、といった判断や設計はまだエンジニアじゃないと厳しい が、これもAIエージェント向けの言語などで、目的だけ伝えたら、できるようになると思うから、結局いつエンジニアが不要になってもおかしくない、というのが個人的な意見 こうなると、「何をしたいか」の目的と「何を満たしてほしいか」の条件（要件）を言語化できる人が強いよ エンジニアに限らずね！

jevのlinterがでてきた！ コードの命名・コメント・テストが実装内容とズレがないかを高速・安価に確認できるLinterだ 例えば、以下のような問題を見つけられる ・calculateTotal という関数が、合計を計算するだけでなく注文データまで保存している ・safeParseConfig という名前なのに、不正な設定を渡すと例外を投げる ・「同じ通知を二重送信しない」というテストが、通知処理を1回しか呼んでいない ・「5秒でタイムアウトする」というコメントがあるのに、実装では30秒に設定されている コードは正しく動いていても、名前やコメントが実装と異なることはよくあるが、これまではLLMでレビューコストをかけたり、人間が見つけるしかなかった jev-lintは、こうした意味のズレをAIで検査してくれるため、人間のレビュー負荷を下げてくれる これまでのLintや型チェッカーを置き換えるものではなく、それらに足りないものを補完してくれるLinterだ 構文や型、決められたパターンなど、機械的に判定できる問題は既存のツールに任せ、判断が必要な部分をjev-linterが担ういうjevの役割分担通りの使い方ができる 現在用意されている標準ルールは以下のとおり ・fn-name-promises 関数の処理が、名前から期待される内容と違っていないか ・var-name-describes-value 変数名が、実際に入っている値を正しく表しているか ・test-name-describes-code テスト名と、実際に実行している内容が一致しているか ・test-name-verifies-claim テスト名が主張している動作が壊れても、テストが通ってしまわないか ・module-name-describes-contents ファイル名やモジュール名が、中身の役割を表しているか ・module-naming-consistent 同じモジュール内の似た操作に、一貫した名前が付いているか ・safe-name-is-safe safe、try、OrNullなどと付いているのに、失敗が例外として外へ漏れていないか ・idempotent-name ensure、upsert、registerなどと付いているのに、繰り返し呼ぶことで余計な変更が発生しないか ・pure-name-is-pure compute、format、parseなどと付いているのに、外部の状態を読み書きしていないか ・test-mocks-subject 本番コードを検証しているように見えて、実際にはモックが返した値だけを確認していないか ・snapshot-only-behaviour-claim 特定の動作を検証すると書いてあるのに、スナップショットしか確認していないか ・comment-describes-declaration 関数や変数の上にあるコメントが、現在の実装と一致しているか ・comment-describes-block 処理の途中にあるコメントが、その直後のコードを正しく説明しているか ・log-level-matches-event 失敗なのにinfo、通常の処理なのにerrorなど、ログレベルが処理内容と食い違っていないか ・script-name-does package.jsonのscript名と、実際に実行するコマンドが一致しているか さらに、プロジェクトに合わせて独自ルールも追加できる 例えば、以下のようなルールを追加できる ・デバッグメッセージの内容と、実際に出力している値が一致しているか ・プロジェクト固有のアンチパターンが含まれていないか ・独自の命名規則と実装が一致しているか ・特定の処理に必要なエラー対応が抜けていないか

Jev + Grok Botはめっちゃいいかもしれない そして、1つ超よさそうなユースケースを思いついた それが、Samの判断部分をJevに行ってもらうことだ SamはSlack、Notion、メールで決まったことをNotion DBに記録してくれるBotで、チケットが完了するまで、全体にOpenに保ってくれる神Botだ Jevに以下の項目を判断させたら、結構良さそうに思う 特に、モデルとEffortの判断って結構迷う部分だから、Recommendで書いてあるだけで嬉しいかもしれない ・誰にアサインするべきか ・どのモデルを、どのEffortで使うべきか ・重要度・緊急度の判断 ・いつまでに何が完了していないといけないか ・制約・前提条件は何か ・依存タスクはどれか

Grok Botはチャットからしか動かないと思っているなら、それは古いよ Slack・Email・Sentry・Notion・フィードバック・パッケージエラーなどイベントをトリガーにできる やり方はDr. eggbot に「how can I do your need with webhooks?」と聞けばいい

pstackのno-commentsは、コメント削除スキルじゃないよ コメントが要らない実装に、してくれるものだ 実際には実装後に、別人格のサブエージェントがコメントが不要となるようにしてくれる コメントは原則、以下だけでいいと思ってる ・外部連携などでコンテキストがないとわからなくなるもの 以前もポストしたが、コメントはエージェントのハックの結果で、バグの原因にすらなりかねないからだ

Bendがプログラミング言語の未来なので、私も強気かつ楽観的だ 今コードレビューが一番のボトルネックになっているが、Bendを使えばコードレビューはなくなる Bendは言語自体が検証機能を持つ、Vibe Coding時代にも、AIへ正確に意図を伝えるための言語で、@VictorTaelin さんによって開発されている 言語、つまり、コードベース自体が自分自身を形式的に検証する仕組みがあるから、人間は「目的を定義すること」に集中できるし、開発速度も爆発的に上がる 型システム、Lint、pre-cmmit、CIでは届かなかった箇所を言語で補うことができるし、人間がハーネス設計を頑張る必要もなくなる 今だとJevでそういったことを補完はできるが、私は、言語やフレームワークで補う方向性が未来だと感じる 仕組みとしては、以下だ 1. LAWS.bendにプログラムに満たしてほしい条件を記述 2. AIが実装コードを書き、そのコードが条件を満たすことを示す証明をPROOF.bendに記述 3. bend PROOF.bend を実行し、証明の正しさを検証する 未証明のルールが残っていたり、証明が成立しない場合、検証は失敗する AIにLAWS.bendを変更させないようにすれば、実装が正確に行われるまで修正→検証ループを回すことができる しかもBendのコンパイル速度は驚くほど速いので、AIがコードを変更するたびに検証を確認することも可能となっている 人間がやるのは目的の定義だけになる 形式的にコンパイルが検証を行い、自信を持ってコードを本番に届けることができるようになる UIはpstackの検証Skillで検証できることも忘れてはいけない