4 ms·

I have found what works well is to modularise the code as much as possible and get an agent to work within a very limited scope. Break everything down well usin

I have found what works well is to modularise the code as much as possible and get an agent to work within a very limited scope. Break everything down well using SRP with well defined interfaces and let the agent work on small problems. Then when it shits the bed, there’s a smaller blast radius and you can strip back and try again. I think seasoned developers, over time, learn how to work a code base and design components with well defined interfaces, where the implementation is isolated in small well contained classes. SRP etc. more junior programmers can work on those smaller components/services in isolation. For me this also seems to be a productive way to work along side an agent. Break up functionally into well defined chunks, and let the agent work on each small problem. Take more of a lead in the architecture I suppose.

jbstack 1mo 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 1mo ago
  I 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 1mo ago
    My 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 1mo ago
  I 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 1mo ago
    Yes, 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 1mo ago
      Exactly. 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.

jbstack 1mo 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 1mo ago
I 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 1mo ago
  My 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 1mo ago
I 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 1mo ago
  Yes, 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 1mo ago
    Exactly. 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.