AI Made Coding Faster. It Didn't Make Teams Work Better Together.
Generative AI has sharply cut the time engineers spend on individual tasks — but the coordination overhead at the team level has not come down with it. That is the central observation in a recent O'Reilly Radar commentary. The author describes a personal experiment called ContextCue, and is explicit that the work grows out of practical experience gained during an internship. Readers should treat it as a starting point for a question, not as a finding they can cite.
The friction moved upward
According to the author's own account, the idea grew out of something repeatedly visible during an internship: engineers around them were applying AI across nearly every stage of the development pipeline — GitHub Copilot and Claude models drafting specs, generating code, reviewing code, and writing tests. The same team also maintained a reusable library of agent "skills" to teach coding agents what a codebase looks like: how modules are organised, what the naming conventions are, what existing patterns look like.
The catch is elsewhere. Those skills libraries are, in effect, a form of documentation compression — but most of them only capture what the code looks like, not why it was written that way. As individual output speeds up, the decisions that still require human confirmation pile up even higher. The author calls this friction shifted upward: the bottleneck has moved from getting features written to confirming they were written correctly.
What this means for hybrid teams (editorial extension)
The original author does not draw region-specific conclusions. The discussion below is an editorial extension based on their argument, and readers comparing it with the source should keep that distinction in mind.
Hybrid development teams common in Hong Kong and the Greater Bay Area often span languages and time zones, which means the tacit background knowledge between members is already thinner than in co-located teams. Applying the author's observation to that setting: if a team's collaborative documentation leans mainly on agent skills, and those skills describe the current state of the code rather than the reasoning behind it, the costs of onboarding new members, running cross-team reviews, and retracing decisions become even harder to see. This is an editorial inference, not an empirical finding from the original article or from the ContextCue experiment.
The practical takeaway is not to slow AI adoption, but to stop assuming that faster code generation means collaboration problems are solved. Teams that want traceability alongside their agents may need to maintain decision logs, codified review practices, and shared context documents across groups — not just keep expanding their skills libraries.
One final caveat: ContextCue is a personal experiment by a single author, and neither its methodology nor its data has been published. Any reference to it here stays at the level of practitioner opinion. If the author later releases the methods and data, this caveat can be lifted and the strength of the article's conclusions reassessed accordingly.
AI 讓寫程式變快了，團隊協作的摩擦卻往上移
生成式 AI 大幅壓縮了工程師個人任務的耗時，但團隊層面的協作開銷並沒有同步下降——這是 O'Reilly Radar 一篇評論文章提出的核心觀察。作者在文中分享了一項名為 ContextCue 的個人實驗，並強調這是源自實習期間的實務觀察，讀者宜把它視為提出問題的切入點，而非可直接引用的定論。
摩擦往上移了
據作者自述，這個想法源自實習期間反覆看到的現象：身邊的工程師把 AI 用在軟件開發流程的幾乎每個環節——GitHub Copilot 與 Claude 模型協助撰寫規格、產生程式碼、進行程式碼審查與撰寫測試。同一團隊也維護了一套可重複使用的 agent「skills」庫，用來教 coding agent 認識程式碼庫的樣貌：模組如何組織、命名慣例為何、既有寫法長怎樣。
問題出在別處。這類 skills 庫本質上是一種文件壓縮，但它們多半只記錄了「程式碼看起來如何」，卻幾乎沒有沉澱「當初為什麼這樣決定」。當個人產出速度加快，需要人工確認的決策反而堆得更高；作者將此形容為摩擦向上轉移（friction shifted upward）：瓶頸從「把功能寫出來」移到「確認這樣寫對不對」。
對混合開發團隊的啟示（編輯部延伸）
原作者並未針對特定地區發表結論，以下為本文編輯部依其論點所作的延伸討論，請讀者對照原文時留意區分。
香港以及粵港澳大灣區常見的混合開發團隊，往往跨語言、跨時區運作，成員之間的隱性背景知識本來就比同辦公室團隊稀薄。把這個情境套回原作者的觀察：若團隊的協作文件主要依賴 agent skills，而 skills 又只描述「程式碼現狀」而非「決策脈絡」，新人接手、跨組審查、決策回溯的成本只會更難被看見。這是編輯部的推論，並非原文或 ContextCue 實驗的實證結果。
實務上的提醒，不是放慢採用 AI，而是別假設「程式碼生成變快」等同於「協作問題已被解決」。團隊若要在導入 agent 的同時維持可追溯性，可能需要額外整理決策紀錄（decision log）、審查慣例，以及跨組共享的上下文文件，而不只是持續擴充 skills 庫。
最後仍須一併留意：ContextCue 是單一作者的個人實驗，其方法與具體數據尚未公開，本文對它的引用只能停留在「實務觀點」的層級。若日後作者補上實驗方法與數據，這段保留相應可以解除，全篇結論的強度也應跟著重新評估。