战术编码助手
[
[
Over the past 15 months I have been actively working with LLM’s in my job as a software engineer. I have had many moments where I thought singularity was here, but then almost immediately after I would see the agent fall flat on its face. I have become interested in figuring out when and why these new tools fail, in the hope that it can help me use these tools to their maximum potential while still keeping control over the quality of what I commit. In this short article, I want to expand on a recent observation.
在过去的15个月里，我作为软件工程师积极与LLM合作。我经历了许多时刻，认为奇点已经到来，但几乎在那之后，我会看到代理人跌倒在地。我开始对这些新工具失败的原因和时机产生兴趣，希望这能帮助我在保持对我所提交内容质量的控制的同时，充分利用这些工具。在这篇短文中，我想扩展一下最近的观察。
Generated using Gemini Imagen 4
使用Gemini Imagen 4生成
In the book ‘A Philosophy of Software Design’ by John K. Ousterhout, a great analogy is made between two different modes of development: tactical and strategic programming.
在 John K. Ousterhout 的书《软件设计的哲学》中，做了一个很好的类比，比较了两种不同的开发模式：战术编程和战略编程。
Tactical programming: this is a shortsighted approach focused on completing the immediate task as quickly as possible. Here, the primary goal is to make a feature or bug fix work in the most direct way. You can imagine what will happen if you have a team of engineers that only works like this: technical debt will pile up fast.
战术编程：这是一种目光短浅的方法，专注于尽快完成当前任务。在这里，主要目标是以最直接的方式使某个功能或修复程序有效。你可以想象，如果你有一个只这样工作的工程师团队，会发生什么：技术债务将迅速积累。
Generated using Gemini Imagen 4
使用 Gemini Imagen 4 生成
On the other side there is strategic programming: this involves a higher level of thinking. A strategic programmer is not finished when the feature is implemented. They take a step back and review the architecture, to see if any abstractions can be made. Does the current approach overcomplicate things? Can we refactor things? The focus here is on design, where the engineers mai...