For the past two years, the conversation about AI-assisted software development has been dominated by speed. A new GitLab survey of more than 1,500 developers and technology leaders found that 60% say AI coding ROI has already exceeded expectations, and 78% report their teams are writing and committing code faster since adopting AI tools.
But speed without control is a liability.
Most organizations have pursued agentic engineering by adding AI coding tools on top of their existing infrastructure. Coding agents are delivering speed, but that speed isn’t showing up across the full software lifecycle: Only 21% of respondents report productivity gains beyond code generation itself.
“Speed without control is a liability.”
The infrastructure problem runs deeper. Git backends, toolchains, and governance frameworks were built for human-scale concurrency. Agents operate at machine scale, and that mismatch shows up fast. Platform reliability breaks down with millions of agent sessions hitting the same backend, security exposure widens as agents touch dependencies at scale, and cost overruns mount as agents consume tokens inefficiently on infrastructure that wasn’t built for them.
Agentic adoption outpaced governance
The adoption curve for AI coding tools outpaced the development of required guardrails, with 80% of organizations saying they adopted AI tools faster than they developed policies to govern them, and 82% reporting that AI-generated code risks creating a new form of technical debt that their organizations are not prepared to manage.
In practice, that means platform reliability challenges under agent load, security and compliance exposure that widens as agents touch dependencies at volume, and agents operating with artificial confidence because they lack full context. Only 28% of organizations say their software development lifecycle tools are fully integrated with shared data and workflows, which means most teams are trying to govern agent actions across a toolchain that was never designed for them.
Agentic engineering needs agentic infrastructure
Agentic engineering requires two things: agentic coding and agentic infrastructure. Most organizations have the first but lack the second.
Agentic infrastructure spans four areas: the execution layer, the context layer, the governance layer, and the orchestration layer working together.
The first is machine-scale execution. Git backends, CI/CD pipelines, and deployment systems were designed for human-paced development. In the agentic era, they need to handle millions of agent sessions without breaking. When a production incident occurs, the path from symptom back to origin should take minutes, not days.
The second is context that travels with code. As Bastian Stahmer, Business Owner of Vehicle Software Development Platform at Mercedes-Benz, put it on a panel recently, “An agent can only be as good as the context and semantics fed to it.” A context graph connecting code, work items, pipelines, security findings, and production signals is what makes agents genuinely useful at scale and keeps artificial confidence in check.
“An agent can only be as good as the context and semantics fed to it.”
The third is governance built into the flow. Agent actions need to be tied to an identity, logged against a policy, and provable to a reviewer. Low-risk changes move fast, while higher-risk changes trigger review. For Mercedes, operating under automotive regulatory standards that require full traceability and human accountability, GitLab is the control plane where that accountability lives.
The fourth is orchestration. Execution, context, and governance are only as effective as the system coordinating them. The orchestration layer coordinates agent actions across the full software lifecycle according to the policies teams define, determining which agents run, in what order, and how failures and handoffs are managed. Without it, agentic infrastructure is a set of independent capabilities rather than a working system.
What’s next
The next phase of AI in software will focus less on generating code and more on governing it, according to 85% of respondents. That shift reflects how enterprises are maturing their thinking about AI, from a productivity tool to a foundational capability that needs to be trusted, traced, and maintained at scale.
When governance is built into the platform, speed and control are no longer in tension. Traceability becomes a competitive advantage. Context becomes institutional memory. And the codebase, rather than accumulating invisible risk, becomes an asset that grows more reliable over time.
The biggest news to emerge from the AI world this week was undoubtedly that Elon Musk’s SpaceX had agreed to acquire AI coding startup Cursor in an all-stock deal valued at $60 billion.
But on the very same day, at an invite-only developer conference hosted by Cursor in San Francisco, Tomas Reimers took to the stage to unveil a fledgling project that could prove just as consequential for the developer tools industry.
Reimers, it’s worth noting, is co-founder of Graphite, a code-review startup that Cursor revealed it was acquiring back in December (a deal that apparently closed in January). At the time, some commentators noted the deal’s implications for GitHub — among them was Gergely Orosz.
Orosz, author of The Pragmatic Engineer newsletter and an investor in Graphite, who wrote on LinkedIn: “I’m telling you: GitHub’s biggest competitor could soon be Cursor. Graphite — in my view — is the best AI code review + stacked diffs + PR workflow product out there. GitHub is already playing catch-up to Cursor/Graphite.”
Put simply, Graphite had already built workflow tools that GitHub was scrambling to replicate — and with Cursor’s resources behind it, the gap was only going to widen. And now with the might of SpaceX, a $2.5 trillion company, behind it, things could be about to get very interesting.
The Origin origin story
On stage in San Francisco ahead of Origin’s unveiling, Reimers pointed to Graphite’s customer base — which includes Shopify, Snowflake, Notion, and Figma — as evidence of a problem already well underway before Origin existed.
“When we were acquired by Cursor, we accelerated our most ambitious project — to rebuild that tooling from scratch.”
“Over the past few years, we noticed the trend as these companies adopt AI tooling,” Reimers said. “The tools that they relied on started to become unreliable. That’s because over the past few years, AI tooling has totally changed our industry. It’s enabled every developer to be a 10 to 100x developer, but that change has required fundamentally different tooling. That’s why, when we were acquired by Cursor, we accelerated our most ambitious project — to rebuild that tooling from scratch.”
Amid all the hullaballoo of SpaceX hitting the public markets, becoming one of the world’s most valuable companies overnight, and doling out a cool $60 billion for a four-year-old startup, it’s easy to appreciate why Origin might have slipped under the radar. But the infrastructure problem it’s setting out to solve is real.
It’s easy to appreciate why Origin might have slipped under the radar. But the infrastructure problem it’s setting out to solve is real.
GitHub, the world’s dominant code hosting platform by some distance, is having a rough time of it. As The New Stackreported in June, the platform has logged hundreds of incidents over the past 12 months, struggling to keep pace with the volume of code that AI agents are generating. The company says it’s now processing about 1.4 billion commits per month — up from 1 billion across all of 2025 — with agents alone generating more than 17 million pull requests per month.
The irony isn’t lost on anyone: GitHub helped kickstart the AI coding era with the launch of Copilot in 2021, and it’s now buckling under the weight of it. And for some, the cracks are already showing in their day-to-day habits.
“Agents are quickly killing the will for doing open source.”
“Agents are quickly killing the will for doing open source,” Douglas says. “I’d love to see what GitHub’s [monthly active user] numbers look like today, because I am sure there are a number of folks choosing to do code reviews elsewhere — or exclusively collaborating with agents to get the work to the last mile — which is at an all-time high.”
Douglas, for what it’s worth, counts himself among them, saying he now does much of his review and PR work directly in AI coding tools.
“As a GitHub power user, I find myself using it less, and relying more on Claude and Codex for review and PR interactions,” he says.
A post-GitHub world?
Origin remains in waitlist-only mode ahead of a planned fall launch, and those present at Compile reported enough detail to sketch its ambitions. Developer advocate and independent commentator Shawn Wang Yuexian, known as swyx, described it as a “long-awaited Git competitor, scalable for agent workloads, extensible with API and MCP, and with built-in merge conflict and CI failure agent resolution.”
Whatever Origin looks like in its launch guise, it’s clear the appetite for an alternative to the status quo is growing. The software development world has changed considerably since GitHub popularized the pull request model back in 2008 — a feature that Douglas calls its “best ever.” But the pull request was designed for a world where humans deliberately wrote and reviewed code, one change at a time. That world is receding fast.
“Right now, the velocity of projects being created is overwhelming GitHub, and engineers are not looking at the code.”
“Right now, the velocity of projects being created is overwhelming GitHub, and engineers are not looking at the code,” Douglas says. “So if the goal is to put it in the cloud so agents are managing the code, I think that is absolutely an opportunity for disruption.”
So, as AI agents push code at a rate no human reviewer can keep up with, the pull request risks becoming a formality — a box to tick rather than a meaningful quality gate. Which raises a deeper question about how the industry should measure the value of software work at all.
For Douglas, the answer lies in a different unit entirely. Commits and lines of code — the traditional proxies for developer output — tell you little in a world where an agent can generate thousands of lines in seconds. Tokens, by contrast, map directly to compute cost and, therefore, to the real effort and value generated. It’s a reframing that suits Cursor rather well.
“Tokens are a better metric than commits.”
“Tokens are a better metric than commits,” Douglas says. “They align to a dollar spent that correlates to the effort of work. Previously, we pretended lines of code were the metric, and that was proven incorrect. But tokens plus agent sessions equals customer value — and Cursor is positioned well to own a deeper part of the collaboration stack.”
Cursor, though, isn’t alone in that conviction, and a slew of tangential efforts to rebuild that infrastructure for the agentic era are emerging.
At its Transcend conference in London on June 10, GitLab announced a private beta of what it calls Next Generation Source Code Management — known internally as Project Switch. Unveiled on stage by GitLab chief product and marketing officer Manav Khurana, the new backend keeps the Git protocol intact but redesigns the underlying architecture entirely, allowing agents to query repositories server-side rather than cloning them in full.
GitLab says it delivers up to 50 times faster task execution per agent, with up to 3 times fewer tokens consumed. And notably, Anthropic is a design partner on the project.
“The most popular Git platforms in the world are buckling under the load, not just because of your teams cloning, branching, and merging code, but also dozens, in some cases hundreds, of agents working simultaneously and putting a lot of pressure on those systems,” Khurana said.
The day after GitLab’s Transcend announcement, Zed co-founder Nathan Sobo published details of DeltaDB, a project the company had first teased the previous fall. A more radical proposition than either Origin or Project Switch, DeltaDB replaces Git’s commit-based model entirely with a continuous stream of fine-grained deltas — every operation an agent performs, linked directly to the conversation that produced it. Sobo confirmed that a beta version is just weeks away.
HashiCorp co-founder Mitchell Hashimoto, meanwhile, has seen this coming. Back in December, he wrote on X: “The AI companies are on track to become GitHub faster than GitHub is becoming an AI company.”
The AI companies are on track to become GitHub faster than GitHub is becoming an AI company. I'm sure there's a lot of sycophants within GH/MS showing off PowerBI dashboards to argue against this for their own personal gain, but wake the fuck up.
Hashimoto, as it happens, is an investor in another agent-native code hosting startup called East River Source Control (ERSC), which is building a Git-compatible platform designed to land thousands of commits per second.
The model is the moat
For Douglas, the convergence of competing efforts to rebuild version control from the ground up isn’t hugely surprising. In the past year, he points out, a similar dynamic played out with developer sandboxes — the environments where code gets written and tested — as companies like Docker, Cloudflare, and Vercel moved into that space because that’s where developers were spending their time.
The same gravitational pull is now acting on version control. The way developers work has changed fundamentally — where once they wrote code directly inside their editors, many now spend their time directing AI agents that do the writing for them. The IDE is no longer primarily a place to type; it’s increasingly a place to watch, review, and steer.
“I think all the folks who are part of the story have a shot, and we need to rethink our infrastructure to prepare for this.”
“Now, IDEs are suffering from the fact that developers have evolved to foundational model harnesses writing code, and they need to position themselves as the tool you open to watch agents write the code,” Douglas says. “I think all the folks who are part of the story have a shot, and we need to rethink our infrastructure to prepare for this.”
Underpinning all of this, though, is a commercial reality. Cursor has been building toward this position for some time, having launched its own first-party coding model, Composer, in 2025 and iterating on Composer 2.5 in May, giving it cheaper, in-house inference rather than relying entirely on costly API calls to Anthropic and OpenAI. Composer 2.5 costs a fraction of Claude Opus at equivalent tasks — as much as a tenfold difference on output tokens. Owning the model, in other words, is what makes owning the rest of the stack viable.
Introducing Composer 2.5, our most powerful model yet.
It's more intelligent, better at sustained work on long-running tasks, and more reliable at following complex instructions.
“It’s clear you can’t just insert an OpenAI key and expect hyper-growth or longevity in this market anymore,” Douglas says. “Instead, you need to own the model to win.”
Whether SpaceX’s firepower accelerates that ambition or complicates it remains to be seen. But the companies placing bets on the next era of software development aren’t waiting for GitHub to catch up.
A recent GigaOm CxO Decision Brief explores how AI retrieval architectures are evolving beyond flat vector databases as organizations combine semantic search, ranking, personalization, and machine learning inference in production systems.
Vector search changed the AI infrastructure landscape by making semantic retrieval practical at scale. By converting text, images, and user behavior into embeddings, organizations could move beyond exact keyword matching and retrieve information based on meaning. But production AI systems rarely stop at vector similarity.
A real-world query often requires multiple signals to be evaluated simultaneously. Semantic relevance may be one factor, but so are structured attributes, business rules, personalization signals, freshness, access controls, recommendation logic, and machine-learned ranking models. As organizations move from AI experimentation to production-scale applications, the challenge is no longer simply finding similar items. It is in combining all of the signals that matter while maintaining low latency and operational simplicity. This is where tensors are attracting increasing attention.
While vectors represent information as a single dimension of numerical values, tensors provide a more general framework for representing and operating on complex, multi-dimensional data structures. They offer more control in how relevance is computed, allowing dense embeddings, sparse features, metadata, and model outputs to be evaluated together within a unified retrieval and ranking process. For organizations building large-scale retrieval systems, this raises an important architectural question: is a flat vector store sufficient, or does the next generation of AI applications require something more expressive?
“Tensors provide a more general framework for representing and operating on complex, multi-dimensional data structures.”
A new GigaOm CxO Decision Brief, “The Tensor Advantage in AI Search,” explores this question in depth.
Among the findings:
Production AI systems increasingly depend on combining semantic, lexical, behavioral, and business signals rather than relying on vector similarity alone.
Architectural fragmentation between vector databases, search engines, rerankers, and feature stores introduces latency, operational complexity, and synchronization challenges that become more significant as workloads scale.
Emerging retrieval models, including multi-vector and late-interaction approaches, place new demands on infrastructure that were not anticipated when first-generation vector databases were designed.
Tensor-native architectures provide an alternative approach by treating multidimensional data structures as first-class citizens rather than forcing them into simpler vector abstractions.
The paper also examines the infrastructure, operational, and organizational implications of these architectural choices, including benchmark data, deployment considerations, and the trade-offs engineering leaders should evaluate when planning future AI retrieval systems.
“Retrieval is evolving from a nearest-neighbor problem into a ranking and decision-making problem.”
As AI applications become more sophisticated, retrieval is evolving from a nearest-neighbor problem into a ranking and decision-making problem. Understanding the role tensors play in that transition may be one of the most important architectural discussions facing engineering leaders today.
GitHub hasn’t had an easy year. The platform has been hit by repeated outages affecting core services — including the Actions-based CI/CD pipelines that engineering teams depend on daily — and has had to issue public apologies as a result.
The scale of the problem is staggering: Where GitHub handled roughly 1 billion commits across the whole of 2025, it now processes 1.4 billion every month, with AI agents alone responsible for more than 17 million pull requests in the same period. GitHub’s COO Kyle Daigle told The New Stack in early June that the company is now targeting capacity to handle 30 times its current load — a challenge he described as far beyond the normal playbook of adding more machines.
Against that backdrop, Microsoft has chosen this moment to make its most direct push yet to push enterprise customers off Azure Repos — its own Git-based source code platform, which has existed in various forms since 2013, predating Microsoft’s $7.5 billion acquisition of GitHub in 2018 — and onto GitHub.
The exit ramp
The tool Microsoft is using to make that case is Enterprise Live Migrations (ELM), currently in limited public preview. The core problem it solves is downtime: previously, moving large repositories from x to x could take days, leaving teams frozen out of active development.
In a blog post authored by Soo Stahl, principal product manager at Azure DevOps, and product manager Bhuvan Shah, the pair explain that ELM works by keeping the source and destination repositories in sync while developers continue working in Azure Repos, with a final switchover window that they say typically takes under 30 minutes.
“Teams can migrate at their own pace, without coordinating complex, high-risk ‘all-at-once’ migrations.”
“This means no extended freeze periods, no multi-day outages – just a controlled, predictable transition that fits into your operations,” they write. “Teams can migrate at their own pace, without coordinating complex, high-risk ‘all-at-once’ migrations.”
There are real limitations worth acknowledging. ELM carries over the fundamentals — full Git history, branches, tags, pull request metadata, including comments and user history, and branch policies translated into GitHub rulesets — which, for teams whose work is primarily code-focused, may cover most of what they need.
But pipelines, work items, wikis, and test plans all have to be handled separately, and for enterprises deeply embedded in Azure DevOps’s broader project management and CI/CD tooling, ELM is a starting point rather than a complete solution.
For large organizations with hundreds of repositories, this is a multi-stage undertaking regardless.
Migration to GitHub
For Microsoft, the calculus is all about AI — GitHub is where Copilot, the Copilot Coding Agent, and the broader agentic development suite live, and Azure Repos is not part of that picture.
To demonstrate that this is more than a customer pitch, Microsoft recently published details of its own migration — its Copilot, Agents and Platforms (CAP) organization moved over 1,600 repositories and 3,100 developers across in six months, with a team of just two dedicated engineering leads driving the effort.
By consuming its own dog food at scale, Microsoft is making the case that the disruption is manageable and the payoff meaningful. Poonam Gupta, partner director of product management for 1ES and Azure DevOps at Microsoft, cites AI as the primary driver of the migration.
“Software development is being reshaped by AI, and where code lives now have a direct impact on how much value organizations can capture.”
“Software development is being reshaped by AI, and where code lives now has a direct impact on how much value organizations can capture,” Gupta writes. “For teams that want to take full advantage of AI-native development, repository location is becoming a strategic decision.”
The elephant in the room
Rumors of Azure Repos’ eventual deprecation have circulated online for years, and while Microsoft has not confirmed anything on that front, the direction of travel is clear.
The community response to Gupta’s June 3 post captured the mood among enterprise customers: several questioned why AI capabilities couldn’t be brought to Azure Repos rather than requiring a platform change, while others raised the cost differential — Azure DevOps Basic costs $6 per user per month, compared with GitHub Enterprise’s $21.
And more than one commenter interpreted the post as a deprecation notice in all but name. “The writing was on the wall since MS [Microsoft] bought GitHub,” wrote one commenter. “[Azure DevOps] is dead and MS wants everyone moving to GitHub… Everybody saw this coming, and only MS denied it.”
Perhaps more important here is the question that Microsoft sidesteps: if GitHub has spent the past year struggling under the weight of agentic development traffic, why is now the right time for enterprises to bet their critical infrastructure on it?
The timing acquired an extra layer of awkwardness on Friday, when 73 Microsoft-owned GitHub repositories — including the Actions used to deploy Azure Functions — were disabled in a Miasma worm attack, breaking CI/CD pipelines for developers globally.
None of this necessarily undermines the strategic case for moving to GitHub. The AI development ecosystem is consolidating there, and the migration tooling is getting meaningfully better. But for enterprise teams weighing the decision, reliability and security aren’t footnotes — they are the main criteria. Microsoft is betting that access to Copilot and agentic workflows is compelling enough to tip the balance.
It may well be right, but a 30-minute cutover window is only part of what it will take to make that argument stick.
AI retrieval has moved well beyond embeddings and vector search. Early retrieval architectures focused primarily on semantic similarity. Still, production AI applications increasingly demand more from the retrieval layer: combining keyword matching, semantic retrieval, ranking, and real-time signals within a single request path.
Vector databases solved an important problem by making semantic retrieval practical. But production AI systems increasingly require more than retrieval alone. Customer-facing applications such as search, recommendations, and RAG must retrieve, filter, and rank results in real time while serving large user populations under tight latency constraints.
As systems evolve toward conversational, research-oriented, and agentic workflows, retrieval performance, ranking quality, and architectural simplicity become increasingly important to maintaining relevance at scale.
In recently published research commissioned by Vespa, GigaOm explores how AI search platforms are evolving as organizations move beyond standalone vector search toward more integrated retrieval and ranking architectures. Rather than focusing purely on model quality, the report examines the operational and architectural trade-offs that emerge as AI workloads move into production.
GigaOm’s findings
AI retrieval architectures have become more fragmented over time. What begins as a straightforward search stack often evolves into a collection of loosely coupled systems: lexical search, vector retrieval, feature serving, reranking, synchronization pipelines, and model infrastructure.
“What begins as a straightforward search stack often evolves into a collection of loosely coupled systems.”
GigaOm’s view is that the operational overhead of connecting and maintaining these layers is becoming a limiting factor in itself, slowing iteration cycles and making every relevance improvement dependent on coordinated changes across multiple systems.
One of the more interesting findings in the report is that consolidation is not framed primarily as a procurement exercise but as an engineering and systems design decision. GigaOm argues that teams increasingly pay for fragmentation through duplicated data movement, synchronization logic, operational maintenance, and cross-system tuning.
The hidden cost is not simply infrastructure spend but the engineering effort required to keep retrieval pipelines aligned, rather than improving ranking quality, personalization, and user-facing AI capabilities.
“The hidden cost is not simply infrastructure spend but the engineering effort required to keep retrieval pipelines aligned.”
The report also suggests that platform convergence matters because modern retrieval workloads increasingly combine keyword search, vector retrieval, real-time features, and ML-based ranking in the same request path.
GigaOm highlights architectures that bring these stages closer together to reduce latency, improve data freshness, and simplify experimentation, while acknowledging trade-offs such as concentration risk and migration complexity.
Rather than recommending wholesale replacement, the report advocates a phased adoption approach, beginning with ranking and validation on production workloads before progressively consolidating retrieval capabilities.
Login
