告诉 HN：我们对样板代码的成本进行了建模（它占据了大约 80% 的预算）
1 分•作者: thesssaism•6 个月前
我们花了上个月的时间来建模软件预算，以找出为什么即使是资深团队，开发速度也常常感觉如此之慢。简而言之，原因似乎是结构性的：大约 80% 的工程时间花在了非差异化的基础设施（身份验证、管道、CRUD）上，而不是独特的业务逻辑上。
我们称之为“基础设施税”。我们分析了一份匿名的 240 万美元的工程支出，老实说，这个分解令人沮丧。只有大约 20% 的预算用于真正区分产品的特性。剩下的呢？身份验证流程、数据库配置、CI/CD 管道，以及第 50 次编写相同的用户模式。即使有了现代框架，感觉我们也一直在支付通行费，只是为了到达起跑线。
为了量化这一点，我们建立了一个理论模型（是的，我知道，模型不是现实，但请耐心听我说）。我们采用了标准的创业公司场景：
- 5 名开发人员
- 总成本 50 万美元/年（保守输入）
- 标准 SaaS 需求
我们将时间映射到“设置/样板”与“核心业务逻辑”。然后，我们模拟了一种“AI 原生”方法，其中 AI 处理大约 90% 的初始脚手架——不仅仅是编写函数，而是将堆栈连接在一起。
数学计算表明结构发生了逆转。在传统模型中，你看到的大约是 80/20 的比例（维护/基础设施与特性）。通过大量 AI 自动化处理样板，这个比例会向 30/70 转变。
对于一个 5 人的团队，该模型意味着每年可以节省大约 900 多个小时。但真正的指标不是节省的时间，而是机会成本。如果你发布 20 个特性而不是 12 个，价值差异是非线性的。这是找到产品市场契合点和耗尽资金之间的区别。
显然，这就是怀疑开始的地方（而且是正确的）。这里存在巨大的警告：
- *维护负担：* 生成代码很容易创建，但调试可能是一场噩梦。如果 AI 吐出意大利面代码，你没有节省时间；你只是将痛苦推迟到维护阶段。
- *架构锁定：* 自动化设置通常意味着僵化的观点。如果你的应用程序不符合“标准 SaaS”模式，与生成的抽象作斗争可能比从头开始编写它的成本更高。
- *“黑盒子”风险：* 初级开发人员生成他们根本不理解的基础设施，这存在真正的危险，导致高级开发人员以后必须修补的安全漏洞。
我们正在使用这些模型来考虑内部资源分配，但我很好奇这是否符合你的现实情况。
- 80/20 的比例是否适用于你的堆栈，或者现代工具（Vercel/Supabase/等）是否已经为你解决了这个问题？
- “机会成本”是你实际在工程中跟踪的指标，还是只是 CFO 们谈论的事情？
- 对于那些使用 AI 进行脚手架的人：你是否在调试成本上为此付出了代价？
我怀疑“基础设施税”是软件感觉昂贵的主要原因，但也许我低估了定制管道的价值。
查看原文
We spent the last month modeling software budgets to figure out why velocity often feels so low even with senior teams. The short answer seems to be structural: about 80% of engineering time goes to non-differentiating infrastructure (auth, pipelines, CRUD) rather than unique business logic.<p>We call it the "Infrastructure Tax." We analyzed an anonymized $2.4M engineering spend, and honestly, the breakdown was depressing. Only about 20% of that budget went to features that actually differentiated the product. The rest? Auth flows, database provisioning, CI/CD pipelines, and writing the same user schema for the 50th time. Even with modern frameworks, it feels like we're constantly paying a toll just to get to the starting line.<p>To quantify this, we built a theoretical model (yeah, I know, models aren't reality, but bear with me). We took a standard startup scenario:<p>- 5 developers
- $500k/year combined cost (conservative inputs)
- Standard SaaS requirements<p>We mapped hours to "Setup/Boilerplate" vs. "Core Business Logic." Then we modeled an "AI-native" approach where the AI handles ~90% of that initial scaffolding—not just writing functions, but wiring the stack together.<p>The math suggests a structural inversion. In the traditional model, you're looking at roughly an 80/20 split (Maintenance/Infra vs. Features). With heavy AI automation handling the boilerplate, that shifts toward 30/70.<p>For a 5-person team, the model implies saving roughly 900+ hours a year. But the real metric isn't hours saved; it's opportunity cost. If you ship 20 features instead of 12, the value difference is non-linear. It's the difference between finding product-market fit and running out of runway.<p>Obviously, this is where the skepticism kicks in (and rightfully so). There are massive caveats here:<p>- *Maintenance Burden:* Generative code is easy to create but can be a nightmare to debug. If the AI spits out spaghetti code, you haven't saved time; you've just deferred the pain to the maintenance phase.
- *Architectural Lock-in:* Automated setup usually means rigid opinions. If your app doesn't fit the "standard SaaS" mold, fighting the generated abstraction might cost more than writing it from scratch.
- *The "Black Box" Risk:* There's a real danger of junior devs generating infrastructure they don't fundamentally understand, leading to security holes that senior devs have to patch later.<p>We're using these models to think about internal resource allocation, but I'm curious if this matches your reality.<p>- Does the 80/20 split hold true for your stack, or have modern tools (Vercel/Supabase/etc.) already solved this for you?
- Is "Opportunity Cost" a metric you actually track in engineering, or just something CFOs talk about?
- For those using AI for scaffolding: are you paying for it later in debugging costs?<p>I suspect the "Infrastructure Tax" is the main reason software feels expensive, but maybe I'm underestimating the value of bespoke plumbing.