Code found in the iOS 27 beta suggests Apple is developing a system that could restrict leased iPhones when customers fall behind on payments. The discovery follows a recent Bloomberg report that Apple may soon launch a new "Apple Upgrade" leasing program, allowing customers to pay for hardware through monthly installments. 9to5Mac reports: The code describes a system called App Managed Features, which allows an authorized financing or provider app to enroll an iPhone and perform ongoing status checks. If the contract is no longer in good standing, Apple's system services can place the iPhone in "Restricted Mode," which blocks access to most apps until the payment or contract issue is resolved, while keeping a small set of apps available. The fixed allowlist currently found in the iOS 27 beta includes: Accessibility Reader, App Store, Health, Magnifier, Phone, Clock, Settings, Wallet, Passwords, and the Restricted Mode interface itself.
Apps that can send critical alerts, such as Messages, Home, and certain medication or safety apps, may also remain accessible. However, the provider appears to have some control over those exceptions. The code does not appear to cancel, suspend, or otherwise modify App Store subscriptions associated with blocked apps. As a result, a subscription could continue billing even while access to its app is restricted.
Additionally, there isn't a fixed number of missed payments that automatically triggers the restrictions. The financing provider's app decides when to lock the device based on its own policies. Finally, the new framework also introduces a new type of activation lock called "Partner Finance Lock," which is meant to prevent users from erasing, reselling, or stripping a restricted device for parts.
Nearly 20 years ago (!), in 2007, I published my first and only book: Microsoft 2.0. It focused on changes I expected at the company in the “Post-Gates” era. What would remain the same and what likely would be different once co-founder and CEO Bill Gates had left the building?
CEO Satya Nadella has not exited the company (yet). But there’s no question that Microsoft and its mission have morphed considerably in the past year or two. I’m not quite ready to christen this the Microsoft 3.0 era, even though Nadella handed the reins of Microsoft’s dominant commercial business to Judson Althoff nearly a year ago.
That decision resulted in Nadella moving into more of a “founder mode” role, allowing him to focus less on the day-to-day work of running the business. (Microsoft historians may recall that Gates made a somewhat similar move back in 2000 when he became Microsoft’s chief software architect.)
While it might not yet be time for Microsoft 3.0, we arguably could be in the “Microsoft 2.5” era. Windows and Office are still around and still play a big role. Microsoft still builds and sells developer tools and databases. But there’s no question that the cloud and all things AI are at the top of the pecking order now.
I’m embarking on a series here at GeekWire that will focus on what matters to Microsoft and, by extension, to its customers, partners, investors, and employees these days. Who are some of the people shaping and leading the company? What are their opportunities and challenges right now?
Over the next few weeks, I will be profiling various Microsoft execs working on plans for Microsoft’s ongoing evolution. Some are company veterans; some are newcomers. I’ll be talking with top execs from Microsoft’s Security, Copilot, Windows + Devices, Xbox, GitHub, and more.
I’m interested in their strategies for Microsoft’s key products and technologies and how they plan to try to turn Microsoft’s ambitious vision into reality. What are their teams building? What do they see as their biggest challenges and opportunities? And where do they see the technologies in their respective areas heading?
I feel like many of us who’ve been keeping track of the biggest tech companies (myself included) have fallen into the trap of blaming or attributing everything a company does to AI. Layoffs? AI is the culprit. Price increases? It’s all thanks to AI. Changing sales strategies? Chalk it up to AI …
But upon further reflection, I believe Microsoft’s strategy is more nuanced than “AI or bust.” There’s no question that Microsoft’s AI ambitions are shaping its goals and tactics. But Microsoft, as a heavily enterprise-focused entity, can’t simply stop supporting products that aren’t built from the ground up with AI (as much as it might like to do so). Nor can it just leave behind customers who aren’t 100% onboard with its AI moves.
Couple those enterprise hurdles with some not-so-popular consumer decisions, like axing 3,200 people in the gaming unit, and Microsoft’s approach to turning the ship looks a lot trickier.
Our Microsoft 2.5 series kicks off Thursday. Stay tuned.
L-R: Mantra CEO John Patrick Mullin, Docugami CEO Jean Paoli, and Inveniam CEO Patrick O’Meara. The companies are partnering to make DGML a standard for AI, with Docugami turning documents into data, Inveniam verifying it on a blockchain, and Mantra providing the chain.
Jean Paoli has spent his career making documents readable by machines — first as a co-creator of XML, then helping build the file formats behind Microsoft Office. Now his Kirkland, Wash.-based startup, Docugami, is open-sourcing the technology at the heart of its business, betting it can become a standard way to turn documents into data that people and AI agents can trust.
The company is releasing its technology, called DGML (short for Document Graph Markup Language), under Apache 2.0, a widely used open-source license, so other developers and companies can adopt it.
The idea is to turn it into a shared standard that no single company owns, much as XML became a common foundation across the tech industry.
The move reflects a shift in where the value is created in AI. Docugami until now has made its money selling software that turns unstructured documents into usable data. It’s betting now that there’s more value in proving that data is trustworthy instead.
How it works: Docugami is teaming up with Inveniam, a Detroit company whose software helps big investors keep tabs on the mountains of paperwork behind real estate and other hard-to-value assets. Inveniam will record a kind of digital fingerprint of each piece of DGML data on NVNM Chain, its blockchain built with Mantra, a crypto firm that Inveniam is acquiring.
That means, for example, that a single fact buried in a 200-page lease — such as the rental rate, a renewal option, or a default clause — can be verified on its own, without exposing the whole document. An investor, auditor, or AI agent can trace it to the page it came from.
To work with documents, AI systems usually convert them into a simpler format first. DGML enters a growing field of contenders in that regard, competing with the popular Markdown format and DocLang, a new open standard for AI-ready documents backed by IBM, Nvidia and Red Hat.
The business model: This is a big move for a company of Docugami’s size, taking the 30-person startup in a new direction. Paoli is handing the industry the technology his team spent years building, and pinning the company’s future on a larger idea.
The plan is to make money not from the format itself but from the value of the trusted data. Once a company converts its leases or loans into DGML and anchors the key numbers on the blockchain, investors, lenders and auditors can pay to draw on that verified data.
Docugami will share in the revenue through its partnership with Inveniam. The company also stands to collect a small fee each time a piece of data is recorded on the chain.
The company is giving away the DGML format and a working version of the software, but not everything. Paoli said the company is keeping some of its own technology private, including AI models it has fine-tuned to read documents, and could sell those or other tools to enterprises.
“The business model of everybody is changing. And if you know any company where it’s not true, you need to tell me, because I haven’t met them yet,” Paoli said in an interview.
Docugami has raised about $13 million to date, including a $10 million seed round in 2020 that drew the first investment in Grammarly’s history.
The partnership: Paoli met Patrick O’Meara, Inveniam’s CEO, a few months ago, through a former Microsoft colleague who had become one of O’Meara’s advisers. They quickly realized they had been working toward the same idea from different directions.
Inveniam, founded in 2017, helps big investors keep track of assets that are hard to value, like office towers, private loans and infrastructure. It monitors the documents behind those assets and flags changes as they happen, and its clients include some of the world’s largest sovereign wealth funds, according to O’Meara.
What it lacked was a consistent way to break those documents into verifiable pieces. That is what Docugami provides.
“We’re not putting the data itself on-chain, just a fingerprint of the document. Change one bit, one byte, one pixel, and the hash won’t match,” O’Meara said.
Paoli said the project uses the underlying blockchain, not the token.
“Crypto as an industry has gone through a lot of changes in the last 18 to 24 months, and it’s growing up in a lot of ways. This is a real use case with fundamental value, not just pure speculation,” Mantra’s Mullin said in an interview.
The result is a division of labor: Docugami turns documents into data, Inveniam verifies it and brings the customers, and Mantra provides the chain where the proof is recorded.
The DGML specification, sample documents and reference code are at dgml.io and on GitHub.
Editor’s note: This story was updated after publication to correct the name of a competing document format, DocLang, and to note that Inveniam’s blockchain is called NVNM Chain.
Microsoft is expanding its Xbox backward compatibility efforts today by bringing original Xbox games to PC. An early preview release will see four classic Xbox games available on PC today, as part of a bigger effort to bring more Xbox console games to PC in the future.
The first four games are Blinx: The Time Sweeper, Conker: Live and Reloaded, Crimson Skies: High Road to Revenge, and Fuzion Frenzy. You'll be able to purchase and download each of these games on PC, and they'll also be included with all Xbox Game Pass plans. If you already own a digital copy of these games, you can now play them on PC or handhelds like the Xbox Ally and Xbox …
Code coverage is one of those metrics that every development team talks about but few use to its full potential. Whether you’re shipping a SaaS product or maintaining a legacy monolith, understanding what your tests actually exercise-and what they miss-can make the difference between a confident release and a 2AM incident page.
This article walks you through the core coverage metrics, how to measure them with modern tools, and practical steps to improve code coverage without wasting effort on tests that don’t matter.
Code coverage is a software testing metric that measures the percentage of source code executed by your automated tests. It directly impacts software quality and deployment confidence.
Measuring code coverage starts with choosing the right metrics-line, branch, condition, and path coverage-and using tools like Qodana, JaCoCo, Istanbul/NYC, Coverage.py, or Jest to generate coverage reports in your CI pipeline.
Aiming for 80% code coverage is generally considered a good target for critical business logic, but achieving 100% code coverage is often impractical and costly. High coverage never guarantees bug-free software.
To improve code coverage, use coverage reports to identify untested parts of the code, prioritize risky modules, and integrate coverage checks into your CI/CD workflow.
Code Coverage measures the percentage of code executed during testing. If your code base has 1,000 executable lines of code and your test suite runs 900 of them, you have 90% line coverage. It’s typically expressed as a percentage and serves as a runtime metric-meaning it tracks what actually executes, not what could be problematic based on structure alone.
This makes it distinct from static code analysis, which inspects source code without execution to flag complexity, style issues, or security smells. The two are complementary: static analysis tells you where trouble might lurk, and Code Coverage tells you whether your tests actually reach those areas. We expand on this in detail here.
It’s worth clarifying the difference between Code Coverage and what’s sometimes called test coverage:
Code Coverage focuses on how much source code executed during a test suite runs-lines, branches, conditions.
Test coverage is broader. It asks whether business requirements and user behaviors were validated, even if every relevant line was hit.
For example, a test suite might execute 95% of the lines in a payment module, giving high Line Coverage. But if no test checks that a payment fails gracefully on a negative balance, test coverage measures for that behavior are incomplete.
Code Coverage identifies untested code that allows developers to improve testing efforts, especially in critical parts like authentication, data access layers, and error handling. Measuring Code Coverage helps discover untested paths and edge cases that could hide regressions or security issues.
Here’s a quick example in JavaScript:
function foo(a, b) {
let c = 42
if (a > 0 && b > 0)
c = c + a * b
return c
}
If your only test calls foo(1, 1), every line executes-but the else branch is never tested. Line coverage looks complete; branch coverage reveals the gap.
Core Code Coverage metrics and criteria
Coverage criteria are formal rules for determining how thorough your code execution is during tests. Rather than chasing every metric simultaneously, teams get better results by picking a small set of primary coverage metrics and focusing effort there. Here are the common coverage types you’ll encounter.
Metric
Definition
Best For
Line/Statement
Checks if each line of code has been executed. Statement coverage measures executed statements in the program.
Baseline dashboards
Function
Function coverage checks if each function has been called at least once.
Spotting dead code
Branch
Branch coverage determines how many branches of control structures have been executed (e.g., both sides of an if/else).
Decision logic
Condition
Condition coverage tests how many boolean sub-expressions have been evaluated for both true and false.
Complex predicates
Path
Path coverage tests all possible execution paths in the code.
Critical algorithms
Line coverage and statement coverage are often reported as a single percentage by most tools, making them the easiest baseline metric. But high line coverage but high line does not mean other metrics are scored high. For example, if we had 5 functions, 4 of which has 1 line, and the last of which has 100 lines in it’s body, while tests only covered the last one, the code coverage will be almost 100%, but the function coverage will be 20%.
Condition coverage goes further. For a compound expression like if (a && b || c), condition coverage demands that each boolean sub-expression (a, b, c) evaluates to both true and false across your test cases. This can reveal missing tests that branch coverage alone might hide.
Full path coverage is practically impossible for non-trivial applications due to combinatorial explosion-loops and nested branches multiply code paths exponentially. It remains useful only for particularly critical algorithms.
In safety-critical domains, more advanced criteria like Modified Condition/Decision Coverage (MC/DC) are mandated. DO-178C, for example, requires Modified Condition/Decision Coverage (MC/DC) for Level A avionics software, demonstrating that each condition independently affects the outcome of every decision.
How to measure Code Coverage in practice
Here’s how to measure Code Coverage in four steps:
Instrument your code – Instrument your code by introducing hooks that allow coverage tools to observe execution. This can be done through source instrumentation, bytecode instrumentation, or runtime instrumentation.
Run your automated tests – unit tests, integration tests, or end-to-end coverage tests.
Collect coverage data – record which lines, branches, and conditions were executed.
Generate coverage reports – HTML dashboards, terminal summaries, or machine-readable formats (Cobertura XML, LCOV).
Running coverage in practice
Qodana supports coverage reports generated by a range of popular tools, including:
Coverage is typically reported as a percentage of the code elements exercised during testing:
Line coverage = executed executable lines ÷ total executable lines.
Branch coverage = executed branches ÷ total branches.
Different metrics provide different levels of confidence. Line coverage indicates which code was executed, while branch coverage reveals whether every decision path has been tested.
Measuring Code Coverage involves using tools that analyze executed parts of the source code, then surfacing those results where developers can act on them-in pull request comments, IDE plugins, or CI dashboards. Exact coverage calculations can vary slightly between tools and languages, but line and branch coverage are the most commonly used metrics.
Understanding coverage percentages and “good” Code Coverage
Headline coverage numbers can be misleading if taken alone. A project at 85% line coverage might still have only 55% branch coverage, leaving complex logic undertested. Coverage metrics provide insights into test execution rather than test quality. A test that runs every line but asserts nothing offers a false sense of security.
So what counts as good coverage? Here are practical guidelines:
To many, aiming for 80% coverage is a healthy industry standard for critical business logic. But 100% Code Coverage does not guarantee bug-free code-it just means every line was touched, not that every behavior was validated.
Generated or boilerplate code → exclude from thresholds entirely
Treat coverage as a trend indicator over time (week over week, sprint over sprint) rather than a one-off target. High coverage data indicates risks associated with legacy or untested code when numbers start dropping. Dashboards that visualize this trend help teams spot regressions before they compound.
How to improve Code Coverage without sacrificing quality
To improve Code Coverage meaningfully, treat it as a practical playbook, not an abstract goal. Here’s a step-by-step approach that keeps software quality front and center.
1. Start with your coverage reports. Use coverage reports to identify untested code sections, focusing on high-risk, low Code Coverage areas like core domain services, payment processing, and data access layers. Don’t try to raise the global coverage percentage uniformly.
2. Write focused unit tests first. Unit tests help quickly increase Code Coverage because they target isolated, pure functions and small components. Use frameworks like JUnit 5, pytest, or Jest to write additional tests around functions with the highest business impact.
3. Target uncovered branches and conditions. Line coverage remains the most common way to measure how much of a codebase is exercised by automated tests. However, you can look beyond it. Write test cases that exercise error paths, retry logic, timeout handling, and edge cases in complex logic. This will increase Code Coverage at the branch and condition level, where bugs most often hide.
4. Refactor overly complex code. Functions with very high Cyclomatic Complexity are hard to test and hard to cover. Splitting them into smaller, testable units improves both coverage numbers and static analysis findings.
5. Handle hard-to-test code. For third-party integrations, legacy modules, or code with heavy I/O, use dependency injection, mocking, test doubles, and contract testing. These strategies make writing tests possible without requiring full external environments.
6. Integrate coverage checks into CI. Integrate Code Coverage tools into your CI pipeline and set the goal to 80%, then track your progress. Enforce “no significant coverage regressions per pull request” using coverage status checks on GitHub, GitLab, or Azure DevOps.
7. Set realistic coverage goals based on project criticality. Not every file deserves the same target. Set coverage goals per module rather than globally.
Avoid writing superficial tests solely to push the coverage percentage up. Useful tests should assert meaningful behavior, edge cases, and error conditions – not just execute lines of code.
Code Coverage improves code reliability by verifying critical paths and logic, but only when the tests themselves are meaningful. Code coverage strengthens quality assurance by measuring test thoroughness, not by padding numbers.
Integrating Code Coverage with static analysis and CI/CD workflows
Combining coverage tools with static code analysis platforms gives you a more complete picture of code health: runtime execution metrics plus structural and style checks across multiple languages and programming languages.
You can find Code Coverage statistics in the upper-right corner of the Qodana report UI. It also lists the inspections used by the feature.
IDE
You can view Code Coverage reports using IntelliJ IDEA, WebStorm, PhpStorm, PyCharm, and GoLand IDEs. This feature is available for reports retrieved from Qodana Cloud after linking, or reports from local storage.
Currently, Code Coverage overview is not available for XML-formatted reports generated by .NET coverage reports.
Open reports from Qodana Cloud
In your IDE, navigate to Tools | Qodana | Log in to Qodana.
On the Settings dialog, click Log in. This will redirect you to the authentication page.
In the Settings dialog, search for the project you would like to link with.
View coverage reports in IDE
You can view code coverage reports based locally using JetBrains IDEs.
In your IDE, navigate to Run | Show coverage data and open the file containing a code coverage report.
In the Coverage tool window, you can view the test coverage report. This report shows the percentage of the code that has been executed or covered by tests.
Report overview
The IDE highlights the codebase test coverage using color marking. By default, the green color means that a particular line was covered, and the red color means the uncovered line of code.
If you see that code coverage results look incomplete, you probably need to reconfigure your code coverage tool and generate a new code coverage report.
The report shows coverage for the lines that implement the logic of a method, function, or a class, but not for the function, method, or class declaration. The image below shows that code coverage is not applicable to line 7, while line 8 is not covered.
With Qodana, you can view Code Coverage in your Insights Dashboard.
FInd out more about Code Coverage and other features here.
Common pitfalls and misconceptions about high Code Coverage
High code coverage may provide a false sense of security. Consider a test suite with 100 code coverage on line coverage: if assertions are weak or missing entirely, serious bugs can slip through undetected. Execution alone isn’t validation.
Pitfalls to watch for:
Completely ignoring other types of coverage. Qodana supports both overall line coverage and fresh lines coverage, allowing teams to focus on ensuring that newly added or modified code is properly tested while gradually improving coverage across the rest of the codebase. However, we encourage you to explore other types over time, such as branch coverage.
Using coverage as a performance metric. When a single global coverage percentage becomes a team KPI, it incentivizes maintaining tests that are superficial-just enough to hit the number. This can slow the development process without meaningful benefit.
Forcing coverage on untestable code. Generated code, trivial getters/setters, and framework glue are legitimately unnecessary to test. Trying to force coverage here wastes effort. Exclude these from thresholds.
Forgetting what coverage doesn’t measure. Coverage tools do not evaluate whether all business requirements, user journeys, or non-functional aspects (performance, security, usability) are adequately tested. They only report which code was executed.
Microsoft Research examined 100+ large open-source Java projects and found insignificant correlation between high coverage and fewer post-release defects at the file level. This reinforces that coverage is necessary but not sufficient-balance it with defect trends, incident postmortems, static analysis warnings, and production monitoring.
Is 100% code coverage ever required in real projects?
Yes, in safety-critical domains. Aerospace software under DO-178C and automotive systems under ISO 26262 can require near-100% statement, branch, and MC/DC coverage based on one or more criteria tied to safety integrity levels. For most commercial web and mobile applications, 80% code coverage is generally considered a good goal for core modules, with diminishing returns beyond that. Test quality and risk-based focus matter more than chasing 100% across the entire code base.
How often should I run coverage analysis in my project?
Run coverage on every pull request in active repositories so regressions are caught immediately. For large software projects with slower integration and end-to-end existing tests, schedule a nightly or weekly full-coverage job. Use the trend data to guide refactoring investments and determine where additional tests are most needed.
Which coverage metric should I prioritize first: line, branch, or something else?
Start with line coverage as a simple baseline that’s easy to communicate to stakeholders. Once your team is comfortable, introduce branch coverage as the primary metric for non-trivial business logic. Condition Coverage and Path Coverage are most useful in particularly complex, risk-heavy code-authorization checks, pricing engines, or any program with deeply nested control structures-and can be adopted selectively rather than project-wide.
How do static code analysis and code coverage complement each other?
Static analysis flags potential problems without running the code, including dead code, null dereferences, security smells. Code coverage shows which parts of the source code are actually exercised by tests. Together they create a feedback loop: static analysis identifies complex or risky areas, coverage reports reveal whether they’re adequately covered, and developers prioritize new tests or refactors accordingly.
Can I use code coverage for manual tests or only for automated tests?
Coverage tools work with automated tests by default, but they can also collect data while manual exploratory tests run against an instrumented application. This is useful during pre-release hardening phases to confirm which functionality was exercised. The most valuable manual scenarios can then be converted into automated tests to preserve that coverage over time across your software projects.
Note: While examples in this article use specific coverage tools, Qodana isn’t tied to any particular solution. Any tool that produces a supported coverage report format can be used.
Special thanks to Andrei Iurko and Ivan Efiminov for their assistance with this post.
I keep seeing this question: “Why would I pay for GitHub Copilot when I can call the same models through an API?”
It’s a fair question. The answer depends on what work you need to own.
Are you building a product feature with your own prompts, retrieval, routing, logs, security model, and billing controls? Or are you trying to get from a GitHub Issue to a reviewed pull request with the editor, repository, terminal, and organization policies already connected?
Cost is part of that equation. Copilot plans include a monthly allocation of GitHub AI Credits. Metered usage is calculated from input, output, and cached tokens at the listed rate for the selected model.
Raw API access and Copilot address different layers of that system. The right choice follows the work you need to own.
Copilot is development tooling around the model
Now take a common maintenance task: a developer starts from a GitHub Issue, inspects the repository, changes the affected files, runs the test suite in the terminal, and opens a pull request for review. The model call is one step in that workflow. The surrounding system needs the issue, the diff, repository instructions, permitted commands, and the organization’s policies.
GitHub Copilot connects those surfaces across the editor, repository, pull request, issue, terminal, and organization controls. That is what the plan covers alongside model access. The billing change makes the split easier to see: code completions and Next Edit Suggestions remain included in paid plans, while AI Credits apply to more resource-intensive chat and agentic work.
Cost per task therefore depends on more than the listed token rate. Context selection, tool use, retries, and the path from an issue to a reviewed pull request all affect the number of tokens spent and whether the work finishes.
The same billing model gives buyers visibility. Organization plans “pool” AI Credits across the organization, and admins can set budgets and track usage in the billing dashboard. Adoption stays measurable instead of scattering across individual API keys and untracked scripts.
Raw API access is for systems you own
Direct API access is the right foundation when you are building a product feature, an internal agent platform, an evaluation harness, or an automation pipeline. You control the prompts, retrieval, routing, retries, logs, security model, and billing.
Consider an internal agent that reads a tagged issue, retrieves company documentation, creates a change request in a separate system, and writes a complete audit record. That workflow needs its own data boundaries, event triggers, and approval points. An API gives the team the primitives to build those requirements into the product.
The engineering work is real. A production system needs to decide which repository files to retrieve, how to preserve instructions, when to retry a failed tool call, where to store traces, and which credentials an agent can use. Those are system design decisions made by developers. A model endpoint does not make them for you.
Agent SDKs sit between these layers. Handling orchestration, tool use, sessions and streaming, with some tradeoffs: some are tied to a single provider’s API while others work across providers. GitHub ships this layer. The Copilot SDK exposes the same agent’s runtime that powers the Copilot CLI, so you can embed a benchmarked, production tested harness instead of building one. Run it with your Copilot subscription or your own provider key.
BYOK keeps the workflow and changes the bill
Bring Your Own Key for Copilot, currently in public preview, lets developers make supported provider models available in Copilot Chat, Copilot CLI, and VS Code. Supported providers include Anthropic, AWS Bedrock, Google AI Studio, Microsoft Foundry, OpenAI, OpenAI-compatible providers, and xAI.
BYOK models run through the same harness and the same integrations GitHub builds and maintains. Your provider takes over the token bill. GitHub still develops the tooling.
Model access is a policy decision either way. Copilot supports more than 20 models, and enterprise and organization admins choose which ones are enabled for their teams, whether GitHub-hosted or connected through BYOK.
A team with an existing provider contract or committed cloud spend can keep that commercial relationship while developers use Copilot in their normal workflow. Copilot CLI also supports local and external BYOK models, including OpenAI-compatible endpoints, Azure OpenAI, Anthropic, and local Ollama models.
Choose raw API access when you are building a system that requires custom behavior, integrations, and controls. Choose GitHub Copilot when the work is software development inside the tools and repositories where a team already writes, reviews, secures, and ships code.
Shipping software is the work around the code: issues, pull requests, reviews, checks, actions, and security. GitHub is where teams do that work. Copilot helps them move through it faster.
Log in
