Developer self-service forms are dead: stop maintaining the forms nobody fills out right

A developer fills out a self-service form to provision a new DB, but he’s unsure which instance size he actually needs, so he picks one at random, creating confusion and prompting a blame game. The platform engineer blames the developer for failing to read the fields. The developer blames the platform engineer for building a form that asks questions they can't answer. Both are right, and the DB still takes days to provision.

Platform engineers have spent years solving a hard coordination problem. You encapsulate complex infrastructure configs in developer-friendly forms, pass the values to Terraform modules and GitHub workflows, and call it self-service. It works until it doesn't.

What breaks, and why

Three things go wrong with static templates, and they compound over time.

• Maintenance becomes a tax. Every new policy, compliance requirement, or infrastructure change means running through every existing template and updating it. Organizations with mature IDPs carry dozens of templates. Keeping them consistent is a part-time job.
  
• Templates can't flex. Developers have edge cases. The form handles the 80% case, and for the remaining 20%, the developer either files a ticket asking for a new variation or bypasses the portal entirely and makes the change directly in the console. Both outcomes defeat the point of removing the tickets bottleneck while staying in control.
  
• The fields ask the wrong questions. "Should this run on EC2, EKS, or GCP?" is a reasonable question to a platform engineer. To the developer who owns the payment service and just needs to add a cache, it's not. They don't know the answer, and they shouldn't have to. The ping-pong that follows is friction you built in when you wrote the form.
  

The root issue is that forms can't reason. You make them as thorough as possible, ask all the right questions upfront, and still can't anticipate every combination of what a developer needs and what your infrastructure requires. You're encoding a decision into a fixed structure, and the decision changes faster than the structure.

What you get with context-aware agents

AI agents can do something forms never could: they can interview the developer in the developer's language, look up what already exists, apply your organizational policies without surfacing them as fields, and produce the output you would have produced yourself.
This only works with the right foundation. The agent needs to reason over the same context you use: your IaC repositories (Terraform modules, GitHub Actions workflows), your provisioned resources, your written policies. Without that context, you get a model that generates plausible-looking code with no knowledge of your actual standards. A rich context lake is the difference between an agent that reasons like a senior platform engineer and one that invents a new VPC.

Teach the agent how you think

Once you have the context, you can encode your reasoning into skills rather than forms. Each skill handles a step in the process.

1. Ask the developer questions they can actually answer. Instead of "which region," ask what flows the service touches, which clients it serves, how mission-critical it is. The agent gathers what the developer knows; it figures out the infrastructure implications.
   
2. Cross-reference what already exists. Before generating anything, check whether the same resource is already provisioned or already in a queue from another team. This removes duplication in both work and resources.
   
3. Apply your organizational playbooks. Mission-critical services go in AWS. Payment flows require 90-day log retention. Services under a cost threshold skip the security review. The agent applies these rules without surfacing them as fields the developer has to interpret, using your existing templates (such as Terraform modules) to understand how those rules actually translate into infrastructure.
   
4. Generate the code and open the PR. The agent uses your existing modules and configuration examples, produces the GitOps code, and opens a PR with a description that explains both what the developer asked for and how the agent translated it into your platform standards.
   

These steps appear linear, but the power no form can match is the ability to loop. If what the agent learns in step 2 or 3 raises a question that step 1 didn't cover, it goes back to the developer. It keeps going until it has the full picture it needs to be confident in its output.

Opening a PR is not the finish line, but it is where you decide how much you trust the agent, and that requires the right safety nets in place.

Stay in control

The right concern isn't whether AI will stray from your golden paths; it's whether you have the right mechanisms in place to catch them before they cause harm. These three patterns are key to staying in control:

Guardrails. Start conservatively with the tools you give your agents. Give them read-only permissions first: the agent can inspect, reason, and propose, but only a human can apply. As you build confidence in specific skills, you can expand permissions selectively. An agent that has produced 50 correct Redis provisioning PRs has earned a different trust level than one you deployed last week.

AI as a judge. Add a second agent whose only job is to review the first agent's output. It acts as the platform lead: it doesn't generate anything, it just examines the PR against your production stability, security, and cost criteria. The human queue receives a PR that has already passed two rounds of automated inspection.

Human in the loop. The easiest place to start, and still the most important safety gate. The agent stops at the PR. Your team reviews, fine-tunes, and merges. But if you instrument this correctly, every delta between the agent's output and the merged PR becomes a signal you can feed back into the skill. The human review stops being just a checkpoint and becomes a feedback loop that makes the agent more accurate over time. That's what lets you narrow the scope of review as confidence grows and remove the bottleneck.

How we do this at Port

Port's platform team is in the middle of this shift, using Port itself as the platform. Developers interact with a platform agent from Slack, their IDE, or their preferred coding agent. The agent connects to Port's MCP server, which surfaces the internal context lake: infrastructure state, organizational policies, and previous provisioning decisions. A set of skills handles questioning the developer, cross-referencing playbooks, and opening the PR.

We track three phases of Time to Resolve: discovery (ticket to work starting), implementation (work starting to PR), and review (PR to merge). Discovery dropped from days to minutes once the agent took over the developer interview and eliminated the friction with the platform team. Implementation time per request is similar to a well-filled form, but the compounding savings show up elsewhere: every edge case that would have spawned a new template variation, or triggered a maintenance pass across existing ones, the skill is dynamic enough to resolve. The review phase is where we're investing most right now as we build out the feedback loop.

Port's workflows handle the sequencing across steps. Skills handle the reasoning within each step. That separation matters: the orchestration is explicit and auditable, while the reasoning is adaptive.

Start small, move fast

You don't need to migrate everything at once. Pick one resource type (where the ping-pong is worst, or the setup is the easiest) and start there. Test it with your team, then get it to early adopters. When new requests come in, don't go back to the old way. Instead, translate your way of thinking into another skill you can serve.

What happens next tends to be self-reinforcing. Instead of asking developers to find the portal, locate the right form, and fill it out with fields they don't understand, you're meeting them in Slack or their IDE, asking questions in their language. Your governed path becomes the easiest path to getting infra done, leaving no reason for developers to bypass you. When something is good, even if not perfect or yet complete, it makes developers hungry for more. Once you achieve that, you will never write a developer form again.

{{public_demo}}