After Infrastructure-as-Code (IaC) comes Infrastructure-as-Prompt (IaP). At least, that’s how Dmitry Panenkov, founder and CEO of emma, sees it. IaC is reaching its limits. So IaP provides an extra layer of abstraction to circumvent those limits, offered, of course, by emma. What exactly is Infrastructure-as-Prompt? And why is Luxembourg-based emma introducing this new way to build digital infrastructure?
Infrastructure-as-Code was a great way to build and run (cloud) infrastructure, Dmitry tells us. However, platform engineers were primarily focused on all kinds of different IaC tools in order to set up the entire digital infrastructure as effectively as possible based on what they thought the intended purpose was. As environments become increasingly complex, they also have to manage more and more resources. This will inevitably have consequences for how quickly the infrastructure can be built and maintained.
If it were up to Dmitry, the above approach would come to an end. He bluntly calls Infrastructure-as-Prompt the replacement for Infrastructure-as-Code. “In principle, the idea remains the same, you describe what you want, but you use natural language instead of a scripting language,” he says, summarizing what IaP ultimately is.
IaP is built on an existing platform
Based on the description above, you might think we’re dealing with a kind of chatbot for vibe coding, similar to what’s offered by well-known LLM providers. However, that’s not the case with emma’s IaP approach, Dmitry explains. IaP uses the entire underlying platform that emma has built over the past eight years.
Internally, the company was the first to make the switch from IaC to IaP. According to him, that actually didn’t require much work at all. Expanding the Unified API gateway to also support MCP, for example, was a breeze. So it made perfect sense for emma to make what worked well internally available through its own management platform as well.
emma keeps AI in check
However, AI can’t simply be layered on top of anything, no matter how good the underlying platform is. emma has therefore made the necessary updates to its own platform to effectively adapt to how agents work. In addition, it adapted to how people interact with them. “If you give it a prompt, it does exactly what you want it to do. If it doesn’t understand what you want to do, it asks more questions, for example to make it more specific,” Dmitry explains. The cheapest instance for a specific workload might well be located somewhere you don’t want to run that workload, for example. The AI agents that emma deploys can ask for clarification.
When we ask further questions to understand how IaP actually works at emma, we learn that it’s a fairly finely-meshed approach. IaP uses more than 180 AI agents, all working simultaneously. Each agent has a very limited set of tasks. For example, there are agents that monitor. There are also agents for security, agents that deal exclusively with connectors, and agents that manage network connections.
According to Dmitry, the best way to visualize how IaP works is to think of it as an army, where soldiers, officers, generals, and the highest-ranking member, the human, go into battle together. Each of them does exactly what they’re supposed to do. Specifically, that might mean “make sure you get an IP address,” “read this API,” or similar tasks. Each AI agent then confirms what it has done.
All in all, every command passes through five layers. The entire process takes only a few seconds, so it’s also quite fast. Additionally, according to Dmitry, you have a constant overview of how it works and what steps are being taken. You can even make adjustments yourself during the process.
Why emma?
emma has clearly put a lot of effort into developing IaP. Given its history of abstracting IaC to a higher layer, it’s also conceptually one of the most suitable parties to further develop IaC toward IaP. After all, part of the IaC approach has always been that it had no commercial preference regarding where workloads run. It also doesn’t have a preference about what infrastructure is used for them. It was able to do so because it supports a broad spectrum of providers. According to emma itself, there are now more than 15 such providers, ranging from hyperscalers, sovereign clouds, and AI clouds to on-premises providers.
Another key component of emma’s story is its own 400 Gbps private backbone. This means that emma does not have to charge egress fees when data needs to be transferred.
All in all, emma has a strong case for bringing Infrastructure-as-a-Service to market. The demos we’ve seen combine performance, cost, and governance to ensure workloads always run where they perform best. Integrations with messaging apps mean it isn’t necessarily necessary to log into a dashboard when a notification comes in that something is going wrong. The engineer can simply send a message back. They can take immediate action that way.
No reason to keep using IaC
Dmitry is clear during our conversation. There is absolutely no reason for organizations to continue using Infrastructure-as-Code. “It’s just another way to achieve the same result,” he says. Assuming that the framework emma has built for the AI agents used by the platform can actually keep those agents in check, IaP could be very interesting. This is particularly true for organizations that are already hitting the limits of IaC. It is also attractive for those that are actively working to make AIOps a priority.
At the end of the day, Infrastructure-as-Prompt isn’t a hugely revolutionary concept, as it builds on the same principles as Infrastructure-as-Code. However, it does need to be implemented properly. emma is convinced that it is excellently positioned for this. It has already undergone this evolution itself. Now it’s up to the rest of the market.
Read also: emma wants to make multi-cloud accessible for everyone