8 ms·
This is fundamentally a scaling problem, not a tooling problem. When AI generates PRs that no single person can fully grasp, the question isn't "how do we make
by funkattack 7mo ago
This is fundamentally a scaling problem, not a tooling problem. When AI generates PRs that no single person can fully grasp, the question isn't "how do we make reviewing 5,000 lines more comfortable" – it's "who is actually vouching for this code?"
The answer is already deeply embedded in Git's tooling: every commit carries both an author and a committer field. The author wrote the code, the committer is the person who put it into the codebase. With git blame you always know who is to blame – in both senses. In the age of AI-generated code, this distinction matters more than ever: the author might be an LLM, but the committer is the human who vouches for it.
Disclosure: non-native English speaker, used AI to help articulate these thoughts – the ideas are my own.
- moritzwarhier 7mo agoSo who authored your comment? What would you put into the commit message fields if it were a git commit?
- funkattack 7mo agoCurrently you'd read quite a lot of: "Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>"
- moritzwarhier 7mo agoAh, co-authored, but that's different thing, isn't it? Tbh I only know it from squashed PRs. However: > "Co-author" is not a git concept. It is a convention in commit messages used by some services, including GitHub. So, the solution is to edit the actual commit message with git commit --amend and add a line to the end: https://stackoverflow.com/a/64311381 https://stackoverflow.com/a/64311381
- funkattack 7mo agoIt's a door opened by git (interpret-trailers), walked through by GitHub with the Co-authored-by key and UI support, GitLab followed.