克劳德不是你的建筑师。别再假装了

上个月我已经看了三遍了。三个不同的组织，三个不同的技术堆栈，相同的模式。有人有一个想法。也许是产品经理，也许是团队领导，也许是会议后的首席技术官。他们打开 Claude、ChatGPT 或 Copilot（无论是哪一个）并询问他们应该构建什么。人工智能会做它一贯做的事情：热情地验证想法，提出架构建议，并开始绘制组件草图。说得很清楚。这是有信心的。听起来就像一位非常资深的工程师对这个问题进行了深入的思考。根本就没有考虑过这个问题。它根据训练数据进行模式匹配，并产生听起来最可信的响应。但这听起来太好了，没有人反对。不知不觉中，克劳德就成为了建筑师。 attaboy 问题人工智能代理在病态上是令人愉快的。询问克劳德你的想法是否好，它会告诉你它很好。询问微服务架构对于您的三人团队是否有意义，它会解释为什么微服务是一个绝佳的选择。询问它是否应该构建自定义 ML 管道而不是使用托管服务，它会热情地展示设计。这不是说谎。这不一定是错误的。它只是无法做到让真正的建筑师变得有价值的事情：说“不”。优秀架构师最重要的技能不是设计系统。它知道不应该构建哪些系统。它正在降低复杂性。它在问“为什么？”五次，直到实际的需求从渴望的废话中出现。它告诉 CTO，他们受会议启发的想法非常适合他们实际拥有的团队。克劳德永远不会这么做。它经过训练可以提供帮助。有帮助意味着令人愉快。令人愉快意味着你会得到一个 attaboy 和一座被视为建筑的 Jenga 塔。 Jenga 塔 这是人工智能设计的建筑在实践中的样子。这在技术上是合理的。这些组件单独存在是有意义的。这些模式是可识别的——这里是事件驱动，那里是 CQRS，服务网格，因为为什么不呢。它看起来像是高级建筑师会制作的东西。它通过了斜视测试。但它不是为您的团队设计的。它不是为您的限制而设计的。它并不是为生产环境的无聊现实而设计的——VPC 锁定、遗留集成、从未在生产中操作过 Kubernetes 的团队、意味着一半托管服务是禁止使用的合规性要求。它是为克劳德所见过的一切的中位数而设计的。针对通用公司的通用问题的通用最佳实践。也就是说，它是为任何人设计的。真正的架构充满了只有在上下文中才有意义的权衡。您选择 Postgres 而不是 DynamoDB，因为您的团队了解 Postgres，并且您宁愿在两周内发货，也不愿花一个月的时间学习新的数据模型。您跳过服务网格，因为您有四个服务，而不是四十个。您使用整体架构是因为问题很简单，而且微服务将是职业驱动的开发。这些决定需要判断。他们需要了解团队。他们需要了解组织的实际限制，而不是白板上看起来不错的限制。人工智能代理没有这些背景，更糟糕的是——它不知道自己没有这些背景。 Jira 票务管道 真正让我担心的是接下来发生的事情。一旦克劳德设计了架构，要求其设计的人就会要求其分解工作。它产生史诗。故事。验收标准。格式整齐、理由充分，准备好投入 Jira 中。现在，工程师们——那些花了数年时间磨练技术、了解这个领域、知道尸体埋在哪里的人——不再解决问题。他们正在实施克劳德的设计，一次一张票。想想这里发生了什么。那些最有背景、最有经验、最有风险的人已经沦为票证实施者。背景最少、没有经验、也没有责任的实体正在制定架构决策。这不仅仅是低效。这是倒退的。 “但是有一位前辈签字了”这是我最常听到的辩护。 “克劳德提出了这种方法，但一位高级工程师对其进行了审查。”让我们诚实地了解“审查”在实践中的含义。一位忙碌的技术主管收到了一份清晰明确的架构提案。这是连贯的。它使用了正确的术语。它满足了规定的要求。这些图表是有道理的。它看起来像是他们自己设计的东西。他们会给予多少阻力？在一个对“我不认为这是正确的”的反应是“克劳德花了二十分钟在这上面，你想把它扔掉吗？”的世界里，阻力最小的途径就是通过轻微的评论来批准它。这才是真正的危险。并不是说人工智能会产生糟糕的架构——它通常会产生完全合理的架构。危险在于它会短路