Rebuilding the Cloud for AI Agent Code

0:00For two decades, the cloud has been shaped by human developers writing code and managing its deployment. Now a growing share of production code is generated by LLMs with little human review. Because that code is not fully trusted, it increasingly runs in isolated, sandboxed environments. Meanwhile, AI agents are starting to operate infrastructure directly by spinning services up and tearing them down on their own. Together, these shifts raise the question of whether the cloud needs to be rebuilt for machine operators rather than humans. Render is a cloud platform designed for application deployment by handling scaling, self-healing, and security to reduce operations work.

0:44Render has been adapting to the AI era by building tools that let agents deploy and debug applications directly, with added guardrails and security. Anurag Gohl is the founder and CEO of Render. In this episode, Anurag joins Sean Falconer to discuss why so many teams end up rebuilding the same infrastructure on top of Kubernetes. What changes when AI agents become first-class users of infrastructures and the guardrails that shift demands? And why the economics of AI are pushing developers towards higher-level platforms that trade fine-grained control for speed and safety? This episode is hosted by Sean Falconer.

1:25Check the show notes for more information on Sean's work and where to find him.

1:41Anurag, welcome to the show. Thank you, Sean. It's great to be here. Yeah, absolutely. I've been looking forward to this. So I wanted to go back a little bit in time and ask you a little bit about your history and maybe how some of those experiences led you to the founding, render, and everything that you're doing there today. So you were roughly, I think, around the eighth employee at Stripe? Yes. Yeah, absolutely. So by the time you left, how many engineers were managing AWS? And I guess, like, what did that experience kind of teach you about cloud complexity and the actual cost companies are putting into just simply like managing this beast of the cloud?

2:18Yeah. So at all times when I was at Stripe, around 15 to 20 % of the engineering team was simply managing VMs on AWS and all the complexity around that storage and networking and load balancing. and it didn't really get easier. And obviously as Stripe's scale grew, the complexity increased and you needed to continue to hire people to continue to help you scale. And it just never stopped. I also think, you know, if you think about like Stripe or even other examples of great engineering organizations like that, they're probably one of the best engineering organizations in the world. And if they're running into this problem, clearly it's a problem that's going to essentially impact everyone if they can't figure this thing out.

3:09Yeah, and just to be clear, I do think that Stripe did the best they could at that time because that was really the only way for them to run in the cloud reliably and scalably. But as technology changed, as containerization took hold, it became clearer to me, and I'm talking about the 2017, 2016 era, when a lot of people were containerizing their apps, but then they had to deal with Kubernetes complexity to actually run these containers in production in a way that was scalable or secure or reliable. It became clear to me that you could give app developers, and specifically app developers, not DevOps engineers, because Render has always focused on application developers.

3:57You could give application developers the same powers that they would get from the most accomplished, world-class internal DevOps team. And you could do it in a way that was entirely self-serve for them. And they could simply focus on pushing their code and then get out-of-the-box primitives for scaling, for self-healing, for all kinds of state management. And they would get, you know, effectively one of the best DevOps teams in the world productized. And that's what Render ended up becoming. Yeah, I guess before kind of getting into specifics on Render, what kind of breaks down, like you have people using containers, using containerized orchestration platforms that are well sort of established in the industry like Kubernetes.

4:49But at the same time, it seems like at scale, that's a very hard thing to just manage. So given that there's all this industry investment into Kubernetes? What is it that specifically kind of breaks down as teams start to try to scale the management of that? Yeah, so we do manage a lot of Kubernetes clusters ourselves, and we see this firsthand. I think it all depends on what kind of application architecture you're working with. If it's a really simple application, then it can run anywhere. It can run on Kubernetes, it can run on Heroku, it can run on other cloud providers. But as you start to become bigger, if your business is growing, you start needing more configuration around which applications can talk to each other.

5:36You start needing the notion of CICD needs to work in a certain way. You need to have certain environments be protected. You need certain services to be not available to the Internet. You need observability across all of this. And then you need to be aware of when something goes down, you need to get alerted, and then you need to go solve that problem yourself because you have to then understand, well, you stood up on Kubernetes and you need to understand sometimes exactly how Kubernetes works under the hood to know, well, this network policy change is what caused this DNS error. And with Kubernetes, you have to manage all of these things yourself.

6:17You spin up, even on quote unquote managed Kubernetes clusters, you have to write a lot of YAML by hand that describes how to deploy your applications. But that really what that YAML is doing is describing a lot of the internals of the Kubernetes architecture and the Kubernetes concepts themselves. And then as your application scales, things become bottlenecks. And then you have to kind of manage those bottlenecks by understanding exactly what that is. You might never have encountered it, but suddenly you have a lot of internal DNS traffic because your application grew and now your core DNS isn't working anymore.

6:56Well, who takes care of that? And then you have to go figure out how to configure core DNS to serve all that traffic. So it's every layer of the infrastructure stack within Kubernetes and even below it, because you also have to figure out how to keep your VMs patched when things happen. And you have to deal with node pools and you have to configure different nodes for different things. And you have to make sure that your nodes are also well utilized. You have to pay for a lot of extra capacity because that's what Kubernetes likes to do. And you end up spending way more on just managing lots of unused Kubernetes capacities just so you can deploy your application the next time.

7:34Yeah. And then I think companies end up spending a lot of time on COGS optimization because their cloud bills escalating and getting out of control. I made this point recently about sort of data infrastructure where we have all these great data tools today, but the complexity of actually managing our data has not decreased as we've gotten better tooling. it's actually gotten harder because there's just simply more data, there's more complexity involved, and now we have a bunch of tools that we also have to understand how those things fit together. It kind of sounds like the same problem when it comes to managing network infrastructure.

8:09We have all these great tools, we have elastic scalability, but there's a lot of complexity making this sort of juggernaut of different services work together in a reasonable way, especially at scale. Yes, exactly. And different parts of your application might scale differently. And so you just have to manage all of that across the board. And even understanding Kubernetes is not something you can sort of just do. You can't really build your Kubernetes YAMLs using AI because AI makes mistakes and you have to understand when it does make a mistake. Because something will stop working at 2 a.m. at night and then AI won't really be able to tell you what it should change.

8:51because you just wrote it with AI. You have no idea how the thing works. And then you don't really want to be vibe coding your infrastructure when something's down. Yeah. Yeah. And I would think that I'm sure we'll touch on AI because you can't really have a conversation of technology without talking about AI these days. But as people are using AI to generate more code, we're creating essentially more abstraction from the details of the code. So there's going to be, I think, more buffer between really understanding the deep internals of how that thing was built and run in the interest of essentially speed, which then when things go wrong, of course, makes it even harder to kind of debug and understand what's going on.

9:30Exactly. So I've heard you mention that you've observed that every company that runs on Kubernetes ends up building some version of like an internal pass that all kind of look roughly the same. Why is it that teams end up insisting on building their own thing? It kind of reminds me a little bit of in the early days of auth, Every engineer wrote auth eight different times across every company. And eventually, services came out that take that thing off of people's plate. But why is it that we're still in this place where people are writing these internal passes? I think there's a little bit of, well, this is how we used to do it, so why change?

10:09And there's also a generational thing. A lot of people learn to build cloud infrastructure using the tools that AWS gave them. And then Kubernetes was sort of this state that we ended up in. And you just sort of assume that that is how you always do it or that that's how you will always do it. But I also now see from Render's perspective, we actually see teams moving from large Kubernetes clusters to Render because they get all the functionality that they're looking for without having to deal with the complexity of Kubernetes. And interestingly, that's happening more and more now, just partly because, and I'm sorry to bring up AI again, but so many more people are building so many more applications with AI.

10:57that this whole notion of statically managing your cluster using a DevOps team is breaking down. It's breaking down very quickly because the DevOps teams are stretched thin beyond capacity everywhere. And they're just trying to keep up with the core application. But then everyone else is like, well, I have this other application I want to stand up. Well, good luck because you can only do so much with a small DevOps team or even a large DevOps team. Yeah, I mean, I think that if you look at sort of the traditional software development lifecycle of discovery, design, implementation, testing, productionization, that kind of thing running in a loop.

11:31Historically, the coding part, the implementation piece was like kind of slow and hard. The other things around it could kind of be relatively slow because it was not as slow as the thing in the middle, which was actually writing a code. But now we've compressed that time. So if people generating, instead of having two apps, they're generating two apps a week. The crippling slowdown, the company suddenly becomes the DevOps team, and how do you actually run the platform? Yeah, and that's exactly what we're seeing, and it's why Vendor has grown more in the last two years than in the previous six.

12:02So it's actually really interesting to see so many more companies come to us now that already have existing DevOps teams. That was not the case two years ago. Yeah, it's interesting. So you mentioned that in terms of why is it that companies are still continuing to build their own internal past is perhaps because of the history, essentially, of people being kind of trained to do it. And this becomes sort of the default of like, oh, this is how you have to do it. One of the knocks I've heard historically against platforms as a service that have tried to ease the challenge of kind of running infrastructure has been that at some point, the company outgrows that and you have to get to a place where you're managing the knobs directly.

12:42Do you think that is going away? Or do you think that's an unfounded reflection on the reality of a platform as a service. Yeah, for the majority of applications out there, you really don't need something like Kubernetes. And Render, especially as we continue to add more functionality, more customization, more flexibility, more power to Render, we continue to raise the ceiling on what's possible. And we continue to do that as a platform. Now, I know I've seen other platforms where you hit that ceiling much, much, much sooner. For example, with Heroku, you can't get more than 14 gigs of RAM if you wanted to build an application that did that, or your application was restarted every 24 hours.

13:32And there was just a very small number of compute plans that you got out of the box. Private networking isn't available in the self-serve version. There's no way to store data on a disk. So there were so many reasons for why you grew out of Haruko really quickly. And Render's always built for people who are building complex, ambitious applications. And we want to make sure that you never outgrow the platform because we think that we can continue to raise the ceiling on what a platform can do. And we've been able to do that with a lot of our customers. And some of our, I mean, OpenAI and Stripe are amongst Render's customers.

14:09Obviously, they use other cloud providers, but we also have companies like Base44, which is one of the largest Vibe coding platforms in the world. They're running all of their compute for their web apps on Render. And they're able to scale with Render. They're now part of Wix, and Wix has some infrastructure on AWS, but Base44 runs really well on Render and they want to stay on the platform, even though now they have access to this massive DevOps team inside Wix that has access to AWS. What are the things that you have to do specifically to make it so that people don't outgrow you? And how do you think about sort of balancing, I guess like blurring the lines between automating it, making it really easy and hiding some of the complexity while also giving enough controls to your customer to not outgrow you or not get frustrated with some opinionated view of how this should be done?

15:04Yeah, that is really the crux of how we think about product and specifically progressive disclosure of complexity. So to give you a really simple example, something that happened recently, we gave a customer a specific control that was only available in our REST API because they were creating services through the REST API. They're not using the dashboard. Their use case is actually quite complicated. and they want to use Render just like they would use AWS where they would spin up a VM and install things on it and spin up an application there. With Render, you can do all of that in a single API call.

15:44But most of our users don't need that specific thing that they want. And so we're not going to expose it to everyone in the dashboard. And so it's stuff like that where you kind of think about who needs something and what's the surface area of how they're using Render and how do you expose that feature in a way that is fully productized, fully supported, but it may not be something that everyone has to think about all the time. Agents are getting smarter every day, but even the smartest agents get stuck without the right context and the right tools. That's where Notion comes in. With the recent launch of custom agents, Notion became the collaborative AI workspace where teams and agents work side by side.

16:24And now their new developer platform is turning that workspace into infrastructure developers can build on. What stands out to me about Notion's developer platform is how much they've built underneath the surface. The platform ships with a set of new primitives that change what you can actually do. Workers are Notion-hosted sandboxes where you run custom code, database syncs, agent tools, webhook triggers without spinning up your own infrastructure. The CLI lets developers and coding agents read from Notion, take actions, and deploy workers through one interface. And with the external agent API, you can bring agents like Claude or Codex into Notion as workspace participants with real permissions and triggers, not just a sidecar tab you're copying from.

17:00Pulling in research sources tracked externally, syncing them into Notion, and having an agent help triage what is worth covering, all in the same place the team already works. Learn more about Notion's developer platform today at notion.com.s-e-d. That's all lowercase letters, notion.com.s-e-d, to try Notion's developer platform today. And when you use our link, you're supporting our show, notion.com.s-e-d. If you're running Postgres in production, you've probably felt the moment analytical queries start fighting your transactional workload. Most teams end up adding a second database and all the pipeline complexity that comes with it.

17:35Tiger Data, creators of Timescale DB, takes a different approach. We extend Postgres with hybrid, row, and columnar storage so one table handles both writes and analytical scans. Native compression cuts storage costs up to 95%. Continuous aggregates keep dashboards live without bash jobs. And it scales to petabytes without you re-architecting. Companies like Cloudflare, Octave Energy, Schneider, Axpo, and FlowCo run production workloads on Tiger Data today. No stale data. No second system to operate, just Postgres. Managed for you, ready for the workload you're building toward. Try it free at tigerdata.com.

18:09You're shipping faster than ever with AI coding agents, but those agents don't vet the packages they pull in, and they don't have security contacts built in. Ori by Endor Labs fixes that. It plugs directly into your editor via MCP, catching vulnerabilities, blocking malicious packages and flagging exposed secrets in real time. No separate tool to switch to, no dashboard to babysit, security that fits how you actually build. Teams using Ori see 10 times fewer security tickets and six times faster fixes. Free for developers. Get started at www.endorlabs.com slash A-U-R-I. I guess it's a little bit like you mentioned, sort of progressive disclosure.

18:46It's kind of a little bit like how video games work, where you start on level one, you have kind of limited amount of functionality, And then over time, as you get more comfortable to controls, they add more and more complexity to it. And by the, you know, I don't know, level 15 or something like that, you're an expert, but not everybody's going to get there. You know, some people just want to come into level one and have a good time. Yeah, exactly. And the other thing that is changing is a lot of people are now using Claude or Codex to manage their render deploys. And we have skills and MCP servers that allow them to do that.

19:20and the complexity is hidden away a little bit further from them, even though Cloud and Codex can actually look at all the different things in our API and make the right calls and they can create our infrastructure as code format called Blueprints and they can describe the application of Blueprint so you don't have to understand what a Blueprint even looks like. But the main thing is that Render operates at a much higher level than, say, AWS. We operate at the level of the application. So you don't need to, even if you're using Cloud and Codex, you don't really need to understand a lot of complex infrastructure concepts.

19:57You really need to focus on how really your application runs on render, which is a very small surface area typically, depending on the complexity of your app. And you can debug it fairly easily given the tools that we have. And these days, again, because of the tools we've built for AI agents to debug render, people are able to do a lot more themselves. And again, I should clarify that we're building all of this for application engineers. We're not building for DevOps people. So the kind of tools that DevOps engineers might want, we don't worry too much about not having them. But if you're building a standard AI native company or a SaaS or whatever it is, there's a 95 % chance that you don't need to go to AWS.

20:41And there's a smaller number of companies, like if you're building an infrastructure company yourself, if you're building, say, a database company that needs to really go down to the metal and figure out exactly how the database clusters are going to work together and use some esoteric AWS incantation, then you should not be using render. It's not for you. But if you're an application developer, you can really use render and continue to use render as your application grows. Yeah, it makes sense. I mean, I think that there's always going to be a spectrum, right, of the types of applications that we're building.

21:12Are you building core infrastructure? Are you building more of an application? And do you need scale for users? You mentioned AI management of infrastructure there. How do you think about, as people leverage tools like CloudCode, Cursor, anti-gravity, whatever it is, more and more. I think the tools that are going to be really successful in kind of this agentic engineering era are the ones that are easy to use as a default experience from the agentic engineering experience itself. So has that been something that you've thought about at Render? How do we make ourselves essentially usable by AI and AI agents to be successful in this new wave?

21:49Yeah, we think about it a lot because our users are already using us with Cloud and Codex and Antigravity. They prefer it because they're already in there. They're already coding using these tools. And so why not deploy using these tools? And why not debug your deploys using these tools? So we've made it so that our MCP server can give you all the information that you need, that we expose the right kind of tools that allow you to spin up new applications. But we're also now thinking about how you can build systems that can be reverted if your agent makes a mistake without losing data or without causing some sort of massive disruption to your infrastructure.

22:32We're also thinking about how if we can identify that it's an agent user, then you can say, well, if it reaches this level of severity or this level of cost, then I need a human in the loop to approve it. So those are some things that I think not just render, but everyone will have to build as agents start using these applications more and more using their API or CLI or MCP server. Yeah, I mean, a lot of people talk about like guardrails around these things, but I think from infrastructure, like guardrails around the cost as well, because you don't want to accidentally spin up something that suddenly you have a huge bill for because some agent made a decision that was not necessarily the right decision.

23:10So for MCP, was there specific things that you had to do design-wise that was above and beyond what the render APIs were capable of? Yeah, so when we first launched our MCP, there were certainly some things that we did not put into the MCP that you could use our API for. But in general, our MCP is able to do a lot that Claude and others wanted to do. One of the big things that we did was the ability to really pull logs and deploy data in a way that can then help you troubleshoot failing deploy. And you can get metrics from the MCP as well. And so what we find is that a lot of people use our MCP to debug what's going on, especially when they're developing the application and they're in this loop of quickly pushing code and seeing what happens.

24:01And so it makes it really fast for them to develop on render because all of that stuff is available as tools in Cloud and cloud can correlate deploys with what happened in production. Yeah, I mean, that's a common pattern that we see at Confluent, which is where I work my day job as well. I think the number one use of our MCP server is probably outside of exploring the data that you have would be around debugging. And I've even seen recently some clients out there putting into their contracts with vendors that they're considering purchasing from within the contract, essentially need to know what is their support for agent debugging.

24:41Yeah, it makes sense. Yeah, I mean, it's just the way the world's kind of going. Like, why leave the tool that you're in all day to go and log in some dashboard? Yeah, exactly. And I think dashboards are great for maybe when you're first trying to explore a new tool and you want to understand the different concepts. But once you have a good sense of what's going on, and maybe these days you don't even need that because you can build the exploration into your API or your MCP server, just like any MCP server can expose the tools that are available to the LLM. How do you think about balancing, just from a product standpoint and a resourcing perspective, where to put your resources?

25:23If the world is kind of largely going towards some sort of unified experience from the terminal, from the CLI, interacting through these agents, Does that mean that you put less time and effort behind the user interface, your web-based interface into Render to put more time behind your MCP and your APIs, which are going to be more of the native experience that agents are interacting with you? I don't think that we're treating it that way. We still want to continue to improve our dashboard because I think people do like a visual experience for certain things. And again, if you want to see a lot of information in a very specific way, then often very purpose-built info-dense views that are designed with that workflow in mind might be more efficient than using Cloud or an MCP and might be faster.

26:20So I don't think that we can do either or. So we're actually increasing our investment in both. We're hiring people, we're hiring design engineers to continue to grow the dashboard with all the new tools that we're supporting. And I don't think developers are saying, look, I'd never want to use the dashboard. They're just adding another interface. And it depends on maybe where they are in their journey. If they're coding and pushing code, then sure, they need that MCP server. But sometimes when something goes wrong, sometimes they do need to go into the dashboard or they do need to see all the metrics in one place or they do need to look at all the logs manually.