先週、私たちのプロダクトマネージャーの1人（PM）が、ある機能を作って出荷しました。仕様には載せていません。チケットも起票していません。作って、テストして、たった1日で本番環境にリリースしました。
それより数日前、私たちのデザイナーが、IDEプラグインの見た目がデザインシステムからずれてきていることに気付きました。昔の世界なら、スクリーンショット、JIRAチケット、意図を説明するための会話、そしてスプリント枠です。ところが彼はエージェントを開き、自分でレイアウトを調整し、試して、反復して、リアルタイムでチューニングしてから、修正を投入しました。デザインの直感が最も強い人が、デザインをそのまま直接直しました。翻訳レイヤーは不要でした。
こうしたことは、理屈の上では新しい話ではありません。バイブ・コーディングは、ソフトウェア作成の門戸を何百万人にも開きました。これは願望でした。私が共有したデータで、私たちのエンジニアがどのようにスループットを2倍にし、コーディングからバリデーションへとシフトし、迅速な実験のためにデザインを前倒しで持ち込み、それでも工学的な物語として語れるのだと示しました。変わったのは、理論が実践になったことです。ここでは実際にどう展開したのかをお伝えします。
ボトルネックが移動した
2025年にAIファーストへ舵を切ったとき、実装コストは崩れ落ちました。エージェントが足場作り、テスト、そしてスプリントの半分を食っていた反復的なつなぎ（グルー）コードを引き受けました。サイクルタイムは、週単位から日単位へ、日単位から時間単位へと短縮されました。エンジニアは、ファイルや関数で考えるのを減らし、アーキテクチャ、制約、実行プランで考えるようになりました。
しかし、一度エンジニアリングの処理能力がボトルネックでなくなると、私たちはあることに気づきました。決定のスピードがボトルネックになっていたのです。私たちがエンジニアリング時間を守るために作ってきた調整メカニズム（仕様書、チケット、引き継ぎ、バックログの手入れ）は、今やシステム全体の中で最も遅い部分になっていました。存在しなくなった制約に対して最適化していたのです。
「作る」が「調整する」より安いと何が起きるか
私たちは別の問いを投げ始めました。意図に最も近い人たちが、ソフトウェアを直接出荷できるなら、どんな姿になるだろうか？
PMはすでに仕様の形で考えています。デザイナーはすでに構造、レイアウト、挙動を定義しています。彼らはシンタックス（構文）のことでは考えていません。成果（アウトカム）のことを考えています。意図を動くソフトウェアへ変換するコストが十分に下がると、これらの役割は「コードを学ぶ」必要がなくなりました。実装コストは単に、彼らのレベルまで落ちたのです。
私たちのPMの1人、ドミトリーに、彼の視点で何が変わったのか説明してもらいました。彼はこう言いました。「Zenflowでエージェントがタスクを生成している間、数分のアイドル時間がある。完全に何もない時間です。待っている間にやり取りできる、小さなゲームを作りたかったんです。」
プロダクトチームを運営したことがあるなら、こういう発想は分かるはずです。KPIは動かしません。優先順位付けの会議で正当化するのは不可能です。いつまでも先送りされます。けれども個性は生まれます。プロダクトが、細かな部分に誰かが気を配ってくれた感じがするのです。こうしたことは、バックログの手入れ（グルーミング）をするあらゆるセッションから最適化によって削り取られてしまうものですが、それとまさに同じことをユーザーは覚えているのです。
彼はそれを1日で作りました。
過去なら、この発想は優先順位付けのスプレッドシートで死んでいたでしょう。悪いからではなく、実装コストがそれを追うことを非合理にしていたからです。そのコストがゼロに近づくと、計算方法はまったく変わります。
説明するより出荷する方が安くなった
より多くの人が直接作り始めるにつれ、プロセスの何層もの部分が静かに消えていきました。チケットが減る。引き継ぎが減る。「…の意図は何だと言っているのか説明してもらえる？」という会話が減る。翻訳の迷子になってしまう瞬間も減る。
意味のあるタスクのカテゴリにおいては、やりたいことを説明して、それを誰かに作ってもらって待つより、ただ作ってしまったほうが速くなりました。少し考えてみてください。あらゆる現代のソフトウェア組織は、「実装こそが高コストだ」という前提に基づいて構造化されています。その前提が崩れたとき、組織はそれに合わせて変わらなければなりません。
私たちのデザイナーがプラグインのUIを直したのは、その完璧な例です。昔のワークフロー（問題をスクリーンショットで撮る→チケットを起票する→意図と実装のギャップを説明する→スプリント枠を待つ→結果をレビューする→調整を依頼する）は、エンジニアの稼働（バンド幅）を守るために存在していました。デザインの直感を持つ人がそれを直接実行できるなら、その積み上げは丸ごと消えます。私たちがプロセスをそれ自体のために削ったわけではありません。そのプロセスが解こうとしていた問題が、もはや存在していなかったからです。
増幅する効果
私がいちばん驚いたのは、これが「増幅」することです。
PMが自分のアイデアを自ら作ると、仕様がより鋭くなります。なぜなら、エージェントがうまく実行するために何が必要かを、今度は自分が理解するようになるからです。より鋭い仕様は、より良いエージェントの出力を生みます。より良い出力は、より少ない反復サイクルにつながります。私たちは、モデルが改善したからだけでなく、それを使う人たちが実作業により近づいたから、週ごとに速度が積み上がっていくのを見ています。
ドミトリーがうまく言っていました。意図と成果の間のフィードバックループが、週単位から分単位になったと。仕様の結果をすぐに見られるなら、システムが必要とする精度を理解でき、そして本能的にそれを提供し始めるのです。
測りにくいものの、見逃せない二次的な効果もあります。オーナーシップです。人は待つのをやめます。自分で直せることに対してチケットを出すのもやめます。「ビルダー」という職種名は仕事の肩書きではなくなりました。デフォルトの振る舞いになったのです。
これが業界にもたらす意味
昨年の「誰もがコードを書ける」という物語の多くは、理論上のものでした。また、個人創業者や小さなチームに焦点が当たっていました。私たちの経験はそれとは違います。私たちは複雑なブラウンフィールドのコードベースで約50人のエンジニアが働いています。複数の画面（サーフェス）とプログラミング言語、エンタープライズ統合、本物の本番システムが持つ全重量です。
私たちが特別だとは思いません。私たちは早いだけだと思います。そしてモデルの世代が新しくなるごとに、「作れる人」と「作れない人」のギャップは、多くの組織が考えているよりも速いスピードで縮まっていきます。あらゆるソフトウェア会社が、「PMやデザイナーが、実現されていないビルディング（構築）の能力を抱えている。スキルではなく、実装コストによってブロックされているだけだ」と気づくことになるでしょう。実装コストが下がり続けるほど、組織的な含意は深くなります。
私たちはソフトウェア工学を加速させたいという意図から始めました。私たちが目指しているのは別の姿です。誰もが出荷する会社。
Andrew FilevはZencoderの創業者兼CEOです。
