AI is forcing a redefinition of the developer stack.
A developer stack is more than the software required to run an application. It is the set of technical surfaces a developer routinely touches while building one. During the late 1990s, that idea became closely associated with LAMP: Linux, Apache, MySQL, and Perl, PHP, or Python. A developer lived in those systems. I lived in those systems. I configured Apache, shaped database schemas, installed libraries, changed operating system settings, and wrote application code.
The individual products changed as software moved into the cloud, but the underlying development surfaces remained surprisingly stable. Linux became a VM, container, or managed runtime. Apache gave way to application servers, APIs, and cloud delivery services. MySQL might become PostgreSQL, DynamoDB, or some other managed database. Perl and PHP gave way to newer languages and frameworks. The names changed, but developers were still working with an operating environment, an application delivery layer, a database, and code.
AI is changing those surfaces themselves.
Programming Moves Up a Level
Increasingly, the developer does not begin by writing code. They work through a coding agent such as Cursor, Claude Code, or Codex. The developer describes an outcome, gives the system access to the relevant codebase, sets constraints, reviews the work, and redirects it when necessary. Programming languages remain important, of course, but the human interface to programming is moving up a level. I think the coding agent has become significant enough that it deserves to be treated as a development surface in its own right. We have made this kind of transition before. Early programmers had to think directly about the processor, writing assembly instructions around registers, memory, and the architecture of a particular machine. Higher-level languages moved that work into the compiler. Developers could focus on expressing the logic of a program while the compiler translated it into the instructions the hardware actually executed. Coding agents move the interface up another level. Increasingly, the developer focuses on intent, constraints, architecture, and specifications, while software takes on more of the work of turning those decisions into code.
When you change the layer you operate at, you change the tools you need. An AI application may reason about a problem, choose a tool, gather new information, reconsider what it knows, and continue working. That makes the runtime fundamentally different from the deterministic application logic developers have spent decades optimizing around. You can still have unit and integration tests, but they are no longer sufficient on their own. Developers now have to understand how an agent arrived at an answer, whether it chose the right path, and how reliably it behaves across a range of situations. That work increasingly happens inside the agent runtime itself.
A new layer, the model layer, has also become much more complicated. A single application may use one model for coding assistance, another for low-latency classification, another for difficult reasoning, and entirely different systems for voice, images, or video. Even when several tasks use the same underlying model family, developers still have to make decisions about serving, routing, context limits, caching, latency, cost, and how much infrastructure to dedicate to each workload. I would describe this as a model services layer because the developer is not choosing a single model. They are managing access to a changing set of capabilities.
All of those models need context, and this is where the data side of the developer stack changes most dramatically.
The old application world was built around relatively stable data abstractions such as files, objects, relational tables, and logs. While they remain, useful context now comes from much more dynamic sources. An agent may need to understand what just happened in a live business process, retrieve semantically related material through vectors, remember what happened earlier in a long-running interaction, inspect the result of a tool call, and combine all of that with the authoritative data already held by the application. New AI powered applications have to continuously assemble the right context from information that may have been created in very different ways and at very different times.
I think of these four surfaces as the CAMP stack: Coding Agents, Agent runtime, Model services, and Platform. CAMP is not intended to describe every component inside an AI application. It describes the parts of the environment that increasingly shape a developer's daily work.
Integration Made LAMP Work
The comparison with LAMP becomes more useful when you look at why LAMP worked so well. Its components were well integrated. Linux gave Apache a strong multiuser operating environment and mature networking. Apache modules such as mod_perl and mod_php brought application execution directly into the web server. A URL that a web browser served was literally a direct pointer to the code. Programming languages had mature database libraries that could persist state in a database as easily as in a variable. A developer did not need to constantly build translation layers between them.
That integration mattered because the stack behaved like a system rather than a collection of products. I do not think CAMP can succeed unless it develops the same property.
Consider what happens when an application needs semantic search. If an object has to be copied into a separate system before it can be represented as a vector, the developer inherits another data pipeline and another copy that has to remain synchronized with the source. The problem becomes more serious when security is involved. If the permissions protecting the original information do not remain attached to the semantic representation derived from it, then the application can retrieve something the user was never entitled to see. At that point the vector system is no longer simply a useful capability. It has become another independent data estate that the developer has to govern.
The same issue appears with live data. If an agent is supposed to react to what is happening in the business right now, but the event first has to be landed somewhere, transformed by another service, and then re-ingested before the agent can use it, the architecture has introduced delay and complexity precisely where the application was supposed to become more responsive. I think the platform underneath AI needs to make these different forms of context feel much closer to the underlying data than they often do today.
The requirement for integration extends upward through the rest of CAMP as well. An agent runtime should be able to use different model services without forcing the application to be rebuilt around every provider. Model services should be able to retrieve context without every data source requiring a custom movement pipeline. Coding agents need enough visibility into the rest of the system to understand what they are changing and why an application behaves the way it does. Security rules and operational history cannot disappear every time execution crosses from one surface into another.
Developers Still Need the Controls
LAMP had another quality that is easy to underestimate now: developers could configure almost everything.
The software infrastructure was something developers could shape. Apache rewrite rules allowed a developer to change how requests flowed through an application. Database schemas and indexes were part of application design. Process limits and operating system settings were fair game when the application demanded it.
I think that matters even more for CAMP because the architecture is still evolving so quickly. Developers need to decide which model should handle a particular task and what should happen when that model is slow, expensive, or unavailable. They need to control how context is assembled and how much of it is retained. They need to decide when an agent can call a tool and what happens when that tool fails. They need enough control over the platform to determine how semantic data is produced and how live events enter the application.
Those are developer control points now. Hiding them behind fixed abstractions can quickly become a constraint.
That is why I think CAMP is a useful way to think about modern AI development. Coding Agents, Agent runtime, Model services, and Platform are becoming the surfaces developers spend their time inside. Their value will depend heavily on how naturally they work together, and on whether developers retain enough control to shape the stack around the application they are trying to build.
LAMP became powerful because a developer could move through the entire stack without constantly fighting the boundaries between its components. CAMP will need to do the same.
Putting Names to the CAMP Stack
It helps to put some names against these surfaces, because CAMP is already taking shape around us. Coding Agents, Agent runtimes, Model services, and Platforms exist today.
The Coding Agent market is probably the easiest to recognize. Cursor, Claude Code, Codex, and Factory have become prominent examples of a new interface between developers and code. They are hardly alone. Pi, for example, is a popular open-source project exploring a different version of the same idea. The implementations vary, but the direction is clear. Developers spend part of their day directing software that writes software rather than entering every instruction in the programming language themselves.
I am going to skip A for a moment and move directly to Model services, because that market is already sprawling. OpenAI, Anthropic, Google, and xAI continue to push frontier general-purpose models forward. NVIDIA, Meta, Alibaba, Mistral, Cohere, and others are producing models that can be operated with control over where and how they run. Then there are increasingly specialized models. TwelveLabs, for example, focuses on understanding video, while Deepgram focuses on voice. Every new application has access to a collection of intelligence and capabilities.
Those models can be consumed in very different ways. A developer can rent GPU capacity from providers such as CoreWeave, Nscale, or Nebius and run the model directly, paying primarily for the infrastructure it occupies. Or they can consume inference as a service and pay for the work the model performs on a token basis, through services such as Together AI, Baseten, or Crusoe Managed Inference. You can choose whether you want to own more of the serving stack and pay for compute, or consume model intelligence as a service and pay for usage.
That brings us back to A and P, and there is a reason I have left them together.
VAST takes a different approach to A and P by providing them as parts of the same AI Operating System. There are individual capabilities underneath that description, including AgentEngine, DataEngine, DataBase, DataStore, PolicyEngine, and TuningEngine. I think the more important architectural point is that those pieces share a platform. The agent runtime and the data it reasons over do not begin life as separate islands that developers then have to integrate.
That changes some surprisingly fundamental things. Semantic understanding, for example, does not require creating an independent vector estate disconnected from the source data. Vectors can behave more like another representation of the underlying information, retaining their relationship to the source and its permissions. Structured filtering and vector similarity search can operate together in the same query rather than requiring the developer to shuttle data between unrelated systems. When something changes, the platform can produce an event and trigger work against the same data rather than waiting for another pipeline to copy it somewhere else.
The same integration matters as an agent continues working. Its execution history can become part of the observable state of the system. Events can be followed through the work they trigger and toward the resulting outcome. Data can remain available through the interfaces traditional applications already use while simultaneously becoming context for AI. Even when an application deliberately creates another copy, VAST's underlying data reduction can prevent that logical copy from consuming any raw capacity.
This is the part of CAMP where I think the old LAMP lesson becomes especially relevant. Nobody remembers LAMP because Linux, Apache, MySQL, and Perl happened to be four popular products. They worked well together while still giving developers enormous freedom to configure each layer. VAST's role in CAMP is to provide that tightly integrated A and P foundation while leaving the C and M layers open. A developer can choose Cursor or Codex today and something else tomorrow. The same application can reach models from OpenAI, Anthropic, NVIDIA, Alibaba, or a model running on its own infrastructure. The parts of CAMP that need to share data, identity, state, and execution context can still behave as one system.
Giving the New Stack a Name
CAMP gives a name to the way many developers already build AI applications today.
Coding agents are already part of daily development. Agent runtimes are already becoming a core application surface. Model services are already consumed through APIs, hosted inference, and rented GPU capacity. The Platform layer is where much of the remaining architectural work is happening, because AI applications need live data, vectors, events, memory, and operational context to behave as parts of one system rather than separate services joined by pipelines.
That is where VAST fits. The VAST AI Operating System brings the Agent runtime and Platform layers together, while leaving developers free to choose the coding agents and models they want. AgentEngine can work directly with the same data, events, vectors, permissions, and execution history managed by the rest of the platform, so developers do not have to rebuild those relationships at every layer of the application.
LAMP succeeded because its components were deeply integrated without taking control away from the developer. I think the same requirement now applies to CAMP. The stack already exists, with the VAST AI OS.
