{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreieytvo6hsbju4hwpjz7aiux3hl4vcwtaazah75j5i5myy2uygyqba",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mfhy5a4dtrz2"
  },
  "path": "/t/contributor-responsibility-and-review-cost-in-the-age-of-code-generation/24010#post_12",
  "publishedAt": "2026-02-22T19:38:16.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "kornel:\n\n> when I change something, I usually want to refactor the codebase first to make the change simpler/cleaner afterwards. For example, instead of adding nearly-duplicate code, I first extract common code into helpers. Or if new feature makes something fallible, I'll need error handling plumbing in the code around it. The problem is that the groundwork often doesn't make sense as a standalone PR. The motivation for changes is unclear without the addition that follows. If I just submit the groundwork, it gets rejected as a pointless change for the sake of change. However, if I submit refactorings plus a new feature together, I often get told off for changing unnecessary stuff at the same time, and not splitting PRs into small enough pieces. This motivates making changes minimal in the number of lines changed in the diff.\n\nI tend to do this by having one PR with multiple commits, and explicitly saying in the PR description \"this is best reviewed commit-by-commit, rather than all at once\".\n\nI do wish, though, that forges like github had better support for sending multiple PRs with interdependencies. And I _especially_ wish that you could comment on individual commits and make suggestions there rather than only on the complete diff.",
  "title": "Contributor Responsibility and Review Cost in the Age of Code Generation"
}