Internal Developer Portals Are Dead. Long Live Internal Developer Harness.

Published in August 2026

New startup. You're the first infrastructure hire. by Branko (@brankopetric00).

Branko posted this on February 3, but things have changed quite a bit since then.

This is a classic infrastructure interview question: you're the first infrastructure hire at a Series A startup.

I’ve seen this question so many times that I usually don’t pay much attention to it.

But things are changing fast, and advances in agents and large language models mean that what used to be obvious isn’t so clear anymore.

Here’s how the scenario plays out:

• The CTO wants the platform ready in three months.
• The team has four developers with no Kubernetes experience.
• The company expects ten times more users within a year.

Do you choose Kubernetes, ECS with Fargate, or EC2 with Docker Compose?

To answer this, you need to understand EC2, ECS, and Kubernetes.

And AI agents.

The old platform goal

Team size: 4 developers (none with K8S experience)

Infrastructure teams have always tried to keep things simple for their users.

This was the main factor in the decision.

And for good reason: it's not just Kubernetes—it's the whole stack: AWS, Terraform, Ansible, and more.

There's so much knowledge required to operate production infrastructure that you can't learn those different skills in isolation.

Let alone assume other people can learn those as part of their day jobs, while developing applications.

The challenge for the first infrastructure hire is to build something the team can use independently, even after that person moves on.

And this used to be a good test: what can four developers manage after the infrastructure engineer leaves?

Give both teams an agent

Compare two versions of the same handover.

First, the infrastructure engineer built an ECS cluster and a CI/CD pipeline before leaving the company.

In the second, they built it on EKS.

In both cases, the team doesn’t really know what’s happening in production. They don’t understand the cluster, the deployment model, or where to look when something breaks.

But they can connect an agent to either platform.

The agent can check on a failed deployment, read logs, check service health, explain why a task isn’t starting, trigger a manual deployment, and run the CI system.

Can the agent break production?

Absolutely.

The same permissions that let the agent fix a deployment can also let it break things.

Still, the team can use the agent to get themselves unstuck.

The APIs, tools, permissions, and context determine what the agent can do on either ECS or EKS.

This setup will probably fall apart when the team faces a tough upgrade or hits a problem the tools don’t cover.

But if the platform stays the same, it might be a while before that happens.

ECS and EKS still have different costs, failure modes, and operational requirements.

But now, developers don’t have to remember every platform detail just to do their jobs.

If the infrastructure engineer stays

Now imagine the infrastructure engineer stays, but the role is still a potential single point of failure.

With four developers for every infrastructure engineer, all the operational questions eventually end up with that one person.

The infrastructure engineer’s main job is to help the developers by:

• Creating the tooling for developer self-service
• Supporting critical incidents
• Maintaining and extending the cluster (e.g., planning upgrades, augmenting instrumentation, adding features, etc.).

The work doesn’t stop once the platform is live.

But now, agent tooling is part of that ongoing work.

The infrastructure engineer decides how the agent connects to the cluster and what it can do, which keeps the underlying platform hidden from developers.

The agent helps move an app from a laptop to production.

ECS and EKS stay hidden from the developer.

The Internal Developer Platform moves behind the agent

This idea of creating an abstraction between developers and production isn't new.

Internal developer platforms (IDPs) have already created a boundary between developers and infrastructure.

Developers use the IDP, while ECS, EKS, Terraform, and everything else run underneath.

But stop and think about how this changes with AI agents.

When an agent executes actions on behalf of the operator, the portal's shape changes.

We no longer need to teach the developer to pull the correct lever; instead, we want the agent to discover the tools and execute operations within the platform's guardrails (policies).

In this "delegated" model, the agent is up front, and the IDP sits behind it.

The IDP turns into a set of APIs, MCP servers, policies, operational knowledge, and approval gates.

Mauricio managed to pinpoint the challenge exactly:

"Investing in your existing platforms is key to equipping your agents and teams with the tools to build more automation through the right abstraction layers."

This changes what the infrastructure (or, for a better word, platform) engineer has to design.

The engineer decides what the agent can see, what actions it can take, what permissions it needs, when it needs human approval, and what proof it must provide after making a change.

Is this just an evolution of an internal developer platform?

Maybe.

But to me, this sounds more like designing a new harness.

So your Claude Code (harness) interacts with the internal platform (also a harness): it's harnesses all the way down.

Why Docker Compose is the worst choice

So, back to the question: ECS or Kubernetes?

My bias is obvious: I think Kubernetes offers better and more coherent primitives, so I'd choose it as the target platform.

Kubernetes provides the agent with a stable API, well-defined objects, standard operations, and extensive public documentation.

When the agent sees a Deployment, a Service, or a failed Pod, it’s working with concepts used by thousands of other clusters.

ECS is still a reasonable choice.

It’s quicker to adopt, reduces operational workload, and provides agents with a supported interface.

Option C brings up a different problem.

In the original post, Open C is "Just EC2 + Docker Compose".

EC2 with Docker Compose doesn’t have a clear platform definition.

It combines Terraform, VPCs, EC2 instances, Auto Scaling groups, Docker, deployment scripts, networking, and monitoring into a solution specific to one company.

Mac Chaffee describes this path perfectly in Dear friend, you have built a Kubernetes.

You start with a simple deployment script, but soon you need rolling updates, rollbacks, a second server, service discovery, networking, immutable nodes, and an API.

Six months later, you’ve rebuilt a lot of Kubernetes features using shell scripts, but with fewer guarantees.

Agents make this option even harder because every operation starts by reverse-engineering the local setup.

The agent has to inspect the Terraform configuration, read the deployment scripts, infer the naming conventions, find the undocumented sysctl change, and determine which assumptions apply to this particular cluster.

It has to relearn the platform every time the context changes.

A standard platform gives the agent familiar concepts, documented APIs, established diagnostics, and reusable tools.

A custom platform:

• Consumes context before the agent can even start solving the problem.
• The infrastructure engineer becomes a critical single point of failure.
• The platform is fragile, scaling needs custom work, and the so-called simpler developer experience is a myth because everything from development to production is custom.

An agent might get the job done, but it’s more likely to force its way through than use a safe platform feature.

AI makes it cheaper to write the glue code, which makes building a homemade platform more tempting.

It also leaves the company with more glue code that only one person understands.

My take

Agents now sit one layer above platforms.

Platforms become harnesses.

Someone still has to define those capabilities, set limits, and keep everything running while everyone else treats production as a black box.

That makes the platform engineer’s job even more interesting.