编码代理在启动项目时是否比修复实际代码库要好得多？
摘要
观察发现，编码代理在新项目上表现出色，但在现有代码库中常常遇到困难，因为需要最小化更改并理解隐藏的依赖关系，这限制了它们的有效性。
我一直在观察编码代理的一个现象：在项目全新时，它们表现得令人惊艳。你让它开发一个应用、一个功能、一个脚本、一个仪表板，代码立刻就生成了。但现有的代码库就不同了。那里有过去的决策、奇怪的命名、隐藏的依赖关系、不完整的文档、没人信任的测试，以及除非你真正理解系统否则不应触碰的文件。这时候，编码代理的魅力就开始减弱。不是因为它们不能写代码，而是因为真正的工程常常是在不破坏周围一切的前提下，做出最小的改动。绿地任务奖励生成，棕地任务奖励克制。对于在实际项目中使用编码代理的人来说：你更信任它们构建新东西，还是修改现有代码？在较老的代码库中，是什么让它们最容易失败？
相似文章
感觉编码代理擅长找代码，但不擅长理解项目
讨论了一个观察：编码代理虽能有效定位代码，但难以深入理解项目，比如组件关系和项目风格。作者介绍了 RepoWise，一个提供仓库级信号（如依赖图和Git历史）的工具来解决这些问题。
在实际仓库中运行编码代理：代理写完代码后哪些环节会出问题？
本文讨论了工程团队在采用AI编码代理时面临的实际挑战，如任务安全性、上下文检索、输出审查和协调，并提出了一个用于评估的准备度模型。
编码代理是否带来了新的审查问题？
本文讨论了虽然编码代理能够有效生成代码，但它们却在审查和信任变更方面引入了新的瓶颈，质疑代理是减少了审查工作量还是转移了审查工作量。
本地编码智能体现在不错，但得盯着用
作者认为本地编码智能体对小型任务很有用，但需要持续监督以防止错误和范围蔓延，描述了小修复、测试和手动差异检查的迭代工作流程。
前沿编程智能体利用元编程适应陌生编程语言
本文在深奥编程语言上评估了六个前沿编程智能体，发现更强的智能体使用元编程——编写Python程序在陌生的目标语言中生成和调试代码。禁止此策略导致性能大幅下降，而提供Python辅助代码则能提升较弱的智能体。