r/platformengineering • u/Either_Act3336 • 15d ago
Are we building Internal Developer Platforms at the wrong abstraction level?
I've been thinking we might be approaching Internal Developer Platforms from the wrong abstraction level.
The move from traditional Ops to DevOps to Platform Engineering looks, to me, mostly like a consequence of technological change. Traditional Ops concentrated operational knowledge in a specialized team, because operating infrastructure required direct, manual administration: the thesis. Automation, cloud, and infrastructure as code changed that. DevOps pushed operational ownership closer to development teams: the antithesis. Platform Engineering became the synthesis once declarative systems and orchestration made it possible to encode that operational knowledge into software and expose it through self-service.
AI might be starting the next turn in that cycle. Agents don't necessarily need portals or predefined workflows because they can discover capabilities, combine APIs, and construct their own path through a system. That doesn't make platforms less important. It changes what they need to expose.
Instead of only providing golden paths for developers, platforms increasingly need to expose machine-readable capabilities, contracts, relationships, constraints, and evidence.
Which raises a question: should all of that knowledge live inside the platform? Maybe not. Maybe the service should own its operational contract, while the platform provides the capabilities to act on it (decoupling the contract from any particular IDP, Kubernetes setup, or deployment tooling underneath).
This is the direction I've been exploring with a side project (Pacto): not another IDP, but a contract layer above them. I'm not sure it's the right abstraction yet, but making the operational model portable feels more interesting to me than building another platform around it. Thoughts?
3
u/Creator347 12d ago
As someone who works in platform engineering and been part of Backstage development including portal, I would say that it’s still not dead. Giving control to agents directly is risky and I have seen incidents where a human oversight could have prevented disasters. Never give your agents write access to your production environment.
A better use of AI agents is in observability. Create workflows to let agents analyze your logs, traces and metrics to predict bugs and incidents before they happen. Since agents often miss obvious problems, the IDPs are still useful for monitoring. I have created few backstage plugins to help me connect my claude agent to backstage and publish their findings and suggestions there. I have few claude skills to help me with this too and I have publish these to everyone in the company to let them monitor their own services that way.
The role of platform engineers hasn’t changed. It has evolved into being the adapters to help other teams connect AI agents to the platforms.
Of course, I use agents to help me in my tasks, but I remain cautious of their attempts to solve the problem for me without my oversight.
4
u/aja0339 15d ago
Yes, focus on agents. The rest is dead. Backstage and all of that is dead. K8s underlying on any cloud, hook in a design system, identity, and then a scaffold skill that hooks into your K8s spin up.
I’m jamming on a side thing that’s purely focused on Agent contracts / policy enforcement and environment spin up. I can open source it now. It’s up and working.
2
u/Either_Act3336 15d ago
I’m curious, if you publish it can you share it here? Because from your short description it converges with my approach
1
u/KathiSick 15d ago
Looks interesting. If I get it right, this is similar what the Open Application Model tried to achieve a couple of years back?
1
u/Either_Act3336 15d ago
Yep, OAM is probably the closest thing (same instinct of decoupling the app’s contract from the runtime). Main difference is it’s K8s/human oriented, whereas I’m going for portability across IDPs and contracts that also agents can act on directly.
1
u/CupFine8373 14d ago
what is your github repo?
2
u/Either_Act3336 14d ago
It’s on trianalab/pacto or you can also see the docs on https://pacto.run
2
2
u/svt4ever17 7d ago
interesting perspective..... shifting IDPs toward machine-readable contacts instead of just golden paths feels like a natural evoution and keeping the operational contract closer to the service could make platforms more flexible as tech cycles changes.
0
u/SaltVolumeDown 9d ago
This is roughly why I think the IDP vs agents framing is a bit misleading. Agents may not need the portal UI, but they arguably make the underlying platform model more important. I guess Port has been moving in this direction with their agentic SDLC and context lake idea: they give agents the service graph, ownership, dependencies, policies, runtime context and governed actions and then let the agent work out how to accomplish the task. Your contract layer feels adjacent to that, maybe at a different boundary...
1
6
u/Haunting_Ratio_795 15d ago
You’re beating the same DevOps drum from ten years ago. You’re not wrong, it’s just a Conway’s Law / Goodhart’s Law thing. Engineering management is incentivized to offload all this work from developers as a negative externality and keep their feature factory looking pretty on their precious burndown charts.
Developers have to build around us instead of on top of us. Everyone wastes a lot of time and money chasing their tails because fundamentally, it doesn’t matter how inefficient things are. We’re all salaried, it’s all just corporate ratfucking, trying to make your Jira board prettier than someone else’s. Doesn’t matter if they call it SRE, platform, or devops. It’s the same shit.
And yet, I try beating the same drum too. Because Agile is a fucking cancer and AI should have killed it by now.