Santosh Praneeth Banda is a senior technical leader in the developer platform space who has pioneered ways to accelerate software delivery and reduce infrastructure complexity. He is known for introducing production-first, multi-tenant architectures that replace slow, fragile staging environments with safe, real-time testing in live systems. By focusing on scalable developer platforms and robust infrastructure, Santosh’s work has helped empower engineering teams to iterate faster without compromising safety or reliability. In this expert Q&A, Santosh Praneeth Banda, shares how innovations in isolation, orchestration, and observability are redefining how software — and the teams behind it — operate at scale.
Interviewer: Developing software “at production speed” sounds ideal, but also challenging. What are the biggest obstacles to scaling software development in production-like environments, and how have you addressed them?
Santosh: One of the biggest challenges is that traditionally, production was seen as too risky for testing new features. Modern software development especially craves production-scale data and compute to truly validate performance, but using live environments for experiments was long considered off-limits. Early in my career, many believed it was impossible to safely test large applications (or any complex code) in a live system due to the risk of impacting users.
I encountered this firsthand; staging environments just couldn’t mimic the scale or realism we needed, and that slowed down our iterations. The turning point was realizing we could engineer our way past those risks. We designed a multi-tenant, production-first testing model that isolated experiments from real users while still running in the real environment. We leveraged technologies such as service mesh for traffic routing and strict data isolation so that even though we were “in production,” our tests were contained and safe.
It wasn’t easy; it took deep experimentation, convincing stakeholders, and changing long-held habits. Step by step, we proved it could work. By starting small, enforcing strong safety guardrails, and being transparent with results, we built trust in this approach. In the end, we saw on the order of 10× faster feedback loops for our developers. In fact, the success of this model inspired similar approaches at other tech companies. That journey taught me that what feels “impossible” in scaling software development can often be solved with a mix of technical ingenuity, persistence, and a clear vision for safety.
Interviewer: How did your earlier infrastructure work influence your later innovations in developer platforms?
Santosh: My foundation was in large-scale infrastructure — ensuring that systems could scale efficiently, tolerate failure, and recover automatically. Early on, I worked on infrastructure that optimized database replication, fault tolerance, and distributed consistency across global data centers. Those experiences taught me how resilience and performance are tightly linked to developer productivity.
Building developer platforms draws on the same principles. When systems are predictable and recovery is automated, developers move faster because they trust the platform. The transition from infrastructure to developer experience wasn’t a change in philosophy — it was a continuation. Both require designing for scale, safety, and clarity.
Interviewer: Why move away from traditional staging environments? How does a multi-tenant, production-first workflow change the game for developer velocity and safety?
Santosh: For decades, staging environments were the de facto way to test changes – it’s what everyone used because touching production was taboo. The problem is that staging is often slow, brittle, and never truly identical to production. You might spend days testing in staging only to hit unseen issues when you finally go live. By transitioning to a production-first workflow with multi-tenant isolation, we flipped that script.
In a production-first model, every developer can test their changes in a live system sandbox, essentially an isolated slice of the real production environment. Because it’s isolated, it doesn’t affect real users, but it behaves exactly like the actual product. The impact on developer velocity is dramatic: feedback that used to take days or require a full release now comes in minutes or hours. Engineers can validate how their code runs under real conditions immediately, which cuts down release cycles and boosts confidence.
Importantly, this approach improves safety too. Since you’re testing in the real environment, you catch issues that a staging area might miss, before they reach users. And if something does go wrong in a test, the blast radius is contained to that sandbox. In my experience, moving to this kind of workflow set a new standard for reliability; we could deliver features faster without the “move fast and break things” mindset. Instead, it’s move fast and don’t break anything, because you’re testing in production responsibly. It fundamentally changes how software gets built: developers spend less time waiting and more time building, all while trusting that if it works in the test sandbox, it will work in production for everyone.
Interviewer: You often mention the importance of fast feedback loops and real-time observability. Why are these so critical in modern AI and software development?
Santosh: Quick feedback loops are the lifeblood of innovation. The faster you know whether a change works or a model is performing well, the faster you can iterate and improve. I learned this lesson early on.
During my time at a large social networking company, I saw firsthand that even small improvements in developer feedback loops led to massive productivity gains across thousands of engineers. When it comes to AI development, this is especially true. You need to train, tweak, and retrain models rapidly, and you can’t afford to wait weeks to find out a model’s behavior in a real environment. Shortening that loop from idea to result means your team stays in sync with what’s actually happening, which accelerates learning.
Now, real-time observability is what makes those fast loops safe. If you’re going to be testing in something close to production, you must have visibility into everything that’s going on. Observability tools and telemetry let us monitor experiments as they happen. The systems are instrumented with these tools so that every test run, every new model deployment, streams back metrics and traces in real time. That way, if an anomaly or error pops up, we catch it immediately. It creates a tight feedback loop not just for developers writing code, but for the system itself to tell us how it’s behaving.
In practice, real-time observability has been our early warning system and our guide; it gives developers confidence to move quickly, knowing that if something’s off, we’ll see it and can respond right away. Ultimately, fast feedback and observability work hand-in-hand: they turn development into a continuous conversation between the engineers and the live system, which is crucial for building complex AI systems safely at speed.
Interviewer: Enabling safe, scalable experimentation at production scale requires the right infrastructure. What key architectural choices did you make to support this?
Santosh: One key decision was to embrace container orchestration from the start. We used Kubernetes to spin up ephemeral, isolated environments on demand. If a developer needed to test a new machine learning model or a service change, the platform would provision a containerized instance of that service (and any dependent components) in seconds. This environment was a replica of production in terms of configuration, but isolated in terms of data and scope.
Another crucial piece was how we routed traffic. We implemented context-based routing, essentially using identifiers (with the help of telemetry data) to ensure that test requests from a specific developer or session would be routed only to that developer’s isolated instance. This is where OpenTelemetry-based context propagation came in handy: it allowed us to tag and trace requests so they flowed through the correct pathways without bleeding into the main system.
Data isolation was also non-negotiable. We made sure that any data generated during experiments was kept separate from real user data, often by using dummy accounts or separate databases for test runs, so even in a worst-case scenario, a rogue experiment could never affect live customer information. By combining these architectural choices—on-demand ephemeral environments, multi-tenant isolation, intelligent request routing, and rigorous observability—we created a platform where experimentation could happen safely at scale.
Developers could run hundreds of experiments, using real workloads, and the system would handle the orchestration and cleanup automatically. This kind of architecture turns experimentation from a risky, infrequent event into a routine part of development. It enables teams to push the envelope with AI models and new features, because the infrastructure has their back, maintaining safety and performance no matter how many experiments are running.
Interviewer: What lessons have you learned from implementing these systems in large-scale engineering organizations? Any advice for teams looking to adopt production-first practices?
Santosh: One of the biggest lessons I’ve learned is that scale doesn’t come from complexity; it comes from clarity. In other words, the most impactful systems we built succeeded not because they were overly intricate, but because they made life simpler for developers. If you want hundreds of engineers to adopt a new platform or workflow, it has to remove friction from their day-to-day work. We focused on turning slow, manual processes into fast, intuitive experiences. When something that used to take an afternoon now takes minutes, and it’s easier to do, people naturally embrace it. True innovation often lies in eliminating unnecessary steps and making the complex feel effortless.
Another lesson is about people, not just technology. Driving a change like moving to production-first testing in a large org taught me the value of influence over authority. You can’t simply mandate engineers to change their habits; you need to earn their buy-in. I found that success came from empathy and patience: listening to concerns, demonstrating improvements, and aligning the change with a shared vision of better quality and speed.
As I often say, technology may be logical, but progress is always human. Finally, a piece of advice I share with others is to focus on leverage, not control. The goal should be to build tools, systems, and even teams that outgrow you. If the platform you create only works when you’re personally involved, then it won’t scale. But if it empowers others to do more even when you step away, that’s real impact. Lasting impact in large organizations isn’t about what you can accomplish alone – it’s about what you enable everyone else to accomplish because of the foundations you put in place.
Interviewer: Looking ahead, what are your thoughts on the future of developer platforms, especially as AI gets more integrated? How do you see AI influencing developer workflows and infrastructure?
Santosh: I’m incredibly excited about where things are headed. I envision intelligent developer environments that seamlessly integrate AI at every level. We’re already seeing early signs – from AI-assisted coding to smart analytics in CI/CD – but I think it will go much further. In the future, your developer platform itself might have AI copilots working alongside you. Imagine an AI that can automatically configure your test environment, or suggest optimizations in your code and infrastructure based on patterns it has learned from thousands of deployments. AI could help analyze your experimental results in real time, flagging anomalies or performance regressions that a human might miss.
Essentially, a lot of the grunt work in software development and testing can be augmented by AI, which will let developers focus more on creative problem-solving and less on babysitting environments or crunching log data. As AI models become more complex and data-hungry, this integration will also be key to keeping development cycles fast. The industry as a whole is moving toward this fusion of AI with developer operations; you can see it in the way new tools are coming out that embed machine learning into monitoring, security, and even the coding process. I believe we’ll look back and see this period as a turning point where development became smarter and more autonomous.
My own goal is to keep pushing in that direction: building platforms that help developers ship software at blistering speed with AI quietly streamlining the path. It’s a broader shift, and I’m happy to be one of the contributors working on making it a reality. In the end, the future of developer platforms will be about marrying the creativity of human developers with the power of AI-driven automation and insight. That combination holds the promise of software and AI innovation at a pace and scale we’ve never seen before, and doing it safely, scalably, and with a whole lot less friction than in the past.