# Why Software Factories Fail: Turning the lights back on
**作者**: dex
**日期**: 2026-07-25T16:46:42.000Z
**来源**: [https://x.com/dexhorthy/status/2081058573556306030](https://x.com/dexhorthy/status/2081058573556306030)
---
This is part two of Why Software Factories Fail
The talk version of this post is live on youtube: https://www.youtube.com/watch?v=Ib5GBkD555M
## Turning the lights back on
In part 1, I went deep on why models can't be trusted to maintain codebase quality over time. Why no amount of harness engineering or tokenmaxxing will solve a model-training and benchmarks problem. Why "model as judge" for code quality doesn't work as well as some folks want to tell you.
For now, the judge is you -- so we're gonna put the code review back.
We're gonna embrace that same thing we've been doing since before AI, which is to do a little bit of planning up front, to reduce the odds of a long and difficult review.
We're gonna find leverage, and we're gonna use AI to help with this, across 4 phases:
- Product Requirements
- System Architecture
- Program Design
- Vertical Slices
## Product review
Everything starts with a product review: a short doc that pins down what we're building and why. The goal is to be able to take two sentences or a long voice note ramble and turn it into something semi-structured.
First, we align on the problem to solve -- the actual user pain, in the user's terms. Second, what success looks like -- what can we read after shipping to decide the thing was worth building. Ideally this is a user outcome like "can do XYZ workflow in less time" or "reaches onboarding milestone ABC earlier". Sometimes it's lower level like an error rate or a latency number, sometimes just "the support tickets about X stop."
We try to keep this pretty grounded in the product space, not the technical. As someone who lives with one foot in the product world and one foot in the tech, I often find myself drifting into the technical details here. When that happens, I try to just jot it down for later phases and get back to what the user actually experiences. If tech decisions are blocking product decisions, then we commit what we have and get into the architecture or do more prototype research on what's feasible
And since most of this is about what the user sees, I don't describe it -- I mock it up. A rough HTML mockup of the actual screen settles an argument that three paragraphs would only prolong.
Here's a real one in progress -- the doc pins down the feature with a JSON outline, then two rough HTML mockups of the actual screens:
https://x.com/dexhorthy/status/2078592010852982977
Of course, not everything gets a product review. A copy tweak, a one-off script, a bug with an obvious repro -- we still just oneshot those straight to the agent. This is for the changes where an agent misunderstanding our intent is expensive.
For this and all docs in the series, we do author-opt-in reviews. If you wanna save time during review, you pick the person who would review the PR, and run through the product/tech specs with them, either async via doc comments (we dogfood humanlayer for this, but you can just as easily do this in github/notion/plannotator/etc).
## System architecture
Once the product review is settled, we do system architecture. This is not particularly novel and is something even vibe coders are starting to swear by.
## If you wanna save time during review, you pick the person who would review the PR, and run through the product/tech specs with them before you get to the coding part.
In this phase we align on how the services, endpoints, schemas, queues, and stores talk to each other, without getting into the details of program design. To maximize human<>agent communication bandwidth, we make heavy use of visualizations here - for example sequence diagrams:
Contract / endpoint shapes:
Data models and transformations:
Mermaid is fine here but it can sometimes be overkill and sometimes lure you into a false sense that you are aligned. Architecture is fairly high leverage and there's a lot of potentially-bad model tics that you can head off during this phase. But it is insufficient to produce high-quality code. For that we need program design.
## Program design
After architecture we do this thing that I think is criminally underemphasized in agentic coding: program design.
Most people assume that once the architecture is right, the model can just cook. You can go ahead and do this, but you might not like what you get back.
But what I see working well is that before anyone (human or agent) writes the implementation, we go a level down from architecture into the shape of code: the types, the method signatures, the program layout, and the call stacks.
The first version of our program design skill sucked. It was hard to read, it was exhausting. We tried mermaid, which has its place, but what we actually love are light visualizations in pseudocode:
Call-stack trees, for any orchestration or control-flow change. Use diff syntax when the interesting part is what's changing:
Dillon Mulroy talks about using call graphs as part of his planning process, and I think that's exactly right.
File-tree diffs - so you can stay in touch with the layout of your codebase and where stuff lives
Types and method signatures for the key new functions -- the stuff that's too internal for an architecture doc but that an agent might still get wrong
None of these take long to produce (the model drafts them, you argue with it), and every one of them is a decision you'd otherwise be making implicitly during code review -- at the most expensive possible time to change your mind.
## Vertical slices
Next we love doing what I call "vertical slices" - Matt Pocock and I had a
chat about vertical slices or "tracer bullets" on a live stream back in January 2026 - this is also referred to as - tracer bullets
Models love what I call "horizontal plans" - doing things in stack-order:
1. Database Migrations
2. Service Layer
3. API
4. Frontend
In practice, what this means is there's no real way to "touch" the solution as you're going. You can test things with code, but for almost any feature I've ever built, reading the tests was a start but pulling something up in a browser, or hitting it with curl while I was working was always a frequent part of the workflow.
Before AI, it was rare for anyone to write 2000+ lines of code or even 500 lines of code without checking something along the way.
It took me a while to notice the difference in what I was used to - when I wrote code before AI, I would always start in the middle and work outwards. Vaguely:
1. Create API contract and serve mock data, test with curl
2. Create frontend to consume mock data, iterate+polish in browser
3. Wire API to services layer (services serves mock data/behavior)
4. Add database migrations, wire services to database
5. Add a bunch of business logic
6. Add a bunch of error handling
And I'd be testing/iterating/polishing at each step.
If I care about the code a lot or skeptical about the model's ability to do good work in this part of the codebase, I'm reviewing the code at each step too. Checking 100-200 lines and resteering is a lot cheaper
here, I would.Most frontier models won't design a plan like this without human steering, and it's hard to generalize per codebase or even per task, so I prefer to stay in the loop here. Trust me. If I couldoutsource the thinking
30 minutes of planning saves hours of review
And so we have some steps that I would argue that humans need to be in the loop for, if you want to maintain a near-human level of quality without slaving over mountains of slop code trying to clean it up after the fact. (i.e. you actually wanna go fast)
1. Product Design
2. System Architecture
3. Program Design
4. Vertical Slices
Obviously we don't do this whole process for everything we ship (see the sidequest below). I would guess the distribution is roughly:
- ~40% of tasks get oneshot or oneshot w/ 1-2 rounds of light feedback
- for medium tasks, we do product/system design all in one plan document, and don't bother breaking the work into phases
- for large things, we do all the steps. we'll skip the product part for things where it doesn't make sense like big refactors.
And in most cases, I'll send off a model to do 1-3 slices at a time, and review the code as I go. It's a lot easier to resteer early on, whether it's the internals or the actual functionality, than to end up on the other side of 2k+ lines of code with no idea what's broken.
## You probably feel like you have too many pull requests
You don't have too many PRs. You have too many bad PRs.
We've all reviewed a lot of PRs that needed rework, since long before AI.
But a great PR is a joy to review. You're scrolling through every file, the code is clean, it follows all your decisions/discussions/hard-won opinions about how software should be.
On the other hand, if a Pull Request needs even 20% rework (and that's generous, I'd say most AI oneshot PRs trend closer to 50%), that's both an intellectual burden and an emotional burden on both the submitter and the reviewer. (Even if the submitter is an AI, someone probably kicked off this work or vibe polished the AI result or at the very least, cares about the outcome).
To spare you time (we're almost at the end), I rambled more about this in a side quest:
"where does the time go"
## a theory of constraints (2026 edition)
It's easy to be a little bummed by the core thesis here: "for now we're stuck reading the code".
I was pretty excited for a world where we could just ask for things and let the models cook and not read the code and get beautiful production software that evolves over time and doesn't go to shit.
But what I've done my best to lay out here are nothing but constraints. Models are good at some things, not so good at others. How do you optimize your process in light of those constraints?
Models are good at some things, not so good at others. How do you optimize your process in light of those constraints?
It is possible you are too busy trying to move 10-100x faster and trying to convince yourself code quality doesn't matter any more, when you could embrace the constraints and move 2-3x faster, safely.
My kind of closing advice here is basically:
1. Learn the constraints well, develop intuition by working with models a lot
2. Optimize systems within the arena of these constraints
3. Seek leverage
4. Read the dang code
That's it. If you wanna stay for the pitch, keep scrolling I guess. I hope this helps you avoid disaster or at least that you had fun watching some cute little animations.
Thanks for reading
-dex
## PS We're obsessed with this
We're building humanlayer.com, an agentic IDE and collaboration platform to help you move 2-3x faster while maintaining a human (or pretty-dang-close-to-human) level of code quality.
We're building towards two ideas: "building blocks for your software factory" and "better verifiers for software maintainability" (perhaps better models even).
HumanLayer is free for small teams of up to 3 people, and if you want help getting started, you can come hang in our discord or drop us a line at founders@humanlayer.dev
A quick shout out to @calvinfo for inspiration, to my cofounder @0xBlacklight, to @swyx and the team at @aiDotEngineer for giving me an arena to explore these ideas, and to all our incredible customers, investors, friends, and family cheering us on.
If you wanna learn more, I basically won't shut up about this, so you can find all the links from this post as well as a few other projections of the material into podcasts, long form whiteboard, etc, below.
## PPS Other resources
Podcasts and Articles:
- Dex and Gergely talk context engineering and software factories on The Pragmatic Engineer - July 2026
- Dex and Matt Pocock talk evergreen ai coding advice (and ralph loops) - January 2026
AI That Works Episodes:
- Benchmarks prove nothing
- Product Specs for AI Coding
- Learning Tests for better backpressure
- Applying 12-factor agents principles to AI coding
Links from this post:
- Why Software Factories Fail keynote — AI Engineer World's Fair 2026
- StrongDM's lights-off software factory
- OpenAI: Harness Engineering (Feb 2026)
- Ryan Lopopolo on Symphony (talk, Apr 2026)
- Mario at AI Engineer Europe: "Building pi in a world of slop"
- FT: Amazon outages from coding-agent mishaps
- Matt Pocock: codebases falling apart
- Faros AI: the AI acceleration whiplash report
- Advanced Context Engineering for Coding Agents (talk 8/25)
- No Vibes Allowed (talk 11/25)
- Everything We Got Wrong About RPI (talk 3/26)
- Awesome-RLVR - Reinforcement Learning resources
- Advanced Context Engineering for Coding Agents (write-up)
- 12-Factor Agents
- Addy Osmani on vibe-coding vs. maintenance
- NATO Software Engineering Conference, 1968
- DoD DevSecOps Reference Design (PDF)
- Ramp's coding-agent platform
- Stripe: Minions, one-shot end-to-end coding agents
- WorkOS: Project Horizon
- Brex (Latent Space)
- Dan Shapiro: the five levels to the software factory
- Simon Willison on StrongDM's software factory
- "Boil the ocean"
- Shotgun surgery (refactoring.guru)
- John Ousterhout — A Philosophy of Software Design
- Robert C. Martin — Clean Code
- Martin Fowler — Refactoring
- aider
- cline
- codebuff
- SWE-Agent paper (2024)
- OpenAI Codex talk (Nov)
- Calvin French-Owen — AI Council talk
- SWE-bench Multilingual (dataset)
- AIE Worlds Fair 2026 - The Great Loops Debate ("the hype is outrunning the discipline")
- SWE-Marathon (Abundant AI)
- DeepSWE (Datacurve)
- Frontier Code (Cognition)
- Mutation testing (Wikipedia)
- Dillon Mulroy on call graphs in planning
- Dex × Matt Pocock: vertical slices / tracer bullets (livestream, Jan 2026)
- "The hard work of thinking can't be outsourced" (Jake Nations)
## 相关链接
- [dex](https://x.com/dexhorthy)
- [@dexhorthy](https://x.com/dexhorthy)
- [52K](https://x.com/dexhorthy/status/2081058573556306030/analytics)
- [Why Software Factories Fail](https://x.com/dexhorthy/status/2080697380379427275)
- [https://www.youtube.com/watch?v=Ib5GBkD555M](https://www.youtube.com/watch?v=Ib5GBkD555M)
- [part 1](https://x.com/dexhorthy/status/2080697380379427275)
- [a little bit of planning up front](https://github.com/humanlayer/advanced-context-engineering-for-coding-agents/blob/main/wsff.md#front-loading-alignment)
- [prototype research on what's feasible](https://www.youtube.com/watch?v=Zx_GOhGik0o)
- [https://x.com/dexhorthy/status/2078592010852982977](https://x.com/dexhorthy/status/2078592010852982977)
- [program design](https://github.com/humanlayer/advanced-context-engineering-for-coding-agents/blob/main/wsff.md#program-design)
- [Dillon Mulroy](https://x.com/dillon_mulroy/status/2059985696148849025)
- [chat about vertical slices or "tracer bullets" on a live stream back in January 2026](https://www.youtube.com/live/NKu3T9FUjmU?si=6BGnZLOkmuIPTjzh&t=2230)
- [tracer bullets](https://basecamp.com/shapeup/3.2-chapter-11#integrate-one-slice)
- [outsource the thinking](https://www.arthropod.software/p/vibe-coding-our-way-to-disaster#:~:text=The%20methodology%20I%27ve%20outlined%20goes%20beyond%20productivity%20with%20AI%20tools.%20At%20its%20core%2C%20it%20maintains%20the%20discipline%20and%20thoughtfulness%20that%20creates%20maintainable%2C%20understandable%20systems.%20It%20recognizes%20that%20the%20hard%20work%20of%20thinking%20can%27t%20be%20outsourced%20to%20AI%2C%20only%20amplified%20by%20it.)
- ["where does the time go"](https://github.com/humanlayer/advanced-context-engineering-for-coding-agents/blob/main/side-quests/where-does-the-time-go.md)
- [humanlayer.com](https://humanlayer.com/)
- [discord](https://hlyr.dev/discord)
- [founders@humanlayer.dev](mailto:founders@humanlayer.dev)
- [@calvinfo](https://x.com/@calvinfo)
- [@0xBlacklight](https://x.com/@0xBlacklight)
- [@swyx](https://x.com/@swyx)
- [@aiDotEngineer](https://x.com/@aiDotEngineer)
- [Dex and Gergely talk context engineering and software factories on The Pragmatic Engineer - July 2026](https://www.youtube.com/watch?v=Usufn8IQJgw)
- [Dex and Matt Pocock talk evergreen ai coding advice (and ralph loops) - January 2026](https://www.youtube.com/watch?v=NKu3T9FUjmU)
- [Benchmarks prove nothing](https://www.youtube.com/watch?v=X5mI1ZVxaIc)
- [Product Specs for AI Coding](https://www.youtube.com/watch?v=0LPBw3NO3Jc)
- [Learning Tests for better backpressure](https://www.youtube.com/watch?v=Zx_GOhGik0o)
- [Applying 12-factor agents principles to AI coding](https://www.youtube.com/watch?v=qgAny0sEdIk)
- [Why Software Factories Fail keynote — AI Engineer World's Fair 2026](https://hlyr.dev/wsff-live)
- [StrongDM's lights-off software factory](https://factory.strongdm.ai/)
- [OpenAI: Harness Engineering (Feb 2026)](https://openai.com/index/harness-engineering/)
- [Ryan Lopopolo on Symphony (talk, Apr 2026)](https://www.youtube.com/watch?v=am_oeAoUhew)
- [Mario at AI Engineer Europe: "Building pi in a world of slop"](https://www.youtube.com/watch?v=RjfbvDXpFls)
- [Matt Pocock: codebases falling apart](https://www.youtube.com/watch?v=3MP8D-mdheA)
- [Faros AI: the AI acceleration whiplash report](https://www.faros.ai/research/ai-acceleration-whiplash)
- [Advanced Context Engineering for Coding Agents (talk 8/25)](https://hlyr.dev/ace)
- [No Vibes Allowed (talk 11/25)](https://hlyr.dev/nva)
- [Everything We Got Wrong About RPI (talk 3/26)](https://hlyr.dev/qrspi-mlops)
- [Awesome-RLVR - Reinforcement Learning resources](https://github.com/opendilab/awesome-RLVR)
- [Advanced Context Engineering for Coding Agents (write-up)](https://github.com/humanlayer/advanced-context-engineering-for-coding-agents/blob/main/ace-fca.md)
- [12-Factor Agents](https://hlyr.dev/12fa)
- [Addy Osmani on vibe-coding vs. maintenance](https://x.com/addyosmani/status/2066595308629594363)
- [NATO Software Engineering Conference, 1968](http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF)
- [DoD DevSecOps Reference Design (PDF)](https://dodcio.defense.gov/Portals/0/Documents/Library/DevSecOpsReferenceDesign.pdf)
- [Ramp's coding-agent platform](https://infoq.com/news/2026/01/ramp-coding-agent-platform/)
- [Stripe: Minions, one-shot end-to-end coding agents](https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents)
- [WorkOS: Project Horizon](https://workos.com/blog/project-horizon)
- [Brex (Latent Space)](https://www.latent.space/p/brex)
- [Dan Shapiro: the five levels to the software factory](https://www.danshapiro.com/blog/2026/01/the-five-levels-from-spicy-autocomplete-to-the-software-factory/)
- [Simon Willison on StrongDM's software factory](https://simonwillison.net/2026/Feb/7/software-factory/)
- ["Boil the ocean"](https://garryslist.org/posts/boil-the-ocean)
- [Shotgun surgery (refactoring.guru)](https://refactoring.guru/smells/shotgun-surgery)
- [John Ousterhout — A Philosophy of Software Design](https://web.stanford.edu/~ouster/cgi-bin/aposd.php)
- [Robert C. Martin — Clean Code](https://www.oreilly.com/library/view/clean-code-a/9780136083238/)
- [Martin Fowler — Refactoring](https://martinfowler.com/books/refactoring.html)
- [aider](https://aider.chat/)
- [cline](https://cline.bot/)
- [codebuff](https://codebuff.com/)
- [SWE-Agent paper (2024)](https://arxiv.org/abs/2405.15793)
- [OpenAI Codex talk (Nov)](https://www.youtube.com/watch?v=wVl6ZjELpBk)
- [Calvin French-Owen — AI Council talk](https://www.youtube.com/watch?v=q-ntX4DLW_c)
- [SWE-bench Multilingual (dataset)](https://huggingface.co/datasets/SWE-bench/SWE-bench_Multilingual)
- [AIE Worlds Fair 2026 - The Great Loops Debate ("the hype is outrunning the discipline")](https://www.youtube.com/watch?v=c35YoMdnI78)
- [SWE-Marathon (Abundant AI)](https://www.swe-marathon.org/)
- [DeepSWE (Datacurve)](https://deepswe.datacurve.ai/blog/deepswe)
- [Frontier Code (Cognition)](https://cognition.com/blog/frontier-code)
- [Mutation testing (Wikipedia)](https://en.wikipedia.org/wiki/Mutation_testing)
- [Dillon Mulroy on call graphs in planning](https://x.com/dillon_mulroy/status/2059985696148849025)
- [Dex × Matt Pocock: vertical slices / tracer bullets (livestream, Jan 2026)](https://www.youtube.com/live/NKu3T9FUjmU?si=6BGnZLOkmuIPTjzh&t=2230)
- ["The hard work of thinking can't be outsourced" (Jake Nations)](https://www.arthropod.software/p/vibe-coding-our-way-to-disaster)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [12:46 AM · Jul 26, 2026](https://x.com/dexhorthy/status/2081058573556306030)
- [52.1K Views](https://x.com/dexhorthy/status/2081058573556306030/analytics)
- [View quotes](https://x.com/dexhorthy/status/2081058573556306030/quotes)
---
*导出时间: 2026/7/26 11:16:05*
---
## 中文翻译
# 为什么软件工厂会失败：重新开灯
**作者**: dex
**日期**: 2026-07-25T16:46:42.000Z
**来源**: [https://x.com/dexhorthy/status/2081058573556306030](https://x.com/dexhorthy/status/2081058573556306030)
---
这是《为什么软件工厂会失败》的第二部分
这篇文章的演讲版本已在 YouTube 上线：https://www.youtube.com/watch?v=Ib5GBkD555M
## 重新开灯
在第一部分中，我深入探讨了为什么不能信任模型长期维护代码库质量。为什么无论多少约束工程或追求 Token 极致利用都无法解决模型训练和基准测试的问题。为什么由“模型充当裁判”来评判代码质量的效果并不像某些人告诉你的那样好。
目前，裁判是你——所以我们要把代码审查找回来。
我们将拥抱我们在 AI 时代之前一直在做的同一件事，即在开始前做一点计划，以减少漫长而艰难的审查的几率。
我们将寻找杠杆，我们将利用 AI 在以下 4 个阶段提供帮助：
- 产品需求
- 系统架构
- 程序设计
- 垂直切片
## 产品审查
一切都始于产品审查：一份简短的文档，确定了我们要构建什么以及为什么。目标是能够接受两句话或一段冗长的语音笔记，并将其转化为半结构化的内容。
首先，我们要在要解决的问题上达成一致——即用用户的术语描述的实际用户痛点。其次，成功的样子是什么——我们在发布后可以观察什么来决定这件事是否值得构建。理想情况下，这是一个用户结果，例如“可以在更短的时间内完成 XYZ 工作流”或“更早达到入职里程碑 ABC”。有时它是较低级别的指标，如错误率或延迟数字，有时仅仅是“关于 X 的支持工单停止了”。
我们尽量将其保持在产品领域，而不是技术领域。作为一个一只脚在产品世界、一只脚在技术领域的人，我经常发现自己在这里会滑向技术细节。当这种情况发生时，我会试着把它记下来留给以后的阶段，然后回到用户实际体验的内容上。如果技术决策阻碍了产品决策，那么我们确定目前的方案，进入架构阶段，或者对可行性做更多的原型研究。
由于其中大部分内容都是关于用户看到的，我不去描述它——我把它画出来。实际屏幕的粗略 HTML 模型可以解决一个本来需要三段文字争论不休的问题。
这是一个正在进行的真实例子——文档用 JSON 大纲确定了功能，然后是两个实际屏幕的粗略 HTML 模型：
https://x.com/dexhorthy/status/2078592010852982977
当然，并非所有事情都需要产品审查。文案微调、一次性脚本、复现路径明显的 Bug——我们仍然直接一键发送给代理处理。这是针对那些代理误解我们的意图会带来高昂代价的变更。
对于本文档以及本系列中的所有文档，我们采用作者主动选择审查的方式。如果你想在审查期间节省时间，你会选择原本会审查 PR 的人，并与他们过一遍产品/技术规格，可以通过文档评论异步进行（我们自己内部使用 humanlayer 做这件事，但你完全可以在 github/notion/plannotator 等平台上做）。
## 系统架构
产品审查确定后，我们进行系统架构。这并没有什么特别新颖之处，甚至连那些凭直觉编码的开发者也开始对此深信不疑。
## 如果你想在审查期间节省时间，你会选择原本会审查 PR 的人，并在进入编码阶段之前与他们过一遍产品/技术规格。
在这个阶段，我们在服务、端点、模式、队列和存储之间如何相互通信上达成一致，而不深入程序设计的细节。为了最大化人类与代理之间的通信带宽，我们在这里大量使用可视化工具——例如时序图：
契约 / 端点形状：
数据模型和转换：
在这里使用 Mermaid 是可以的，但有时可能有些过头，有时会诱使你产生一种虚假的一致感。架构具有相当高的杠杆作用，你可以在这一阶段避免许多潜在的、糟糕的模型怪癖。但这对于产生高质量的代码来说是不够的。为此我们需要程序设计。
## 程序设计
在架构之后，我们要做一件我认为在代理编码中被严重低估的事情：程序设计。
大多数人认为，一旦架构正确了，模型就可以大显身手了。你当然可以继续这样做，但你可能不会喜欢得到的结果。
但我看到行之有效的方法是，在任何人（人类或代理）编写实现之前，我们从架构向下一层进入代码的形态：类型、方法签名、程序布局和调用栈。
我们的程序设计技能的第一个版本很糟糕。它很难阅读，让人筋疲力尽。我们试过 Mermaid，它有它的用武之地，但我们真正喜欢的是伪代码中的轻量级可视化：
调用栈树，用于任何编排或控制流变更。当有趣的部分是变化的内容时，使用 diff 语法：
Dillon Mulroy 谈到将调用图作为他规划过程的一部分，我认为这是完全正确的。
文件树差异——这样你可以与代码库的布局以及内容的存放位置保持同步
关键新函数的类型和方法签名——这些对于架构文档来说太内部了，但代理仍然可能会搞错
这些都不需要很长时间生成（模型起草它们，你与它争论），而且每一个都是你否则在代码审查期间会隐式做出的决定——而那是在改变主意成本最高的时候。
## 垂直切片
接下来，我们喜欢做我称之为“垂直切片”的事情——Matt Pocock 和我在 2026 年 1 月的一次直播中聊过垂直切片或“曳光弹”——这也被称为 - 曳光弹
模型喜欢我称之为“水平计划”的东西——按堆栈顺序做事：
1. 数据库迁移
2. 服务层
3. API
4. 前端
在实践中，这意味着在进行过程中没有真正的办法“触摸”到解决方案。你可以用代码测试东西，但对于我构建的几乎所有功能，阅读测试只是一个开始，而在浏览器中拉出某些东西，或者在我工作时用 curl 访问它始终是工作流程中经常的一部分。
在 AI 之前，很少有人会在不沿途检查某些东西的情况下编写 2000 多行甚至 500 行代码。
我花了一段时间才注意到这与我习惯的差异——当我在 AI 之前编写代码时，我总是从中间开始，向外工作。大致如下：
1. 创建 API 契约并提供模拟数据，用 curl 测试
2. 创建前端以消费模拟数据，在浏览器中迭代+打磨
3. 将 API 连接到服务层（服务提供模拟数据/行为）
4. 添加数据库迁移，将服务连接到数据库
5. 添加大量业务逻辑
6. 添加大量错误处理
而且在每一步我都会测试/迭代/打磨。
如果我很关心代码或者对模型在这部分代码库中做好工作的能力持怀疑态度，我也会在每一步审查代码。在这里检查 100-200 行代码并重新调整方向要便宜得多。我会在这里这样做。大多数前沿模型如果没有人类的引导不会设计这样的计划，而且很难针对每个代码库甚至每个任务进行泛化，所以我更喜欢保持在这个循环中。相信我。如果我能外包思考
30 分钟的规划可以节省数小时的审查
因此，我们有一些步骤，我认为如果要保持接近人类的质量水平，而不用在事后为了清理如山的劣质代码而受苦（即你实际上想快点），人类需要参与其中。
1. 产品设计
2. 系统架构
3. 程序设计
4. 垂直切片
显然，我们不会为我们发布的所有事情都做整个过程（见下面的支线任务）。我猜分布大致如下：
- 约 40% 的任务是直接完成或带有 1-2 轮轻微反馈的直接完成
- 对于中等任务，我们在一个计划文档中完成产品/系统设计，而不费心将工作分解为阶段
- 对于大型任务，我们要做所有步骤。对于不合理的事情，我们会跳过产品部分，比如大型重构。
在大多数情况下，我会一次发送一个模型去做 1-3 个切片，并在我进行时审查代码。在早期重新调整方向要容易得多，无论是内部还是实际功能，而不是在写了 2000 多行代码后却不知道哪里出了问题。
## 你可能觉得你的 Pull Request 太多了
你的 PR 并不多。你的糟糕 PR 太多了。
我们在 AI 出现很久之前就已经审查了很多需要返工的 PR。
但是，一个很棒的 PR 是一种审查的乐趣。你浏览每个文件，代码很干净，它遵循了你所有的决定/讨论/关于软件应该如何构建的来之不易的观点。
另一方面，如果一个 Pull Request 需要 20% 的返工（这已经很宽容了，我会说大多数 AI 直接生成的 PR 趋向于接近 50%），那么这对提交者和审查者来说都是智力负担和情感负担。（即使提交者是 AI，也可能有人启动了这项工作或者对 AI 结果进行了风格上的打磨，或者至少关心结果）。
为了节省时间（我们快结束了），我在一个支线任务中更多地讨论了这个问题：
“时间去哪了”
## 约束理论（2026 版）
核心论点在这里有点令人沮丧：“目前我们只能老老实实看代码”。
我很期待这样一个世界：我们可以直接要求东西，让模型大显身手，而不需要阅读代码，就能获得漂亮的、随时间演进而不会变糟的生产软件。
但我在这里尽最大努力列出的仅仅是约束。模型擅长某些事情，不太擅长其他事情。如何在这些约束的条件下优化你的流程？
模型擅长某些事情，不太擅长其他事情。如何在这些约束的条件下优化你的流程？
你可能太忙于试图将速度提高 10-100 倍，并试图说服自己代码质量不再重要，而你可以拥抱约束，安全地将速度提高 2-3 倍。
我在这里的结束建议基本上是：
1. 很好地学习约束，通过大量与模型合作来培养直觉
2. 在这些约束的领域内优化系统
3. 寻找杠杆
4. 阅读该死的代码
就这样。如果你想留下来听推销，我想继续往下滚动。我希望这能帮助你避免灾难，或者至少你看着一些可爱的小动画玩得开心。
感谢阅读
-dex
## PS 我们对此很着迷
我们正在构建 humanlayer.com，这是一个代理 IDE 和协作平台，帮助你在保持人类（或非常接近人类）代码质量水平的同时，将速度提高 2-3 倍。
我们要致力于两个想法：“软件工厂的构建模块”和“软件可维护性的更好验证器”（也许是更好的模型）。
HumanLayer 对最多 3 人的小团队免费，如果你需要帮助入门，可以来我们的 discord 闲逛，或者给 founders@humanlayer.dev 发邮件
快速致谢 @calvifo 的灵感，我的联合创始人 @0xBlacklight，@swyx 和 @aiDotEngineer 团队给了我一个探索这些想法的舞台，以及我们所有令人难以置信的客户、投资者、朋友和家人的欢呼。
如果你想了解更多，我基本上对此喋喋不休，所以你可以在下面找到这篇文章的所有链接，以及一些其他形式的材料，如播客、长篇白板等。
## PPS 其他资源
播客和文章：
- Dex 和 Gergely 在 The Pragmatic Engineer 上谈论上下文工程和软件工厂 - 2026 年 7 月
- Dex 和 Matt Pocock 谈论常青 AI 编码建议（以及 ralph 循环）- 2026 年 1 月
AI That Works 剧集：
- 基准测试证明不了任何东西
- AI 编码的产品规格
- 用于更好回压的学习测试
- 将 12 因素代理原则应用于 AI 编码
本文中的链接：
- Why Software Factories Fail 主题演讲 — AI Engineer World's Fair 2026
- StrongDM 的关灯软件工厂
- OpenAI: Harness Engineering (2026 年 2 月)
- Ryan Lopopolo 谈 Symphony (演讲，2026 年 4 月)
- Mario 在 AI Engineer Europe：“在一个充满垃圾的世界里构建 pi”
- FT：由编码代理事故引起的亚马逊中断
- Matt Pocock：代码库分崩离析
- Faros AI：AI 加速震荡报告
- Advanced Context Engineering for Coding Agents (演讲 8/25)
- No Vibes Allowed (演讲 11/25)
- Everything We Got Wrong About RPI (演讲 3/26)
- Awesome-RLVR - 强化学习资源
- Advanced Context Engineering for Coding Agents (文章)
- 12-Factor Agents
- Addy Osmani 谈论氛围编码与维护
- NATO 软件工程会议，1968
- DoD DevSecOps 参考设计 (PDF)
- Ramp 的编码代理平台
- Stripe: Minions，一键端到端编码代理
- WorkOS: Project Horizon
- Brex (Latent Space)
- Dan Shapiro：通往软件工厂的五个层次
- Simon Willison 谈 StrongDM 的软件工厂
- “Boil the ocean”
- 霰弹式手术 (refactoring.guru)
- John Ousterhout — 软件设计哲学
- Robert C. Martin — 代码整洁之道
- Martin Fowler — 重构
- aider
- cline
- codebuff
- SWE-Agent 论文 (2024)
- OpenAI Codex 演讲 (11 月)
- Calvin French-Owen — AI Council 演讲
- SWE-bench Multilingual (数据集)
- AIE Worlds Fair 2026 - 大循环辩论 (“炒作超过了纪律”)
- SWE-Marathon (Abundant AI)
- DeepSWE (Datacurve)
- Frontier Code (Cognition)
- 变异测试 (维基百科)
- Dillon Mulroy 谈论规划中的调用图
- Dex × Matt Pocock：垂直切片 / 曳光弹 (直播，2026 年 1 月)
- “思考的辛苦工作不能外包” (Jake Nations)
## 相关链接
- [dex](https://x.com/dexhorthy)
- [@dexhorthy](https://x.com/dexhorthy)
- [52K](https://x.com/dexhorthy/status/2081058573556306030/analytics)
- [Why Software Factories Fail](https://x.com/dexhorthy/status/2080697380379427275)
- [https://www.youtube.com/watch?v=Ib5GBkD555M](https://www.youtube.com/watch?v=Ib5GBkD555M)
- [part 1](https://x.com/dexhorthy/status/2080697380379427275)
- [a little bit of planning up front](https://github.com/humanlayer/advanced-context-engineering-for-coding-agents/blob/main/wsff.md#front-loading-alignment)
- [prototype research on what's feasible](https://www.youtube.com/watch?v=Zx_GOhGik0o)
- [https://x.com/dexhorthy/status/2078592010852982977](https://x.com/dexhorthy/status/2078592010852982977)
- [program design](https://github.com/humanlayer/advanced-context-engineering-for-coding-agents/blob/main/wsff.md#program-design)
- [Dillon Mulroy](https://x.com/dillon_mulroy/status/2059985696148849025)
- [chat about vertical slices or "tracer bullets" on a live stream back in January 2026](https://www.youtube.com/live/NKu3T9FUjmU?si=6BGnZLOkmuIPTjzh&t=2230)
- [tracer bullets](https://basecamp.com/shapeup/3.2-chapter-11#integrate-one-slice)
- [outsource the thinking](https://www.arthropod.software/p/vibe-coding-our-way-to-disaster#:~:text=The%20methodology%20I%27ve%20outlined%20goes%20beyond%20productivity%20with%20AI%20tools.%20At%20its%20core%2C%20it%20maintains%20the%20discipline%20and%20thoughtfulness%20that%20creates%20maintainable%2C%20understandable%20systems.%20It%20recognizes%20that%20the%20hard%20work%20of%20thinking%20can%27t%20be%20outsourced%20to%20AI%2C%20only%20amplified%20by%20it.)
- ["where does the time go"](https://github.com/humanlayer/advanced-context-engineering-for-coding-agents/blob/main/side-quests/where-does-the-time-go.md)
- [humanlayer.com](https://humanlayer.com/)
- [discord](https://hlyr.dev/discord)
- [founders@humanlayer.dev](mailto:founders@humanlayer.dev)
- [@calvinfo](https://x.com/@calvinfo)
- [@0xBlacklight](https://x.com/@0xBlacklight)
- [@swyx](https://x.com/@swyx)
- [@aiDotEngineer](https://x.com/@aiDotEngineer)
- [Dex and Gergely talk context engineering and software factories on The Pragmatic Engineer - July 2026](https://www.youtube.com/watch?v=Usufn8IQJgw)
- [Dex and Matt Pocock talk evergreen ai coding advice (and ralph loops) - January 2026](https://www.youtube.com/watch?v=NKu3T9FUjmU)
- [Benchmarks prove nothing](https://www.youtube.com/watch?v=X5mI1ZVxaIc)
- [Product Specs for AI Coding](https://www.youtube.com/watch?v=0LPBw3NO3Jc)
- [Learning Tests for better backpressure](https://www.youtube.com/watch?v=Zx_GOhGik0o)
- [Applying 12-factor agents principles to AI coding](https://www.youtube.com/watch?v=qgAny0sEdIk)
- [Why Software Factories Fail keynote — AI Engineer World's Fair 2026](https://hlyr.dev/wsff-live)
- [StrongDM's lights-off software factory](https://factory.strongdm.ai/)
- [OpenAI: Harness Engineering (Feb 2026)](https://openai.com/index/harness-engineering/)
- [Ryan Lopopolo on Symphony (talk, Apr 2026)](https://www.youtube.com/watch?v=am_oeAoUhew)
- [Mario at AI Engineer Europe: "Building pi in a world of slop"](https://www.youtube.com/watch?v=RjfbvDXpFls)
- [Matt Pocock: codebases falling apart](https://www.youtube.com/watch?v=3MP8D-mdheA)
- [Faros AI: the AI acceleration whiplash report](https://www.faros.ai/research/ai-acceleration-whiplash)
- [Advanced Context Engineering for Coding Agents (talk 8/25)](https://hlyr.dev/ace)
- [No Vibes Allowed (talk 11/25)](https://hlyr.dev/nva)
- [Everything We Got Wrong About RPI (talk 3/26)](https://hlyr.dev/qrspi-mlops)
- [Awesome-RLVR - Reinforcement Learning resources](https://github.com/opendilab/awesome-RLVR)
- [Advanced Context Engineering for Coding Agents (write-up)](https://github.com/humanlayer/advanced-context-engineering-for-coding-agents/blob/main/ace-fca.md)
- [12-Factor Agents](https://hlyr.dev/12fa)
- [Addy Osmani on vibe-coding vs. maintenance](https://x.com/addyosmani/status/2066595308629594363)
- [NATO Software Engineering Conference, 1968](http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF)
- [DoD DevSecOps Reference Design (PDF)](https://dodcio.defense.gov/Portals/0/Documents/Library/DevSecOpsReferenceDesign.pdf)
- [Ramp's coding-agent platform](https://infoq.com/news/2026/01/ramp-coding-agent-platform/)
- [Stripe: Minions, one-shot end-to-end coding agents](https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents)
- [WorkOS: Project Horizon](https://workos.com/blog/project-horizon)
- [Brex (Latent Space)](https://www.latent.space/p/brex)
- [Dan Shapiro: the five levels to the software factory](https://www.danshapiro.com/blog/2026/01/the-five-levels-from-spicy-autocomplete-to-the-software-factory/)
- [Simon Willison on StrongDM's software factory](https://simonwillison.net/2026/Feb/7/software-factory/)
- ["Boil the ocean"](https://garryslist.org/posts/boil-the-ocean)
- [Shotgun surgery (refactoring.guru)](https://refactoring.guru/smells/shotgun-surgery)
- [John Ousterhout — A Philosophy of Software Design](https://web.stanford.edu/~ouster/cgi-bin/aposd.php)
- [Robert C. Martin — Clean Code](https://www.oreilly.com/library/view/clean-code-a/9780136083238/)
- [Martin Fowler — Refactoring](https://martinfowler.com/books/refactoring.html)
- [aider](https://aider.chat/)
- [cline](https://cline.bot/)
- [codebuff](https://codebuff.com/)
- [SWE-Agent paper (2024)](https://arxiv.org/abs/2405.15793)
- [OpenAI Codex talk (Nov)](https://www.youtube.com/watch?v=wVl6ZjELpBk)
- [Calvin French-Owen — AI Council talk](https://www.youtube.com/watch?v=q-ntX4DLW_c)
- [SWE-bench Multilingual (dataset)](https://huggingface.co/datasets/SWE-bench/SWE-bench_Multilingual)
- [AIE Worlds Fair 2026 - The Great Loops Debate ("the hype is outrunning the discipline")](https://www.youtube.com/watch?v=c35YoMdnI78)
- [SWE-Marathon (Abundant AI)](https://www.swe-marathon.org/)
- [DeepSWE (Datacurve)](https://deepswe.datacurve.ai/blog/deepswe)
- [Frontier Code (Cognition)](https://cognition.com/blog/frontier-code)
- [Mutation testing (Wikipedia)](https://en.wikipedia.org/wiki/Mutation_testing)
- [Dillon Mulroy on call graphs in planning](https://x.com/dillon_mulroy/status/2059985696148849025)
- [Dex × Matt Pocock: vertical slices / tracer bullets (livestream, Jan 2026)](https://www.youtube.com/live/NKu3T9FUjmU?si=6BGnZLOkmuIPTjzh&t=2230)
- ["The hard work of thinking can't be outsourced" (Jake Nations)](https://www.arthropod.software/p/vibe-coding-our-way-to-disaster)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [12:46 AM · Jul 26, 2026](https://x.com/dexhorthy/status/2081058573556306030)
- [52.1K Views](https://x.com/dexhorthy/status/2081058573556306030/analytics)
- [View quotes](https://x.com/dexhorthy/status/2081058573556306030/quotes)
---
*导出时间: 2026/7/26 11:16:05*