AIエージェントが目標を自走する「ソフトウェアファクトリーパターン」を試す
Trying the Software Factory Pattern
AIエージェントが広い目標に向かって自走する「ソフトウェアファクトリーパターン」を試した。Linearプロジェクトを読み込み、目標定義を監査し、メトリクスと課題をレビューし、非ブロックのタスクを実行するスキルを実装。ローカルで動かしているが、リリース後のチェックにも有効で、Datadog MCPやSnowflake、Linear、オーケストレーションされたハーネスなど、他の要素が揃って初めて機能する点が興味深い。
私が特に気に入っているのは、ファクトリーパターンが私のローカルでの働き方と非常に似ている一方で、プロジェクトの目標に関して私が誤って状態の一部を自分に囲い込んでいた場所を認識させてくれることだ。
HNでの議論
45- hibikir
Willは、採用するものをかなり自分でコントロールできる、比較的機敏な組織でこれに苦労している。効率的に仕事を進めることが、devリードやラインマネジメントのお墨付きを得てプロセスを迂回することを意味するような、もっと硬直化した企業環境では、これがどれほど楽しいか想像してほしい。個人間のパフォーマンスの差はかつてないほど広がっている。それは生産性の向上だけでなく、判断が怪しい人たちがはるかに速くトラブルを引き起こすことによるパフォーマンスの損失でもある。
組織に変化を起こす筋力が欠けていて、稼働時間を良好な状態に保つことを確実にしようとする権限を持つ人が誰もいないときに、品質を維持するのは難しい。多くのものが壊れる。まさにWillが見ているのと同じくらいの変化があるからだが、それは非常に不均等に分布している。
- alexpotato
それで、私は似たようなことをやることにした：
- issue用のGitHubプロジェクトボードを作成
- Grokを上記に接続
- Grokの音声モードを使ってアイデアを取り込み、Grokと一緒に洗練させてからissueとして保存
- OpenCodeで/ni（新規issue）、/do（issueを実行）、/curr（現在のissueは何か）、/done（説明不要）などのスラッシュコマンドを作成
- 普段はOpenCodeインスタンスに/do <番号>と指示すると、あとは勝手に進む
これにはいくつか利点がある：
- 歩いたり運転したりしながらGrok Voiceを使ってアイデアを練ってテストできる
- ローカルのOpenCode環境を全部失っても、関連データはissueに残っている
- 複数のマシンがGitHubから読み取れる
- さらに進んで、自分のボットごとに別のユーザーアカウントを持たせることもできる
PM、開発者、SRE、マネージャーを経験してきたが、これは本当に開発者のチームをマネジメントしている感覚だ。
- richardbarosky
こうしたことを公の場で書き、自分をさらけ出すのはとてもありがたい。脱帽ものだ！
しかし、追求されている内容に関しては、新しいソフトウェア開発アプローチのエンドツーエンドの価値を強く疑問視したり、その即時の適合性を吟味したりすることなく、ただ熱狂のサイクルに乗ろうとしているように見える。
個人的には、数人か小さめのチームを選んで、もっと孤立した／スカンクワークス的な実験を行い、その人たちが報告／経験したことに基づいて正当化されるものを採用する方が賢明だと思う。小さなグループはより速く調整でき、良いアプローチ／技術／戦略について大きな開発組織に助言しつつ反復でき、十分に考え抜かれていないものによる広範な損害／混乱を避けられる。
コードレビューへの追加、重要度の低いPR要約の作成、セキュリティチェックの強化といった、より保守的なAIのユースケースについては、よりグローバルでありながらも脱線しないアプローチが、より広く推進するのが理にかなう種類のものだろう。
- bsilvereagle
エージェント型ソフトウェア開発フローを採用していないと声高に主張している競合から、市場シェアを実際に奪った人はいるのだろうか？この記事は、機能開発や収益にどう影響しているかという明確な一貫した筋道がないまま、多くのプロセスの混乱を概説している。
- bicx
私のチームはエージェント型オーケストレーターの段階にいる。このソフトウェアファクトリーパターンは概念としては気に入っているが、開発における最大の課題はUI関連の受け入れテストだ。特にモバイルアプリのテストは依然として人間を必要とする大きなボトルネックだ。AIモデルは、特にアプリのある時点のスナップショットしか通常処理しないため、使いにくさやジャンクを特定するのが本当に苦手だ。
ジッターやフレーム落ちをある程度検出できる従来のテストフレームワークがあることは知っている。エージェントにそれを組み込ませることもできるかもしれない。
すべてのプロジェクトに具体的な設計と仕様があればそれも助かるが、動きの速いスタートアップでは、それはビルダーに委任される。そのたびに人間がループに戻ってくることになる。
ソフトウェアファクトリーパターンを完全に採用するために、他の人がどうしているのかぜひ聞いてみたい。