3 ms·

Seems to me the real question is "what scheme can we use to organize our code base such that an agent working on one part really can make changes and not break

Seems to me the real question is "what scheme can we use to organize our code base such that an agent working on one part really can make changes and not break the other parts on accident". My current theory I might test out is to treat generative AI as generative AI. This means instead of editing things like a microservice in place you version freeze them to bug fixes only and create new versions for new features. This way you can go and update all the places that use the old version to the new version one at a time. As you do you can check that the new version does not break anything while still having an old version to fall back to.

kstenerud 2mo ago
This would presuppose only a single new version being "in-flight". But a microservice change often bleeds into another microservice having to change. Multiply this by all the agents working on the product, and you get a very complicated release process for those microservices. The ripple effects are basically the same as what you'd get in a monolithic codebase. In fact you can still think of a set of microservices as a single codebase, just not centrally maintained anymore. The complexity is moved rather than eliminated. And you'll still have agents (and people) stepping on each other if there's too little coordination.
- jatora 2mo ago
  More coordination is exactly what the commenter was proposing though so I dont really see the point in your response.
- pianopatrick 2mo ago
  Right but if you coordinate those changes in a new version you would still have the old version to fall back to if any of those changes lead to problems.
  - kstenerud 2mo ago
    Yes, but then there's a trap lurking nearby: As different versions of the same function proliferate, it muddies the waters, because you now have multiple parts of your system calling a similar-but-not-quite-the-same function. Your refactors are never complete, and you find yourself less able to properly reason about the system as a whole anymore. The payment and subscription systems call different versions of the same function, which works most of the time but they don't always agree. With a lot of discipline and process control, one could make such a system work, but it's most definitely not a free lunch. The complexity has to go somewhere.
    - pianopatrick 2mo ago
      Yes, I agree half finished refactors are bad. But I think with AI the timing is a bit different now so the best plan changes. I.e. AI can finish various steps in generating the new version and transitioning to the new version much faster than people could in the past. So you are unlikely to end up with lots of half finished refactors because AI can finish them fast. The bigger problem now is handling the AI mistakes and failures, not slogging through all the steps of a refactor. So having a full and complete ready to go fallback version with like Blue / Green deploys might be really helpful. But to do that you need discrete versions, not digging through diffs to find the problem and redeploy. But this is all just a theory I haven't tested right now.
honr 2mo ago
This has been one of the billion(s) dollar questions of 2026. There have been a few approaches emerging throughout the year (heuristics to hard-divide work, using better languages with dependable contracts, task management protocols, and organizational agent roles). None has won so far, though, but some appear (or claim) to be close.
zelphirkalt 2mo ago
How does this freezing version and new version and so on differ from having the code in a version controlled repo?
- pianopatrick 2mo ago
  It would be more about the release cadence and strategy. I.e. instead of deploying to production as fast as possible after merging new code, have discrete releases. Like maybe daily, weekly or monthly. And keep the last couple releases around ready to roll back as fast as possible if there are issues with the new release

kstenerud 2mo ago

This would presuppose only a single new version being "in-flight". But a microservice change often bleeds into another microservice having to change. Multiply this by all the agents working on the product, and you get a very complicated release process for those microservices. The ripple effects are basically the same as what you'd get in a monolithic codebase. In fact you can still think of a set of microservices as a single codebase, just not centrally maintained anymore. The complexity is moved rather than eliminated. And you'll still have agents (and people) stepping on each other if there's too little coordination.

jatora 2mo ago
More coordination is exactly what the commenter was proposing though so I dont really see the point in your response.
pianopatrick 2mo ago
Right but if you coordinate those changes in a new version you would still have the old version to fall back to if any of those changes lead to problems.
- kstenerud 2mo ago
  Yes, but then there's a trap lurking nearby: As different versions of the same function proliferate, it muddies the waters, because you now have multiple parts of your system calling a similar-but-not-quite-the-same function. Your refactors are never complete, and you find yourself less able to properly reason about the system as a whole anymore. The payment and subscription systems call different versions of the same function, which works most of the time but they don't always agree. With a lot of discipline and process control, one could make such a system work, but it's most definitely not a free lunch. The complexity has to go somewhere.
  - pianopatrick 2mo ago
    Yes, I agree half finished refactors are bad. But I think with AI the timing is a bit different now so the best plan changes. I.e. AI can finish various steps in generating the new version and transitioning to the new version much faster than people could in the past. So you are unlikely to end up with lots of half finished refactors because AI can finish them fast. The bigger problem now is handling the AI mistakes and failures, not slogging through all the steps of a refactor. So having a full and complete ready to go fallback version with like Blue / Green deploys might be really helpful. But to do that you need discrete versions, not digging through diffs to find the problem and redeploy. But this is all just a theory I haven't tested right now.

honr 2mo ago

This has been one of the billion(s) dollar questions of 2026. There have been a few approaches emerging throughout the year (heuristics to hard-divide work, using better languages with dependable contracts, task management protocols, and organizational agent roles). None has won so far, though, but some appear (or claim) to be close.

zelphirkalt 2mo ago

How does this freezing version and new version and so on differ from having the code in a version controlled repo?

pianopatrick 2mo ago
It would be more about the release cadence and strategy. I.e. instead of deploying to production as fast as possible after merging new code, have discrete releases. Like maybe daily, weekly or monthly. And keep the last couple releases around ready to roll back as fast as possible if there are issues with the new release