在过去的一两年里，我感受到的最大变化是、 *拉取请求的数量异常增加。
我是一名工程经理。 我的团队有十几个人、 其中一半以上是承包商（二级工程师）。
---
他们在白天工作之余，在夜间和周末开展业务。 从周五晚上到周日晚上 大量的拉杆同时上升
一个承包商可能会同时为多个资源库工作、 到了周末，他们就会陷入 "我该从哪里开始？ 光是周末就堆积了几十个拉取请求，这种情况屡见不鲜。
---
只是因为产品是微服务配置、 即使是合并过程也不是微型的。
在实践中，业务逻辑非常复杂 复杂，而且跨越每个服务、 如果在不了解上下文的情况下进行合并、 整个系统的完整性会立即遭到破坏。
乍一看，生产率似乎在提高。 但从总体上看，产品变得更加不稳定。
---
在这种情况下很难休息。 如果周六和周日的拉扯不加制止、 周一，可能会有什么地方坏了。
毕竟，管理人员和开发人员 "不能休息的结构"。
---
从表面上看，这可以说是 "生产率的提高"。 但从本质上讲，"失去背景 "的情况越来越严重。 生产力是 不是为了更快地编写代码、 *而是取决于了解背景的人能否做出正确的决定并正确地合并**。
---
不过，人工智能可以在某些领域提供帮助、 但其局限性也是显而易见的。 尤其是在用户体验和前端领域、 需要 "眼睛 "和 "耳朵"、 人工智能还无法补充人类的感官。
不过，人工智能可以只进行后端逻辑、 用户界面和体验设计却不能。
据说人工智能用得越多，生产率就越低、 *人工智能用得越多，生产率就越低，很容易陷入"反向生产率陷阱 "。
---
当你的开发组织超过十几个人时，这个问题就会变得很明显。 我说的不是 "克劳德代码中的 01 个原型 "这样的事情。 *这是当你进入到维护一个在生产规模上有效的产品阶段时才会出现的现实问题。
人工智能和人类的工作都已达到极限。 但是，我们仍然无法保证产品不会出现故障。
