Some Thoughts on the Future of Software Infrastructure

Where are we in software infrastructure in the fall of 2026?

Everyone I talk to seems to have a different definition for what “infrastructure” means these days. Pre-AI, the vocabulary was stable— it was dev tools/devops, data infrastructure, machine learning tooling, and security products for the cloud-native, micro-services centric world of software. We were ~15 years post EC2 and S3 launching, and somewhat in the “optimization” phase of the cycle following a period of mass disruption. Technologies like dbt, Dremio, eBPF, Grafana, etc were all top of mind for anyone in the ecosystem…they were the things of that era.

And then disruption hit yet again in the form of generative AI, manifesting with the ChatGPT moment in 2022. Now, the infrastructure stack (and the very definition of what infrastructure means) is in a state of reconfiguring itself again. When thinking about how infrastructure tends to evolve with shifts in the surrounding technology ecosystem, two archetypes of events tend to be large-scale drivers in the emergence of new infrastructure:

• Workload Shocks: A new workload or form of application (and the characteristics embedded in creating them) that pulls in new infrastructure to support it: in the last era, this was SaaS/mobile apps enabled by the Internet and the iPhone. Internet native apps demanded Akamai, native mobile applications demanded Firebase, integrating payments in these applications demanded Stripe, the new speed of software iteration created the need for MongoDB, and the new enormity of semi-structured clickstream and event data created the need for Hadoop/Spark/Kafka. There are many more examples.
• Design Shocks: infrastructure that existed in a previous paradigm still needs to be there! It just has to be redesigned with a new environment in mind, rebuilt for a new nature of usage and consumption. We saw this happen with the cloud, where a number of infrastructure products with on-prem incumbents saw new cloud-native startups take market share: Snowflake disrupted Teradata and Vertica, Datadog and AppDynamics disrupted Wiley Technologies, Crowdstrike disrupted McAfee. In each of these cases, a new technology/delivery model represented a better way for a current system to be built, and the startups that were able to do that built huge businesses.

How is this playing out in the age of AI? We have a net new workload in the form of AI applications (including agents); building and deploying those applications have created the need for inference platforms, eval solutions, model routers, sandboxes, and many other emergent categories of software infrastructure (we wrote about this in our piece on the Agent Runtime). And we also have a design shock, in that AI agents represent a net new consumer of software! If you are to believe that agents will outpace humans as the primary user of software (we’re already seeing this with coding agents like Claude Code and Codex consuming the developer tools required to create applications), it reasons to follow that there will be a next generation of software infrastructure that is wholly optimized and designed for agent consumption.

What does this infrastructure look like and how is it deviating from the previous generation? When thinking of areas of software that would benefit from a product redesigned, from the ground up, for agent consumption, three places immediately come to mind: version control, databases, and search.

Version Control

Version control for code is bound to change as the very nature of code goes through metamorphosis. Git, and the commercial entity around it in GitHub, has been an extraordinary product for the ecosystem that served the developer community well over the last 20 years. But inherently, it was built for human developers and the tempo at which they operate. A few changes per hour, with each one being deliberate and requiring human thought. Even in the age of agile development, GitHub was positioned just fine. And, in addition to a nice UI and functionality that served as a system of record for engineering teams, they had “speed limits” baked into the product:

• A cap at 5,000 API requests an hour
• No more than 100 concurrent requests
• No more than 80 content creation requests a minute
• GitHub even states to “store programmatically generated files outside Git, such as in object storage”

So what happens when the vast majority of code becomes programmatically generated, as a downstream result of coding agents? It’s almost like what happened to road traffic when the default mode of transportation went from horses to cars; any semblance of a prior speed limit was shattered by the velocity of the new reality. The changing technological substrate changes the criteria for what “good version control” means, and nowhere is that reflected more than in the issues GitHub has been seeing. Database saturation was a prime reason for a recent incident, and that is a telltale sign that the infrastructure is receiving more usage than it expected.

New upstarts are rising to solve this. Take Code.storage, for example. They advertise unlimited git requests, unlimited API requests, and unlimited repos. Its API is built for agents rather than humans, with repo creation as easy as “store.createRepo())” and no need for clicking around the site. Their pricing aligns with the agentic-era behavior of “millions of mostly-idle repos”, where hot storage is priced at $0.005 per GB per hour while cold (idle) drops to $0.0002 per GB per hour. Lovable is a customer, and the results they are seeing is astounding: with Code.storage, they’re able to manage a peak repo creation of 250 repos/second, a peak operations load of 15k operations/second, and all that with a 230% improvement in fetch latency.

Databases

While databases have always been mission critical to software applications, the criteria of what makes a great database is similarly undergoing drastic change, given that the dominant database consumer today is not a developer– it’s a developer’s coding agent. Up until this point, databases were designed for an environment of overlaying applications that were scarce and persistent. A developer or team deliberately chose a database, provisioned it, built an application around it, and then accumulated data in it for years. As a result, the database itself could afford to be relatively heavyweight: provisioning could take minutes, infrastructure could remain permanently running, and database migrations were an an out-of-distribution event given the complexity associated with them.

Things change when it’s coding agents spinning up these databases as opposed to IT teams and human developers. All of a sudden, we go from one database per application to one database per application per branch per attempt. Provisioning is starting to happen on a per session and even per exploration path basis. Teams are even scaling to thousands of databases per day! This volume of scaling up and down is something that the prior generation of databases were not designed for.

There are a lot of interesting approaches happening in real-time to build data systems that win the hearts and minds of agents. Databricks’s $1B acquisition of Neon in May of 2025 feels prescient looking back, especially given that at the time of acquisition, 80% of databases created on Neon were being spun up by agents. The team’s release of the Lakebase expressed an interesting point of view on the future of databases: decoupling of storage and compute with both in fully open formats, operations (ie provisioning, scaling up, down, branching, snapshotting, recovery) that can be completed in seconds, and a Git-like developer experience that’s attuned to the current pace of experimentation. Archil takes this idea a step further by treating an agent’s entire working state (not just its database) as something that should be cheap to fork and manipulate; its filesystem can hold SQLite databases alongside code and files, then checkpoint and branch that entire environment so parallel agents can each operate on their own isolated copy.

Search

When you embody human behavior into software, things that were previously consumer applications become net new infrastructure consumed by AI agents. Nowhere is this more clear than the search API space. If we are to expect agents to perform knowledge work tasks at human level capabilities, it’s important for them to have access to the tools humans use to do their work, including the ability to search the web. But while Google Search (one of the greatest products in the history of software) was purpose-built for human consumers back in 1998, the advent of agents created an opportunity to design a net new search system against the behaviors native to these agents. Think about how the interaction model differs:

• A human types in one relatively imprecise query into a box, Google ranks the web according to this query, and the human decides what to read. This entire experience is built around the constraints of human cognition.
• Agents? A single Deep Research query may fan out into dozens of searches, with agents iteratively searching, reading, forming hypotheses, and searching again. Instead of looking at ten blue links, they can process information from dozens or hundreds of sources simultaneously, approaching the search problem like a GPU rather than a CPU. And they don’t care about the visual presentation of a search result at all; the output of search is simply an input into the next step of reasoning.

All of a sudden, the criteria for what makes a great search engine starts to look very different: latency, cost, coverage, and the amount of useful information delivered per token all become paramount. A number of startups have entered this space: Exa, Firecrawl, and Parallel among others. Exa operates its own search engine and offers different retrieval modes across the latency-quality frontier, from ~250ms instant search to deeper searches that spend more time reasoning. Firecrawl approaches the problem from the ingestion/data extraction layer, with its core edge being the ability to turn turn the messy web (JavaScript-heavy sites, PDFs, entire websites) into clean markdown or structured data that an LLM can consume. Parallel treats search as primitive inside a larger reasoning system; its Search API returns ranked, token-dense excerpts rather than results designed to maximize human engagement. The product surface increasingly looks less like a search engine and more like compute for operating over the web.

These are just three categories. Holistically, the design shock of agents being the primary consumer of software is bound to hit every software company in some way shape or form. While humans still like a UI, that interaction between a human and a well designed interface will represent a smaller and smaller proportion of total software activity as time goes on. Clinging on to the UI delivery model is akin to clinging on to the on-premises software delivery model in the late 2000s. The future is that the vast majority of software consumption will happen via agent integration surfaces (MCPs, CLIs, APIs) in the coming years, and pouring deep amounts of effort, intent, and thought into building those surfaces for the best possible agent experience is very important.

Subscribe to Proby on Substack for more musings on what's next in enterprise tech.