HackerNews中文版

我们在过去一个月里对软件预算进行了建模，以弄清楚为什么即使是资深团队，开发速度常常感觉如此低下。简而言之，这似乎是结构性的问题：大约80%的工程时间用于非差异化的基础设施（如身份验证、管道、CRUD操作），而不是独特的业务逻辑。我们称之为“基础设施税”。我们分析了一份匿名的240万美元的工程支出，老实说，这个支出明细让人感到沮丧。只有大约20%的预算用于真正能使产品差异化的功能。其余的呢？身份验证流程、数据库配置、持续集成/持续交付管道，以及第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.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.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:- 5 developers - $500k/year combined cost (conservative inputs) - Standard SaaS requirementsWe 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.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.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.Obviously, this is where the skepticism kicks in (and rightfully so). There are massive caveats here:- *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.We're using these models to think about internal resource allocation, but I'm curious if this matches your reality.- 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?I suspect the "Infrastructure Tax" is the main reason software feels expensive, but maybe I'm underestimating the value of bespoke plumbing.

告诉HN：我们对模板代码的成本进行了建模（大约占预算的80%）。