Qodo（在新窗口中打开） 开发用于代码审查和软件质量保障的 AI 工具，为编程智能体提供所需的组织知识，帮助它们理解自己修改的代码。联合创始人兼首席执行官 Itamar Friedman 称其为“编程智能体的最佳伙伴”。
Qodo 使用包括 GPT‑6 Astra 在内的 OpenAI 模型来收集工程知识、审查代码并监测软件质量。其 Codex 插件将这些上下文和审查能力带入开发者的编程会话。
“我们非常喜欢 OpenAI 的模型。我们既想用最前沿、推理能力最强的模型，也想用速度特别快的模型。”
Itamar 介绍，有些客户的环境涉及 10,000 个甚至更多代码仓库。在这样的环境中，一处局部代码修改即使单独看起来没有问题，也可能导致下游服务故障。为解决这一问题，Qodo 开发了一款插件，并将其上架 Codex 插件市场。
Itamar 表示：“Codex 非常擅长高效完成局部任务。”Qodo 的插件让 Codex 能够通过 Qodo 的 Agentic Toolbox 获取代码库知识、组织规则和独立审查能力。
有了上下文，Codex 就能考虑跨代码仓库的依赖关系，包括托管在不同 Git 平台上的仓库之间，以及通过 Kafka 连接的服务之间的依赖关系。Itamar 表示：“Qodo 会识别这些关联，帮助 Codex 从整体上审视软件，不漏掉那些 P0 级缺陷。”
在开始编写代码之前，Codex 可以通过 Qodo 插件检索相关代码库规则，以及 pull request 的历史记录和常见模式。Codex 完成修改后，Qodo 会审查这些改动，并在开发者发起 pull request 之前，将审查结果直接反馈给同一会话中的 Codex。
Qodo 的 AI 开发者关系负责人 Nnenna Ndukwe 看到，开发者正在采用这一工作流，借助 Codex 中的 GPT‑6 模型开发功能、处理技术债务。他们正让 Codex 的编程工作与 Qodo 的独立审查自动衔接起来。Nnenna 表示：“我看到开发者正在这样做，这真的令人振奋，因为 GPT‑6 的能力非常强。”
Itamar 将编程智能体和审查智能体比作“阴阳两面”：一个编写代码，另一个对代码提出质疑。每种角色都需要各自的配置和上下文，也可能由多个智能体共同承担。他希望智能体能讨论审查发现的问题，“只把无法达成共识的部分”提交给人类审查。开发者将成为规划者和审查者，在查看未解决问题的同时，也能查阅智能体的讨论、上下文，以及开发者此前做出的决策。
Itamar 表示：“信任就是这样建立起来的。”Nnenna 补充道：“我认为这让整个流程更加高效。我们可以充分发挥自身最有价值的专业能力。”
在 Qodo 内部，Nnenna 一直在自己的自动化开发工作流和知识工作中，使用 GPT‑6 Astra 的“极高”和“Ultra”推理强度设置。
“还有什么是 Codex 不做的？我喜欢 Codex 做的每一件事，也很喜欢把 AI 与自动化结合起来的想法。”
Nnenna 为 Codex 设置了定时任务，让它汇总她这一周完成的工作，并建议她接下来可以重点关注哪些方面、在哪些地方作出改进。她还让 Codex 研究社交平台上有关智能体工程的讨论，并为面向开发者的内容提出选题建议。对于自己所做的代码修改，她会安排 Codex 定时分析，并建议创建或完善哪些智能体技能。
Itamar 认为，OpenAI 最近推出的 Decisions API 提供了一个机会：用它来选择开发各阶段适用的规则和智能体技能，而不必每次决策都依赖语言模型。
他举例说，Decisions API 可以先从 200 条规则中选出需要检查的规则，再由语言模型针对相关规则进行推理。这有助于加快筛选速度、降低成本，同时提高审查质量。Itamar 表示：“Decisions API 为我们提供了一个绝佳机会，让整个流程更值得信赖。”
Nnenna 表示，Qodo 的方法结合了“人工智能的优势，以及传统软件工程和脚本编写的优势”。企业知识为编程智能体提供指引，独立审查检查其工作成果，而尚未解决的问题则交由人类运用专业知识处理。
这为 Itamar 所说的“软件工厂”奠定了基础。在他的设想中，客户可以自行搭建并拥有这样一套系统。它能将编程智能体和审查智能体结合起来，并利用有关软件在生产环境中如何变化的知识。
Qodo 正与 OpenAI 携手，希望未来编程智能体能更充分地运用企业积累的经验，开发者也能把判断力用在最关键的地方。
