Build what's next on GitHub, the place for anyone from anywhere to build anything.
Join us October 28-29 in San Francisco or online for GitHub Universe, our flagship developer event uniting people, agents, and the world's code.
Nearly a billion commits later, the way we ship code has changed for good. Here’s what the 2025 Octoverse data says about how devs really work now.
If you’re building software today, you’ve probably noticed that it’s like… really fast now. And that’s the thing: it’s not just that we code faster. It’s how we code, review, and ship that has changed (and is changing).
You might have seen the Octoverse 2025 report, but in case you haven’t, the stats are pretty wild: developers created 230+ repositories per minute and pushed 986 million commits last year. Almost a billion commits! With a b!
Because developers (and teams of developers) are moving faster overall, the expectation is to make different choices because they’re moving faster. When they move faster, their workflows change, too.
Iteration is the default state
What’s really interesting is that this doesn’t feel like a temporary spike. It feels like an actual long-term shift in iteration. The days of shipping big releases once per quarter are rapidly going away.
Developers are pushing constantly, not just when things are “ready.” Smaller and more frequent commits are becoming more of the norm. Personally, I love that. Nobody wants to review a gigantic, 1000-line pull request all the time (only to inevitably plop in a “LGTM” as their eyes glaze over). It’s still more code, shipped faster, but in smaller bursts.
The new normal is lightweight commits. You fix a bug, write a small feature, adjust some configurations, and… push. The shift we’re seeing is that things continue to move, not that things are “done” in huge chunks, because “done”-ness is temporary!
“
ArtCode is never finished, onlyabandonediterated upon.”
Leonardo Da VinciCassidy, as well as most developers at this point
And devs know that shipping constantly is about reducing risk, too. Small, frequent changes are easier to debug, and easier to roll back if things go wrong. You don’t have to sift through a month’s worth of changes to get something fixed.This cycle changes how teams think about quality, about communication, and even hiring. If your team is still moving at a pace where they wait weeks to ship something, your team honestly isn’t working like a lot of the world is anymore.
Shipping looks different now
Because we’re iterating differently, we’re shipping differently. In practice, that looks like:
More feature flags: Feature flags used to be “for A/B testing and maybe the spooky experimental feature.” Now they’re core to how we ship incomplete work safely. Feature flags are everywhere and let teams ship code behind a toggle. You can push that “maybe” feature to prod, see how it behaves, and then turn it off instantly if something goes sideways. Teams don’t have to hold up releases to finish edge cases. And feature flags are more a part of main workflows now instead of an afterthought.
CI/CD runs everything: Every push sets off a chain of events: tests, builds, artifact generations, security scans… if it passes, it deploys. Developers expect pipelines to kick in automatically, and manual deploys are more and more rare.
Smaller, focused pull requests: Pull requests simply aren’t novels anymore. We’re seeing more short, readable pull requests with a single purpose. It’s easier and faster to review, and that mental overhead alone increases speed and saves us some brain cells.
Tests drive momentum: Developers used 11.5 billion GitHub Actions minutes running tests last year (a 35% increase! That’s with a b! Again!). With all this automation, we’re seeing unit tests, integration tests, end-to-end tests, and all the tests becoming more and more necessary because automation is how we keep up with the new pace.
How teams communicate should also change
We know it’s a fact now that developer workflows have changed, but I personally think that communication around development should also follow suit.
This is how I envision that future:
Yes, the code got faster, so developers have to move faster as well.
Developers are still a part of engineering speed. But developer workflows should never slow things down too much.
Take this with you
It’ll be interesting to see what developer workflows in 2026 look like after such rapid changes in 2025.
I think “AI fatigue” is incredibly real (and valid) and we’ll see many tools fall by the wayside, of course, as the natural productivity enhancers succeed and the ones that add friction go away. But I also think new standards and tooling will emerge as our new “baseline” for our ever-changing success metrics.
In the future, specs and code will live closer together (Markdown-to-code workflows are only going to grow). That will mean more communication across teams, and perhaps even more documentation overall. And we’ll continue to see more and more constant and collaborative shipping (even from companies that are still slow to adopt AI tooling) because it’s necessary.
This year, we’ve seen a lot of growth across the board in terms of pull requests, projects overall, contributions, and so on… so perhaps we’ll see some stabilization?
But, of course, the only constant is change.
Looking to stay one step ahead?
Read the latest Octoverse report and consider trying Copilot CLI.
GitHub Agentic Workflows are built with isolation, constrained outputs, and comprehensive logging. Learn how our threat model and security architecture help teams run agents safely in GitHub Actions.
