# AI's Best Engineering Teams Are Its Smallest
**作者**: Mark Ajzenstadt
**日期**: 2026-07-21T08:54:56.000Z
**来源**: [https://x.com/mardehaym/status/2079490298393006370](https://x.com/mardehaym/status/2079490298393006370)
---
A delivery orchestration platform that supplies FedEx estimated 7 to 8 months to rebuild their core invoicing system. We put two FDEs on it and delivered in 3.5 months, with 122 merged pull requests in the first 90 days.
They needed a brownfield migration of a financial-grade invoicing platform that was buckling under scale: cost calculations, dispute workflows, approval chains, financial reporting. A decimal error in this system means someone loses real money.
The client's CTO has 100+ engineers across multiple teams. He called our 2-engineer pod the top performing team inside his organization.
Monthly AI compute cost per engineer: $200.
I've run a 180-person engineering company for over a decade, across 174 client engagements. A year ago I would have told you two FDEs couldn't handle a system this complex in production.
I mean, this engagement rewired how I think about team composition.
## Same tools, different output
Cursor and Claude are available to anyone with a credit card. The dev shops competing for this work had access to the same LLMs, the same IDE integrations, the same agentic frameworks we used. Those teams see a 10-15% productivity bump. Better autocomplete, some boilerplate generation. Fine for greenfield work.
Our 2-engineer pod replaced a full cross-functional squad on brownfield financial infrastructure. The reason is structural.
AI code generation scales per engineer. Each engineer working with an agent produces output that used to require a full cross-functional team. But coordination costs scale with headcount squared. A 2-engineer pod has one communication channel. A 10-person team has 25. On a brownfield financial system where PRs touch shared business logic, those 25 channels multiply the chances that someone misunderstands the architecture. And at AI generation speed, misarchitected code compounds faster than a large team can catch it.
The other advantage is context depth. Two engineers who hold the full system in their heads make better decisions about what to accept and reject from the AI than 10 engineers who each see one module. When the agent suggests a change that conflicts with a business rule three services away, they catch it because they built the knowledge graph themselves.
Our engineers generated 90% of the code with AI and reviewed it before anything merged. Three process decisions made that possible, and all of them happen before or after the AI generates a line of code.
## Step 0: grounding the AI before development starts
Step Zero
Before an engineer opens the IDE, the team scans the repo, builds a knowledge graph of the existing architecture, generates AI documentation, and creates a prompt library specific to that codebase.
On this engagement, that meant mapping a legacy Knack-based invoicing system with its data models, integration points, and business rules accumulated over years. Before writing a single feature, the AI could answer contextual questions grounded in actual architecture rather than training data.
The companies I've worked with that skip this step (and about 9 out of 10 do) hand an engineer Cursor, tell them to go faster, and call it an AI strategy. The AI produces useful output in proportion to the context you feed it, and building that context at the system level before development starts is what separated this team's results from the 10-15% bump you see elsewhere.
## Six checkpoints per feature
Our 6-step workflow
After Step 0, features run through a delivery sequence: define and clarify requirements, write a technical specification, generate an AI implementation plan, build with AI generation and human review, test and iterate, finalize and document.
FDEs don't move forward until the specification is tight enough to produce useful code. The typical AI workflow generates against vague requirements and then the team spends days debugging. We front-load the specification work, which means the generation step produces something close to shippable.
Reviewers flagged fewer than 5 comments on 104 of the 122 merged PRs, because the specifications going in were tight enough that the AI-generated code barely needed correction.
## The V.U.E. Gate
The V.U.E. quality gate
Before anything merges, the FDE has to pass three checks: can you verify the code works, can you understand and explain what it does, and can you debug it without the AI agent?
The AI-augmented teams I've watched fail skip this step. Their engineers merge code they can't explain, and when production breaks, they have no diagnostic capability. They prompt the agent again and hope for better output.
Our FDEs use AI to generate 90% of the code and carry 100% of the accountability for what ships.
## The numbers behind the engagement
The estimate was 7-8 months with a traditional team. Our 2-engineer pod shipped it in 3.5, with 50% faster delivery cycles across the engagement.
The contract has been running for over a year, month-to-month, with no lock-in and no discovery fees.
The client gave our engineers discretionary performance bonuses twice during the engagement. I've been doing this for 10 years across 170+ engagements, and I can count on one hand the number of times a client has bonused an outsourced team. This CTO did it twice for the same pod.
At $400/month in AI compute and $15K/month per pod, you can calculate the unit economics yourself.
## 170+ engagements later
We've built this system across 170+ client engagements and 10+ years of delivering software for mid-market companies. That's what our Velocity Framework was built for.
If you want to see what a 2-engineer velocity pod looks like on your codebase, book a discovery call: https://meetings-na2.hubspot.com/paul-bracht
P. S. If a call right away is too much pressure, feel free to fill out the form and we'll get back to you as soon as we can: https://limestonedigital.com/contact
## 相关链接
- [Mark Ajzenstadt](https://x.com/mardehaym)
- [@mardehaym](https://x.com/mardehaym)
- [21K](https://x.com/mardehaym/status/2079490298393006370/analytics)
- [https://limestonedigital.com/contact](https://limestonedigital.com/contact)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [4:54 PM · Jul 21, 2026](https://x.com/mardehaym/status/2079490298393006370)
- [21.1K Views](https://x.com/mardehaym/status/2079490298393006370/analytics)
- [View quotes](https://x.com/mardehaym/status/2079490298393006370/quotes)
---
*导出时间: 2026/7/22 09:52:07*
---
## 中文翻译
# AI 最优秀的工程团队往往规模最小
**作者**: Mark Ajzenstadt
**日期**: 2026-07-21T08:54:56.000Z
**来源**: [https://x.com/mardehaym/status/2079490298393006370](https://x.com/mardehaym/status/2079490298393006370)
---
一个为联邦快递提供支持交付编排平台的公司估计，重建他们的核心发票系统需要 7 到 8 个月。我们派了两名 FDE（全栈开发工程师）去负责，结果在 3.5 个月内交付，前 90 天就合并了 122 个拉取请求（PR）。
他们需要迁移一个金融级的发票平台，这是一个在规模压力下摇摇欲坠的遗留系统：涉及成本计算、争议处理工作流、审批链、财务报告等。这个系统中的一个小数点错误都意味着真金白银的损失。
客户的 CTO 手下有 100 多名工程师，分布在多个团队中。他称我们的 2 人小组是他组织中表现最顶尖的团队。
每位工程师每月的 AI 算力成本：200 美元。
我经营一家拥有 180 名员工的公司超过十年，经手了 174 个客户项目。如果是一年前，我会告诉你两名 FDE 根本无法处理生产环境中如此复杂的系统。
我是说，这次项目彻底改变了我对团队配置的思考方式。
## 工具相同，产出迥异
只要有信用卡，任何人都可以使用 Cursor 和 Claude。竞争这项工作的开发工作室也能获得相同的 LLM、相同的 IDE 集成以及我们使用的相同的智能体框架。那些团队的生产力提升了 10-15%。更好的自动补全，一些样板代码生成。这对于全新项目来说还不错。
我们的 2 人小组取代了负责遗留金融基础设施的完整跨职能团队。原因在于结构性。
AI 代码生成是按工程师规模扩展的。每位与智能体协作的工程师产出的成果，过去都需要一个完整的跨职能团队来完成。但协调成本是随人数平方级增长的。一个 2 人小组只有 1 个沟通渠道。一个 10 人的团队有 25 个。在遗留金融系统中，当 PR 触及共享业务逻辑时，这 25 个渠道成倍增加了有人误解架构的可能性。而且以 AI 生成的速度，架构糟糕的代码积累之快，会让大团队根本来不及发现。
另一个优势是上下文的深度。两名能在大脑中掌握整个系统的工程师，比 10 名各自只看一个模块的工程师，能更好地决定从 AI 生成的代码中接受什么、拒绝什么。当智能体建议的更改与三个服务之外的业务规则冲突时，他们能发现这一点，因为是他们自己构建了知识图谱。
我们的工程师 90% 的代码由 AI 生成，并且在合并前进行了审查。三个流程决策使这成为可能，而且所有这些决策都发生在 AI 生成一行代码之前或之后。
## 步骤 0：在开发开始前为 AI 注入上下文
步骤零
在工程师打开 IDE 之前，团队会扫描代码库，构建现有架构的知识图谱，生成 AI 文档，并创建针对该代码库的提示词库。
在这个项目中，这意味着映射一个基于 Knack 的遗留发票系统，包括其数据模型、集成点和多年积累的业务规则。在编写单个功能之前，AI 就能回答基于实际架构而非训练数据的上下文问题。
我合作过的公司中有跳过这一步的（大约 9 成都是），他们给工程师配备 Cursor，告诉他们加快速度，并称之为 AI 战略。AI 产生的有用输出与你输入的上下文成正比，在开发开始前在系统层面构建这种上下文，正是这个团队的成果与别处看到的 10-15% 提升拉开差距的原因。
## 每个功能六个检查点
我们的 6 步工作流
在步骤 0 之后，功能会经历一个交付序列：定义并厘清需求、编写技术规范、生成 AI 实施计划、通过 AI 生成和人工审查进行构建、测试和迭代、最终确定和文档化。
FDE 不会推进，直到规范足够严密以产生有用的代码。典型的 AI 工作流是基于模糊的需求生成代码，然后团队花费数天时间调试。我们将规范工作前置，这意味着生成步骤产生的代码接近可交付状态。
在 122 个合并的 PR 中，有 104 个的审查者评论少于 5 条，因为输入的规范足够严密，AI 生成的代码几乎不需要修正。
## V.U.E.关卡
V.U.E. 质量关卡
在合并任何内容之前，FDE 必须通过三项检查：你能否验证代码有效，你能否理解并解释它的作用，以及你能否在没有 AI 智能体的情况下调试它？
我见过失败的 AI 增强团队都跳过了这一步。他们的工程师合并了他们无法解释的代码，当生产环境出现故障时，他们没有诊断能力。他们再次提示智能体，希望能得到更好的输出。
我们的 FDE 使用 AI 生成 90% 的代码，并对交付的内容承担 100% 的责任。
## 项目背后的数据
使用传统团队的预估时间是 7-8 个月。我们的 2 人小组在 3.5 个月内交付，整个项目的交付周期加快了 50%。
合同已经运行了一年多，按月续签，没有锁定期，没有发现费。
客户在项目期间两次向我们的工程师发放了自由裁量绩效奖金。我从事这一行 10 年，经手 170 多个项目，一只手都能数得出来客户给外包团队发奖金的次数。这位 CTO 给同一个小组发了两次。
按每月 400 美元的 AI 算力和每个小组每月 1.5 万美元的成本，你可以自己计算单位经济效益。
## 170 多个项目之后
我们在 170 多个客户项目和 10 年为中型公司交付软件的过程中构建了这个系统。这也是我们构建 Velocity Framework 的初衷。
如果你想在你的代码库上看看 2 人 Velocity 小组是什么样子，请预约一次发现电话：https://meetings-na2.hubspot.com/paul-bracht
P. S. 如果立即通话压力太大，请随意填写表格，我们会尽快回复你：https://limestonedigital.com/contact
## 相关链接
- [Mark Ajzenstadt](https://x.com/mardehaym)
- [@mardehaym](https://x.com/mardehaym)
- [21K](https://x.com/mardehaym/status/2079490298393006370/analytics)
- [https://limestonedigital.com/contact](https://limestonedigital.com/contact)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [4:54 PM · Jul 21, 2026](https://x.com/mardehaym/status/2079490298393006370)
- [21.1K Views](https://x.com/mardehaym/status/2079490298393006370/analytics)
- [View quotes](https://x.com/mardehaym/status/2079490298393006370/quotes)
---
*导出时间: 2026/7/22 09:52:07*