Waiting on AI costs your team practice. Every recurring assignment is a chance to learn where an AI draft goes wrong, which corrections hold, and what the reviewer needs before saying yes. Start with something low-risk. Buying the same software as a competitor six months from now will not give you its history of corrections.

GitHub’s October 28 Octoverse report puts numbers behind the change. By September, more than 40% of proposed code changes on GitHub began with an agent’s draft, up from 17% in March. GitHub calls these pull requests. Someone submits a proposed change; reviewers decide whether it belongs in the project. Starting a proposal says nothing, on its own, about whether the finished software helps the business.

In brief

Give one recurring assignment a reviewer and keep a record of the corrections. Then check the next attempt. Does the same mistake come back? How much work does the reviewer still have to do before the result is usable? Count that effort alongside the drafts.

Read the activity numbers carefully

One finding in the report deserves care. New projects containing an agent configuration file recorded eight times as many saved code changes, on average, as new projects without one.

Eight times the activity. We do not know from that comparison whether agents caused the difference, whether the projects were comparable, or whether the extra changes helped anyone. Projects without a configuration file may still use AI.

I would leave that multiplier out of a business case and go talk to the people receiving the work instead. If substantially more proposals arrive, can they still examine them properly? Where does the queue build up?

Imagine a marketing department where generating campaign variations becomes quick enough that every meeting starts with another dozen options. Someone still has to choose. A dozen plausible variations can be a miserable use of a good reviewer’s afternoon if none answers the brief.

That example is hypothetical; GitHub’s data does not establish a marketing outcome. It gives a business leader somewhere to look, though: at the desk where all those drafts arrive.

There is a second learning curve

Requesting a draft takes practice. So does spotting the persuasive one that misses the assignment, especially when it reads well enough to survive a hurried review.

For that marketing team, I would want the reviewer to save the reason for a rejection. “Promises a feature we don’t sell” is useful. So is “accurate, but any of our competitors could say this.” They call for different corrections. “Make it better” leaves the next person guessing.

This is where I think a team can build an advantage. Save an accepted brief beside a rejected one, with the reason, and you have something a new reviewer can study and the next AI attempt can be checked against. Throw the corrections away and you have to explain them again.

GitHub’s Universe announcement, also published October 28, describes automations that learn from outcomes and propose improvements for people to approve. That is a product description, not independent evidence of a productivity gain. I would ask to see which correction survived into the next run.

Acceptance is not the same as impact

GitHub reports that 90% of agent-involved proposals in September were incorporated within two weeks, compared with about 86% of proposals without detected agent involvement. Acceptance is worth measuring. So are repairs after release and whether customers use what shipped. Ask your tech lead to keep those measures separate.

METR’s July 2025 study offers a useful example of how to test a productivity claim. Researchers randomly allowed or disallowed AI on 246 real assignments supplied by 16 experienced developers. They measured the work rather than relying only on impressions of speed.

METR has since published new data on late-2025 tools. I would not use the early-2025 study to judge today’s tools; I would borrow its insistence on testing them under actual working conditions.

Your team does not need to run a research project. Record the time through review and any repairs, then check whether the result was used. Compare reasonably similar assignments. If the comparison is messy, say so.

Give the next month a learning objective

I would start with a weekly internal campaign brief, assuming its reviewer already knows what an acceptable one looks like. Use approved materials. Keep customer-facing publication outside the trial.

Before starting, save an accepted example and write down what would make a new brief unusable. After each attempt, record the correction that mattered most. Update the instructions if that would help, but test the correction on a different brief before calling it learned.

A month later, put the early and recent attempts in front of the reviewer. Ask where the work got easier and where they are still making the same repairs. If nothing has improved, keep the trial small until you understand why.

That is the test I would set for human-AI collaboration. Next month’s reviewer should not have to explain the same product promise all over again.

Research and draft: Mai. Editorial direction: John Lipe.