エルヴィス・サントス(Elves Santos)は8月27日、dev.toに寄稿し、AIはソフトウェアの納品を大幅に速めた一方、保守コストはほぼ変わっていないと述べた。ブラジルの開発者であるサントスは今年、ある機能を午前中だけで出荷したという。内容は、数式分析のCRUD、マイグレーション、4つの新ルート、949行の画面、208行のハードコードされた計算戦略を50行の数式評価器呼び出しに置き換える作業だった。フロントエンドのPRは午前11時17分、バックエンドのPRは午前11時32分に作成された。

2週間後、サントスによると3つの新しい分析タイプが現れ、汎用エンジンが14日前に不要にしたはずの3つのハードコード戦略を、サーバー側のマップへ戻すことになった。27日後には、数式が欠けている場合に`throw new Error(JSON.stringify({...}))`が発生し、HTTPハンドラーが例外メッセージからJSONを解析せざるを得ない問題で再び同じ箇所に戻った。修正にはコード35行とテスト175行が必要で、サントスはこれを、本来は最初の午前中の納品時に考慮すべきだったケースに対して、本番コードの5倍のテストコードを書いた例だと位置づけた。

5カ月後、サントスによれば、そのファイルは268行になり、`// Keep for backwards compatibility with tests`という自身のコメントも残っていた。16項目のマップは本番コードでは読まれなくなっていたが、14件のテストアサーションはなおそれに依存していた。テストファイルは351行まで増え、テスト対象のサービスより大きくなった。サントスは、節約できた午前中には、同じファイルへ3回戻るコストが含まれていなかったと述べた。

サントスは、AIが下げたのはコード作成のコストであり、ソフトウェアを理解可能に保つコストではないと主張した。ボイラープレート、DTO、マイグレーション、慣れたCRUD作業、モジュールのひな型、未知のライブラリ習得は安くなったが、コードはなお読まれ、デバッグされ、金曜日に急いで変更され、先月入ったチームメートに説明されなければならない。開発者が「3倍生産的」だと感じるとき、測っているのは、もともと工程の中で最も速かった部分だけかもしれないと警告した。

サントスが提案した実践的なテストは、午前3時にAI生成コードをチャットを開き直さずデバッグできるかどうかだ。答えがノーなら、その作業は終わっていないという。200行を読むには約10分かかる一方、読んでいない200行をデバッグするには1日かかることがあるとも述べた。サントスの見方では、AIは最小の解ではなく完全な解を返しがちで、依頼が関数1つだけでも、抽象化、任意パラメーター、インターフェース、フレームワークを追加することがある。

サントスは、ボトルネックがレビューと価格設定へ移ったと述べた。書く速度は上がったが、レビューは同じ人間の頭脳と同じ24時間に依存し、いまは40ファイルのPRに向き合う。AIは単純なレビュー上の問題を見つける助けにはなるが、レビューにはチーム内の少なくとも2人がそのコードの存在を知るための役割もある。スコープ単位で請求する請負開発者にとって、以前は2日と見積もられた作業が2時間で期待される一方、後の保守は未払いのまま残る。サントスの例では、請求できたのは午前中の作業分で、3回のフォローアップ訪問は自分の時間で支払った。

サントスは現在、AIに直接コードを求めるのではなく、問題を説明している。すでに存在するもの、制約、とりわけ望まないものを指定する。一般化せず課題を解く最小版を明示的に求め、PR説明は自分で書き、大きすぎるPRは分割し、ネットワークエラー、不正なペイロード、古い顧客データといった痛みの大きい失敗ケースにテストを集中させる。コードを書く時間の見積もりをやめ、1カ月安定していなければならない期間を含め、解決された問題を見積もるようになったという。

サントスは、AIがエンジニアリング作業をなくしたのではなく、その機械的な部分の多くを取り除いたのだと結論づけた。残る仕事は、システムを理解し、意図的にトレードオフを選び、本番環境のコードを維持することだ。納品速度はデイリーミーティングで示しやすいが、保守コストは後になって姿を現すまで見えにくいと述べた。

エルヴィス・サントス(Elves Santos)は8月27日、dev.toに寄稿し、AIはソフトウェアの納品を大幅に速めた一方、保守コストはほぼ変わっていないと述べた。ブラジルの開発者であるサントスは今年、ある機能を午前中だけで出荷したという。内容は、数式分析のCRUD、マイグレーション、4つの新ルート、949行の画面、208行のハードコードされた計算戦略を50行の数式評価器呼び出しに置き換える作業だった。フロントエンドのPRは午前11時17分、バックエンドのPRは午前11時32分に作成された。

2週間後、サントスによると3つの新しい分析タイプが現れ、汎用エンジンが14日前に不要にしたはずの3つのハードコード戦略を、サーバー側のマップへ戻すことになった。27日後には、数式が欠けている場合に`throw new Error(JSON.stringify({...}))`が発生し、HTTPハンドラーが例外メッセージからJSONを解析せざるを得ない問題で再び同じ箇所に戻った。修正にはコード35行とテスト175行が必要で、サントスはこれを、本来は最初の午前中の納品時に考慮すべきだったケースに対して、本番コードの5倍のテストコードを書いた例だと位置づけた。

5カ月後、サントスによれば、そのファイルは268行になり、`// Keep for backwards compatibility with tests`という自身のコメントも残っていた。16項目のマップは本番コードでは読まれなくなっていたが、14件のテストアサーションはなおそれに依存していた。テストファイルは351行まで増え、テスト対象のサービスより大きくなった。サントスは、節約できた午前中には、同じファイルへ3回戻るコストが含まれていなかったと述べた。

サントスは、AIが下げたのはコード作成のコストであり、ソフトウェアを理解可能に保つコストではないと主張した。ボイラープレート、DTO、マイグレーション、慣れたCRUD作業、モジュールのひな型、未知のライブラリ習得は安くなったが、コードはなお読まれ、デバッグされ、金曜日に急いで変更され、先月入ったチームメートに説明されなければならない。開発者が「3倍生産的」だと感じるとき、測っているのは、もともと工程の中で最も速かった部分だけかもしれないと警告した。

サントスが提案した実践的なテストは、午前3時にAI生成コードをチャットを開き直さずデバッグできるかどうかだ。答えがノーなら、その作業は終わっていないという。200行を読むには約10分かかる一方、読んでいない200行をデバッグするには1日かかることがあるとも述べた。サントスの見方では、AIは最小の解ではなく完全な解を返しがちで、依頼が関数1つだけでも、抽象化、任意パラメーター、インターフェース、フレームワークを追加することがある。

サントスは、ボトルネックがレビューと価格設定へ移ったと述べた。書く速度は上がったが、レビューは同じ人間の頭脳と同じ24時間に依存し、いまは40ファイルのPRに向き合う。AIは単純なレビュー上の問題を見つける助けにはなるが、レビューにはチーム内の少なくとも2人がそのコードの存在を知るための役割もある。スコープ単位で請求する請負開発者にとって、以前は2日と見積もられた作業が2時間で期待される一方、後の保守は未払いのまま残る。サントスの例では、請求できたのは午前中の作業分で、3回のフォローアップ訪問は自分の時間で支払った。

サントスは現在、AIに直接コードを求めるのではなく、問題を説明している。すでに存在するもの、制約、とりわけ望まないものを指定する。一般化せず課題を解く最小版を明示的に求め、PR説明は自分で書き、大きすぎるPRは分割し、ネットワークエラー、不正なペイロード、古い顧客データといった痛みの大きい失敗ケースにテストを集中させる。コードを書く時間の見積もりをやめ、1カ月安定していなければならない期間を含め、解決された問題を見積もるようになったという。

サントスは、AIがエンジニアリング作業をなくしたのではなく、その機械的な部分の多くを取り除いたのだと結論づけた。残る仕事は、システムを理解し、意図的にトレードオフを選び、本番環境のコードを維持することだ。納品速度はデイリーミーティングで示しやすいが、保守コストは後になって姿を現すまで見えにくいと述べた。