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! “Art Code is never finished, only abandoned iterated upon.” Leonardo Da Vinci Cassidy, 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: Standups are shorter (or async). Status updates live in issues (and “where code lives,” not meetings). “Blocked because the pull request isn’t reviewed yet” is no longer acceptable. Hiring shifts toward people who can ship fast and communicate clearly. 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. The post What 986 million code pushes say about the developer workflow in 2025 appeared first on The GitHub Blog. ​ News & insights, Octoverse, agentic workflows, CI/CD, developer productivity, developer workflows, feature flags, GitHub Actions, modern developer practices, pull requests The GitHub Blog

As engineers at GitHub, “dogfooding” is core to our culture. We build GitHub on GitHub, using the same tools we ship to developers. But as GitHub Copilot has evolved from an autocomplete suggestion to a sophisticated AI assistant, our own use of it has evolved, too. It’s no longer just a tool in our editors. We’ve integrated Copilot directly into our development lifecycle. Inside our core repository, the one we use to build github.com, @Copilot isn’t just suggesting code; it’s an active contributor. It gets assigned issues by human engineers, opens pull requests, and does the work assigned. Copilot is a prolific engineer within GitHub, and it’s taking on some of our most time-consuming and tedious tasks. For this article, we analyzed a month of pull requests created within our core repo by Copilot. Here’s what we found. Copilot does simple work that saves time Before we get to the complex, architectural work, it’s worth noting how much of Copilot’s day-to-day work is about accelerating the small tasks that add up. These are the quick fixes that save engineers from constant context-switching. UI and copy tweaks: It gets tasked with fixing minor UI bugs, like realigning a misaligned icon, or updating placeholder text in a filter bar to be more accurate. Documentation and cleanup: It also handles straightforward cleanup. In one pull request, @Copilot was assigned to fix 161 typos in comments and documentation strings across 100 different files. It’s a simple task, but one that no human engineer wants to spend an afternoon doing. Critical cleanup and maintenance A healthy codebase requires constant care. This is where @Copilot shines. A significant portion of the pull requests were focused on code maintenance, modernization, and large-scale refactors that would have been time-consuming for human engineers, including: Removing feature flags: This is a huge one. @Copilot is constantly assigned to clean up deprecated feature flags, removing the conditional logic, stale code, and old tests across the entire codebase. Large-scale refactoring: When we need to rename a class used across the application, @Copilot can take it on. It’s even authored massive, repository-wide pull requests to rename core internal classes, a task that would be tedious and time-consuming for any developer. Performance optimization: It finds and fixes common performance anti-patterns, replacing inefficient code with more optimized alternatives in high-traffic areas. Fixing bugs and flaky tests @Copilot also helped us solve a number of bugs. It’s patched production issues and improved the stability of our CI/CD pipeline. Production errors: It’s not just fixing simple bugs; it’s resolving tricky NoMethodError issues in core logic and even fixing complex error masking issues in our caching infrastructure. Performance bottlenecks: One of its most impactful contributions was a pull request that fixed a severe performance issue where git push was taking ~15 minutes for engineers in Codespaces. Fixing flaky tests: We all know the pain of a test breaking a build. @Copilot was regularly assigned to investigate and fix them. Building new features This is where it gets really interesting. @Copilot isn’t just maintaining old code; it’s actively building new functionality. Human engineers spec out the work in an issue, assign it to @Copilot, and it gets to work. It’s adding: New API endpoints: One pull request added a new REST API endpoint to list repository security advisory comments. New internal tools: It’s not just adding production features. Copilot has been extensively used to improve our internal tools. Our internal intranet, training sites, onboarding, etc. All of these have been maintained significantly by Copilot.  Migrations and security Beyond daily tasks, we’re also assigning @Copilot to high-stakes, complex projects that are critical for the platform’s future. Security gating: @Copilot has been tasked with adding security gates to prevent our own internal integrations from performing sensitive actions, such as modifying releases or release assets. Database migrations: It’s even handling database schema migrations. We’ve assigned it critical, high-precision tasks like migrating column types to support new standards. Documentation creation: It’s used to keep documentation in sync with fast-moving code. For example, it has authored numerous pull requests to add comments to our rate-limiting code to ensure developers easily remember to keep it synchronized with another service. Codebase-wide audits and analysis: Discerning problems, then solving them In some of its most advanced tasks, @Copilot acts as a researcher. We can assign it an ambiguous task, and it will analyze the codebase and report back with its findings in a pull request. In one pull request, it was tasked with auditing all our Codespaces feature flags. It returned a pull request with a comprehensive report categorizing all the flags and their references throughout the code. In another, it performed a “comprehensive analysis of authorization queries” to identify opportunities for performance and safety improvements. This moves Copilot’s role from code generation to systems-level architectural analysis, helping developers to jump straight to solving a complex problem rather than spending days just identifying it. A new way to collaborate If you check Copilot’s merged pull request rate in your repo, you’ll notice it’s lower than human contributors. That’s expected—and useful. Here’s the pattern we discovered: You assign @Copilot an issue It opens a pull request with a first-pass solution You review it like any other pull request Then you choose to merge it, iterate on the branch, or close it and take a different approach. The value isn’t in blindly merging. It’s in not starting from zero. You’ll get a concrete implementation to critique right away. All the boilerplate and the basic scaffolding is already handled. This shifts our focus away from writing all the code. Instead, you get to jump straight to the most critical parts of engineering: solving the core problem, refining Copilot’s suggestions, working in areas of the codebase not fit for AI, and owning the architecture, security, and user experience. It’s not about automating our jobs; it’s about letting Copilot handle the tedious 80% of the work. This frees us up to dedicate our expertise to the critical 20% that truly matters.

When people talk about AI and software development, the focus usually lands on productivity: faster pull requests, fewer boilerplate chores, auto-generated tests, autocomplete that feels psychic. But according to Idan Gazit, who leads GitHub Next—the team behind Copilot and GitHub’s long-range R&D—that’s the shallow end of the change curve. The deeper shift is happening before a single line of code is written. “AI isn’t just changing how we write code,” Gazit says. “It’s starting to change what we choose to build with in the first place.” That shift is already visible in this year’s Octoverse report. In 2025, TypeScript overtook both JavaScript and Python as the most-used language on GitHub—a 66% year-over-year surge and the biggest language movement in more than a decade.  But the story isn’t “TypeScript beats Python.” It’s that AI is beginning to shape language trends from the inside out. The last generation of change was about where code runs: cloud, containers, CI/CD, open source ecosystems.The next one is about what code is made of, and why those choices suddenly have different stakes. TypeScript passed Python. But the real story is why. Developers don’t usually switch languages just for philosophical reasons—they switch when something makes their work meaningfully faster, simpler, or less risky. And increasingly, what feels “easier” is tied to how well AI tools will support their work with that language. “Statically typed languages give you guardrails,” Gazit says. “If an AI tool is going to generate code for me, I want a fast way to know whether that code is correct. Explicit types give me that safety net.” Typed languages reduce hallucination surface area. They also give models more structure to reason about during generation. That’s not a theoretical benefit. It’s now a behavioral signal in the data: AI models tend to perform better on languages which expose information about correctness, like a type system Developers using AI tools are more likely to adopt typed languages for new projects The more teams rely on AI assistance, the more language choice becomes an AI-compatibility decision, not merely a personal preference That shift sets up a feedback loop. AI assistance is a new consideration when developers are selecting languages and frameworks AI models are strongest at authoring code in popular languages: TypeScript, Python, Java, and Go, just to name a few. “If the model has seen a trillion examples of TypeScript and only thousands of Haskell, it’s just going to be better at TypeScript,” Gazit says. “That changes the incentive before you even start coding.” If an AI tool is going to generate code for me, I want a fast way to know whether that code is correct. Explicit types give me that safety net. Idan Gazit, head of GitHub Next Before AI, picking a language was a tradeoff between runtime, library ecosystem, and personal fluency. After AI, a new constraint appears: How much lift will the model give me if I choose this language? “Python is the dominant language for machine learning, data science, and model training,” Gazit says. “Why would I not choose the one that already has the most robust frameworks and libraries? Those are wheels I don’t need to reinvent.” So TypeScript isn’t winning against Python; each is winning in the situations where it is the right tool for the job, and where AI makes it more valuable. The surprise winners of the AI era: the “duct tape” languages One of the most unexpected signals in the Octoverse data wasn’t about TypeScript or Python—it was about Bash. Shell scripting saw +206% year-over-year growth in AI-generated projects. So what gives? Because AI makes painful languages tolerable. “Very few developers love writing Bash,” Gazit says. “But everybody needs it. It’s the duct tape of software. And now that I can ask an agent to write the unpleasant parts for me, I can use the right tool for the job without weighing that tradeoff.” If AI automates the drudgery layer of programming, the question stops being “Is this language enjoyable?” and becomes “should I consider using it when I don’t have to write the code myself?” Very few developers love writing Bash. But everybody needs it. It’s the duct tape of software. And now that I can ask an agent to write the unpleasant parts for me, I can use the right tool for the job without weighing that tradeoff. Enterprises aren’t asking “Should we adopt AI?” anymore. They’re asking “What happens after we do?” “A lot of enterprises have been sitting on the sidelines, waiting to see when the water is warm enough to jump in,” Gazit says. “Now they’re seeing the value: junior developers ramp faster, and senior developers spend less time on toil and more on architecture.” That creates second-order effects: Before AI After AI Skill measured by lines of code Skill measured by validation, architecture, debugging Juniors slow to ship Juniors ship faster than seniors can review Senior devs write the hardest code Senior devs now judge the hardest code Tooling was mostly a matter of taste—IDEs, linters, build setups, etc. Tooling now defines the surface area AI can operate on: the wrong stack can block or limit agentic assistance Typed languages accelerate this shift—the stronger the safety rails, the more work can be handed to automation. The next horizon: when language stops being a constraint Today, language choice matters because runtimes are still fragmented. Browsers require JavaScript. Models need Python. Firmware expects C. But that’s already eroding. “WebAssembly is starting to change the rules,” Gazit says. “If any language can target Wasm and run everywhere, that removes one key consideration when picking your stack.” Combine that with AI-generated code, and you get a plausible future: Developer writes in Rust (or Go, or Python) AI generates code in that language Compiler targets Wasm The same code runs on web, edge, cloud, local sandbox That’s not a TypeScript-wins future. It’s a portability-wins future, and a natural extension to the rise of containerization over the last decade as a means of packaging and