I agree with this to some degree. Agents often stub and take shortcuts during implementation. I've been working on this problem a little bit with open-artisan which I published yesterday (https://github.com/yehudacohen/open-artisan).
Rather than having agents decide to manage their own code lifecycle, define a state machine where code moves from agent to agent and isolated agents critique each others code until the code produced is excellent quality.
This is still a bit of an token hungry solution, but it seems to be working reasonably well so far and I'm actively refining it as I build.
Not going to give you formal verification, but might be worth looking into strategies like this.
Author here, and I mostly agree with this sentiment. With that said, part of my Kiro spec here, had Kiro read my other blog posts and attempt to emulate my style.
I too found the write-up to be a little dry and long-winded, even though the same critique might be leveled at myself [hopefully to a lesser extent]. I did feel like it was a good step up from the usual AI slop out there, and served to illustrate Kiro's capabilities.
I suppose in this context, I wanted to see whether I could take my reader on a journey long enough for them to be surprised by the AI reveal at the end. I'm not sure whether it achieved that but that was the artistic intent of this specific piece.
I absolutely agree with the first part of this advice.
As to the assertion that complexity is not worth worrying about, I could not disagree more. I have watched projects fail time after time because of complexity, dependencies, and lack of budget.
Managers should encourage their engineers to spend time trying to simplify architecture and reduce code, infrastructure, and package dependencies. Smart engineers can learn to think simply over time, but this will not happen automatically. (I plead guilty to gravitating toward complexity in the early part of my career, but I have since learned better.)
Managers should place emphasis on using existing patterns wherever possible rather than re-inventing the wheel. Practicing laser focus on delivering value, evaluating solution dependencies with an eye to keeping things simple, and accurately modeling the problem domain in question.
Rather than trying to fight with engineers about implementation approaches, managers should try to guide engineers toward arriving at these conclusions themselves. I have also found that stressing simplicity as a key performance metric for engineers is a useful tool.
> I have also found that stressing simplicity as a key performance metric for engineers is a useful tool.
Some of the smartest engineers I've ever worked with produce code that is so well crafted it feels simple when you look at it, but it's actually extremely clever.
I think the conversation about "clever", "smart", "volatile" programmers tends to align the axis of _code_ complexity with cleverness, but often the cleverness is in finding the perfect simple solution.
"Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better." -- Edsger W. Djikstra
Complexity sells better because it's cheaper. This is not the, "look at this novel abstraction I wrote and proof of its correctness with respect to our specifications," kind of "complexity" that folks often mean. It's the hand-waving, just add the simplest patch you can to make it work for the business problem at hand, type of complexity. The kind of complexity that ends up with giant balls of "really simple" code that nobody understands entirely anymore.
It sells better for all the usual reasons that driving slightly over the speed limit gets you where you're going a little faster. It's only a problem if you get caught or cause a collision.
Your comment touches on the awol concept of clarity in this conversation: "The quality of being coherent and intelligible".
Balls of mud are the very essence of simplicity (in one sense) yet lacking any clarity.
Clarity is a (bad sort of) hot commodity in an immature yet rapidly developing technical field. In our field this is exacerbated by the fact that the entire field can be viewed as a monument to the peter principle (but thankfully the imposter syndrome is there as a collective salve for us all.)
I think highly intelligent engineers that can penetrate the essence of a problem and come up with effective & coherent conceptual models are a valuable but (in places) untimely assets. My recommendation to such engineers (who also wish to be responsible team members) is to recognize the cognitive impedance mismatch and broaden the 'scope' of the solution to include the human element, and descend to norm if necessary. The ultimate goal is to serve a broader goal, and fighting against impedance mismatch is un-/counter-productive.
My personal red line is the 'big ball of mud' teams.
Rather than having agents decide to manage their own code lifecycle, define a state machine where code moves from agent to agent and isolated agents critique each others code until the code produced is excellent quality.
This is still a bit of an token hungry solution, but it seems to be working reasonably well so far and I'm actively refining it as I build.
Not going to give you formal verification, but might be worth looking into strategies like this.
reply