Author name: ITMAITY

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

In October, we experienced four incidents that resulted in degraded performance across GitHub services. October 09 14:45 UTC (lasting 1 hour and 55 minutes) On October 9, 2025, between 14:35 UTC and 15:21 UTC, a network device in maintenance mode that was undergoing repairs was brought back into production before repairs were fully completed. Network traffic traversing this device experienced significant packet loss. Authenticated users of the github.com UI experienced increased latency during the first 5 minutes of the incident. API users experienced up to 7.3% error rates, after which it stabilized to about 0.05% until mitigated. Actions service experienced 24% of runs being delayed for an average of 13 minutes. Large File Storage (LFS) requests experienced minimally increased error rate, with 0.038% of requests erroring. To prevent similar issues, we are enhancing the validation process for device repairs of this category. October 17 13:11 UTC (lasting 1 hour and 1 minute) On October 17, 2025, between 12:51 UTC and 14:01 UTC, mobile push notifications failed to be delivered for a total duration of 70 minutes. This affected github.com and GitHub Enterprise Cloud in all regions. The disruption was related to an erroneous configuration change to cloud resources used for mobile push notification delivery. We are reviewing our procedures and management of these cloud resources to prevent such an incident in the future. October 20 08:56 UTC (lasting 2 hours and 5 minutes) On October 20, 2025, between 08:05 UTC and 10:50 UTC the Codespaces service was degraded, with users experiencing failures creating new codespaces and resuming existing ones. On average, the error rate for codespace creation was 39.5% and peaked at 71% of requests to the service during the incident window. Resume operations averaged 23.4% error rate with a peak of 46%. This was due to a cascading failure triggered by an outage in a third-party dependency required to build devcontainer images. The impact was mitigated when the third-party dependency recovered. We are evaluating options to ensure  this dependency is no longer a critical path in our container build process and improving our monitoring and alerting to reduce the detection time of similar issues in the future. October 29 16:17 UTC (lasting 6 hours and 58 minutes) On October 29, 2025, between 14:07 UTC and 23:15 UTC, GitHub experienced service degradation due to a widespread outage at a third-party provider. Codespaces users faced severe connection issues, with error rates averaging 90% and peaking at 100% across all regions during the incident. GitHub Actions larger hosted runners were also impacted, with 0.5% of workflows and nearly 10% of large runner jobs failing or delayed beyond five minutes. Actions impact recovered by 20:40 UTC. The GitHub Enterprise Importer service was impacted as well, causing migration failures during git push operations and significant delays in processing migrations. Additionally, new trials for GitHub Enterprise Cloud with Data Residency were delayed, and Copilot Metrics API downloads were unavailable, resulting in approximately 100 failed requests until recovery began around 20:25 UTC. Mitigations were applied throughout the incident to reduce impact, but full recovery was only achieved once the service provider resolved its outage. GitHub is now focused on reducing critical path dependencies on external providers and implementing strategies to gracefully degrade services during similar events, aiming to improve resilience against future outages. Follow our status page for real-time updates on status changes and post-incident recaps. To learn more about what we’re working on, check out the engineering section on the GitHub Blog. The post GitHub Availability Report: October 2025 appeared first on The GitHub Blog. ​ Company news, News & insights, GitHub Availability Report The GitHub Blog

Copilot code review (CCR) helps you automate code reviews and ensure your project meets your team’s standards. We recently added support for both copilot-instructions.md and path-specific *.instructions.md files, so now you can customize Copilot’s behavior to fit your workflow. This flexibility empowers you to guide Copilot with clear, actionable rules for effective and consistent reviews. But with this flexibility comes some uncertainty: When is Copilot code review reading your instructions? Why doesn’t it always follow your instructions exactly? How can you ensure Copilot code review listens to your guidance? While you can format your instructions file however you want, Copilot code review is non-deterministic and has specific limitations that will evolve as we improve the product. Understanding how to guide Copilot within its current capabilities is key to getting the most from your reviews. After reviewing many instructions files, common questions, and feedback, we’ve created this guide to help you write instructions that really work—and avoid some pitfalls along the way. ⚠️ Note: While these tips are designed for Copilot code review, you might find some of them useful when writing instructions files for other Copilot products. General tips Getting started is the hardest part. Here are some things to keep in mind when starting with your instructions.  Keep it concise: Copilot works best with focused, short instructions. Start small and iterate. Even a single line can help guide Copilot. On the flip side, long instructions files (over ~1,000 lines) can lead to inconsistent behavior. Structure matters: Use headings and bullet points to keep information organized and easy for Copilot to process. Be direct: Short, imperative rules are more effective than long paragraphs. Show examples: Demonstrate concepts with sample code or explanations—just like you would with a teammate. Repo-wide vs. path-specific instructions In addition to the centralized repo-wide copilot-instructions.md file, we recently expanded your customization options by enabling Copilot code review to read any NAME.instructions.md file with an applyTo frontmatter in your .github/instructions directory. It can be confusing to have two seemingly similar options for customization, but each provides different value! Here are some tips for how to differentiate between the two, and use them both effectively. Place language-specific rules in *.instructions.md files and then use the applyTo frontmatter property to target specific languages (e.g., applyTo: **/*.py or applyTo: documentation/*.md). Place rules meant specifically for only Copilot code review or only Copilot coding agent in *.instructions.md files, and use the excludeAgent frontmatter property to prevent either agent from reading your file. Organize different topics (e.g., security, language-specific guidelines, etc.) into separate *.instructions.md files. Reserve general instructions, team standards, and guidelines for the whole repository for copilot-instructions.md (e.g., “Flag use of deprecated libraries across the codebase”). Rules of thumb Effective instructions files often include: Clear titles A purpose or scope statement to clarify intent Lists of guidelines/rules instead of dense paragraphs Best practice recommendations Style conventions (indentation, naming, organization) Sample code blocks for clarification Section headings for organization Task-specific instructions (e.g., for tests or endpoints) Language/tooling context Emphasis on readability and consistency Explicit directives for Copilot (“Prefer X over Y”) What not to do Certain types of instructions aren’t supported by Copilot code review. Here are common pitfalls to avoid: Trying to change the UX or formatting of Copilot comments (e.g., “Change the font of Copilot code review comments”). Trying to modify the “Pull Request Overview” comment (e.g. prompting to remove it or change its purpose to be something other than provide an overview of the pull request). Requesting Copilot code review performs tasks outside of code review. (e.g., trying to modify the product behavior like asking it to block a pull request from merging). Including external links. Copilot won’t follow them. You should copy relevant info into your instructions files instead. Adding requests meant to generally and non-specifically improve behavior (e.g., “Be more accurate” or “Identify all issues”). Copilot code review is already tuned to do this and adding language like this adds more noise that confuses the LLM. Recommended structure for instructions files Starting off with a blank Markdown file can feel daunting. Here’s one structure that you can use, ready to copy-paste into your instructions file as a starting point! # [Your Title Here] *Example: ReactJS Development Guidelines* ## Purpose & Scope Briefly describe what this file covers and when to use it. — ## Naming Conventions – [Add rules here, e.g., “Use camelCase for variable names.”] ## Code Style – [Add rules here, e.g., “Indent using 2 spaces.”] ## Error Handling – [Add rules here.] ## Testing – [Add rules here.] ## Security – [Add rules here.] — ## Code Examples “`js // Correct pattern function myFunction() { … } // Incorrect pattern function My_function() { … } “` — ## [Optional] Task-Specific or Advanced Sections ### Framework-Specific Rules – [Add any relevant rules for frameworks, libraries, or tooling.] ### Advanced Tips & Edge Cases – [Document exceptions, advanced patterns, or important caveats.] Example: A typescript.instructions.md file Now let’s implement all of these guidelines in an example path-specific instruction file. — applyTo: “**/*.ts” — # TypeScript Coding Standards This file defines our TypeScript coding conventions for Copilot code review. ## Naming Conventions – Use `camelCase` for variables and functions. – Use `PascalCase` for class and interface names. – Prefix private variables with `_`. ## Code Style – Prefer `const` over `let` when variables are not reassigned. – Use arrow functions for anonymous callbacks. – Avoid using `any` type; specify more precise types whenever possible. – Limit line length to 100 characters. ## Error Handling – Always handle promise rejections with `try/catch` or `.catch()`. – Use custom error classes for application-specific errors. ## Testing – Write unit tests for all exported functions. – Use [Jest](https://jestjs.io/) for all testing. – Name test files as `<filename>.test.ts`. ## Example “`typescript // Good interface User { id: number; name: string; } const fetchUser = async (id: number): Promise<User> => { try { // …fetch logic } catch (error) { // handle error } }; // Bad interface user { Id: number;