AI開発においてルールベースの自動化が失敗する理由
多くの開発者は、自動化を「トリガー、プロセス、出力」と定義しています。これはcronジョブやデプロイスクリプトには有効です。しかし、AIを使ってソフトウェアを記述する場合、この定義は通用しません。
AIは固定された一連の手順に従うわけではありません。アーキテクチャや依存関係について判断を下します。この変化により、単純な自動化から「管理された実行（managed execution）」への移行が必要になります。
単純な自動化の問題点
単純な自動化は、予測可能なタスクには有効です。ボイラープレートの作成やリンターの実行などは得意分野です。これらのタスクは経路が明確で、出力も既知のものです。
問題は、タスクにコンテキスト（文脈）が必要になったときに発生します。新しい機能が既存のサービスとどのように相互作用するかを知る必要があります。スキーマの変更が何かを壊さないかを確認しなければなりません。
当面のタスクだけに集中するツールは、しばしば失敗します。それらは一見正しく見えるものの、アーキテクチャを破壊するコードを生成します。そのコードには、特定のシステムに対する認識が欠けているのです。
ワークフローにおけるギャップ
ほとんどの企業は、すでに簡単なタスクを自動化しています。業界のデータによると、ワークフローの30%から40%はすでに自動化されています。
残された作業には判断が必要です。これこそがソフトウェアエンジニアリングの難しい部分です。ルールベースの自動化はコンテキストを欠いているため、この領域ではコストが高くなってしまいます。
管理された実行が提供するもの
管理された実行は、システムの仕組みを変えます。それは以下の3つの段階に焦点を当てています。
• 実行の前に「計画」を行う。システムは要件とアーキテクチャに基づいた計画を作成します。コードが書かれる前に、ユーザーはこの計画をレビューします。 • 速度よりも「可視性」。現在のツールは、作業プロセスを示すことを優先しています。後で推測するのではなく、ビルドの背後にある論理を確認できます。 • 制御されたワークフロー。システムはステートマシンとタスク委譲を使用し、エージェントのアクションを検査可能な状態に保ちます。
正しいツールの選び方
そのツールが時間を節約できるかどうかを問うてはいけません。ほぼすべてのツールは時間を節約できます。問うべきは、タスクの範囲（スコープ）です。
限定的でリスクの低いタスクには、単純な自動化を使用してください。高速でオーバーヘッドも少ないです。
複雑なビルドには、管理された実行を使用してください。アーキテクチャ上の決定が重要な意味を持つ場合に適しています。
目標は自動化を置き換えることではありません。作業のリスクに合わせてツールを選択することなのです。