Exploring a portable declaration of development-session intent for AI-assisted development

[ksteffe]

I’ve been experimenting with an interoperability problem around AI-assisted software development and would appreciate feedback on whether this represents a useful standards boundary, overlaps work already happening in CNCF, or should be expressed through existing specifications instead.

I recently came across #1797, Specification for declaring application integration dependencies, and commented there because I was struck by the similarity in approach: describe requirements independently of the implementation that ultimately satisfies them.

The problem I’m exploring is adjacent, but focused on the development session rather than the deployed application.

The problem

AI coding agents increasingly run in very different environments:

• on a developer’s laptop
• in a cloud development workspace
• inside Kubernetes
• through products such as Cursor, Claude, Codex, Coder, DevPod, etc.
• inside enterprise networks with their own identity, secrets, networking, and policy infrastructure

The project may need things such as:

• access to a GitHub repository
• read access to an observability system
• access to a development database
• connectivity to an internal network
• a running service that can be securely accessed for review

Today, much of this intent is reconstructed separately by each development environment or encoded in vendor-specific configuration.

I’m wondering whether there is value in making some of that intent portable.

A small experiment

I’ve been building an experimental specification and Go reference CLI called PADE (Portable Agent Development Environments):

https://github.com/ksteffe/pade

The current experiment uses a Kubernetes-style declarative resource:

kind: DevelopmentSession
metadata:
  name: default
spec:
  capabilities:
    github.user.read:
      access: read

The important part isn’t the YAML syntax or the PADE implementation. The hypothesis is:

The portable thing should be the intent, not the implementation.

A repository declares what a development session requires.

A conforming environment decides how to satisfy it.

For example:

DevelopmentSession.spec
          |
          | portable intent
          v
Conforming implementation
          |
          +-- local / DevPod / Coder / Kubernetes / cloud agent
          |
          +-- env / Vault / 1Password / enterprise secret broker
          |
          +-- VPN / Cloudflare / internal ingress / other networking

PADE does not attempt to replace those systems.

The Go CLI is primarily a reference implementation for testing whether the boundary itself makes sense.

Why AI agents made me notice the problem

This isn’t necessarily an AI-only problem, but agents make it much more visible.

A developer may start work locally, continue from another device using a cloud agent, need access to APIs or internal infrastructure, and want to interact with a running version of uncommitted code without first publishing a branch or deploying a preview environment.

Different organizations will satisfy those requirements very differently.

That makes me reluctant to define another vertically integrated development platform. I’m more interested in whether the requirements themselves can be expressed portably.

In other words:

declare intent
      ↓
discover available providers
      ↓
resolve capabilities
      ↓
create development session

rather than encoding a particular vendor stack into the project.

What PADE is not trying to standardize

I’m deliberately trying to keep the experiment narrow.

PADE is not intended to define:

• workload identity
• secrets management
• authorization systems
• development workspace runtimes
• ingress
• agent protocols
• MCP
• Kubernetes controllers
• agent-to-agent communication

Existing systems should continue to own those problems.

The question is whether there is a useful interoperability contract between the project declaring its development requirements and the systems capable of satisfying them.

Questions I’d particularly appreciate feedback on

1. Does an existing CNCF project or specification already own this boundary?
   Finding that I’ve reinvented something would be a useful outcome.

2. Is a development-session declaration meaningfully distinct from application integration dependencies such as the work being explored in [Initiative]: Specification for declaring application integration dependencies #1797, or are these better understood as different expressions of the same underlying requirement model?

3. Does this problem belong more naturally in the AI, Developer Experience, or Platform Engineering parts of CNCF—or somewhere else entirely?

4. Which parts of a development session actually need interoperability?

   My current bias is to standardize as little as possible and leave implementation-specific concerns to providers.

5. Are there existing specifications PADE should compose with rather than defining new vocabulary?

I’m not proposing PADE for CNCF adoption at this point.

I’ve intentionally built a small reference implementation so the idea can be criticized against something concrete rather than remaining an architecture diagram. I’m equally interested in discovering that a new specification is unnecessary.

The broader question I’m trying to answer is simply:

Can a software project declaratively describe what its development session needs while allowing developers, enterprises, agent vendors, and platform vendors to choose independently how those needs are satisfied?

I’d appreciate pointers to related work, reasons this boundary doesn’t make sense, or suggestions about where the conversation would be most useful.