# Pragmatic Leverage in the Software Factory
**作者**: dex
**日期**: 2026-07-29T16:57:28.000Z
**来源**: [https://x.com/dexhorthy/status/2082510831858893115](https://x.com/dexhorthy/status/2082510831858893115)
---

This one is a bit of an addendum / side-quest to the recent series. It didn't fit cleanly into the main post so I'm publishing it standalone. It is referenced briefly in Why Software Factories Fail part 2: Turning the lights back on.
## Seeking Leverage
Even before AI, only 25-50% of the time to ship a feature was writing the code itself. The rest was aligning/planning, code-review/rework, and testing/verifying the solution.

If you're only using AI to write the code, then you're taking the 2-4 hours of coding time down to 10-20 minutes, but you haven't accelerated anything else here.

But if you use AI to help you plan and align, then you actually get closer to 2-3x faster.

## The 80/20 rule in AI coding leverage
Lets assume if you yolo a two-sentence prompt into your factory, your chance of getting a fully-mergeable result is ~50%, the chance you have to rework it is 50%.

Now lets say you are a principal engineer with 10 years of experience. You have the whole codebase across 100 repos downloaded into your head. So you spend an afternoon writing a perfectly detailed spec by hand. Now your odds are better, but you probably still have about a 10% chance that you'll have to redo *something* significant.

And at the far end: write every line yourself. Nothing's left for the agent to get wrong, so the rework chance goes to zero.

**note** For this example I'm gonna blur
> "chance you'll have to change something" weighted by "how painful the change will be"
into a single percentage number but obviously they're two separate variables. If the model is 50% likely to get a button style wrong, but the fix is one cheap prompt, then our combined "expected pain" is low.
> expected pain = P(you'll have to change it) × how painful the change is
If you draw this out, there's an inverse relationship between effort invested up front and expected pain.

What you don't want to do is spend 6 hours planning a task for which you could have eliminated 80% of the expected pain in the first 10 minutes.
You need to do this without overindexing on questions you won't be able to answer without going down a level. For example, if you've done some work at the "Product" level and have not answered all the open questions yet, its possible you may need to end it where you are and zoom down a level to the technical details to understand what's feasible. There's no perfect process for this.
This is what we mean by leverage - and it requires being pragmatic. If you're doing multiple phases of planning, zooming in from 50kft view all the way to the 10kft view, you want to do a little bit of steering at each phase to ensure you are eliminating as much expected pain as possible.
good luck.
## 相关链接
- [dex](https://x.com/dexhorthy)
- [@dexhorthy](https://x.com/dexhorthy)
- [63K](https://x.com/dexhorthy/status/2082510831858893115/analytics)
- [Why Software Factories Fail](https://x.com/dexhorthy/status/2080697380379427275)
- [Turning the lights back on](https://x.com/dexhorthy/status/2081058573556306030)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [12:57 AM · Jul 30, 2026](https://x.com/dexhorthy/status/2082510831858893115)
- [63.1K Views](https://x.com/dexhorthy/status/2082510831858893115/analytics)
- [View quotes](https://x.com/dexhorthy/status/2082510831858893115/quotes)
---
*导出时间: 2026/7/30 10:07:30*
---
## 中文翻译
# 软件工厂中的实用杠杆
**作者**: dex
**日期**: 2026-07-29T16:57:28.000Z
**来源**: [https://x.com/dexhorthy/status/2082510831858893115](https://x.com/dexhorthy/status/2082510831858893115)
---

这一篇是近期系列文章的一个补充/支线任务。因为它不太适合放入正文中,所以我将其单独发表。在《软件工厂为何失败(第二部分):重新开灯》一文中曾简要提及它。
## 寻求杠杆
即使在 AI 出现之前,交付一个功能所需的时间中,只有 25-50% 是真正用于编写代码的。其余时间则用于对齐/规划、代码审查/返工,以及测试/验证解决方案。

如果你仅仅使用 AI 来编写代码,那么你确实将 2-4 小时的编码时间缩短到了 10-20 分钟,但这并没有加速除此之外的其他任何环节。

但是,如果你利用 AI 来帮助你进行规划和对齐,那么你实际上会获得快 2-3 倍的效果。

## AI 编码杠杆中的 80/20 法则
我们假设,如果你向工厂随手输入一个两句话的提示词,你得到一个完全可合并结果的概率约为 50%,而你需要返工的概率也是 50%。

现在,假设你是一位拥有 10 年经验的资深工程师。整个跨越 100 个代码仓库的代码库都已经在你的脑海中。因此,你花了一个下午手动编写了一份完美的详细规范。现在你的几率提高了,但你可能仍然有大约 10% 的几率需要重做*某些*重要的东西。

而在另一个极端:每一行代码都由你自己编写。没有任何留给代理出错的空间,因此返工的几率降为零。

**注** 在这个例子中,我将
> “你需要修改某些内容的几率”与“修改过程有多痛苦”
这两个维度合并成了一个百分比数值,但显然它们是两个独立的变量。如果模型有 50% 的可能性把按钮样式搞错,但修复方法只是输入一条廉价的提示词,那么我们综合的“预期痛苦”就很低。
> 预期痛苦 = P(你需要修改它) × 修改它的痛苦程度
如果你把这一点画出来,就会发现前期投入的精力与预期痛苦之间存在反比关系。

你绝对不想花费 6 个小时去规划一个任务,而实际上你本可以在前 10 分钟内就消除 80% 的预期痛苦。
你需要做到这一点,同时又不能在那些如果不深入细节就无法回答的问题上投入过多。例如,如果你在“产品”层级做了一些工作,但还没有回答所有未解决的问题,那么你可能需要停在那里,深入一层到技术细节去了解什么是可行的。这没有完美的流程。
这就是我们所说的杠杆——它需要务实。如果你要进行多个阶段的规划,从 5 万英尺的视野一直放大到 1 万英尺的视野,你希望在每个阶段都进行一点微调,以确保你尽可能多地消除预期痛苦。
祝好运。
## 相关链接
- [dex](https://x.com/dexhorthy)
- [@dexhorthy](https://x.com/dexhorthy)
- [63K](https://x.com/dexhorthy/status/2082510831858893115/analytics)
- [Why Software Factories Fail](https://x.com/dexhorthy/status/2080697380379427275)
- [Turning the lights back on](https://x.com/dexhorthy/status/2081058573556306030)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [12:57 AM · Jul 30, 2026](https://x.com/dexhorthy/status/2082510831858893115)
- [63.1K Views](https://x.com/dexhorthy/status/2082510831858893115/analytics)
- [View quotes](https://x.com/dexhorthy/status/2082510831858893115/quotes)
---
*导出时间: 2026/7/30 10:07:30*