AI コード修正を止め、システムエージェントが必要とする基盤構築へ
本文の状態
日本語全文を表示中
詳細モードで約8分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
The New Stack AI
Patrick Debois氏は、AIがコード生成を担う時代において、開発者は個々のコード修正ではなくシステム全体の改善に注力し、文脈開発ライフサイクルへ移行すべきだと提言している。
AI深層分析を開く2026年8月4日 02:01
AI深層分析
キーポイント
文脈開発ライフサイクルへの転換
AIの活用により従来のソフトウェア開発ライフサイクルが「文脈開発ライフサイクル」へと進化し、CI/CDフィードバックループから生成・評価・配布・観測を含む同心円状のループへ変化している。
コード修正からシステム改善へのマインドセット
エージェントが期待通りに動作しない際、開発者はプロンプトやコードを微調整するのではなく、エージェントを支援するための基盤となるシステム自体を改善する姿勢へ転換すべきである。
組織規模での文脈駆動型への移行
個人やチームレベルの努力だけでなく、DevOpsと同様に組織全体でスケーラブルな文脈駆動型の文化を確立することが必要であり、コードベースや仕様、アーキテクチャ決定記録など多様なコンテキストを管理する必要がある。
システム最適化の視点転換
個人のノートパソコン向けではなく、チームワークフローやプラットフォームレベルでの最適化が重要である。AI ツールは技術だけでなく、個人から共有へ、そして共同での文脈構築へと人々の行動変容を促すものである。
ウォーターフォールではない反復的な文脈工学
文脈はルール変更時などに一度きりで与えるものではなく、継続的な改善プロセスとして扱う必要がある。文脈が反復的でなければ、エンジニアはプロンプトの言い換えやコード修正という旧来の習慣に戻ってしまう。
重要な引用
"the software development lifecycle becomes the context development lifecycle."
"if the agent didn't do what you want, stop correcting the code. Improve the system, not the prompt."
"I'll help my agent do it better."
"The fundamental change is the system, not the prompt."
編集コメントを表示
編集コメント
この記事は、AIツールが普及した後の開発現場の在り方について本質的な問いを投げかけている。Patrick Debois氏の提言は、単なるツールの使い方の変更を超え、組織文化の変革を促す重要な示唆を含んでいる。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
ソフトウェアエンジニアがもはやコードを書かなくなった今、彼らは何をしているのか。その疑問は数百万人の頭をよぎっている。
AI ツールはすでに開発者に広く利用されているが、レイオフへの不安は依然として残っている。一方でコーディングはソフトウェアエンジニアリングの一部に過ぎない。これはエンジニアがビジネスや、自社の組織・業界における自身の役割の目的という文脈により深く関わる機会を生む。
「平行して考えてみましょう。2009 年当時、私は『もし運用（Ops）が開発（Dev）のようにもっと近ければ』と考えたものです」と語ったのは、Tessl の技術スタッフメンバーであり、DevOps という用語の考案者、そして DevOpsDays グローバルイベントシリーズの創設者であるパトリック・デボイス氏だ。
彼の発言は今年初夏にロンドンで開催された PlatformCon でなされたもので、AI がタスクのために使用する「文脈（コンテキスト）」と呼ばれる特定の知識が人間のコードを置き換えるにつれて、「ソフトウェア開発ライフサイクルは文脈開発ライフサイクルへと変化する」と聴衆に語った。
このライフサイクルは、単一の CI/CD フィードバックループから、生成、テスト駆動開発による評価、パッケージとしての文脈の配布、そして観測を巡る一連の同心円状のループへと成長した。この成長を促しているのは、個人の開発者、チーム、そして組織全体が持つ考え方の転換である。これはプラットフォームエンジニアリングチームにとって全く新しい機会を開くものとなる。
「開発者が抱くべきマインドセットの変化として私が提唱するのは、エージェントが望む通りに動かない場合、コードを修正するのをやめることです。プロンプトではなくシステム自体を改善すべきです」と、Debois氏はThe New Stackに語っています。「この転換は、『私とエージェントが一緒にやる』という発想から、『私のエージェントがより良く動くよう支援する』という姿勢への移行を意味します。」
Debois氏はこれを、決定論的かつ確定的なシステムやワークフローから、非決定論的で確率的なシステム・ワークフローへの不可欠な転換と捉えています。これは技術そのものの変化だけでなく、私たちの働き方にも多大な変化を伴うものです。しかし、これは個人のエンジニアやチームレベルだけで完結するものではありません。DevOpsと同様に、組織全体でスケールして初めて実現できる変革です。
文脈駆動型組織への移行方法
まるでスイッチを入れたかのように、すべての企業が一夜にして「AIファースト」になったように感じるかもしれません。しかし現実は、DevOpsやマイクロサービス、クラウド移行の前例が示す通り、AIもまた着実かつ継続的な変容を遂げながら、予測可能な未来へと進んでいます。では、エンジニアリング組織はどのようにして正しい文脈駆動型の道筋を進むことができるのでしょうか。
チームレベルにおいてDebois氏が推奨する問いかけは、「エージェントが機能するためには、どの程度の情報接触が必要か」という点です。異なるチームの異なるエンジニアが、以下のような多様なコンテキスト情報を提供します：
- コードベース
- 仕様書
- 事後分析レポート（ポストモルテム）
- ドキュメントやSlack上のメッセージ
- 意思決定記録（ADR）
- コードサンプル
- ユースケース
- コンプライアンスガイドライン
コンテキスト、ひいてはエージェントをスケールさせるためには、個人やチームが生成しているエージェントとその出力内容を把握しておく必要があります。
「A の最適化に注力する一方で、我々は B を最適化しています。チーム全体にとって最適な文脈を提供できるよう努めましょう」とデボワ氏は説明します。「例えば、個人のラップトップ向けにシステムを最適化するのではなく、チームのワークフローに合わせて最適化することはできないでしょうか？さらに、プラットフォームレベルや複数のチーム間でも同様のことが可能になるのでしょうか？」
「これは意図的に探すものではなく、自然に広がるものです」とデボワ氏は『ザ・ニュー・スタック』に語ります。「速度が向上する兆しが見えても、重要なのは文脈の共有です。例えば、『ああ、この情報は Slack にあるな』と気づくだけでなく、『リポジトリ内にあり、再利用できる』という形になれば理想的です」。これは技術界隈でよく見られるパターンです。単なる熱心な個人から、情熱的なチームへ、そして複数のチームへと広がり、最終的にはプラットフォームに組み込まれていくのです。
ツール主導の変化と同様に、AI もテクノロジーそのものだけでなく、人々とプロセスに深く関わるものです。しかしデボワ氏は、これらのツールが行動変容の可能性を開くのだと主張します。
「根本的な変化はプロンプトではなくシステムにあります」と彼は続けます。「そして、個人での作業から共有へと、さらにチームで文脈構築に取り組む方向へと協力のあり方を変えていくべきです」
文脈エンジニアリングは、エンジニアリングの活用へと進化していく
組織の中には、コンテキストはアジェンシーシステムに一度だけ、あるいはルール変更時に年に数回しか入力しないと考えるところもありますが、デボワ氏は警告します。これはウォーターフォール型ではなく、反復的なプロセスとして設計されているはずです。もしそうではない場合、エンジニアたちはプロンプトの言い換えやコードそのものの修正といった悪い習慣に戻ってしまいます。従来のフィードバックループに頼りきっていると、AI エージェント群は投資対効果（ROI）を達成できません。
「業界では『AI に問題があれば、より多くの AI を使えばいい』という物語が流布しています」とデボワ氏は PlatformCon の聴衆に語ります。彼は、ある大規模言語モデル（LLM）や AI エージェントがコードを生成する例を挙げました。「その LLM に評価させると、ほぼユニットテストのように呼び出されます。しかし実際にはコードを実行しているわけではなく、ただコードを見ているだけです」。
API エンドポイントの強制や、他のバイナリ品質ゲートの維持などにおいて一定の価値はあるかもしれません。しかしデボワ氏は、それだけでは不十分だと指摘します。むしろ、必要なものをコンテキスト内で明確に指定することが、エージェントがどのようにコードを実行し評価するかを決定づけるのです。
しかし、それで終わらせてはいけません。彼が主張するアジェンシー AI の成熟度の次の段階は、ハーン（harness）とループに基づいたものだとされています。
ハーンエンジニアリングとは、LLM を取り囲むインフラストラクチャ、ガードレール、およびツールを構築し、信頼性の高い自律型エージェントの開発を支えることに焦点を当てています。
Debois 氏は、エージェントの内部ハネスを「クエリ API の背後にあるログ、メトリクス、トレース」と定義します。これによりコーディングエージェントは結果を確認し改善できるようになります。生成、評価、配布、観測という生きたループにすべてがフィードバックされる仕組みです。
このパターンにより、エージェントは「常に人間が指示しなくても、何かがおかしいことを自律的に把握できる」と Debois 氏は説明します。なぜなら、失敗した箇所や改善された部分を認識するセンサーを備えているからです。エンジニアがハードコーディングを行っている場合でも、これらの壁をさらに改善するために戻ることができます。
ハネスは単一の開発者やチームのために孤立して構築されるべきではありません。
「彼らは世界全体のハネスを構築しているのです。つまり、テストの方法や検証のプロセス、そして現在各チームに散在する知識のコンセンサスがここに集約されます」と Debois 氏は語ります。「人々は同じパイプラインの上に構築し始めるでしょう。」
現実には、多くの組織が複数のパイプラインを抱えることになります。しかし、これらのループは各組織のフィードバックループの次の進化形となります。つまり、AI の協調を目的としたシステムを構築することは、より良い組織間の協力につながります。
この投稿「Stop correcting AI code. Build the system agents need.」は The New Stack に掲載されました。
原文を表示
If software engineers are no longer writing code, what are they doing? That’s the question on millions of minds.
AI tools are now widely used by developers, but fear of layoffs remains a concern. On the other hand, coding is only one part of software engineering. This creates an opportunity for engineers to get closer to the business and to the context of their role’s purpose within their organization and industry.
“I like to think in parallels. In 2009, I was like, what if Ops was more like Dev?” wondered Patrick Debois, a member of technical staff at Tessl, coiner of the term DevOps, and founder of the DevOpsDays global event series.
His comments came during PlatformCon London earlier this summer, where he told the audience that as context — the specified knowledge AI uses for tasks — replaces human code, “the software development lifecycle becomes the context development lifecycle.”
This lifecycle has grown from a single CI/CD feedback loop to a series of concentric loops around generating, evaluating via test-driven development, distributing context as a package, and observation. This growth is being spurred by a shift in how individual developers, teams, and whole organizations think. And it opens a whole new opportunity for platform engineering teams.
“The mindset change for a developer that I would advocate is that if the agent didn’t do what you want, stop correcting the code. Improve the system, not the prompt,” Debois tells The New Stack. “That kind of shift is from ‘I’ll do it together with my agent,’ over to ‘I’ll help my agent do it better’.”
Debois sees this as a necessary shift from deterministic to non-deterministic and probabilistic systems and workflows. And it’s one that involves as many changes to the way we work as to the technology itself. But it can’t be just done by an individual engineer or at the team level. Like DevOps, it is a change that can only be realized at scale.
How to become a context-driven organization
It may have felt like we flipped a switch and every company was — wham! — “AI-first.” In reality, just like DevOps, microservices, and cloud transformations before it, AI is making a continuous transition into the foreseeable future. So how does your engineering organization get onto the right context-driven path?
At the team level, Debois says, a good question to ask is how many touches does one need for agents to work? Different engineers across different teams will feed in different points of context, including:
Codebase
Specifications
Post-mortems
Documentation Slack messages
Architectural decision records
Code samples
Use cases
Compliance guidelines
For context and therefore agents to scale, you need to know what agents individuals and teams are producing and their outputs.
“When you’re optimizing for A, and we’re optimizing for B, let’s make sure that the whole context that we give is optimized for the whole team,” Debois explains, including “If you are optimizing the system for your laptop, can we optimize it for the team workflow? And then you just scale up, like, can we do this on the platform level? Or across multiple teams?”
“It’s not something you seek out,” Debois tells The New Stack. “Maybe they can speed it up, but you would see the signs of ‘Oh, I have context, and you have context. Sure, it’s on Slack. What if this was in the repo and I can reuse this?” following the pattern in tech that has any trend spreading from a single enthusiast, to an enthusiastic team, to a couple of teams, and eventually being built into the platform.
Like all tool-driven changes, AI is as much about the people and processes as it is the tech. But, he argues, the tools open up possibilities for behavioral changes.
“The fundamental change is the system, not the prompt,” he continues. “And then look for collaboration directions from solo to sharing things, and now working on the [context building] as a team together.”
Context engineering evolves to harness engineering
Organizations may think that context is fed into your agentic systems just once, or a couple of times a year when rules change, but, Debois warned, it’s not meant to be Waterfall. It’s iterative. If the context isn’t, then engineers fall back into the bad habit of rephrasing prompts or just fixing the code itself. Relying solely on traditional feedback loops means your AI agent fleet will not return on its investment.
“There is the industry narrative that if there’s a problem with AI, we just use more AI,” Debois tells the PlatformCon audience. He gave the example of how one large language model (LLM) or AI agent generates some code. “We ask the LLM to assess this, and it will call almost like a unit test. It hasn’t run the code; it just looks at the code.”
There’s some value in that, perhaps in enforcing API endpoints or other binary quality gates, but, he says, it’s not enough. Instead, if you specify what you need within the context, then that drives how the agent runs and evaluates the code.
But it shouldn’t stop there. The next stage of agentic AI maturity, he contends, is grounded in harnesses and loops.
Harness engineering focuses on building the infrastructure, guardrails, and tools that wrap around an LLM to support the development of reliable, autonomous agents.
Debois defines an agent’s inner harness as logs, metrics, and traces behind query APIs, “so the coding agent sees the consequences and improves,” all of which feed into that living loop of generation, evaluation, distribution, and observation.
With this pattern, the agents “autonomically know that something is wrong without you having to tell them all the time,” he says, because “it has sensors in a way that knows what fails, what it improved, and then can go back to improving these walls,” even when engineers are hard-coding something.
Again, harnesses should not be built in isolation serving a single developer or team.
“They’re building a harness for the whole world, so imagine the consensus of this is how we do tests, and this is how we do verification, and all the knowledge that is currently in all these different teams,” Debois says. “People start building on that same pipeline.”
The reality is that most organizations end up with multiple pipelines, but these loops become the next evolution of each organization’s feedback loops. And thus, building for AI coordination leads to better organizational collaboration.
The post Stop correcting AI code. Build the system agents need. appeared first on The New Stack.
関連記事
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み