6 ms·
I think this is the only sensible way to work with agents, if you care about code quality and reliability but still want the benefits of AI. There seem to be th
by jbstack 24d ago
I think this is the only sensible way to work with agents, if you care about code quality and reliability but still want the benefits of AI. There seem to be three camps that people more or less fall into: (a) AI is terrible/bad/evil and should never be used, (b) you should one-shot everything and be happy if it seems to "work" when you try it, (c) the middle ground, where the AI writes code which you carefully review.
I definitely prefer (c). But I get why (b) can feel necessary. If your competition is using (b) there can be pressure to do the same just to keep up.
- dave_sid 24d agoI think c is the only way it can sustainably work. The idea of b, that software is running and nobody there knows how it works, doesn’t seem like a good foundation for a business to run on.
- bonesss 24d agoMy personal challenge is that if c, generate then review, isn’t pretty close to a one-shot then I am almost certainly negative for time versus creating from scratch (accounting for over-documenting, prompting, and enforced pauses for generation). The sunk cost fallacy bites and then bites again and again.
- zahlman 24d agoI think it must depend at least partially on the task, too. At the extreme, there are things where you won't care beyond "it seems to work" because you only needed it to run once and it got useful results.
- globular-toast 24d agoYes, but all the "don't care" stuff needs to be inside a "don't care" module. For example, I don't actually care about GUI code. I just need "pressing this button emits this event or callback etc". If the GUI module interface is well defined then it doesn't matter how it's implemented as long as it works. The problems start when you don't have clean separations. If your GUI code is also implementing ad hoc business logic like policies and workflows etc then you won't know what you care about and what you don't. So you need to build little ring fenced enclaves where you can say "do whatever you want to implement this interface with this behaviour". If it gets fucked up you could just throw away the whole module and start again.
- dave_sid 24d agoExactly. I think this is it. Clearly separate what must be perfect and well understood (security, business logic), from bits that you are happy to throw some code at and see if they work. And don’t let the latter get its hands on the former. I think going back to OOP principles and SRP/separation of concerns can make this work. Just some conscious planning needed rather than handing over the reins entirely.