The two software development stacks
As a developer tools startup, do you build for the agent-only stack, the AI + humans stack, or both?
Today, virtually all developer tool startups are spending their time trying to rethink their product to serve software engineer with fleets of AI coding agents at their disposal. AI coding agents are changing most, if not all, workflows in the software development lifecycle and are putting enormous pressure on existing tooling for humans to adapt.
Yet, at the same time, a parallel version of the software development lifecycle is emerging - the “agent only” stack. This is the software development stack for code that no human ever sees — code that is written, built, tested, and deployed by an agent completely outside of the scope of a traditional software engineering team. A simple example of this would be any “ephemeral” code written Claude as you interact with it.
Almost no one is thinking about building developer tools for this parallel SDLC, yet I am increasingly confident that all layers of the existing SDLC will be rethought for it.
My central argument in this post is that more developer tools companies should consider going after this market, rather the “human + AI” market, as it is very new, very rapidly growing, utterly underserved, and will likely ultimately eclipse the size of the traditional software development lifecycle tools market.
The agent-only stack
The most obvious version of the “agent-only” stack today is vibe coding applications. Companies like Lovable, Bolt, and Replit are products where, every time a user interacts with the product, a substantial amount of code is being generated behind the scenes. That code needs to be tested, compiled, executed, and hosted somewhere. But it is completely separate from the way we traditionally think about a software engineering lifecycle - there is no pull request, no human code review, and in 99% of cases no human will ever look at that code. The code is an invisible implementation detail rather than an artifact a team of engineers collaborates on.
You are already starting to see “developer tool” startups serve this market in a specialized way - e.g. a few of the major vibe coding startups now use code.storage as their headless git storage layer. This is interesting for two reasons. First, Pierre, the parent company of code.storage, was originally trying to displace Github for humans for a few years, and recently decided to just pivot fully into this direction instead. Second, code.storage is very clearly not attempting to serve the human software engineer use case at all - but is rather going all in on trying to serve the agent-only use case.
I would also argue that the sandbox companies are are version of this - they are essentially cloud development environments for agents, not humans. Indeed, one of the most prominent companies in agent sandboxes, Daytona, was originally building CDEs for humans. This is another success case of a developer tool startup that went all in on the agent-only stack, to great success.
While vibe coding was the first customer segment, the market for these sorts of ideas now extends far beyond just vibe coding startups. Any product that produces dynamically generated UIs or encourages “personal software” as a pattern are using code generation agents to produce code under the hood. Almost every agent using a sandbox is using code generation for things like tool calling, file manipulation, data processing, and similar even if the agent is not in of itself a code gen agent. Any AI tool that supports that idea of “Skills” is writing persistent code that needs to be stored, versioned, and ultimately support operations like merging or approvals. Any Claude Cowork style product is producing numerous files & artifacts that need to be treated like code.
I am quite positive that this agent-only software development stack will end up recreating most of the key ideas that exist in the human SDLC. Code storage is the first step, after which will follow testing, CI, collaborative editing/approval workflows (amongst agents), CD, and monitoring, exactly mirroring the progression that occurred from 2005-2020 with the cloud software development stack for humans.
In simpler terms - there is going to be an invisible, “headless” SDLC that ends up being a core component of most, if not ultimately all, agents.
The strategic question for dev tool startups
This brings me to what I think is the most consequential strategic question for developer tool startups right now: which stack do you build for?
If you are a dev tool startup working on some aspect of the software development lifecycle, you have three options:
1. Adapt for the human-assisted stack — Take what you are building and evolve it for a world where human engineers use agents as part of their existing workflow. This is the obvious move, and it is where most of the market’s attention is focused today.
2. Build for the agent-only stack — Pivot or orient your product entirely around serving the needs of agent-generated code that humans never touch. This space is much earlier, more unknown, and more rapidly changing — but it is also completely greenfield.
3. Try to serve both — Build a product that straddles both worlds. In some cases, this is feasible. An AI code review tool, for example, could plausibly serve both the human use case (by integrating with GitHub Actions and reviewing PRs before humans look at them) and the agent use case (by being a Claude code hook that runs micro-reviews as the agent writes code, completely outside the scope of Github or humans reviewing the review).
Increasingly, my perspective is that if you are a dev tool startup, the right answer is to go all in on the agent-only use case and to deprioritize — or even ignore — the human use case. There are several reasons for this.
First, the market is larger and growing faster. I believe that very shortly, the volume of agent-generated code produced in agent-only contexts — vibe coding apps, vertical AI agents, autonomous systems — will surpass the volume of code produced in human software engineering teams.
Second, the opportunity is dramatically more underserved. The human-assisted stack, while evolving, has a rich ecosystem of existing tools and well-understood workflows. The agent-only stack has essentially nothing purpose-built for it today and no “status quo” solutions. Consider my code storage example earlier - even if your code storage paradigm was dramatically better than git and Github for humans using AI agents, displacing Github is extraordinarily difficult because of the ecosystem & network effects around Github. Every other developer tool integrates with Github, every software engineer is used to Github, and every team has a huge amount of config state stored in their CI pipelines. None of this is an issue if you serve the agent vibe coding an app in Lovable.
Third, the design constraints are fundamentally different. Agent-only developer tools must be built API-first and headless, essentially becoming more like “infrastructure” than a SaaS tool. Deployment may need to be cloud-prem rather than SaaS. The business model must be usage based, not seat based. UIs and workflows don’t matter, and in many cases you need to rethink the core abstractions to serve the agent use case. Finally, fundamental assumptions regarding infrastructure may differ - for example, see how many vibe coding apps struggle with github rate limits on repo creation because repo creation was traditionally a very rare/occasional thing for a human software team, but a vibe coding app probably wants to create a repo per user session. These sorts of factors are also why it will be very hard to serve both agents and human - these are hard fork decisions that are difficult to blend.
Consider observability. What would an observability solution look like for the agent-only stack? All config and setup would need to be via API, dashboards would be completely irrelevant, you’d want to design around an autonomous feedback loop where issues in the deployed software immediately trigger the agent to write new code or update code, and you may very well want to redesign or reconsider the database layer because you will need to deal with a very high volume of “micro apps” rather than a small number of “heavy apps”
Another interesting one to consider is task management. What would a Linear or Asana look like for the “agent-only” stack? Is there room for a product like this?
The hard part about building for this market is it is still so new and emerging. But, that is also what makes it exciting. Today, there are an extremely small number of companies I am aware of focused entirely on this market segment:
Code storage & versioning (e.g. Github for agent-only stack) - https://code.storage/, https://mesa.dev/, https://www.freestyle.sh/
Sandboxes (eg. developer environments for agent-only stack) - Daytona, e2b, Runloop, etc
Essentially nothing in testing, review, CICD, observability, task management, etc
As a result, I think this is a really rich area to explore as a startup right now.