Which Languages Do AI Coding Assistants Write? 2025 to 2026 Data

No public dataset measures the language mix of AI written code directly. The best proxies agree on the top of the list: JavaScript and TypeScript, Python, HTML and CSS, and SQL. Anthropic's own April 2025 study put JavaScript and TypeScript at 31% of coding queries and Python at 14%, while GitHub's Octoverse 2025 shows TypeScript becoming GitHub's most used language in August 2025.

That combination matters for security teams. If assistants and agents write most heavily in the npm and PyPI ecosystems, then the dependencies they add, the advisories those dependencies attract and the upgrade work that follows will pile up in TypeScript and Python first. This post gathers the 2025 to 2026 figures from GitHub, Stack Overflow, JetBrains, Anthropic and the published docs of the main AI coding tools, sets them side by side, and turns them into a scanning and remediation plan per language.

Key takeaways

• There is no direct measurement. No maker, survey or index publishes "share of AI generated code by language". Every figure here is a proxy, and each proxy measures something different.
• The strongest direct signal is Anthropic's own. In a study of 500,000 coding interactions from 6 to 13 April 2025, JavaScript and TypeScript together were 31% of queries, HTML and CSS 28%, Python 14% and SQL 6%.
• GitHub's platform data points the same way. TypeScript reached 2,636,006 monthly contributors in August 2025 and passed Python by about 42,000, according to Octoverse 2025. GitHub links this to agent assisted coding but calls its findings "observational signals rather than causal claims."
• Agents already produce pull requests at scale. GitHub says its Copilot coding agent created more than 1 million pull requests between May and September 2025.
• Adoption is near universal, trust is not. JetBrains reports 85% of developers regularly use AI for coding. Stack Overflow's 2025 survey found 84% use or plan to use AI tools, yet 46% distrust the accuracy of AI output, up from 31% a year earlier.
• "AI repositories" are a different thing. Python leads new AI tagged repositories on GitHub (582,196) by a wide margin, but that counts projects that build AI, not code that AI wrote. Mixing the two is the most common error in coverage of this topic.
• For security programmes, the practical answer is to plan capacity for npm and PyPI first, gate new dependencies that agents add, and use the review controls the tool makers already document.

The honest answer: nobody measures this directly

Before any numbers, the caveat that shapes everything below. To know which languages AI coding assistants write, someone would need to observe generated code at the point it is produced, tag it by language, and publish the totals across tools and customers. No one does that publicly.

The closest public sources each see only a slice:

• Platform telemetry (GitHub Octoverse) sees what lands in repositories, but cannot tell which lines a human typed and which an assistant generated, except for pull requests opened by GitHub's own agent.
• Developer surveys (Stack Overflow, JetBrains) see which languages developers use and whether they use AI, but not the language of the code the AI produced.
• AI makers' usage reports (Anthropic's Economic Index series) see their own traffic only, for a window of days, with stated exclusions.

So the right way to read this post is as triangulation. Where three different instruments point at the same languages, the conclusion is reasonably safe. Where they disagree, the disagreement usually tells you what each instrument is actually measuring.

How we measured

We set a simple rule: every number must come from a page we fetched on 23 October 2026, from the organisation that produced the data, with the date of the data stated.

Sources used. GitHub's Octoverse 2025 report (published 28 October 2025, updated 28 February 2026); Stack Overflow's 2025 Developer Survey press release (29 July 2025) plus its AI and Technology results pages; Anthropic's "impact on software development" study (28 April 2025) and its Economic Index September 2025 report; GitHub's Copilot docs; Anthropic's Claude Code security docs; OpenAI's Codex approvals and security docs; and the OpenSSF Security Focused Guide for AI Code Assistant Instructions (1 August 2025).

One source we could not fetch directly. The JetBrains State of Developer Ecosystem 2025 page returned an HTTP 403 to our fetcher. Its headline figures (85% and 62%, 24,534 respondents) are taken from JetBrains' own summary as shown in search results and confirmed by InfoWorld's coverage of the report. The JetBrains language shares we quote are as reported by InfoWorld, and we label them that way.

What we did not use. We did not use vendor benchmarks that rank assistants or models, studies that claim an "insecure output rate" for a named tool, or secondary sites that restate Octoverse or survey figures with different decimals. Where a secondary summary and a primary page differed, we used the primary page.

How we compared. We did not average proxies together or build a composite index, because the inputs measure different populations (developers, repositories, conversations). Instead we put them side by side, ranked within each source, and noted where the rankings agree.

Limits worth repeating. Anthropic's language data covers one week in April 2025, excludes Team, Enterprise and API traffic, and in Anthropic's words "likely captures early adopters." Octoverse counts contributors and repositories, not lines of generated code. Survey respondents select themselves. None of these sources measures security outcomes of AI generated code by language.

Which languages are growing fastest on GitHub, and how does GitHub tie that to AI?

GitHub's Octoverse 2025 is the largest public view of where code is being written. Its headline: TypeScript became the most used language on GitHub by monthly contributors in August 2025, overtaking Python and JavaScript.

Monthly contributors by language, August 2025 versus August 2024

Octoverse puts TypeScript about 42,000 contributors ahead of Python in August 2025. That is a narrow lead between two languages each with roughly 2.6 million monthly contributors, so a different month or a different counting rule could flip the order. What is not in doubt is the growth rate: TypeScript added more than a million contributors in a year.

New repositories by language

Contributors measure people. Repositories measure projects. Octoverse reports both, and the repository view tells a slightly different story.

Source: GitHub Octoverse 2025.

JavaScript still leads in new repositories, Python is nearly level with it, and TypeScript is growing fastest among the large languages. Octoverse also reports Dockerfile repositories up 120% to 1.9 million, and repositories using Jupyter Notebooks up 75% to 2.42 million. Both are relevant later, because containers and notebooks are where many AI projects pull in their dependencies.

How GitHub explains the shift

GitHub ties TypeScript's rise to agent assisted development. The report argues that typed systems "reduce ambiguity and catch LLM errors before production," and cites a 2025 academic study that found 94% of compilation errors in LLM generated code were type check failures.

Two cautions. First, GitHub itself frames its findings as "observational signals rather than causal claims." The growth coincides with wide AI adoption; the report does not prove that AI caused it. Framework defaults matter too: many popular web frameworks now scaffold TypeScript projects by default, which pushes the count up whether or not an assistant is involved. Second, the 94% figure comes from a study GitHub cites, not from GitHub's own telemetry, and it describes compilation errors, not security defects.

The reasonable reading: assistants work well in languages where a type checker gives fast feedback, developers and agents are choosing TypeScript more often, and the two trends reinforce each other. That is enough to plan around without claiming causation.

How many pull requests did GitHub's coding agent author in 2025?

This is the one place where a platform publishes a number for agent authored work. According to Octoverse 2025, the Copilot coding agent created more than 1 million pull requests between May and September 2025.

For context, Octoverse reports 518.7 million merged pull requests over the trailing 12 months (up 29%), an average of 43.2 million merged per month (up 23%), and nearly 1 billion commits in 2025 (up 25.1%). The agent figure counts pull requests created, not merged, over five months, so it cannot be turned into a clean share of all merged work. Taken loosely, a million agent pull requests is small next to half a billion merged pull requests. What it shows is a new category of contributor that did not exist at scale a year earlier.

GitHub's documentation now refers to the product as Copilot cloud agent in places. The docs describe what it can and cannot do, which matters for governance and is covered below.

Octoverse does not break the agent's pull requests down by language. If you see a language split for them, it did not come from the Octoverse report.

What share of developers use AI coding tools?

Two large surveys from 2025 give the answer, and they broadly agree on adoption even though they ask the question differently.

Adoption and sentiment: two surveys side by side

Sources: Stack Overflow 2025 press release and AI results page; JetBrains 2025 summary as reported in search results and by InfoWorld.

The adoption numbers line up: roughly five in six developers use AI in some form. The "assistant or agent" line does not line up, and should not be expected to. JetBrains' 62% counts reliance on any AI coding assistant, agent or AI code editor. Stack Overflow's 31% counts AI agents specifically, which it separates from autocomplete style tools (13.8% of its respondents use only Copilot style completion). Those are different products and different questions.

The security rows also differ by design. Stack Overflow asked respondents to agree or disagree with a statement about concern, which tends to produce high agreement. JetBrains asked people to pick their top concerns from a list, which spreads responses across many options. Neither number is wrong; they answer different questions.

What developers use, by language

Surveys also tell us which languages the developers using these tools work in. That matters because an assistant mostly writes in whatever language its user is already working in.

Stack Overflow's figures are "used in the past year" (multiple answers allowed; 31,771 people answered this question). JetBrains' figures are "primary language", one answer per person. That is why the JetBrains column is lower across the board. Stack Overflow also notes Python adoption rose 7 percentage points from 2024 to 2025, which it connects to AI and data work.

How much do developers trust AI generated code?

Less than a year ago, according to Stack Overflow. Its 2025 survey breaks trust in the accuracy of AI tools down as follows:

Source: Stack Overflow 2025 Developer Survey, AI section.

Distrust (somewhat plus highly) comes to about 46%, which the press release compares with 31% the year before. Favourable sentiment toward AI tools fell to 59.7% of all respondents in 2025, from what Stack Overflow describes as "70%+" in 2023 and 2024. And 45% of respondents said debugging AI generated code is time consuming.

The press release adds a country split: India had the highest trust (56% highly or somewhat trusting) and Germany the lowest (22%).

For security leaders, the trust numbers are useful in a specific way. Developers who distrust output tend to review it. The risk sits with the minority who accept generated changes, including new dependencies, without reading them, and with agents that open pull requests nobody looks at closely. The survey cannot tell you how many of your developers fall in that group. Your pull request data can.

What do the AI makers' own usage reports show?

This is the closest anyone gets to a direct measurement, and it comes from one maker.

Anthropic's study of coding conversations

In April 2025 Anthropic published an analysis of 500,000 coding related interactions, split evenly between Claude.ai (Free and Pro) and Claude Code (first party API sessions), from 6 to 13 April 2025. It used Anthropic's privacy preserving analysis tool, which the company describes as one that "distills user conversations into higher-level, anonymized insights." Results from the two surfaces were weighted equally.

Ranked by share of queries, the languages it reported were:

Source: Anthropic, "Anthropic Economic Index: AI's impact on software development", 28 April 2025. Java, Go, Rust and other languages were not reported in the article.

Two other findings from the same study shape the security reading:

• Agents automate more. Claude Code conversations were 79% "automation" (the AI performs the task) versus 49% on Claude.ai. More automation means more code and configuration written with less step by step human involvement.
• Front end work leads. "UI/UX Component Development" was 12% of conversations and "Web & Mobile App Development" 8%, both among the top five tasks. That is consistent with JavaScript, TypeScript, HTML and CSS leading the language list.

Anthropic is explicit about the limits. The study "excluded Team, Enterprise, and API usage that might show different patterns," relies on "educated guesses based on incomplete information" for project types, and "likely captures early adopters." It also measured what developers delegate, not the quality of the resulting code.

The later Economic Index report

Anthropic's September 2025 Economic Index report does not break usage down by language, but it shows the direction of travel. In a sample of 1 million Claude.ai conversations from 4 to 11 August 2025, computer and mathematical tasks were 36% of usage, the largest category. Among first party API customers (1 million transcripts from August 2025), the share was 44%, and 77% of API transcripts showed automation patterns. Within Claude.ai, creating new code rose from 4.1% to 8.6% of tasks across the report's period while debugging fell from 16.1% to 13.3%.

Read together: coding is the largest single use of this maker's models, it is moving from debugging toward writing new code, and when language is measured, web languages and Python dominate.

We looked for similar language breakdowns published by other AI tool makers and did not find one on their own sites. If one appears, it belongs in this table; until then, Anthropic's study is a single maker's view of a single week.

Which languages are AI repositories created in?

This is the sub question most often confused with the main one. Octoverse 2025 counts "AI tagged" repositories, meaning projects that build AI systems, use model SDKs or do machine learning. It is not a count of code written by AI.

Languages in AI tagged repositories, Octoverse 2025

Source: GitHub Octoverse 2025.

Python is far ahead here, and Octoverse adds that over 1.1 million public repositories import an LLM SDK (up 178%), 693,867 of them created in the last 12 months. It also counts roughly 4.3 million AI related repositories in total and about 200,000 monthly contributors to generative AI projects by August 2025.

Why this matters for security even though it answers a different question: AI tagged projects bring their own dependency profile. They pull in model SDKs, data libraries, notebook tooling and container images. Octoverse counts about 402,643 Jupyter Notebook repositories among AI tagged projects. A team building AI features in Python carries PyPI and container exposure whether or not an assistant wrote a single line.

Where the datasets disagree

The disagreements are not noise. Each one tells you what a source is measuring.

The first two rows are the ones that matter most for this post. If you only read the AI repositories figure, you would conclude that AI coding is mainly a Python story. The one direct measurement from a maker says the opposite: people ask an assistant to write web code more than twice as often as Python. Both can be true at once, because building AI and using AI to build are different activities.

Our best estimate, and how confident we are

Putting the proxies together, here is the ranking we think is defensible for languages AI coding assistants write most often in 2025 to 2026, with the evidence and our confidence for each.

The bottom rows are deliberately vague. Java and C# have very large professional user bases, and nothing in the public data says assistants are used less there. The data simply does not exist in public.

Do typed languages change the security picture of generated code?

Partly. The evidence supports a narrow claim and does not support a broad one.

What typing helps with. A type checker catches a class of mistakes before code runs: wrong argument types, missing properties, calls to functions that do not exist on an object. GitHub's Octoverse cites a 2025 study finding that 94% of compilation errors in LLM generated code were type check failures. For an agent working in a loop, a compiler or type checker is fast feedback that lets it correct itself. That is a real quality benefit and plausibly part of why agents and TypeScript fit together.

What typing does not help with. The defects that dominate security findings are mostly not type errors. Octoverse 2025 itself reports that Broken Access Control became the top alert from GitHub's code scanning, appearing in more than 151,000 repositories (up 172%). A missing authorisation check is perfectly well typed. So is a SQL query built from user input, a server side request to an attacker controlled URL, or a dependency pinned to a version with a known CVE.

The dependency angle. TypeScript code runs on the npm ecosystem, and typing does nothing about which packages are pulled in. If anything, a language with a huge package registry and a culture of small packages gives an agent more ways to solve a problem by adding a dependency.

So the fair summary: typed languages make generated code fail earlier on correctness, which is good, but leave the security review burden for logic flaws and third party components roughly where it was. Treat the type checker as a quality gate, not a security gate.

The OpenSSF guide reflects this. Its language specific advice for assistants covers bounds checked functions for C and C++, avoiding unsafe in Rust, the race detector in Go, avoiding exec and eval on user input in Python, and prepared statements and output encoding for JavaScript and TypeScript on Node.js. None of those are type problems.

What do AI tools add to the dependency graph, and in which ecosystems?

No public dataset counts dependencies added by AI tools by ecosystem. We could not find a maker report or platform statistic for it, and we are not going to estimate one. What we can do is reason from the measured pieces.

1. Where the code is written is where the packages come from. If JavaScript, TypeScript and Python lead what assistants write, then npm and PyPI are where assistant added packages land. HTML and CSS rarely add packages on their own; SQL usually adds none.
2. AI projects add their own stack. Over 1.1 million repositories import an LLM SDK, per Octoverse, and Python leads AI tagged projects. Those projects bring SDKs, data libraries and notebook tooling, mostly from PyPI, plus container base images. Dockerfile repositories grew 120% in the same period.
3. Agents act without a human typing the install command. In Anthropic's data, Claude Code conversations were 79% automation. GitHub's coding agent opened more than a million pull requests in five months. When the agent writes the manifest change, the dependency choice can arrive in a pull request diff that reviewers skim.
4. The maker docs treat new dependencies as a specific risk. GitHub's cloud agent checks "newly introduced dependencies" against the GitHub Advisory Database for malware advisories and High or Critical CVSS vulnerabilities, according to its risks and mitigations page. The OpenSSF guide tells assistants: "Do not add dependencies that may be malicious or hallucinated," pin "version ranges or exact versions," check for known vulnerabilities, and generate an SBOM in SPDX or CycloneDX format.

The fourth point is the most telling. When the tool makers and the open source security community both write explicit rules about new dependencies, they are describing a problem they see.

The volume side of the queue

Octoverse gives one more number worth holding next to the AI figures: GitHub's automated dependency update tool opened 40.15 million pull requests and 14.17 million were merged in 2025, and the average time to fix critical vulnerabilities fell from 37 to 26 days. Automated upgrade pull requests are already a large share of repository traffic. More generated code in npm and PyPI means more dependency surface, more advisories that apply, and more upgrade pull requests competing for review time.

What do the AI tool makers' own docs say about reviewing generated code and dependencies?

Every maker we checked tells users, in its own docs, that generated output needs human review. The controls differ. Here is what each says, taken only from the maker's own pages, with no judgement about which is better.

Sources: GitHub "About Copilot cloud agent" and "Risks and mitigations for GitHub Copilot cloud agent"; Anthropic Claude Code "Security"; OpenAI Codex "Agent approvals and security". All fetched 23 October 2026.

Three things stand out for a security programme.

First, the controls that touch dependencies are uneven across tools, so a programme cannot assume every agent checks what it installs. A check that runs in CI, independent of which tool wrote the change, covers all of them.

Second, two of the three make human approval the default path but offer modes that reduce prompts. Claude Code's docs describe Auto mode, where "a separate classifier model reviews actions instead of you," as the built in starting mode for interactive terminal and VS Code sessions. Codex documents an approvals_reviewer setting that can route eligible requests to a reviewer agent. These are reasonable features. They also mean that "a human approved every command" is a configuration choice, not a given, and governance should check which mode teams actually run.

Third, every maker puts the final responsibility on the user. The tools do not promise secure output. The docs say so plainly.

Why the remediation queue grows in TypeScript and Python first

Combine the pieces and the mechanism is straightforward.

1. Assistants write most in JavaScript, TypeScript and Python (Anthropic's data; consistent with GitHub and survey usage).
2. Those languages sit on npm and PyPI, the two ecosystems where adding a package is a one line manifest change and where projects commonly carry deep transitive trees.
3. Agents increasingly make that manifest change themselves, inside pull requests (GitHub's million agent pull requests; Claude Code's 79% automation share).
4. Every package added is a package that will, eventually, receive advisories that need an upgrade.
5. The upgrade work then competes with everything else in the queue. Octoverse's 40.15 million automated dependency update pull requests show how large that queue already is.

None of this says AI generated code is worse than human code. It says there is more of it, it is concentrated in two ecosystems, and part of it arrives with less human attention per change. That is a capacity planning problem before it is anything else.

The same reasoning predicts where the queue grows more slowly: Java, C# and Go projects, where assistants are used but no public data shows them leading, and where dependency changes tend to go through build files that teams already review closely. That is an inference, not a measurement, so check it against your own pull request data.

How should security programmes adjust scanning and remediation capacity per language?

Start from your own data, then use the public proxies to set defaults where you have none.

Capacity decision table

Step by step: put a dependency gate in front of agent pull requests

The aim is a check that runs on every pull request, regardless of whether a person or an agent wrote it, and that makes new dependencies visible to a reviewer.

Step 1. Find which pull requests come from agents. GitHub's docs say cloud agent work lands on copilot/ branches and that commits are authored by Copilot with the requester as co author. List them with the GitHub CLI:

gh pr list --state all --limit 200 --json number,title,headRefName \
  --jq '.[] | select(.headRefName | startswith("copilot/"))'

For other tools, use whatever branch naming or commit trailer convention your team sets, and enforce it.

Step 2. Show new dependencies explicitly in review. A diff of the manifest is easy to skim past. Print what changed:

# npm: compare installed tree before and after the change
git diff origin/main -- package.json package-lock.json
npm ls --all --json > after.json

# Python: show added or changed requirements
git diff origin/main -- requirements.txt pyproject.toml

Step 3. Install without running lifecycle scripts while you check. For npm projects, install with scripts disabled in CI checks, then audit:

npm ci --ignore-scripts
npm audit --audit-level=high

For Python, audit the resolved requirements:

python -m pip install pip-audit
pip-audit -r requirements.txt

For Go modules:

go install golang.org/x/vuln/cmd/govulncheck@latest
govulncheck ./...

Step 4. Run the checks on every pull request in CI. A minimal GitHub Actions job:

name: dependency-check
on: pull_request
jobs:
  npm:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci --ignore-scripts
      - run: npm audit --audit-level=high
  python:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: python -m pip install pip-audit
      - run: pip-audit -r requirements.txt

Make the job a required status check in branch protection. GitHub's docs say branch protections and required checks still apply to agent pull requests, so this gate catches agent and human changes alike.

Step 5. Constrain what the agent can run locally. For Claude Code, permission rules can force a prompt before package installs and block network fetch commands. A project .claude/settings.json along these lines, using the rule syntax from Anthropic's docs:

{
  "permissions": {
    "ask": ["Bash(npm install *)", "Bash(pip install *)"],
    "deny": ["Bash(curl *)", "Bash(wget *)"]
  }
}

Anthropic notes that a deny rule matches the command as written, and points to sandbox network isolation for enforcement that does not depend on command text. For Codex, OpenAI's docs say the workspace-write sandbox keeps network access off unless you turn it on, so check that teams have not set network_access = true under [sandbox_workspace_write] in their config without a reason.

Step 6. Scan the whole repository and its images, not only the diff. With the Safeguard CLI, the same scan covers a directory, a container image or an SBOM, and writes JSON results under ./output:

safeguard scan --dir .
safeguard scan --image my-service:latest
safeguard scan --sbom sbom.cdx.json

Step 7. Track the queue by ecosystem. Count open dependency findings and upgrade pull requests per ecosystem each week. If the npm and PyPI share rises after an AI tool rollout, that is your own measurement of what this post can only estimate from proxies.

Common mistakes

• Treating "AI repositories" as "AI written code". Python's lead in AI tagged repositories says nothing about what assistants write. Use the right figure for the right question.
• Citing TypeScript's rise as proof that AI changed language choice. GitHub says its data is observational. Framework defaults and team choices also drive TypeScript adoption.
• Assuming every agent checks new dependencies. One maker documents an automatic advisory check for new dependencies; the others we read document review duties and sandboxing instead. Put the check in CI so it does not depend on the tool.
• Counting survey "concern" as a risk measure. 81% concern in one survey and 13% in another reflect question design, not two different realities.
• Relying on the type checker as a security control. It catches type errors. Access control flaws, injection and vulnerable dependencies pass it.
• Leaving permission modes at whatever developers chose. Several tools offer modes that reduce prompts. Decide centrally which are allowed for which repositories, and use managed settings where the tool supports them.
• Reviewing the code diff but not the lockfile. Agents often change lockfiles in ways a reviewer does not expand. Print added packages explicitly.
• Planning remediation capacity evenly across languages. The public data, and probably your own, says the load is concentrated in npm and PyPI.
• Using model or tool rankings to set policy. Rankings change monthly and rarely measure security outcomes in your codebase. Govern the workflow (review, gates, scans) instead.

Where Safeguard fits

Safeguard does not detect whether code was written by AI, and nothing in this post depends on that. What it does is make the dependency and vulnerability side of AI assisted development visible and fixable, whatever tool produced the change.

• Scanning. The Safeguard CLI scans repositories, container images and SBOM files (safeguard scan --dir ., --image, --sbom), matches components against vulnerability databases and shows which projects contain a given component and version. Reachability analysis ranks the vulnerable code paths your application actually calls.
• Policies and gates. Policies and gates evaluated in the platform can stop a build or flag a pull request when a newly added component breaks policy.
• Remediation. Griffin fix pull requests (autonomous remediation, generally available) open tested upgrade pull requests. They ship switched off by default, so your team decides what runs automatically.
• Inside the AI tools you already use. Safeguard can be added from Claude's connector directory on web, desktop or mobile with OAuth sign in, and installed from the ChatGPT plugin directory, so an assistant can look up vulnerability and project data while it works. The Safeguard CLI's own assistant can edit code and run commands with your approval, using the /permissions modes Ask, Accept edits, Plan, Auto (the default) and Strict.

Where it does not help: Safeguard does not review the logic of generated code for access control flaws, and it does not replace the human review every maker's docs ask for.

Fix it without waiting for upstream

When assistants add packages faster than teams review them, the remediation queue in npm and PyPI is where that shows up. The question then is how fast a known fix reaches production, and what to do when no fix exists yet.

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

FAQ

What programming language does AI write the most?

No dataset measures this directly. The best available signal, Anthropic's April 2025 study of 500,000 coding interactions, found JavaScript and TypeScript made up 31% of queries, ahead of HTML and CSS (28%), Python (14%) and SQL (6%). GitHub and survey data are consistent with web languages and Python leading.

Is TypeScript the most popular language on GitHub because of AI?

TypeScript became GitHub's most used language by monthly contributors in August 2025, with 2,636,006 contributors, according to Octoverse 2025. GitHub links the rise to agent assisted coding and typed languages, but describes its findings as observational, not causal. Framework defaults are another likely factor.

How many pull requests has GitHub Copilot's coding agent created?

GitHub's Octoverse 2025 says the Copilot coding agent created more than 1 million pull requests between May and September 2025. GitHub did not publish a language breakdown for them.

What percentage of developers use AI coding tools in 2025?

JetBrains' 2025 survey of 24,534 developers found 85% regularly use AI for coding and 62% rely on at least one AI coding assistant, agent or AI code editor. Stack Overflow's 2025 survey found 84% use or plan to use AI tools, up from 76% in 2024.

Do developers trust AI generated code?

Less than before. In Stack Overflow's 2025 survey, 46% said they distrust the accuracy of AI output, up from 31% the year before. Only 3.1% said they highly trust it, and 66% cited answers that are "almost right, but not quite."

Why does Python lead AI repositories if assistants write more JavaScript?

Because the two figures measure different things. Octoverse's 582,196 Python AI tagged repositories are projects that build AI systems. Anthropic's language shares describe code people ask an assistant to write, which skews toward web development.

Is AI generated TypeScript more secure than AI generated JavaScript?

Typing catches type errors early, and GitHub cites a study finding 94% of LLM compilation errors were type check failures. But most security findings, such as broken access control, injection and vulnerable dependencies, are not type errors, so typing does not make generated code secure on its own.

Do AI coding agents check the packages they add?

It depends on the tool. GitHub's docs say its cloud agent checks newly added dependencies against the GitHub Advisory Database for malware advisories and High or Critical vulnerabilities. Anthropic's and OpenAI's docs describe permissions, sandboxing and review duties rather than an automatic dependency check. A CI gate covers all tools equally.

How should a CISO govern AI coding assistants?

Decide which permission modes are allowed for which repositories, require human review of agent pull requests, put dependency and vulnerability checks in CI as required status checks, and plan remediation capacity where the code is written, which for most teams means npm and PyPI first.

See how Safeguard would help

The first demo is a real Safeguard CLI session. You install the CLI, open the interactive terminal and ask it to "fix the lodash CVE in this repo"; it reads the finding and the advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. That is the npm remediation loop this post predicts will grow fastest, with a person approving every step.

Click through it at your own pace, or open it full screen.

The second demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. For teams that already use Claude as a coding assistant, this is how the assistant can look up vulnerability and project data before it suggests a dependency. The quicker route in practice is to add Safeguard from Claude's connector directory; the demo shows the same OAuth sign in and tool choice.

Click through it at your own pace, or open it full screen.

The third demo sets up the Safeguard runner on your own machine, approves it with a device code, then scans from the terminal. It is the starting point for Step 6 above: scanning a repository and its images locally before an agent's pull request ever reaches review.

Click through it at your own pace, or open it full screen.

To try it on your own code, download Safeguard or read the CLI docs. For broader governance of AI coding tools, see AI coding agent governance and AI generated code security risks and controls.

Quick check

Sources

• GitHub, Octoverse 2025: A new developer joins GitHub every second as AI leads TypeScript to #1
• Stack Overflow, 2025 Developer Survey press release
• Stack Overflow 2025 Developer Survey, AI results
• Stack Overflow 2025 Developer Survey, Technology results
• JetBrains, State of Developer Ecosystem 2025
• InfoWorld, 85% of developers use AI regularly: JetBrains survey
• Anthropic, Anthropic Economic Index: AI's impact on software development
• Anthropic, Economic Index September 2025 report
• GitHub Docs, About Copilot cloud agent
• GitHub Docs, Risks and mitigations for GitHub Copilot cloud agent
• Anthropic, Claude Code docs: Security
• OpenAI, Codex docs: Agent approvals and security
• OpenSSF, Security Focused Guide for AI Code Assistant Instructions

Last reviewed: 23 October 2026. Figures are as published by each source on the dates shown; check the linked pages for updates.