How to Build an Internal Developer Platform with AI Agents

Engineering teams are spending 30-40% of their time on environment setup, infrastructure configuration, and "works on my machine" debugging. Internal developer platforms (IDPs) solve this by giving every developer a standardized, pre-configured environment.

Now add AI agents - every developer gets a coding assistant that understands the codebase, has access to internal tools, and can run code safely.

This guide shows how to build it.

What an Internal Developer Platform Does

At its core, an IDP gives developers:

1. Instant environments - click a button, get a fully configured workspace with the right language, tools, and dependencies
2. Consistency - every workspace is identical, eliminating "works on my machine"
3. Access to internal tools - database connections, API keys, private registries all pre-configured
4. Self-service - developers don't need to file tickets with the platform team
5. Security - isolated environments that can't affect production or other developers

Adding AI agents gives developers:

6. In-context coding assistance - an agent that knows the codebase and can write, refactor, and debug code
7. Automated workflows - run tests, generate documentation, update dependencies
8. Onboarding acceleration - new hires interact with an agent that explains the codebase

Architecture

┌─────────────────────────────────────┐
│         IDP Dashboard                │
│  (Next.js / React web app)          │
│                                      │
│  ┌──────┐ ┌──────┐ ┌──────────────┐│
│  │Create│ │Active│ │Template      ││
│  │ Env  │ │ Envs │ │Manager       ││
│  └──┬───┘ └──┬───┘ └──────┬───────┘│
└─────┼────────┼─────────────┼────────┘
      │        │             │
      ▼        ▼             ▼
┌─────────────────────────────────────┐
│         IDP Backend                  │
│                                      │
│  - Workspace provisioning            │
│  - User-workspace mapping            │
│  - Template management               │
│  - Access control                    │
│  - Cost tracking                     │
└──────────────┬──────────────────────┘
               │ Oblien SDK
               ▼
    ┌────────────────────┐
    │  Developer Workspaces  │
    │                        │
    │  ┌────┐ ┌────┐ ┌────┐│
    │  │Dev │ │Dev │ │Dev ││
    │  │ A  │ │ B  │ │ C  ││
    │  │    │ │    │ │    ││
    │  │Code│ │Code│ │Code││
    │  │+AI │ │+AI │ │+AI ││
    │  └────┘ └────┘ └────┘│
    └────────────────────────┘

Step 1: Environment Templates

Templates define what a workspace looks like. Each template specifies:

• Base image - Ubuntu, Node.js, Python, Go, etc.
• Pre-installed tools - language-specific tools, CLI utilities, editors
• Repository - which repo to clone on startup
• Setup commands - npm install, database migrations, etc.
• Environment variables - API keys, database URLs, feature flags
• Resource allocation - CPU, RAM, disk size
• Network rules - which internal services can be accessed

Example templates:

Frontend template

Image: node-22
Repo: github.com/yourcompany/frontend
Setup: npm install && npm run build
Env: API_URL, AUTH_TOKEN, FEATURE_FLAGS
Resources: 2 CPU, 4 GB RAM, 20 GB disk
Network: Allow access to staging API

Backend template

Image: python-3.13
Repo: github.com/yourcompany/backend
Setup: pip install -r requirements.txt && alembic upgrade head
Env: DATABASE_URL, REDIS_URL, SECRET_KEY
Resources: 2 CPU, 4 GB RAM, 20 GB disk
Network: Allow access to staging DB, Redis, internal APIs

Data science template

Image: python-3.13-ml (custom, includes CUDA + PyTorch)
Repo: github.com/yourcompany/ml-models
Setup: pip install -r requirements.txt
Env: S3_BUCKET, WANDB_API_KEY
Resources: 4 CPU, 16 GB RAM, 50 GB disk
Network: Allow access to S3, MLflow

Step 2: One-Click Provisioning

When a developer clicks "Create Environment" for the backend template:

1. Create workspace with the specified image and resources (~130ms)
2. Clone the repo into the workspace (~3-10 seconds)
3. Run setup commands - install dependencies, run migrations (~10-60 seconds)
4. Inject secrets - environment variables from your secrets manager
5. Start AI agent - pre-configured with the codebase context
6. Return connection details - terminal URL, preview URL, AI chat URL

Total time: 15-90 seconds, depending on the project size. The developer lands in a fully configured environment with everything working.

Step 3: AI Agent Integration

Every workspace gets an AI coding agent. This isn't a chatbot that answers questions - it's an agent with full access to the development environment.

What the agent can do

• Read and write the entire codebase - understands project structure, imports, patterns
• Run terminal commands - npm test, git status, curl localhost:3000
• Understand your company's patterns - pre-loaded with your coding standards, API conventions, and architectural decisions
• Access internal docs - your Confluence/Notion pages, API specs, runbooks

Example interactions

New hire onboarding:

"Explain how the auth middleware works and where I'd add a new permission check"

The agent reads the middleware code, traces the permission system, and explains it with specific file references.

Bug investigation:

"Users are seeing 500 errors on /api/invoices. The logs show a null pointer in InvoiceService. Find the bug."

The agent reads the service file, identifies the missing null check, writes the fix, and runs the tests.

Feature development:

"Add a bulk export endpoint that exports all invoices for a date range as a CSV"

The agent writes the endpoint, adds validation, implements CSV generation, writes tests, and runs them.

Step 4: Network Access Control

Developers need access to internal services (staging databases, internal APIs, private registries). But they shouldn't have unrestricted access to production.

Network templates by role

Each workspace's network rules enforce these boundaries at the VM level. A frontend developer's workspace literally cannot reach the production database - the network path doesn't exist.

Step 5: Template Versioning

As your infrastructure changes, templates need to evolve:

• New dependency version? Update the template
• New environment variable needed? Add it to the template
• New internal service? Update the network rules

Version templates so developers on older environments can upgrade when ready:

backend-template:
  v1.0: Python 3.11, Postgres 14
  v1.1: Python 3.11, Postgres 14, + Redis
  v2.0: Python 3.13, Postgres 16, + Redis, + new env vars

When you push a new version, optionally notify developers: "A new environment template is available. Your current workspace uses v1.1, latest is v2.0. Upgrade?"

Step 6: Cost Management

Track and optimize costs:

Per-developer cost

• Active workspace: $0.02-0.10/hour depending on resources
• Paused workspace: $0.001/hour (storage only)
• Deleted: $0.00

Organization-wide dashboard

Show managers:

• Total workspace costs this month
• Cost per team
• Most expensive workspaces (who's running a GPU instance 24/7?)
• Idle workspaces that should be paused

Auto-pause policy

• No activity for 30 minutes → pause workspace
• Developer returns → resume in ~2 seconds
• No activity for 14 days → snapshot and delete
• Developer starts new project → restore from snapshot

A typical developer who works 8 hours/day:

• 8 hours active: $0.16-0.80/day
• 16 hours paused: ~$0.00
• Monthly cost: $3-16 per developer

Compare to local machine management, IT support, and "works on my machine" debugging time - it's a fraction of the cost.

Step 7: CI/CD Integration

Developer environments should mirror your CI/CD pipeline:

Pre-merge testing

Developer pushes to a branch → their workspace runs the test suite → results shown inline. No waiting for CI to pick up the job - tests run locally in the isolated environment.

Environment parity

The workspace uses the same base image and configuration as your CI containers. If tests pass in the workspace, they'll pass in CI. No more "it passes locally but fails in CI."

Preview deployments

Developer creates a PR → a temporary workspace is created from the branch → the app runs at a preview URL. Reviewers click the URL and see the changes running in an isolated environment.

What You End Up With

The platform team maintains templates and policies. Developers get instant, consistent, AI-powered environments. Everyone wins.

Related reading → Cloud Dev Environments Guide | Oblien Documentation