“稍后再说”是一个功能。
"Maybe later" was a feature

原始链接: https://arnorhs.dev/posts/2026-06-04/maybe-later-was-a-feature/

任何代码仓库中最有价值的代码,往往是你选择不去写的那些。许多开发者维护着堆积如山的“新颖”功能、迁移计划或架构重构,但这些工作却从未被优先处理。回首往事,通常会发现避免这些项目反而带来了净收益;否则,它们只会沦为难以维护的遗留代码,或随着产品的转型而变得无关紧要。 AI 编程的兴起带来了一种危险的诱惑:由于生成代码的成本极低,团队开始“疯狂堆砌”,将积压清单中的所有内容都开发出来,而不是精心筛选出真正必要的部分。这种趋势有导致代码库臃肿的风险,充斥着不必要的功能、冗余的实现以及难以管理的混乱结构。 战略性开发需要洞察力。我们必须抵制仅仅因为“可以做”就去构建的冲动。“不构建”是一项强大的架构特性,它能提升生产力并保持产品专注。随着 AI 能力的增强,担任“策展人”的角色——决定不做什么,并主动消除技术债务——将依然是人类的核心优势。归根结底,维护一个简洁、高效系统的最佳方式是认识到:有时最有效的工程决策就是什么都不做。

这段 Hacker News 的讨论探讨了 AI 辅助编程与人类驱动开发价值之间的张力。 主要发言者认为,如果 AI 工具能让包括非程序员在内的人们去构建那些缺乏即时商业可行性、但充满热情的项目,那么这些工具就是有价值的。他提出了一种区分:“工具”(如用于修改艺术或音乐的软件,旨在增强创造力)与“垃圾”(缺乏人类表达、由 AI 独立生成的产物)。该评论者主张,虽然有些人视编程环境为神圣不可侵犯,但最终目标应该是功能实现,而非单纯的工艺追求。他总结道,尽管 AI 提升了我们的构建能力,但核心挑战与 AI 出现前并无二致:即拥有良好的品味,避免给软件增加不必要的复杂性。 另一位用户则提出了持怀疑态度的反对意见,强调依赖 AI 意味着开发者没能亲自编写代码。
相关文章

原文

The most valueble code in my repo, is the code I didn't write.

Have you ever thought back to when you were kind of excited about something - eg. of having more tests for some particular part of your stack, or rewriting legacy website from "legacy old thing" to "shiny new thing"? Or deploying your services on AWS intead of GCP?

Or maybe it was a feature you wanted to build - such as a task management thing on top of your CRM, or some slick way of handling images in your infra?

Is your team's backlog filled with these things? I know mine is. Those are ideas and tasks that the business, your boss, your team, or yourself never prioritized. You thought to yourself: I'll get to it later.

The ideas that are actually worth prioritizing, you work on. Or you hire people to work on. They get done because they are deemed important enough.

4 years later it's clear that those backlog features would not have helped at all. It is a good thing they never got built. They're either irrelevent today or you already pivoted your product to something completely different.

They'd simply be legacy cruft you either need to support or remove.

I think about those things all the time. All the things I never built.

Every time you don't build something, you are accelerating your team, the product and you are prioritizing what is important at any given moment. Not building is a really powerful feature. Picking is a product and development strategy.

"the models keep getting better"

People talk about AI taking our jobs all the time now. I'll admit, that I worry about that sometimes as well. It's hard not to. Tech CEOs keep reminding me.

On the surface they already are better and in some localized cases I they can produce better code than I can.

But in the larger picture I feel like they're still ways off. How many times have you tried to completely vibe-out but then you look at the code after a while and you ask yourself why the same thing is defined in 15 different places? Or seen 4 different implementations of the same schema validation in nested if-statements?

Personally, I just find LLM output often hard to read. And when it's hard for me to read, it's probably also hard for the AI to read.

But we will get there. I'm sure.

When to build

So LLMs are improving and everybody is using them. Tokenmaxxing like there is no tomorrow (literally and figuratively).

But I worry that that people are, and will be, spending their tokens building exactly these things that you previously would not have built. The backlog ideas. They are no longer picking, they are just building.

And what happens down the road is that all the code bases will just grow with more features and more frameworks and more things that have been re-written from A to B, when you otherwise would not have.

I also worry that the code ends up in a state where it is illegible to a human, and you can only get AI to interface with the code.

And yes, you will be able to use AI to help you remove those things and reshape them. But will you do that? Won't there simply be more systems or more things or people that now rely on this feature?

It's also really difficult making the argument that you need to spend time, tokens or other resources to remove something. It's often hard for non-developers to undestand how removing things can be a net positive.

Additionally, Hyrum's Law will affect your APIs

There's a lot of value in the code that we don't write. and often not choosing to write some code, is the best thing you can do.

联系我们 contact @ memedata.com