QCon London 2026: AIエージェントがコードを書く時代、人間に残された役割は？
本文の状態
日本語全文を表示中
詳細モードで約9分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
InfoQ
ハンナ・フォックスウェル氏がQCon London 2026で、AIエージェントによるコーディングが開発速度を向上させたが、その活用方法と人間の役割について議論した。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
ハンナ・フォックスウェルは、QCon London 2026 の講演を始めるにあたり、長年待ち望まれていた開発における速度が実現したものの、業界はその使い方に確信を持てでいないと指摘しました。彼女はアジェンティックコーディングの技術的な詳細には立ち入らず、むしろこれらのシステムと共に働く人々への影響について語ることに焦点を当てました。
これは AI に関する講演ですが、私はエージェントそのものについては一切語りません。彼らが到来し、すでにここにあることを提案し、業界で起こっているこの巨大な変化に適応するために、私たち人間やチームとして何を行うべきかについてお話しします。
AI for the Rest of Us および BIMP.ai の創設者であるフォックスウェルは、メインフレームチームで年 2 回のリリースから、大規模な継続的デリバリーへと至るまでの、自身のキャリアを速度の波が次々と押し寄せる過程として振り返ることから講演を始めました。彼女はアジェンティックコーディングの到来が別のステップ変化であると示唆しましたが、それは既存の圧力を単に拡張するものではなく、組織にとって新たな圧力をもたらすものであると指摘しました。彼女はスティーブ・イェグの 8 つの開発者進化モデルを簡潔に紹介し、ガス・タウン（Yegge のエージェントオーケストレーションフレームワークで、同モデルのステージ 7 と 8 で動作するもの）が「私たち全員にとっての未来がどのようなものであるかを示すわずかな兆候」であると述べました。
Foxwell氏は、LLM支援コーディングにおいてすでに転換点に達しており、Cursor などのツールにおいてエージェントによるリクエストがタブ補完型コーディングを上回り、主要なインタラクションの形態となっていると述べました。これは、エージェントの能力と信頼性が急速に向上したため、非常に短期間で起こった出来事です。
エージェンティック AI の台場という背景を設けた上で、他の QCon 講演で信頼性の高いエージェンティック・エンジニアリングプラクティスの現状が説明された後、Foxwell氏はこの未来のビジョンを、それらが関与する人間にとって何を意味するかという観点に grounding（基盤付け）することで、自身の講演を構成しました。彼女は、エージェントの能力がどのように向上しても変わらないと信じる3つのアンカー（基軸）を紹介しました。
- 構築する価値のあるものを構築しなければならない
- 速度には安全性が必要である
- 人々が重要である
最初のアンカーは、チームは構築する価値のあるものを構築しなければならないという点です。エージェンティック・コーディングは製品機能に対してバックプレッシャー（後押し圧力）をもたらします：開発者は、プロダクトマネージャーがパイプラインを埋めるために十分な質の作業を提供できる速度よりも速く機能を生成しており、Foxwell氏は自身のキャリアの中で初めて、開発チームがバックログを使い果たす様子を目撃していると述べました。彼女は、すべての要求に「はい」と答えないよう助言しました。
「エンシティフィケーション（Enshittification）という現象があります」と彼女は指摘し、プラットフォームが多様な機能で肥大化し、結果として誰も十分に満足させられなくなる状況を指しています。彼女は、アイデアを検証するコストが劇的に低下したことで、AI ツールを用いて正式な製品バックログに組み込む前にプロトタイプを作成する「バイブコーディング PM」と呼ばれる新しいタイプの製品マネージャーが登場し、より実験的な製品文化が実現可能になったと説明しました。チーム構造については、前方展開エンジニアや製品エンジニアを活用することで、実際のユーザーとのフィードバックループを短縮できると提案しています。また、2 ピザ・チームの規範にも異議を唱え、ノルウェー銀行投資管理（NBIM）ではより小規模なチーム比率の実験を行っており、一方で別の提案では、エージェント群を指揮する開発者 1 名に対して製品マネージャー 2 名を配置するという逆の構成も示されています。
フォックスウェルの二つ目のアンカーは、「速度には安全性が伴わなければならない」という点です。彼女は、組織がアジェンティック・コーディングを通じてスループットを 10 倍に向上させた AWS の事例を引き合いに出しました。ただし、これはテスト、デプロイメント、調整の慣行を根本から再考した後の結果でした。「彼らは単に AI の速度を既存のプロセスに付け足しただけでは成功しません」と彼女は述べています。「生産までの経路そのものを再設計する必要があったのです」。また、時間的プレッシャー下にある開発者が見落としがちなエッジケースも検出できるため、「疲れず、飽きない」JPMorgan Chase のアジェンティック・テストフレームワーク（agentic testing framework）にも言及しています。
Foxwell は SRE のプラクティス、特にエラーバジェットポリシーにも再び言及しました。これは信頼性目標を達成できなかった場合にチームが何を行うかについてユーザーに対する書面でのコミットメントとして説明されました。彼女は以前、開発チームから孤立した状態の SRE 機能をアンチパターンと考えていましたが、納品速度が非常に速い中でチームの信頼性を維持するための内部コンサルティング機能として、再び脚光を浴びる時期が来ていると示唆しました。
彼女の三つ目の基軸は「人が重要である」という点です。大量の AI 生成コードを検証することは正直言って楽しくないものだと彼女は述べました。Joseph Ruscio の「書き込み専用コード（write-only code）」という概念を指摘し、これはエージェントによって生成されたコードの多くが人間に読まれることがないかもしれないと主張するものです。これが常態化した場合、ピアレビューのプロセスは左側へシフトしなければならないと彼女は論じました。事後のプルリクエストレビューではなく、エンジニアはコードが書かれる前に仕様、テスト戦略、アーキテクチャをレビューすべきだと提唱しました。
スキルに関する質問に対して、Foxwell は QCon London 2025 でシニアエンジニアの Sophie Weston が導入した「壊れた櫛（broken comb）」というアイデアに立ち返りました。T字型の開発者が一つの深い専門性を持つ一方で、壊れた櫛型のエンジニアは複数の深みのある領域を備えた広範な知識基盤を育成します。Foxwell はこれがエージェントと共に働くのに最も適したエンジニアの姿であると論じ、マネージャーに対してこれをチーム開発のためのフレームワークとして活用するよう促しました。
彼女は個人的な事例研究で締めくくりました。2 人のチームで、Cursor のエージェントモードを使用して 2 週間で BIMP（ベースイメージ管理プラットフォーム）を構築しました。チームは昼食前に毎日の目標を繰り返し達成し尽くす状態になり、過酷な優先順位付けの習慣を捨てなければなりませんでした。ドキュメントは数分で生成され、コードベースのリファクタリングも数時間で完了しました。「AI のスピードで製品を構築する経験は非常に示唆に富んでいました」と Foxwell 氏は語り、「将来自分が何を作りうるかについて、以前よりもはるかに野心的になりました」と付け加えました。
Foxwell 氏は過度に指示的になることを避けるよう注意を払いました。彼女は、ほとんどの組織がまだ自律型エージェントの群れに対応できる段階にはない点を指摘しました。しかし、エンジニアたちに対して、エージェントツール自体と、それらが最終的に要求する組織変革の両方について、今すぐ実験を始めるよう促しました。「私たち全員が、将来における自分の役割に自信を持てるようになってほしい」と彼女は言いました。「私たちは、このエージェントの世界の中で自分たちの居場所があると感じられるべきだと考えています。」
著者紹介
マット・サンダース
私はアダプタビストの VP DevOps です。複雑な企業、小さなスタートアップ、中小企業、そしてその間のあらゆる組織と協力し、DevOps、プラットフォームエンジニアリング、クラウドネイティブなツールや技術を活用して、ストレスを最小限に抑えつつ、迅速かつ効率的に信頼性の高い高品質なソフトウェアを提供できるようチームをサポートしています。
また、ロンドン DevOps ミートアップグループの共同主催者でもあり、10,000 名以上のメンバーを抱える非常に人気のある月次業界イベントを開催しています。
原文を表示
Hannah Foxwell began her QCon London 2026 talk by noting that the long-sought velocity in development has arrived, but the industry is unsure how to use it. She set aside the technical details of agentic coding, focusing instead on its implications for the people working with these systems.
This is a talk about AI, but I'm not going to talk about the agents at all. I'm going to propose that they are coming, that they are here, and I'm going to talk about the humans and what we do as teams to adjust to this massive change that is happening in our industry
Foxwell, the founder of AI for the Rest of Us and BIMP.ai, opened by tracing her own career through successive waves of velocity, from shipping twice a year on a mainframe team to continuous delivery at scale. She suggested that the arrival of agentic coding is another step change, but one that creates novel organisational pressures rather than simply extending existing ones. She briefly described Steve Yegge's eight-stage developer evolution model, and suggested that Gas Town (Yegge's agent orchestration framework, which operates at stage 7 and 8 of the model) is "a little glimmer of what the future might look like for all of us".
Foxwell stated that there's already been an inflection point in LLM-supported coding, with agent requests now overtaking tab-completion coding as the dominant form of interaction, in tools such as Cursor, and this has happened very quickly as the capability and reliability of agents has increased so rapidly.
Having set the scene of the rise of agentic AI, with other QCon talks explaining the state of the art for reliable agentic engineering practices, Foxwell structured her talk around grounding this vision of the future in what these advances mean for the humans involved. She introduced three anchors she believes will remain true regardless of how capable agents become.
We must build something worth building
Speed requires safety
People matter
The first anchor is that teams must build something worth building. Agentic coding introduces back pressure on product functions: developers are now producing features faster than product managers can supply well-qualified work to fill the pipeline, and Foxwell said she is now seeing development teams run out of backlog for the first time in her career. She advised not saying "yes" to everything.
"Enshittification is a thing," she noted, referring to the phenomenon of platforms becoming bloated with features that collectively serve nobody well. She explained that the cost to test ideas has collapsed, making a more experimental product culture much more viable with a new breed of "vibe-coding PMs" who prototype ideas with AI tools before committing them to a formal product backlog. Looking at team structure, she suggested that using forward-deployed engineers and product engineers helps shorten feedback loops with real users. She also challenged the two-pizza team norm: Norges Bank Investment Management (NBIM) is experimenting with much smaller team ratios, while others have proposed the opposite, placing two product managers alongside a single developer who orchestrates a fleet of agents.
Foxwell's second anchor is that speed requires safety. She drew on an AWS case study describing how the organisation achieved 10x throughput through agentic coding, only after completely rethinking its testing, deployment and coordination practices. "They couldn't just bolt on the speed of AI to what they were doing," she said. "They had to re-engineer that path to production." She also cited JPMorgan Chase's agentic testing framework that "never gets tired or bored," which catches edge cases that developers under time pressure might miss.
Foxwell also returned to SRE practices, specifically the error budget policy, which she described as a written commitment to users about what a team will do when reliability targets are missed. She suggested that the SRE function, which she had previously considered an anti-pattern when siloed from development teams, may be due for a comeback as an internal consultancy helping teams maintain reliability when delivery is so much faster.
Her third anchor was that people matter. Reviewing large volumes of AI-generated code, she said frankly, is not fun. She pointed to Joseph Ruscio's "write-only code" concept, which posits that much of the code produced by agents may never be read by humans. If that becomes the norm, she argued, the peer review process must shift left: rather than reviewing pull requests after the fact, engineers should review specifications, test strategies and architecture before any code is written.
On the question of skills, Foxwell returned to an idea introduced at QCon London 2025 by principal engineer Sophie Weston: the "broken comb." Where a T-shaped developer has one deep specialism, a broken-comb engineer cultivates a broad base of knowledge with several areas of depth. Foxwell argued this is the shape of an engineer best suited to working alongside agents, and she encouraged managers to use it as a framework for team development.
She closed with a personal case study. In a team of two, she built BIMP, a base image management platform, over two weeks using Cursor in agentic mode. The team repeatedly exhausted their daily goals before lunchtime and had to unlearn the habit of ruthless prioritisation. Documentation was generated in minutes and a codebase refactor took hours. "The experience of building a product at the speed of AI has been incredibly insightful," Foxwell said, "and it did make me way, way, way more ambitious about what I might build in the future."
Foxwell was careful to avoid being too prescriptive. Most organisations, she noted, are not yet ready for fleets of autonomous agents. But she encouraged engineers to start experimenting now, both with agentic tools and with the organisational changes those tools will eventually demand. "I want us all to feel confident about the roles we have in the future," she said. "I want us to feel like we have a place in this world of agents."
About the Author
Matt Saunders
I am VP DevOps at Adaptavist. I help teams use DevOps, platform engineering and cloud-native tools and technologies to deliver reliable quality software quickly and efficiently and with minimal stress. I've worked with complex enterprises, small start-ups, SMEs and everything in between.
I also co-organise the London DevOps meetup group, which has over 10,000 members, hosting a hugely popular monthly industry event.
Show moreShow less
関連記事
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み