AI Predictions, August 2026

AI 预测：2026 年 8 月

For the past two months or so, I’ve been working on a variety of AI development projects rather than writing — writing skills, plugins, workflows, and applications; testing and refining harnesses; and performing diligence or working with clients (hands-on work as well as brains-on work) as they think through where they’re going with AI and how they’re getting there. I’ve been down a lot of rabbit holes and talked to a lot of forward-thinking practitioners, and I have explored a lot of what is actually possible now by building things…and I’ve spent my “think-time” on what that all might actually mean going forward. Here’s what I’ve come up with: 59 predictions in 17 categories around how the world of AI — and the broader world in light of AI — are changing.

在过去的两个月里，我一直忙于各种人工智能开发项目，而不是写作——包括编写技能、插件、工作流和应用程序；测试和优化框架；以及进行尽职调查或与客户合作（既有动手实践，也有深度思考），帮助他们理清 AI 的发展方向及实施路径。我钻研过许多深奥的技术细节，与许多具有前瞻性的从业者交流过，并通过亲手构建项目探索了目前真正可行的技术边界……我也花了很多“思考时间”去推演这一切对未来的意义。以下是我得出的结论：针对 AI 世界——以及在 AI 影响下更广阔的世界——将如何改变，我提出了 17 个类别下的 59 项预测。

Organizational Structure & Delivery Model

组织结构与交付模式

#1. Small Cross-Functional Pods Become the Standard for Software Development (2-4 years) #1. 小型跨职能小组将成为软件开发的标准（2-4 年）

The leading-edge/aspirational development team model will have moved from agile teams of 6-8 to AI-powered Pods of 2-3 (often product/development/deployment, sometimes SrDev/JrDev/Product). This prediction underpins many of the other predictions in this entire group — most of the rest of the Org Structure & Delivery Model cluster assumes it holds. It’s plausible for greenfield and startup work, but much shakier for regulated enterprises, where compliance, audit, and change-control requirements resist small-pod velocity regardless of what the AI itself can do. It’s also asserted here more confidently than prediction #2 (customer absorption is the real bottleneck) actually supports: if absorption genuinely gates release pace, the pressure to compress teams down to 2-3 people is weaker in customer-facing contexts than in internal/back-office work, where there’s no absorption brake. I’d expect the 2-3 person pod to show up first and most durably in internal tooling and greenfield products, and later (if at all, within this window) in regulated, customer-facing systems — see the Regulated Industries prediction near the end of this piece. 领先的/理想的开发团队模式将从 6-8 人的敏捷团队转变为 2-3 人的 AI 驱动小组（通常由产品/开发/部署人员组成，有时是高级开发/初级开发/产品经理）。这一预测支撑了本组中的许多其他预测——“组织结构与交付模式”集群中的大部分内容都建立在此假设之上。对于全新项目和初创公司来说，这很可行，但对于受监管的企业来说则要困难得多，因为无论 AI 本身能做什么，合规、审计和变更控制要求都会阻碍小型小组的速度。此外，这里的断言比预测 #3（客户吸收能力才是真正的瓶颈）更具信心：如果吸收能力确实限制了发布节奏，那么在面向客户的场景中，将团队压缩至 2-3 人的压力要小于内部/后台工作，因为后者没有吸收能力的制约。我预计 2-3 人小组将首先且最持久地出现在内部工具和全新产品中，随后（如果在此窗口期内能实现的话）才会出现在受监管的面向客户的系统中——请参阅本文末尾关于“受监管行业”的预测。

Confidence: Medium 置信度： 中等

Falsification: By 2029-2030, a majority of leading-edge dev orgs (surveyed via “State-of-the-Dev-Org”-style reports) still organize around 6-8 person teams rather than 2-3 person pods, OR pods exist but only in greenfield/startup contexts, not regulated enterprise. 证伪条件： 到 2029-2030 年，大多数领先的开发组织（通过“开发组织现状”类报告调查）仍然围绕 6-8 人的团队进行组织，而不是 2-3 人的小组；或者小组确实存在，但仅限于全新项目/初创公司环境，而非受监管的企业。

#2. No-Brakes Tech Debt and Defect Remediation Is the Order of the Day (next 12 months) #2. 毫无阻碍的技术债务和缺陷修复将成为当务之急（未来 12 个月）

As development teams are restructured into small pods (prediction #1), one of the first benefits seen will be working through tech debt and open issues (defects, bugs) lists. There is tremendous obvious benefit to addressing those as fast as possible — everybody wins. I performed a diligence a year ago where completely eliminating a sizable tech debt backlog was on the docket to be completed within the next 12-18 months (realistically, given their well-tracked internal metrics and progress to date at the time). 随着开发团队重组为小型小组（预测 #1），首要好处之一将是清理技术债务和待处理问题（缺陷、漏洞）列表。尽快解决这些问题有着巨大的显而易见的好处——这是一个双赢局面。一年前我曾进行过一项尽职调查，当时彻底消除大量技术债务积压已被列入议程，计划在未来 12-18 个月内完成（考虑到他们当时良好的内部指标跟踪和进度，这是现实的）。

Confidence: High 置信度： 高

Falsification: Backlog and tech-debt burn-down rate in pod-model orgs is statistically indistinguishable from pre-pod Agile-team burn-down rate. 证伪条件： 小组模式组织中的积压工作和技术债务清理速度，在统计学上与小组模式之前的敏捷团队清理速度没有区别。

#3. Customer Absorption Rate Will be the Real Limit On AI Throughput (2-4 years) #3. 客户吸收能力将成为 AI 吞吐量的真正限制（2-4 年）

Companies with the small pod model will NOT, however, burn through their new feature backlog at the same blazing speed as it will tech debt and issues backlogs (prediction #2) — it will be faster than the rate at which backlog elements are developed now, but customer absorption capacity will limit what’s possible for release rate. Customers can’t or won’t absorb changes as quickly as AI implementation allows. If you have ever been involved in an ERP replacement in any way, you’ve seen this first-hand…organizations have an absorption rate. Change management is still the hardest part of every project, gated by the customer’s capacity (a mixture of willingness and capability) to absorb change. Any customer-impacting work needs to be released in a measured way, with training, documentation, and time for absorption. With AI development, buy-in (or mandate) can now take more time than creation/deployment. Historically, we’ve all worked hard to deliver ever faster, to give our customers what they want. In software, at least, we’re at a point where it’s now possible to overshoot the mark and need to slow down. People like knowing where to find the features they use in the interface they already know, and they like getting the results they expect to get in the ways with which they’re already familiar. 然而，采用小型小组模式的公司，其新功能积压的消化速度将不会像技术债务和问题积压（预测 #2）那样快——虽然会比目前的开发速度快，但客户的吸收能力将限制发布速度。客户无法或不愿像 AI 实现速度那样快地吸收变更。如果你曾参与过任何 ERP 替换项目，你就会亲眼目睹这一点……组织是有吸收率的。变更管理仍然是每个项目中最困难的部分，受限于客户吸收变更的能力（意愿和能力的结合）。任何影响客户的工作都需要以有节制的方式发布，并辅以培训、文档和吸收时间。在 AI 开发中，获得认可（或强制执行）现在可能比创建/部署花费更多时间。从历史上看，我们都在努力交付得更快，以满足客户的需求。至少在软件领域，我们现在已经到了可能“用力过猛”而需要放慢脚步的阶段。人们喜欢在他们熟悉的界面中找到他们使用的功能，也喜欢以他们已经习惯的方式获得预期的结果。

Confidence: High 置信度： 高

Falsification: Customer-facing release cadence in a well-run pod org matches internal delivery speed within a quarter, and is maintained for the next year as release cadence increases, with no corresponding spike in support tickets, rollback rate, or training complaints. 证伪条件： 在一个运营良好的小组组织中，面向客户的发布节奏在一个季度内与内部交付速度保持一致，并在随后一年发布节奏增加时得以维持，且没有出现支持工单、回滚率或培训投诉的相应激增。

#4. Number of Direct Reports Will Grow a Lot (next 12 months), Then We’ll See How Bad That Is and Reduce to Slightly Above Where We Are Now (3-5 years) #4. 直接下属的数量将大幅增加（未来 12 个月），随后我们会意识到其弊端，并将其缩减至略高于目前水平（3-5 年）

I believe managers will NOT wind up managing lots more subteams than now, in the end. Managing MANY small pods is a model being proposed by some, and imo it’s a terrible idea for effective and sustainable management. We’ve been trying to ‘efficientize’ human orgs for a long time now, and the constraint on direct reports and how many of them one c… 我相信，最终管理者不会比现在管理更多的子团队。管理“许多”小型小组是一些人提出的模型，但在我看来，这对于有效和可持续的管理来说是一个糟糕的主意。我们长期以来一直试图让组织“高效化”，而对直接下属人数的限制以及一个人能……