Ask HN: How to organize teams to ship AI-written code?
In our company we still try to play by the (old) book: backlogs, estimates, iterations, feature teams, PR reviews, etc., but the entire thing leaks everywhere you look. There is no point in many of the old rituals, but it is also not clear how to organize ourselves now. This is different, albeit closely related, from the question of how to adjust as an IC.
For example:
- In our team, we almost don't see the point in PR reviews anymore, not in the old way anyway. Generated code is always good enough, and in a sense is already reviewed once by the developer who signed off (the topic is discussed in [1]). So, we are now thinking to abandon PRs, or change what we review and how we do it. We are adding more rules for code review agents and to CI. We are also thinking to replace code reviews by "concept reviews" or similar.
- Speaking of those, we still try to find the right place and a process for architecture and specifications reviews. They seem to become a new subject of PR reviews in fact, but we are not there yet.
- In many places we don't see the need to share the workload and knowledge between multiple developers. Reverting to the model where one developer is responsible for an entire component seems viable again. Although we are naturally worried about BusFactor=1.
- Some Agile-inspired practices still work for us, namely iterative development and "deploy when ready". But the development process itself starts to resemble the old-school waterfall-ish one: think everything through, write down your constraints and your specs, design the architecture first, then (re)generate the code at will. I wonder what other practices will go away or get adopted.
There are probably more examples, hopefully you get the gist. I am very interested in discussing how do we organize the teams now? What did you try? What works, what doesn't?
[1] https://news.ycombinator.com/item?id=50151036 (Ask HN: How to deal with shipping AI-written code you don't understand?)