Developer platforms are designed to reduce unnecessary complexity for engineering teams. They bring together capabilities such as CI/CD, infrastructure provisioning, Kubernetes, GitOps, security controls and observability through a more consistent developer experience.
After exploring golden paths and self service deployment workflows, I started thinking about another question:
Can AI make developer platforms easier to use without allowing AI to bypass engineering policies or make uncontrolled infrastructure decisions?
I believe the answer is yes, but only if the responsibilities are separated clearly.
AI can help developers understand information, translate intent, explain failures and recommend next steps. Deterministic platform services should still validate permissions, policies, approvals and deployment rules before anything is executed.
In this article, I will design an AI assisted developer platform that improves developer experience while keeping engineering decisions and infrastructure execution controlled.
Core Design Principle
Developer Intent
↓
AI Interpretation
↓
Structured Platform Request
↓
Validation + Permissions + Policies
↓
Engineer Approval if Required
↓
Deterministic Automation
↓
Infrastructure Action
The Developer Experience Problem
Modern developer platforms can contain many capabilities.
A developer may interact with:
CI/CD pipelines
Terraform modules
Kubernetes
GitOps repositories
Argo CD
Container registries
Secrets management
Monitoring platforms
Security policies
Service catalogues
A well designed platform already hides some of this complexity.
But developers may still need to understand which capability to use, which parameters are required and why a request has failed.
Developer Goal
↓
Find Correct Platform Capability
↓
Understand Required Parameters
↓
Understand Policies
↓
Submit Request
↓
Interpret Result
This is where AI can potentially reduce friction.
Start with Developer Intent
Developers usually think about outcomes rather than internal platform implementation.
A developer may say:
Deploy version 2.4.1 of the orders API to the test environment.
The developer should not necessarily need to say:
Update the test Kustomize overlay, change the image tag, create a Git commit, merge it and wait for Argo CD reconciliation.
The platform already understands how deployment should work.
AI can help translate the developer's intent into a structured request.
Converting Natural Language into Structured Requests
Suppose the developer enters:
Deploy orders API version 2.4.1 to test.
AI can interpret this and create:
{
"action": "deploy",
"application": "orders-api",
"version": "2.4.1",
"environment": "test"
}
This is where I want the AI responsibility to stop.
The model has interpreted intent.
It has not deployed anything.
The Platform Must Validate the Request
Once the structured request is created, normal platform controls take over.
The platform should verify:
Does the application exist?
Does the requested image version exist?
Is the environment valid?
Does the developer have permission?
Does the request satisfy policy?
Is approval required?
AI Creates Request
↓
Application Validation
↓
Version Validation
↓
Identity Check
↓
Permission Check
↓
Policy Evaluation
↓
Approved or Rejected
Building a Simple Request Validator
A simplified Python implementation could look like this:
SUPPORTED_APPLICATIONS = {
"orders-api",
"customer-api",
"payment-api"
}
SUPPORTED_ENVIRONMENTS = {
"dev",
"test",
"prod"
}
def validate_request(request):
errors = []
if (
request["application"]
not in SUPPORTED_APPLICATIONS
):
errors.append(
"Application is not registered."
)
if (
request["environment"]
not in SUPPORTED_ENVIRONMENTS
):
errors.append(
"Environment is not supported."
)
return errors
AI does not determine whether an application is supported.
The platform catalogue does.
Permission Decisions Must Remain Deterministic
I would never ask an AI model:
Should this developer be allowed to deploy to production?
Access control should come from identity and permission systems.
A simple example could be:
def can_deploy(
user,
environment,
permissions
):
allowed = permissions.get(
user,
set()
)
return environment in allowed
Principle: AI may understand what the developer wants. It should not invent permissions or override access controls.
Policy Decisions Should Also Stay Deterministic
Production may require additional controls.
POLICIES = {
"dev": {
"approval_required": False
},
"test": {
"approval_required": False
},
"prod": {
"approval_required": True,
"security_scan_required": True,
"minimum_replicas": 2
}
}
AI can explain this policy to a developer.
AI should not decide that the policy can be ignored.
AI Can Explain Platform Policies
This is one area where AI can improve developer experience significantly.
Instead of returning:
Policy validation failed.
the platform could provide:
Your production deployment currently defines one application replica. The production platform policy requires at least two replicas for this service type. Update the replica count to two or more and submit the deployment again.
The policy engine decides that the configuration is invalid.
AI simply explains the decision in a more useful way.
AI as a Platform Guide
Another useful role for AI is helping developers discover platform capabilities.
A developer might ask:
I need a PostgreSQL database for my new API. What should I use?
Instead of searching through several documentation pages, the platform assistant could query the approved service catalogue and respond:
The platform provides a managed PostgreSQL database template. It supports development, test and production environments. Production requests require backup retention and high availability settings.
The recommendation comes from platform metadata rather than the model inventing infrastructure options.
Ground AI in the Service Catalogue
The platform already contains structured information about applications and capabilities.
For example:
{
"service": "managed-postgresql",
"type": "database",
"supported_environments": [
"dev",
"test",
"prod"
],
"owner": "platform-team",
"self_service": true
}
AI should answer using this platform information rather than general assumptions.
AI Can Help Explain Deployment Failures
Deployment troubleshooting is another useful application.
Imagine the platform collects:
{
"deployment_status": "FAILED",
"argocd_status": "Synced",
"pod_status": "CrashLoopBackOff",
"readiness": "FAILED",
"recent_log": "Missing environment variable DATABASE_URL"
}
AI could transform this into:
The deployment configuration successfully reached Kubernetes, but the application container is repeatedly restarting. The latest application log reports that the required DATABASE_URL environment variable is missing. Review the application's environment configuration before retrying the deployment.
This is much more useful to a developer than exposing only the Kubernetes state.
Keep Evidence and Suggestions Separate
The platform should clearly separate confirmed information from AI interpretation.
Observed:
Pod status is CrashLoopBackOff.
DATABASE_URL is missing from the application environment.
Suggested interpretation:
The missing configuration is likely contributing to the application startup failure.
Recommended check:
Verify the expected secret or environment configuration for DATABASE_URL.
This reduces the risk of AI presenting assumptions as confirmed facts.
AI Can Generate Deployment Explanations
Developers may also benefit from understanding what will happen before they submit a request.
For example:
You are requesting version 2.4.1 of orders-api to be deployed to production. The platform will validate the container image, run production policy checks, require release approval, update the GitOps repository and wait for Kubernetes health verification.
This makes platform behaviour easier to understand before execution begins.
AI Can Help Developers Create Valid Configuration
Another useful capability is helping developers prepare platform configuration.
Suppose the platform expects:
application:
name: orders-api
runtime:
port: 8080
health:
readiness: /health/ready
liveness: /health/live
deployment:
replicas: 2
A developer could describe the application:
My API runs on port 8080 and has /health/ready and /health/live endpoints.
AI could prepare a suggested configuration for review.
The platform schema should then validate that configuration before it is accepted.
Schema Validation Remains Essential
AI generated configuration should never be trusted simply because it looks correct.
The platform should validate required fields and expected values.
def validate_replicas(
environment,
replicas
):
if (
environment == "prod"
and replicas < 2
):
raise ValueError(
"Production requires "
"at least two replicas."
)
AI may suggest configuration.
Code decides whether it is valid.
AI Can Summarise Changes Before Approval
Production reviewers often need to understand what is changing.
Instead of presenting only configuration differences, the platform could generate a summary:
Deployment Summary
Application: orders-api
Environment: production
Current version: 2.4.0
Requested version: 2.4.1
No infrastructure changes were detected.
Replica count remains unchanged at three.
Health probe configuration remains unchanged.
Approval is required before deployment.
The actual approval still comes from an authorised person.
AI Should Not Approve Its Own Recommendation
This is another boundary I consider important.
I would avoid a flow such as:
AI Creates Deployment
↓
AI Decides It Is Safe
↓
AI Approves Deployment
↓
AI Executes Production Change
A safer design is:
AI Interprets Request
↓
Platform Validates
↓
AI Explains Impact
↓
Authorised Engineer Approves
↓
Platform Executes
Using AI with GitOps
GitOps provides a useful control boundary for AI assisted platforms.
Instead of allowing the AI layer to communicate directly with the Kubernetes API, the approved workflow can update Git.
Developer Request
↓
AI Interpretation
↓
Platform Validation
↓
Approval
↓
GitOps Change
↓
Git Repository
↓
Argo CD
↓
Kubernetes
Git remains the record of the approved desired state.
AI for Observability
The platform can also use AI after deployment.
Suppose the application deploys successfully but begins showing unusual behaviour.
The platform may collect:
Application health
Pod status
CPU and memory metrics
Recent logs
Deployment history
AI could generate:
Version 2.4.1 deployed successfully, but the application error rate increased approximately five minutes after deployment. CPU and memory remain within normal ranges. The most common new error relates to database connection timeouts. Review application database connectivity before further promotion.
Again, the AI provides context rather than automatically rolling the application back.
Creating a Platform Assistant
These capabilities can eventually be combined into one developer assistant.
Developers could ask questions such as:
"How do I deploy my application to test?"
"Why did my deployment fail?"
"Which database service should I use?"
"What changed in the last deployment?"
"Why does production require two replicas?"
"Show me the health of my service."
The assistant becomes an easier interface to existing platform capabilities.
The Platform Remains the Source of Authority
One principle I would maintain throughout the architecture is:
AI provides an interface and interpretation layer. The platform remains the source of truth for capabilities, permissions, policies and execution.
This separation keeps the system easier to reason about.
Logging AI Assisted Actions
AI assisted interactions should also be auditable.
A request record might contain:
{
"request_id": "req-4821",
"requested_by": "[email protected]",
"original_input":
"Deploy orders API 2.4.1 to test",
"interpreted_action": {
"action": "deploy",
"application": "orders-api",
"version": "2.4.1",
"environment": "test"
},
"validation": "PASSED",
"execution": "COMPLETED"
}
This makes it possible to understand what the developer requested, how the request was interpreted and what the platform eventually executed.
Protect Sensitive Platform Data
AI integration also introduces data handling considerations.
Platform context may contain:
Sensitive information should be filtered or protected before being provided to any AI analysis layer.
Platform Data
↓
Access Control
↓
Filtering + Redaction
↓
AI Context
↓
Developer Response
Feedback Can Improve the Platform Assistant
The assistant should not be treated as finished after its first release.
Developers can provide simple feedback:
Developer Question
↓
Platform Assistant Response
↓
Useful / Not Useful
↓
Analyse Feedback
↓
Improve Documentation, Context or Workflow
Sometimes poor AI answers may reveal that the underlying platform documentation or metadata is incomplete.
Where AI Adds the Most Value
From this architecture, I see AI adding the most value in areas that require interpretation.
Developer intent
Translate natural language into structured platform requests.
Platform discovery
Help developers find supported capabilities.
Error explanation
Convert technical failures into actionable guidance.
Configuration assistance
Suggest valid starting configurations.
Change summaries
Explain what a deployment will change.
Operational analysis
Summarise logs, metrics and deployment information.
Where AI Should Not Be the Authority
I would not make AI the final authority for:
Authentication
Authorisation
Production approval
Security policy enforcement
Infrastructure permissions
Destructive operations
Final deployment validation
These areas benefit from predictable rules and clear accountability.
A Practical Responsibility Model
AI Layer
Understand intent, explain, summarise and recommend.
Platform Layer
Validate configuration, permissions, policies and workflow state.
Human Layer
Make decisions where approval or engineering judgement is required.
Automation Layer
Execute approved and deterministic infrastructure actions.
Final Architecture
Developer
↓
Developer Portal / Chat / CLI
↓
AI Assistance Layer
↓
Intent Interpretation + Explanation
↓
Structured Platform Request
↓
Service Catalogue + Platform API
↓
Identity + Permissions + Policy Engine
↓
Human Approval Where Required
↓
CI/CD + Terraform + GitOps
↓
Argo CD + Kubernetes
↓
Observability
↓
AI Assisted Explanation
↓
Developer
What I Learned from Combining AI and Platform Engineering
My earlier AI experiments focused mainly on operational analysis.
I used AI to help answer questions such as:
What might these logs and infrastructure signals be telling me?
Platform engineering introduced another opportunity:
How can AI help developers interact with complex engineering systems without allowing AI to replace the controls and decisions those systems require?
For me, the answer is separation of responsibility.
AI is useful for interpretation.
Software is useful for validation.
Policies are useful for control.
Engineers remain responsible for decisions where judgement and accountability are required.
Conclusion
In this article, I explored how AI can improve developer platforms without becoming the authority responsible for engineering decisions.
The architecture allows AI to:
Interpret developer intent
Generate structured platform requests
Explain policies
Help developers discover platform capabilities
Assist with configuration
Explain deployment failures
Summarise deployment changes
Provide operational context
Improve developer interaction with the platform
At the same time, deterministic platform components remain responsible for:
Identity
Permissions
Policy enforcement
Configuration validation
Approvals
Infrastructure execution
For me, this creates a much more useful relationship between AI and platform engineering.
Instead of replacing engineers, AI becomes another interface to the engineering platform. It helps translate intent, reduce cognitive load and explain complex information, while established controls continue to protect the environment.
My next step: Combining platform engineering with AI made me think more deeply about building complete software products rather than individual automation capabilities. In the next stage of my journey, I will explore how multi tenant SaaS applications can be designed around users, roles, permissions, tenant isolation and scalable workflow architecture.
Join the conversation! Your thoughts help the community grow.