Maintainers Pay For Delivery, Not Code

In a May 3 blog post, Yegor Bugayenko argues that with AI able to generate working code cheaply, maintainers should pay contributors for reliable delivery rather than for raw coding time. Bugayenko recounts rejecting a pull request after an associated feature request had not been accepted, and he says the offended contributor "won't be back" (Bugayenko 2026). He writes: "For years you sold coding skill at $50 an hour. AI now codes for cents." The post defines a delivery as a merge-ready, well-documented, focused, and timely pull request and lists common failure modes that should be refused: missing descriptions, oversized PRs, unapproved features, and PRs that sit in review. Bugayenko frames the maintainer-contributor relationship as payment for trust in the delivery, not for the code artifact itself (Bugayenko 2026).
What happened
In a May 3 blog post, Yegor Bugayenko recounts rejecting a pull request whose related feature request had not been accepted and describes losing the contributor who submitted the PR. Bugayenko writes: "For years you sold coding skill at $50 an hour. AI now codes for cents." He argues that maintainers should pay for the delivery-a merge-ready, well-documented, focused, timely pull request-rather than for the raw code** (Bugayenko 2026).
Editorial analysis - technical context
Industry observers have noted that inexpensive AI code generation shifts the baseline value of a code artifact toward functional correctness, making nonfunctional aspects-tests, documentation, conformance to repository norms, and clear change descriptions-the differentiators that determine whether maintainers can merge without rework. For practitioners, this increases the importance of automated quality gates, review checklists, and small, well-scoped changes that reduce human review cost.
Context and significance
Companies and open-source projects that previously accepted noisy contributions because human coding capacity was scarce now face a wider supply of low-cost generated code. This dynamic raises the bar for contributor processes: projects can be selective about who they accept, and contributors must deliver packages that save reviewer time rather than merely compile.
What to watch
Indicators include stricter repository contribution guidelines, wider adoption of CI gates that enforce reviewability, and marketplace models that explicitly pay for verified, merge-ready delivery rather than hourly coding. Observers should track whether projects formalize delivery metrics and how contributor retention responds.
Scoring Rationale
This is a notable commentary on contributor economics that frames practical changes for maintainers and contributors. It is relevant to practitioners managing repositories, but it is opinionated commentary rather than a new tool or benchmark.
Practice interview problems based on real data
1,500+ SQL & Python problems across 15 industry datasets — the exact type of data you work with.
Try 250 free problems
