The future of the AI-native internal developer platform & the AI SDLC

For the last decade, the internal developer platform was designed around a relatively stable assumption: software is written by engineers, in quantities that humans can reasonably review, deploy and operate.

That assumption is disappearing.

Coding agents are making software dramatically cheaper to produce. Soon, the limiting factor inside large organizations will not be how quickly they can write code. It will be whether they can safely turn an enormous and continuously growing volume of code into running software.

This changes the role of the internal developer platform.

The next generation of developer infrastructure will need to assume that code is abundant, increasingly autonomous and untrusted by default. It will need to give developers and agents the same path from commit to production, without giving up the security, governance and infrastructure control that enterprises require.

We think this will become one of the most important layers of the AI-native enterprise.

An extraordinary amount of investment has gone into making software easier to write.

The results are already visible. Coding agents can generate features, fix bugs, create entire applications and allow people who previously did not write software to produce it.

But generating code is one step in a much longer software lifecycle.

The code still needs to be built. Tested. Given infrastructure. Connected to databases and other services. Run in realistic preview environments. Observed. Secured. Deployed. Scaled. Updated. Eventually retired.

And inside an enterprise, all of this has to happen within existing security, networking, compliance and infrastructure boundaries.

The faster code generation becomes, the more important everything after code generation becomes.

We are beginning to see this directly.

Northflank is receiving more enterprise inbound than at any point in our history, much of it from sophisticated engineering organizations arriving with remarkably similar requirements. They are adopting coding agents, generating far more software, and realizing that their existing internal platforms were never designed for this level of throughput.

Increasingly, the conversation starts with a simple question:

How do we safely deploy all of this?

There has always been some ambiguity around the term "internal developer platform."

Many IDPs are effectively portals: systems of record that provide a catalog and UI over internal systems, Terraform modules and third-party services. They help developers discover infrastructure, but they do not themselves deploy and run workloads in production.

The actual platform underneath has historically been built by the enterprise. Platform teams have assembled Kubernetes, Terraform, CI/CD, observability, networking and other tools into bespoke internal platforms. This gives organizations control, but leaves them responsible for building the abstractions, maintaining the integrations and evolving the entire system as requirements change.

AI changes the requirement.

A platform designed for agents cannot merely describe how software should be deployed. It needs to actually deploy it.

An agent should be able to produce code and hand it to a platform with a well-defined contract: build this, provision what it needs, isolate it, deploy it, expose it, observe it and enforce the policies of the organization.

The developer platform becomes a system of action for software. This is the abstraction we have spent years building at Northflank.

A service, database, job, GPU workload, preview environment or production deployment can all be expressed through the same platform primitives. Humans can use those primitives through an interface. Agents can use them programmatically.

The underlying infrastructure can change without changing that contract. As the volume of software grows, that abstraction becomes increasingly important.

AI also forces a change in the enterprise security model.

Historically, infrastructure was built around a loose assumption that application code came from trusted engineers inside the organization.

That assumption was already questionable. Software depends on enormous dependency trees, third-party packages and external systems.

With generated code, it becomes untenable.

If an agent can generate and modify software autonomously, the infrastructure executing that software should assume that the workload may be compromised.

This is why we think sandboxing, while important, is ultimately a platform primitive rather than a standalone category.

On Northflank, workloads can run inside microVMs by default. That isolation model should apply whether the workload is an ephemeral agent sandbox, a preview environment, a cron job, a database or a production service.

The interesting question then becomes: How do I build an enterprise software platform where isolation is a property of every workload?

Sandboxing is one piece of that architecture. The platform around it is the much larger opportunity.

There is a temptation whenever a new computing paradigm emerges to assume that the infrastructure underneath it will disappear.

We believe the opposite is happening.

Large enterprises have spent the last decade standardizing around Kubernetes. Their networking, security, observability, infrastructure teams and operational practices are built around it.

AI does not erase those requirements.

If anything, it makes them more important.

The overwhelming pattern we see from enterprises evaluating Northflank is a requirement to run inside their own cloud environment. They want the developer experience of a modern PaaS, but they need workloads inside their AWS, GCP or Azure VPC, private cloud or on-premises infrastructure.

They need their network boundaries, their compute, data, policies, and now, their own choice of harness.

This is one reason we made the decision very early to build Northflank on Kubernetes.

The winning enterprise platform cannot require companies to abandon the infrastructure they have spent a decade adopting. It needs to provide a much better abstraction over it.

The developer should not need to care where every workload runs. The enterprise absolutely will.

We believe a few architectural properties become non-negotiable in the AI-native enterprise.

The control plane and runtime need to be separable. The platform that orchestrates software should not dictate where that software runs. At Northflank, the control plane manages the developer experience, deployments and infrastructure lifecycle, while runtimes can live across Northflank infrastructure, an organization's own cloud accounts, private infrastructure or other compute providers.

This makes bring your own cloud (BYOC) fundamental. Enterprises increasingly need to place workloads according to security requirements, data residency, economics and compute availability. As AI infrastructure fragments across hyperscalers, private clouds, neo-clouds and specialized GPU providers, that flexibility becomes even more valuable.

For the most security-sensitive organizations, separating control plane and runtime is still not enough. The control plane itself needs to be capable of running inside the organization's environment. Northflank can be fully forward deployed, keeping both the platform control plane and its workloads within the customer's infrastructure and security boundary. This matters for governments, regulated industries and large enterprises, which are already running workloads on Northflank.

Finally, workload isolation needs to be built into the runtime itself. Northflank can run workloads inside microVM-based sandboxes, combining VM-level isolation with the orchestration and developer experience of Kubernetes. Sandboxing is therefore not a separate destination for a special class of AI workload. It is an infrastructure primitive that can extend from ephemeral agent execution and preview environments through to long-running production workloads.

The AI-native enterprise platform, in our view, needs all four: a Kubernetes foundation, portable runtimes, a forward-deployable control plane and microVM-based workload isolation.

Without those properties, you can build an excellent developer tool. It is much harder to become the platform through which a large enterprise runs its software.

We started Northflank with a fairly simple belief: developers should be able to deploy complex workloads without becoming infrastructure experts, while enterprises should retain control of the infrastructure those workloads run on.

For a long time, that was mostly a developer experience argument.

The more software an organization produces, the more important the infrastructure underneath it becomes. That infrastructure has to assume code is untrusted, support a much larger number of workloads without creating more operational overhead, and give enterprises flexibility over where those workloads run. And it has to do all of this within the security and infrastructure boundaries enterprises already have.

Coding agents will move from a developer’s laptop to remote, secure environments because a coding harness running on a developer’s laptops is essentially a root kit and anything the developer’s laptop can access, the harness can access, too.

Folks will be having more parallel coding sessions with multiple streams of work, so there will undoubtedly not be enough compute on a laptop.

With Northflank, a coding harness can run in a secure remote environment, generate code, build it and deploy it into a production-like preview environment where developers can see how it actually behaves. This matters because AI can review its own code, but that is still the model marking its own homework. The application needs to run. From there, the same platform carries the workload through testing, staging and production, with the same primitives for compute, databases, networking, observability, scaling and microVM isolation throughout.

That is what we believe the AI-native internal developer platform becomes: the execution layer between an increasingly autonomous software development process and the infrastructure of the enterprise.

Humans or agents can write the code. AWS, GCP, Azure, private cloud, neo-clouds can provide the compute. Kubernetes can remain the substrate.

The developer platform is the layer that makes all of it usable as one coherent system.

We have been building toward that architecture for years.

What has changed is that the enterprise now appears to be arriving at the same conclusion.