My perspective is to figure out how to shape the way we use AI to show the right way to use it. This comes from a place of caring about the software and its users.
I strongly believe that when used properly, AI can remove a lot of overhead that comes with writing the code (from both a critical thinking standpoint and physically it actually takes a lot more time than people realize to manually type code). You can focus on the design and have your team much more integrated in the designs and specifications of things without it being a slog to document the damn thing.
If I can go off and write up a draft and get feedback from my team in a day instead of in a week, I think that's fine. We can collectively walk through and use everyone's domain knowledge to correct details. Once everyone is onboard with the spec, I can feed that into a model to progressively do small changes rapidly but in such a way that's still manageable and reviewable for myself and the rest of my team.
If I go off and merge 45000 lines of code into main: fucking fire me and my whole team that approved that.
As with all new things that have extreme views on either side (AI is complete shit versus AI is the second coming of Christ in this case), there's generally a middle ground in between that we can collectively correct toward.
Oh I agree! However, while they do brag about 30,000 PRs per day, they don't state what products these apply to.
I suspect for their public facing products (i.e., the claude ecosystem, which is like four products), the review process is much more rigorous, and the PRs merged in per day is likely much much lower.
A few things about their post: they're doing trunk development on a mono-repo. With their tool, Antique, instead of having branches, they just merge in stacks of commits, which they call "Change Requests". I have to wonder if their engineers have the models running and don't even realize the models are putting up a change request and if that's contributing to the high number.
Additionally, I would guess that a lot of the code merged into that mono repo is for experimental projects or other internal tooling that is in prototyping stage.
I strongly believe that when used properly, AI can remove a lot of overhead that comes with writing the code (from both a critical thinking standpoint and physically it actually takes a lot more time than people realize to manually type code). You can focus on the design and have your team much more integrated in the designs and specifications of things without it being a slog to document the damn thing.
If I can go off and write up a draft and get feedback from my team in a day instead of in a week, I think that's fine. We can collectively walk through and use everyone's domain knowledge to correct details. Once everyone is onboard with the spec, I can feed that into a model to progressively do small changes rapidly but in such a way that's still manageable and reviewable for myself and the rest of my team.
If I go off and merge 45000 lines of code into main: fucking fire me and my whole team that approved that.
As with all new things that have extreme views on either side (AI is complete shit versus AI is the second coming of Christ in this case), there's generally a middle ground in between that we can collectively correct toward.
So the very company you're (possibly) using to "remove a lot of the overhead" is doing what you think is fireable! That's the irony!
¹https://www.anthropic.com/research/redesigning-source-contro...
I suspect for their public facing products (i.e., the claude ecosystem, which is like four products), the review process is much more rigorous, and the PRs merged in per day is likely much much lower.
A few things about their post: they're doing trunk development on a mono-repo. With their tool, Antique, instead of having branches, they just merge in stacks of commits, which they call "Change Requests". I have to wonder if their engineers have the models running and don't even realize the models are putting up a change request and if that's contributing to the high number.
Additionally, I would guess that a lot of the code merged into that mono repo is for experimental projects or other internal tooling that is in prototyping stage.