Deep Dive: I Let Claude Build the Entire IDP. Here's What That Actually Looks Like.

The last time I ran this exercise with Fable 5, it took me about 20 minutes to stand up the cluster. The first time I tried it, it couldn't be done at all. The model wasn't capable. Then it was 13 hours. Then six or seven. Then three. Then 90 minutes. Then 20 minutes. That trajectory tells you more about where this is going than any analyst report will.

I've been doing this with every model since February 2025, when I was in the beta for Claude Code before it launched. I've watched the time-to-IDP cut roughly in half with each model generation. My biggest constraint at this point isn't Claude. It's making sure all the version pins are correct before I hand it the spec.

That's what I want to talk about: what it actually looks like to go all-in on AI as the implementation layer for a full internal developer platform, from bare cluster to AI model hosting, and what your job becomes when you do that.

The Mental Model First

Before you touch a terminal, you need three questions.

One: Is it a bounded system? Does the problem space have finite edges? Go, Python, Kubernetes manifests, Helm charts, these are bounded. The rules are known. The API surface is documented. Claude can work inside a bounded system reliably because there's a floor and a ceiling. If you're asking it to do something with infinite degrees of freedom, you're going to have a bad time.

Two: Is it cheaper to use a human? Bryan Catanzaro, NVIDIA's VP of applied deep learning, told Axios in April 2026 that for his team, the cost of compute runs far beyond the cost of the employees. That is a man with every commercial reason to argue the other way, saying it about his own org. The research points the same direction. MIT CSAIL's "Beyond AI Exposure" study found that only 23% of worker compensation exposed to computer vision was cost-effective to automate, which leaves 77% where the human is still the cheaper option. That study is scoped to vision tasks, not to everything, so do not stretch it further than it goes. Run the math on your specific problem before you assume AI is the right call.

Three: Are you the right person to catch it when it goes wrong? This is the one people skip. Claude is probabilistic. You can make an LLM deterministic by setting temperature to zero, but you'll burn roughly 10x the tokens to get there. In practice, you're working with a system that will occasionally go sideways, and your job is to be the SME who notices. If you don't have the domain knowledge to catch a bad Kubernetes manifest or a misconfigured Argo CD application set, you're not ready to hand Claude the wheel.

The use case we're building today hits all three. Kubernetes, GitOps tooling, observability stacks, AI gateway configuration: all bounded, all documented, all things where a practitioner can review the output and know immediately if something is wrong.

What We're Actually Building

The IDP we're standing up has seven phases, all driven by a battle-tested spec file with pinned component versions. If you've worked in production, you know why versions are pinned. The next minor version of anything can break integrations, and you don't want to find that out at 2am.

Phase zero is preflight. It just checks that your Kubernetes cluster is there and on the right version, 1.35 or 1.36 depending on what's in the components YAML.

Phase one is the GitOps foundation. Argo CD goes in here. So does the External Secrets Operator, cert-manager, OpenBao (the Linux Foundation's open-source fork of HashiCorp Vault, under OpenSSF governance), and Kyverno. If you don't know Kyverno, it's your policy enforcement layer. Security guardrails, admission control, that kind of work.

Phase two is observability. The full Prometheus stack, Grafana, Alertmanager, Loki for log storage, Tempo for tracing, and an OpenTelemetry collector. I thought about adding Jaeger for traces and didn't. I should have. That's the kind of decision you're making as the architect while Claude handles the YAML.

Phase three is the portal layer. Backstage, backed by Postgres. Karpenter is optional here but worth knowing about: it's AWS's open-source dynamic autoscaler, and it's fast at cluster management. KEDA is also in this phase for event-driven autoscaling, along with Argo Workflows, Argo Events, and Argo Rollouts.

Phase four is the AI gateway. Gateway API, K-gateway for routing and exposing AI services, and Agent Gateway, which lets you inject LLM Guard and inference controls into the traffic path.

Phase five is where the agent runtimes land. KAgent is the key piece here: it makes an AI agent a Kubernetes-native object, something you can manage with a CRD like anything else. LLM Guard runs here too. It is a scanner toolkit rather than one model: fifteen scanners on the way in, twenty on the way out, with the prompt-injection and PII checks backed by fine-tuned DeBERTa-v3 classifiers. Small models, hundreds of millions of parameters rather than billions, which is the point. They do semantic matching on inputs and outputs instead of keyword matching, and they are cheap enough to sit in the traffic path.

Also in this phase: OpenLLMetry. Relatively new. It normalizes observability data from AI models into OpenTelemetry format, so you get traces and metrics from your LLM calls in the same pipeline as everything else.

Phase six is model serving. KServe handles model config and deployment. VLLM handles distributed inference. We're running it on one node in this workshop, but it scales horizontally across nodes without much ceremony because it's Kubernetes. Traces go to Tempo via OTLP.

Phase seven is self-service enablement. Scaffolder templates in Backstage, and ApplicationSet for GitOps-driven multi-tenant provisioning. The reason we used ApplicationSet instead of a simpler CI-driven approach is that ApplicationSet lets you tie a repo directly to deployment state. You get a declarative, auditable path from a developer's repository to a running application without a pipeline in the middle making decisions.

What Your Job Actually Is

I want to be direct about this because I think it gets misrepresented.

When Claude is doing the implementation, you are not on vacation. You are the orchestrator. You are the person who wrote the spec, pinned the versions, decided that Kyverno goes in phase one instead of phase three, decided that LLM Guard belongs in the traffic path, decided that ApplicationSet was the right abstraction for multi-tenancy. Claude doesn't make those calls. You do.

What Claude does is take your decisions and produce the artifacts: the Helm values files, the Argo CD Application manifests, the Kyverno policies, the Backstage catalog YAML. It does that faster than any human would, and it does it without getting bored or making typos from fatigue. But it will also occasionally produce something that looks right and isn't, and if you don't have the background to catch it, you won't.

I'm in the top 0.01% of Claude users by usage volume. That's not a flex. It means I have too many projects running simultaneously. I run about 50 to 60 Claude sessions at any given time on a remote Linux VM, specifically so I can close my laptop without killing a session. I've been doing this long enough to know where Claude goes wrong, and I've built the spec file to constrain those failure modes before they happen.

That's the real skill transfer here. Not "how do I prompt Claude." It's "how do I write a spec that's tight enough that Claude can't make a decision I'd disagree with."

The spec is the job. Claude is the implementation. You're the engineer who knows the difference.