The AI Platform Engineer for Developer Experience

The hidden cost of a bad developer environment is not that it does not work, it is that it works just well enough that no one can justify stopping to fix it. The environment that takes forty minutes to set up on a new machine instead of four becomes the environment that new engineers work around rather than fix. The build that takes twelve minutes instead of three becomes the build that engineers run less frequently because checking something has a twelve-minute cost. The service whose README says "see Alice for setup help" becomes the service that only the team who built it knows how to run locally. None of these problems is urgent. All of them are expensive in aggregate: in onboarding time, in feedback loop length, in the cognitive overhead of navigating a fragmented toolchain where nothing is standardized and everything requires tribal knowledge to operate. AI platform engineering exists to address exactly this, not by fixing the symptoms but by paving the road that every developer walks every day, so walking it is fast, predictable, and boring in the best possible way.

Why the generalist approach breaks down

A generalist chatbot can tell you how to write a devcontainer.json file. It can show you the JSON schema, suggest the right base image, and explain the forwardPorts field. What it cannot do is look at your specific repository, the Node.js version you are pinned to, the environment variables you need, the Docker Compose services that the application depends on, the VS Code extensions that are standard for this codebase, and produce a devcontainer that a new engineer can start in a single command and trust to match the production environment. A generic devcontainer template is a starting point; a working devcontainer for a specific project requires reading what the project actually needs and encoding that into a configuration that works the first time, not after three rounds of trial and error.

Cursor and GitHub Copilot face the same limitation at a higher level. They can autocomplete a golden path template based on patterns they have seen, but a golden path is not a pattern, it is a commitment. It is the decision that every new service in this organization will start with these tools, these defaults, this CI configuration, and this deployment model, so that every service produced by different teams in different quarters is consistent, maintainable, and interoperable. That commitment requires organizational knowledge: which tools are actually standard at this company, which CI provider you use, what your deployment targets look like, and what the service catalog will need to track. Autocomplete does not hold that knowledge; a platform engineer does, or an agent built specifically for the platform engineering role.

The service catalog problem is where generalist approaches break down most visibly. Most companies with more than ten services do not have an accurate, up-to-date record of what services exist, who owns each one, what their dependencies are, and whether they are healthy. The catalog that would solve this lives either nowhere or in a Notion document that was accurate six months ago. Maintaining it manually is expensive enough that nobody does it consistently. The result is an organization where engineering leadership cannot answer the question "what services do we have and who is responsible for each one" without asking half the team. A platform engineer builds the catalog and the process that keeps it current, and an ai platform engineer can generate the initial catalog from the actual state of the infrastructure and codebase, making accuracy the default rather than the exception.

What a platform engineer actually does

On a scaling engineering team, the platform engineer is the person who multiplies the productivity of every other engineer by making the common path fast, reliable, and self-service. They build the golden path: the template for creating a new service that comes pre-wired with the local development environment, CI pipeline, deployment workflow, observability setup, and documentation scaffold that every service should have, so new services start correctly instead of accumulating the inconsistencies of whoever created them. They maintain the devcontainer and Docker Compose configurations that let every engineer set up any service locally in a single command without reading a wiki or asking a teammate. They manage the service catalog that gives engineering leadership visibility into what exists, who owns it, and whether it is healthy. They measure developer experience systematically, onboarding time, build duration, deployment frequency, change failure rate, and drive improvements based on data rather than complaints. Their output is invisible when it works, which is exactly the point.

Meet Pave

Pave is Tonone's platform engineer, the specialist agent for developer experience, golden path templates, devcontainer environments, service catalogs, and DX metrics. Pave's working philosophy mirrors that of a senior platform engineer: the best developer tooling is the tooling that engineers never have to think about because it works every time. Every golden path template Pave produces includes a working local setup, a CI pipeline, and a deployment workflow from day one, not as aspirational structure but as functional configuration. Every devcontainer Pave builds is configured for the specific project rather than a generic template, so it actually runs when a new engineer clones the repository.

Tonone's Pave builds golden path templates where every new service starts with local dev, CI, deploy, and monitoring already wired up, so service quality is consistent across the organization regardless of who created it.

What Pave actually does

Setting up one-command local environments

The pave-env skill configures devcontainer and Docker Compose environments for one-command local setup that mirrors production behavior. For a given project, Pave reads the repository, the runtime, the framework, the environment variables, the backing services (databases, caches, queues), the build toolchain, and produces a devcontainer.json and docker-compose.yml configured for this specific project rather than a generic template. The devcontainer specifies the exact runtime version, the required VS Code extensions, the mounted volumes, the forwarded ports, and the post-create command that installs dependencies and runs any necessary setup. The Docker Compose configuration brings up the backing services with the correct versions and seed data so the application is in a known state when a developer starts it. The result is an environment where a new engineer runs one command, waits five minutes, and has a fully functional local setup that behaves identically to every other engineer's local setup and closely matches production. The drift between local and production is one of the most common sources of bugs that only appear in staging or production, Pave eliminates it by making the local environment a configuration-managed artifact rather than an ad-hoc setup each engineer assembles themselves.

Building golden path templates for new services

The pave-golden skill produces golden path scaffolds, complete templates for creating new services that come pre-wired with everything they need to be correct from day one. A golden path template from Pave is not a code skeleton, it is a functional starting point. It includes the local development environment (devcontainer, Docker Compose), the CI pipeline configured for the organization's CI provider (GitHub Actions, GitLab CI, or Cloud Build) with test, lint, and build stages already wired, the deployment workflow for the organization's deployment target, the observability setup (structured logging, basic health check endpoint, metrics instrumentation placeholder), and the documentation scaffold (README template, architecture section, runbook placeholder, environment variable documentation). New services created from the golden path start with the same quality bar as the most mature service in the organization, rather than starting from a blank repository and accreting configuration over months. For organizations that have discovered their services are wildly inconsistent, different CI configurations, different logging formats, different deployment approaches, the golden path is the standardization mechanism that brings consistency without requiring engineers to manually update existing services.

Creating and maintaining the service catalog

The pave-catalog skill generates a service catalog from the actual state of the infrastructure and codebase, not from a Notion document someone wrote six months ago. Pave reads the deployed services, their repository structure, their CI/CD configurations, their ownership files, and any existing documentation to produce a structured catalog entry for each service covering: name, purpose, team ownership, repository, deployment environment, key dependencies (upstream services it calls, downstream services that call it), health check endpoint, on-call contact, and current health status. The catalog output can be formatted for Backstage (the CNCF service catalog standard), for a custom internal catalog tool, or as a standalone YAML or JSON file. For teams that do not have a service catalog at all, pave-catalog produces the initial version from what exists in the actual infrastructure, which means engineering leadership gets an accurate picture of the service landscape immediately rather than after a months-long cataloging project. For teams with an existing Backstage or catalog that has fallen behind, Pave audits the existing entries against the actual infrastructure and identifies discrepancies.

Auditing developer experience health

The pave-audit skill measures and audits the developer experience from the perspective of the metrics that actually matter for engineering productivity. It assesses onboarding time (how long it actually takes a new engineer to go from repository clone to running local setup and first successful test run), build speed (CI pipeline duration broken down by stage, with identification of which stages have the most optimization headroom), deployment friction (how many manual steps are required to get a change from merged PR to production), test suite reliability (flaky test rate and the CI time lost to retries), and DORA metrics (deployment frequency, lead time for changes, change failure rate, mean time to restore). The output is a DX health report with findings prioritized by impact: the issues that are costing the most engineering time are addressed first. For engineering managers who are fielding complaints about developer experience but do not have the data to prioritize improvements, the audit is the document that turns subjective frustration into an actionable improvement backlog with measurable baselines.

Reconnaissance before platform work

The pave-recon skill performs a thorough assessment of the current platform and developer experience landscape before any improvements are designed. It reads the repository structure, CI configurations, deployment scripts, local setup documentation (or absence thereof), and any existing tooling to produce a clear picture of what exists, what is missing, and what is inconsistent. Recon is the step that surfaces the facts a platform engineer needs to prioritize: one team has a beautiful devcontainer setup while three other teams have no local setup documentation at all; the CI pipeline for the main service runs in eight minutes while the pipeline for the most critical service takes twenty-two; the golden path document exists in a wiki but was last updated before the organization migrated to a new CI provider. These findings determine where Pave should invest first, and they are findings that matter to engineering leadership as a picture of current platform health before any improvements are proposed.

A worked example

An engineering team wants to create a standardized golden path for all new Node.js services at their company. They run pave-recon to understand the current state, what CI provider they use, what their deployment target is, what their existing services look like, then ask Pave to produce a golden path service catalog entry and scaffold configuration. The catalog entry for a new service produced by pave-catalog looks like this:

# catalog-info.yaml, generated by Pave (Backstage format)
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: payments-service
  description: Processes payment transactions and manages billing records
  annotations:
    github.com/project-slug: acme/payments-service
    backstage.io/techdocs-ref: dir:.
    pagerduty.com/service-id: P1234ABC
  tags:
    - node
    - payments
    - pci-scope
  links:
    - url: https://payments.internal.acme.com/health
      title: Health Check
    - url: https://grafana.internal.acme.com/d/payments
      title: Grafana Dashboard
    - url: https://github.com/acme/payments-service/blob/main/RUNBOOK.md
      title: Runbook
spec:
  type: service
  lifecycle: production
  owner: group:payments-team
  system: billing-platform
  dependsOn:
    - component:users-service
    - component:audit-service
    - resource:payments-db
    - resource:stripe-integration
  providesApis:
    - payments-api-v1
  consumesApis:
    - users-api-v1

This catalog entry includes the Backstage-standard annotations for GitHub project linking and PagerDuty integration, the tags that allow filtering by technology and compliance scope, the relevant links for health checks, dashboards, and runbooks, and the full dependency graph, what the service depends on (other services, databases, external integrations) and what it provides (APIs) and consumes. For teams using Backstage, this entry can be committed directly to the repository and registered automatically. For teams not yet using Backstage, the YAML format documents the dependencies and ownership in a machine-readable format that any future catalog tooling can consume. The golden path template that Pave produces alongside this entry includes the devcontainer, CI pipeline, and deployment workflow already configured, so a new service created from the template is registered in the catalog and operational from day one.

Pave vs the alternatives

Pave is not competing with Backstage or with CI providers, it produces the configuration and catalog entries that power them. The comparison below focuses on the approaches most commonly used when platform engineering is not a dedicated function: generalist chatbots, code completion tools, and the manual process of setting up Backstage templates or similar catalog tools.

Tonone's Pave generates service catalog entries from the actual state of the infrastructure, giving engineering leadership an accurate picture of service ownership and dependencies without a months-long cataloging project.

Install and try

Tonone is free and MIT-licensed. Install it once and all 23 agents, including Pave, are available in your Claude Code session. Run pave-recon to get a clear picture of your current developer experience health, then pave-env to fix the local setup for the service that takes the longest to get running.