Claude Code Now Writes 4% of GitHub's Commits: What It Means for GTM Teams

The stat that made me stop scrolling

I read a lot of AI-in-sales statistics and most of them are vendor decks dressed up as research. This one was different because it came from SemiAnalysis, an independent research shop that tracks compute and AI infrastructure, not a vendor with a product to sell. Their finding: 4% of public GitHub commits right now are being authored by Claude Code, and at the current trajectory they expect that to exceed 20% of all daily commits by the end of 2026. That is not a survey of intent or a self-reported adoption number. It is commits, the actual unit of software getting built, counted directly off the platform where most of the world's code lives.

What SemiAnalysis actually found

The newsletter frames Claude Code as an inflection point rather than an incremental tool upgrade, and the growth curve backs that up. The share of commits authored by Claude Code roughly doubled in a single month before settling into the 4% figure the firm is tracking now. That is the kind of adoption curve you normally see in consumer apps, not in developer tooling, where habits are famously sticky and switching costs are real. Developer tools do not usually 2x their footprint on the world's largest code host in a matter of weeks. This one did, and it did it without a viral consumer launch, just steady adoption inside teams that already had a reason to ship faster.

Why 4% today matters more than 20% later

The 20%-by-December projection is the number that gets shared on social media, but the 4% figure is the one I actually care about, because it means this is already happening at meaningful scale, not a future scenario to plan around. A GTM team deciding today whether to build an internal tool with a coding agent or wait for the technology to mature is, in effect, deciding whether to wait for a trend that has already cleared the "small experiment" bar and is compounding. Waiting for certainty here has a cost, and that cost is the compounding gap between teams already comfortable directing a coding agent and teams still treating it as a novelty.

From human-as-writer to human-as-orchestrator

The shift underneath this stat is not "AI writes code instead of humans." It is a change in what the human's job actually is. Developers who use Claude Code well spend their time on three things: describing what they need with enough precision that an agent can act on it, reviewing what comes back against the intent they had in mind, and confirming the result actually works once it is live. None of those three skills require years of formal software training. They require the same clarity of thinking a good GTM operator already applies to briefing a rep, writing a sequence, or scoping a campaign. That is exactly why this trend is not staying inside engineering departments.

What this has to do with GTM at all

Revenue teams do not need Claude Code to write production software. They need a handful of specific, unglamorous scripts and systems that never made it to the top of an engineering team's backlog: a job that syncs lead status between two tools that do not natively talk, a script that dedupes a list before it goes to a Forge sequence, a report that pulls pipeline data into the format a VP actually reads. Those are exactly the small, well-scoped, low-risk tasks a coding agent handles well, and exactly the tasks that used to sit in a request queue behind actual product work. A 4%-and-climbing share of the world's commits means the tooling to do this yourself, without waiting on engineering, is not experimental anymore. It is mainstream enough that treating it as a curiosity is the outlier position.

Three ways this already shows up in a GTM stack

1. Enrichment and dedupe pipelines. Pulling firmographic and technographic data from two or three sources, deduping against what is already in a CRM, and writing the clean output back out is exactly the kind of scoped, testable task a coding agent handles in an afternoon.
2. Reporting jobs nobody owns. Every revenue team has a report that exists only because someone manually assembles it every week. A short script that pulls the same fields on a schedule replaces that hour with a few minutes of review.
3. Glue between tools that were never meant to talk. Most GTM stacks are five or six point tools stitched together with manual exports. A coding agent is well suited to writing the small connector scripts that used to require an engineering ticket and a two-week wait.

Building GTM tooling: agency dev vs. a coding agent

Here is the honest comparison I would put in front of a revenue leader deciding how to get a piece of internal tooling built.

Neither column wins outright. The point is that the second column used to not exist as a serious option for a non-engineer. Now it does, and the commit data says it is scaling fast.

Where the Forge stack fits, and where Claude Code fits around it

I run Salesforge for sending and sequencing and Leadsforge for lead data, and I am not looking to replace either with a script I wrote myself. Both are mature, purpose-built products with years of deliverability and data hardening behind them, exactly the kind of system I want a vendor maintaining, not me. Where I reach for Claude Code is the layer around that stack: pulling send and reply data out of Salesforge into a report a client actually reads, syncing enriched leads from Leadsforge into a CRM view a sales manager checks daily, or writing a one-off script that catches a data quality issue before it burns a domain. That division, buy the core sending and data infrastructure, build the glue and reporting around it, is the same split this SemiAnalysis data points to at a much bigger scale. The core, high-stakes systems stay bought. The scoped, internal connective tissue increasingly gets built.

The risk nobody talks about: review debt

The obvious risk with a coding agent is that it writes something wrong. The less obvious one, and the one I actually worry about, is that a team stops reviewing carefully once the agent has been right ten times in a row. A script that dedupes leads incorrectly does not throw an error. It just quietly drops or mismatches records, and you find out weeks later when a rep asks why a known account never got a sequence. The fix is not avoiding coding agents. It is treating anything the agent writes that touches customer data, sending logic, or reporting numbers a leadership team will act on as something that gets tested against a real sample before it runs unattended. Speed of building is not the same as license to skip verification.

What to build first if you are just starting

Do not start with anything that touches live sending or a customer-facing system. Start with a read-only reporting job, something that pulls data and produces an output a person reviews, with no ability to write back anywhere important. That gives you a low-stakes way to learn how to scope a request precisely and review the output critically, the two skills that actually determine whether this works for you. Once that is solid, move to a script that writes to a low-risk destination, like a shared spreadsheet or a staging list, before you ever let a coding agent's output touch a live sequence or a production CRM field.

Where this goes by December

If SemiAnalysis's projection holds and Claude Code's share of commits does cross 20% by the end of the year, the interesting story will not be that more code gets written by AI. It will be that a much larger share of the people directing that code will have never called themselves engineers. Revenue teams that treated this quarter as the moment to build the enrichment scripts, reporting jobs, and connective tooling they always wanted but never got prioritized will be running leaner, more custom stacks than teams still waiting for an engineering roadmap slot that was never going to move up.

FAQ