问HN：如果编码速度加快，架构应该在哪里进行？
如果编码变得更快，架构应该在何时进行？
一个功能可以正常工作，测试通过，拉取请求（PR）也不大。业务希望进行实时测试。没有人想因为架构问题而阻碍价值交付，尽管这个问题在当下听起来可能有些抽象。
但这似乎变得越来越困难。
人工智能辅助开发、快速编码、内部工具和更好的框架都减少了生产代码的摩擦。这是有益的。团队可以更快地进行原型设计，并更早地发布实验。
问题在于，架构判断并没有变得同样便宜。
代码可能正常工作，但仍然会使系统变得更糟：逻辑重复、所有权不清晰、模式不一致、安全漏洞、边界不明确、应当可重用的单一组件，或者后续难以删除的功能。
一种选择是强制在代码审查中引入更多架构内容。但这样一来，PR就会变得缓慢、令人沮丧，并充满难以解决的设计争论，因为代码已经存在。
另一种选择是加快合并速度，同时使合并后的架构反馈循环更加明确。架构本应是持续的，但更快的代码创建可能需要更强的合并后机制：审查系统级别的变化，检查重用机会，重新评估安全假设，安排重构，保持功能在标志后面，并愿意禁用或重写某些内容。
这只有在“稍后重构”成为一个实际流程，而不是一个愿望时才有效。
随着代码生产变得更容易，您的团队是否改变了处理架构的方式？您是在合并之前、合并之后，还是通过某种持续审查流程来处理这个问题？
查看原文
If coding gets faster, where should architecture happen?<p>A feature works. The tests pass. The PR is not huge. The business wants to test it live. Nobody wants to block value delivery because of an architecture concern that may sound abstract in the moment.<p>But this seems to be getting harder.<p>AI-assisted development, vibe coding, internal tooling, and better frameworks all reduce the friction of producing code. That is useful. Teams can prototype faster and ship experiments sooner.<p>The problem is that architectural judgment has not become equally cheap.<p>The code may work and still make the system worse: duplicated logic, unclear ownership, inconsistent patterns, security gaps, bad boundaries, one-off components that should have been reusable, or features that are hard to remove later.<p>One option is to force more architecture into code review. But then PRs become slow, frustrating, and full of design debates that are difficult to resolve after the code already exists.<p>Another option is to merge faster, while making the architecture feedback loop after merge much more explicit. Architecture should already be continuous, but faster code creation may require stronger post-merge mechanisms: reviewing what changed at the system level, checking reuse opportunities, reassessing security assumptions, scheduling refactors, keeping features behind flags, and being willing to disable or rewrite things.<p>That only works if “refactor later” is an actual process, not a wish.<p>Has your team changed how it handles architecture as code has become easier to produce? Do you handle this before merge, after merge, or through some continuous review process?