Claude Code+Gemini CLI
我不“氛围编码”，“我只是向AI提问并迭代”的想法让我很烦躁，除非我是在创建一个演示。然后它还算可以，但一个好的演示几乎总是会被要求继续前进，这意味着“氛围编码”之后就是“技术债务”。所以当Dan向我推荐Claude Code，并说它会改变游戏规则时，我有点怀疑。
然后我用了它。我不通过“氛围编码”来工作，我会思考问题，分解它，然后与Claude Code一起处理各个部分。我们共同构建应用程序，就像有一个出色的初级开发者一样，它会提出好的建议，生成好的代码，但很多时候你必须指出更好的架构方式，这将更好地支持增量开发和未来的变化。我喜欢的另一点是，你可以让它审查自己的代码，让它识别漏洞和缺陷，甚至明确说明代码是由安全威胁编写的，所以我们需要仔细审查。
所以当Gemini CLI发布时，我必须尝试一下以进行比较，而这就是我意识到的时候。
我的开发团队中有两个AI
在第一次将Claude与Gemini CLI放在同一个问题上进行测试时，两者都表现不错，但我会给Claude一点优势，因为质量、方法以及我需要提供的反馈更多。然而，当我把它们都指向同一个仓库时，这个仓库是Claude创建的代码，我让Gemini CLI：
请审查这段代码，我希望你检查文档与代码的一致性，并找出差距、问题以及特别的重构机会
Gemini开始运行并返回了一些建议，我让它把这些建议写入一份评审文档。然后我对一个新的Claude会话说：
我刚刚得到了一段代码的评审，并做了一些评论和建议，你能读取这份评审，然后查看代码，看看你同意什么，不同意什么，并确定其他你应该考虑的选项。
在我忙于其他工作的同时，他们不断更新这个文件，在几次迭代后，两者都说根据需求和文档，他们对所推荐的评审感到满意。
然后我让Gemini实施这些更改。
并让Claude审查Gemini所做的更改，以确保符合评审意见，我让它将它认为没有正确完成或被遗漏的部分附加到评审文件中。
然后我让Claude编写代码，Gemini进行评审。
经过几个循环后，两者都完全满意。
代码非常棒，它运行良好，文档也很完善。
我没有“氛围编码”，我是架构师，我定义了结构，我的两个开发者在这个结构内进行开发。他们比一些开发者需要更少的反馈，关于使用哪些框架或git中的正确分支策略。他们非常出色地遵循了我的规则。
我特别喜欢的是，他们倾向于给出不同的评审意见和风格，Claude经常关注更概念性的问题，而Gemini则常常在格式和结构方面做得更好。但总的来说，这两个一起工作的迭代是关键。
开发的未来在于思考
这意味着什么？这意味着我其实并不关心哪一个更好，因为作为团队，他们绝对是更好的。我可以使用Opus和Sonnet来做同样的事情吗？可能，但那真的只是同样的工作方式，拥有两种视角，我并不是在两者之间选择，而是相互利用。
在过去24小时里，我在其他领域同时使用它们时，它们有时会互相强化，然后我突然意识到“等等，他们做错了”，所以我纠正了它们的错误，然后它们就朝着新的方向发展。
在这个过程中，我的角色是进行最初的分解，设定边界和方法，并制定流程，让他们一起定义“什么”和“如何”再进入代码。虽然敏捷价值观强调工作代码胜过文档，但这些代理开发者在进入代码之前让他们做文档有着巨大的价值。
这感觉像是一种新的软件开发方式，它不仅仅是“感觉编码”，它超越了这一点。
汇智网翻译整理，转载请标明出处