href 在页面上。但是，如果我的一位同事并不专注于前端，而使用 Copilot 只是为了让他们摆脱困境，那会发生什么呢？如果这些代码因为不是他们的专长而被接受，但在他们看来却运行正常，那又会发生什么呢？

毕竟，如果我使用 Copilot 来编写 Rust 或 Go 代码，我根本不知道自己写的代码是否优秀。我会试一试，如果看起来还行，我就继续。五分钟后，我可能甚至都不记得代码是什么样子了。

但我们知道，这种方法会给开发双方带来问题。就前端交互性而言，盲目相信可能会降低产品的可访问性。

还有另一种情况：如果我是一个优秀的开发人员，能够发现这种违规行为，但我没有发现，因为 Copilot 已经让我心力交瘁，就像一个要糖吃的小孩，而我的意志和注意力已经被之前数百次的暗示所侵蚀，那会发生什么？

任何能够并将会产生不可访问代码的工具，实际上都是在为这种结果加权。

如果确保质量是你的责任，而你正在使用的工具却将糟糕的质量推向你，那么在这种情况下，你就是在与地心引力作斗争。这是你与熵的对抗。除非你的战斗完美无缺（你不会），否则最终的结果不可避免地会更糟。

此外，我们也许不应该假设谁能或将首先发现法律硕士提出的问题。我们很容易忽视这种担忧，说 "当然，是的，糟糕的开发人员会接受糟糕的建议"。

至少在某些时候，我们都是糟糕的开发者。

我们中没有人是完美的。我们有最后期限，有其他责任，老板有很多要求，而这些要求并不一定与代码质量直接相关。我们不可能发现屏幕上出现的每一段糟糕代码。(哎呀，我们中的大多数人都曾在周五下午推送过自己写的糟糕代码）。因此，当我们使用的工具在一定比例的时间内会产生不良代码时，我们实际上就保证了不良代码会影响我们的工作。

质量三角洲

为 Copilot 辩护的另一个常见理由是：是的，糟糕的开发人员会用它来编写糟糕的代码。但他们就是糟糕的开发人员；无论如何，他们都会推送糟糕的代码！也许 Copilot 还能帮助他们做得更好。

就我个人而言，我认为这种论调是不可接受的。有人会把糟糕的代码放到网上吗？当然会。难道这就能免除我们给他们提供一个工具，让他们以更快的速度写出更糟糕的代码吗？我真的不这么认为。

当然，我给了马克一瓶啤酒，但他是个酒鬼，他可能无论如何都会喝的。

不公平？也许吧。我不太确定。我认为，如果你知道有很多人会滥用某样东西，你至少有责任去阻止它。

无论如何，如果我们知道我们存在于一个不公平的竞争环境中（确实如此），我们就不应该把倾斜视为底线。如果现状已经很不公平（确实如此），我们就不应该把同样不公平的事情看成很好，仅仅因为这就是当前的现实。这并不好。这只是更多的同样不公平的倾斜。

回到前面的部分；如果 Copilot 让糟糕的开发者工作得比以前更快，做的坏事比以前更多，而且还主动向他们传递糟糕的建议，我认为我们就不能说整件事纯粹是那些开发者的错。

系统就是这样。把糟糕的代码交给糟糕的开发者的机器，就是让糟糕的开发者继续成为糟糕的开发者的机器。

时间理想主义者

好吧，我们就说坏开发者会坏开发者。但有些人仍然认为：没关系，因为现在好的开发者做得更好了！而且，由于 Copilot 正在做的所有其他有益的事情，他们将有时间让网络变得更美好！

哦，我多么希望世界是这样运转的，我可爱的暑期孩子。