Files
acdl/docs/presentations/the-developer-experience-marp.md
T
Jon Chery 807b17d04b
acdl-ci / Lint (push) Successful in 8s
acdl-ci / Test (push) Successful in 29s
acdl-ci / Platform check-only (offline) (push) Successful in 9s
docs(P49): consolidate both Marp decks to 10 high-impact slides
How The Platform Works: 16 → 10 slides
- Merged Problem + North Star + What It Is/Isn't → 1 slide (4 frictions
  → North Star → 3 success criteria → 2 anti-goals)
- Merged Policy & Security + Secure by Default → 'Security by Construction'
- Merged Immutable Audit + Human-in-the-Loop → 'Accountability & Audit'
- Folded Observability, Platform-Managed Environments, Portability into
  existing slides as bullets (Roadmap, Contract-Driven)
- Added 'The Vision Realized' closing slide
- Removed '5-line YAML' claim (credibility — complex stacks are more)

The Developer Experience: 15 → 10 slides
- Merged What Dev Does + Contract + No Platform Code → 'The Contract —
  The Entire Consumer Surface'
- Merged Instant Feedback + Deploy Outputs → 'The Developer Feedback Loop'
- Merged Safe Promotion Path + Rising Bar → 1 slide with side-by-side
  approaches + threshold table
- Cut Citizen Developer Experience as standalone (mentioned on slide 2
  and slide 10 Outcomes)
- Kept Versioned Releases, Friendly Onboarding, Safe Decommission as
  standalone (per user request)
- Removed '5-line YAML' claim

Source markdown files unchanged (remain complete reference with speaker
notes for all original slides).

---ci---
phase: 49
milestone: v1.9
status: complete
requirements:
  covered: []
  partial: []
---/ci---
2026-07-23 15:43:49 +00:00

9.7 KiB

marp, theme, paginate, size, header, footer, style
marp theme paginate size header footer style
true default true 16x9 The Developer Experience Internal section { font-family: "Akkurat Pro", "Helvetica Neue", "Arial", sans-serif; font-size: 22px; color: #1B1B1B; } h1 { color: #D6002A; font-size: 34px; margin-bottom: 0.3em; } h2 { color: #D6002A; font-size: 26px; margin-bottom: 0.2em; } section.title { background: #1B1B1B; color: #fff; border-top: 8px solid #D6002A; } section.title h1 { color: #fff; } table { font-size: 18px; width: 100%; } th { background: #F0F0F0; } blockquote { border-left: 4px solid #D6002A; color: #2E2E2E; font-size: 20px; } pre { font-size: 14px; line-height: 1.3; } code { font-size: 14px; } img { display: block; margin: 0 auto; max-height: 300px; } .badge { display: inline-block; padding: 2px 8px; border-radius: 4px; font-size: 14px; font-weight: 600; } .testing { background: #DBEAFE; color: #1E3A5F; } .planned { background: #fef3c7; color: #78350f; } .agentic { background: #EDE9FE; color: #4C1D95; }

The Developer Experience

Agentic Cloud Delivery Platform

<style> section.title h1 { font-size: 44px; margin-bottom: 0.1em; } section.title h3 { color: #F0F0F0; font-weight: 400; font-size: 22px; margin-top: 0; } </style>

Two Consumer Surfaces, One Platform

The platform serves two kinds of consumer — both converge on the same contract, the same policy envelope, and the same evidence stream.

w:1000

  • Technical developer — owns app code + a contract + a thin CI definition
  • Citizen developer — declares intent in plain language; an AI agent produces a contract that passes the same safety envelope Agentic

The platform is opinionated in what it accepts, regardless of who is declaring. There is no "citizen developer mode" with weaker checks.


The Contract — The Entire Consumer Surface

Three things. That is the entire consumer-side surface.

  • 1. App code — the consumer's service, at the top level of the repo
  • 2. A contract — a single YAML file: module, environment, inputs
uses: acdl/pipelines/deploy.yaml@v1.6
module: microservice
environment: dev
inputs:
  image: my-registry/my-microservice:latest
  port: 8080
  • 3. A one-line CI definition — a thin uses: wrapper pointing at a versioned platform workflow
  • The developer does not: write infrastructure modules, clone the platform repo, hold cloud credentials, or maintain a state backend

The Developer Feedback Loop

Developers see what the platform is doing, in real time, in their own run logs. Testing

  • Streamed output by default — the infrastructure plan, policy-check results, and each check record flow to stdout
  • PR comments after every successful pipeline stage — a developer always knows where they stand without refreshing a dashboard
  • Clear, explainable halt reasons — a policy violation, an insufficient confidence signal, or a missing attestation. Never an opaque debugging exercise.
  • Connection strings posted as PR comments — human-readable, no hunting
  • Runtime secrets in encrypted Parameter Store — KMS-encrypted, namespaced, no raw secrets in logs
  • Errors become GitHub issues, automatically — a failed deploy opens an issue on the platform repo

Versioned, Predictable Releases

Consumers control when they absorb platform improvements. Testing

  • Floating MAJOR + MINOR tags (e.g. @v1.6) — a consumer automatically receives patch updates within the line
  • Semantic versioning with a clear contract: interface → MAJOR, behavior → MINOR, lifecycle → PATCH
  • A consumer can pin to an exact version for maximum stability, or float on MAJOR only (@v1) to absorb new features on their own cadence
  • Unversioned references (@main, bare) are discouraged — the versioned tag is the only immutability lever
  • Automated release job computes the next semver on merge to main, creates the tag, and updates the floating tags

Friendly Onboarding

First impressions of a platform are made when it fails for the first time. The platform fails gracefully. Testing

When no environment is bound, the platform emits a user-friendly onboarding prompt instead of failing opaquely:

  1. That no environment is bound to their repo yet
  2. What the platform will provision on their behalf (account, network, state, role)
  3. The expected turnaround for the platform team to grant the environment
  4. How to request an environment

The pipeline then exits without attempting a deployment — no partial state, no confusing errors.

Citizen developer onboarding path: planned


Safe Promotion Path

The contract is environment-agnostic by design. Promotion is a workflow choice, not a contract edit — the platform raises the bar automatically.

Approach A — One contract, one job per environment. The environment is passed by each job and interpolated at runtime.

jobs:
  dev:
    uses: acdl/.github/workflows/deploy.yml@v1.6
    with: { contract: .acdl/contract.yaml, environment: dev }
  qa:
    needs: dev
    uses: acdl/.github/workflows/deploy.yml@v1.6
    with: { contract: .acdl/contract.yaml, environment: qa }

Approach B — Environment-specific contracts. When inputs genuinely differ, each job points at its own contract file.

jobs:
  dev:
    uses: acdl/.github/workflows/deploy.yml@v1.6
    with: { contract: .acdl/contract-dev.yaml }
  qa:
    needs: dev
    uses: acdl/.github/workflows/deploy.yml@v1.6
    with: { contract: .acdl/contract-qa.yaml }
Environment What the platform adds
dev Confidence ≥ 0.50, fully autonomous Agentic
qa QA human attestation + confidence ≥ 0.75
prod SRE human attestation + confidence ≥ 0.90
<style> section { font-size: 16px; } pre { font-size: 10px; line-height: 1.2; } code { font-size: 10px; } td { font-size: 14px; } table { font-size: 14px; } </style>

Safe Decommission

Tearing down a stack is as deliberate as deploying one — and just as gated. Testing

uses: acdl/.github/workflows/deploy.yml@v1.8
with:
  contract: .acdl/contract.yaml
  mode: decommission
  changeRequestId: "CHG0678912"

A 2-step pipeline with two SRE human-attestation gates:

  1. Validate the change request — the platform queries the CMDB; the CR must be approved and match the consumer repo
  2. Disable deletion protectionSRE approvesZero all counts + destroya second SRE approves

The per-stack encryption key enters a grace window (default 30 days) so encrypted data remains recoverable.


Self-Service Module Catalog

Developers pick from pre-built, security-reviewed building blocks — they don't author infrastructure from scratch. Testing

  • Primitives — single-purpose resources (S3, VPC, ECS, IAM, load balancer, container registry, CloudFront, WAF, RDS), each with documented inputs/outputs, usage, compliance extension points, and versioning
  • Modules — composed patterns (a static site with CDN + WAF; a microservice with VPC + ECS + load balancer + registry)
  • Validated examples per modulesimple.yaml + complex.yaml + variation files, validated against the contract schema in CI. Examples cannot drift from the schema silently
  • Auto-promotion of patterns — a thin-composition layer is auto-promoted to the catalog after 3 observed usages Planned Agentic
  • Compliance extension points — each module lists where GDPR, SOX, SOC2, DORA controls will wire in Planned

The Desired Outcomes

  • Velocity without sacrificing safety. Speed is in the ergonomics (a simple contract, a one-line uses:); safety is in the gates the consumer cannot bypass.
  • Security, observability, and compliance as platform defaults — not per-team effort, not post-hoc remediation. Encryption, deletion protection, uptime monitoring, policy checks, and evidence are on by construction.
  • Auditability as a byproduct, not a project. Every production change is traceable to a human attestation and a tamper-evident evidence event.
  • Blast radius contained by design. Zero-trust OIDC + ABAC means a consumer can only touch its own tagged resources.
  • The bottleneck moves off the platform team's ticket queue. A merged change progresses through lower environments without a platform engineer joining a thread.
  • Infrastructure as a utility, not a craft. The platform abstracts compute, networking, and state. Teams consume infrastructure, they don't maintain it — and the platform compounds value over time by learning from recurring patterns.
  • A path to the citizen developer. The same safety envelope that serves a senior engineer will serve a non-technical consumer — expanding who can ship safely without lowering the bar. Agentic