DEV Community: Juhani Ränkimies

Change Management When Specs Are Living Documents

Juhani Ränkimies — Mon, 09 Mar 2026 19:43:48 +0000

If your spec is the source of truth, what happens when the truth needs to change?

This is the question most spec-first approaches handle poorly. Either the spec becomes stale (everyone ignores it after the first sprint), or updating it becomes ceremony (three documents to change before you can write a line of code). Both failure modes kill the approach.

Living specs need living change management. But the change management has to be lightweight enough that developers actually use it, and structured enough that AI can reason about what's happening.

There's a third failure mode that's less obvious: coupling work breakdown to specs. Most spec-first approaches do this -- user stories have subtasks, BDD features have scenarios that double as work items, spec documents accumulate task lists. This works for the initial build when one team writes one spec and implements it. It breaks when the spec is a living document.

A living spec gets touched by multiple changes over time. CR-001 adds acceptance criteria. CR-007 modifies one of them. CR-012 deprecates another. Each change has its own scope, its own tasks, its own timeline. If tasks live on the spec, you end up with competing task lists from different changes colliding on the same document. The spec becomes a project management artifact instead of a contract.

The fix is recognizing that specs and change management are orthogonal concerns:

The spec defines what must be true (current contract)
The change record defines what's changing and why (delta)
Tasks belong to the change, not the spec

This separation is why change records in this approach live in their own folders (changes/CR-001-slug/) with their own task breakdowns, rather than being embedded in or attached to spec documents. A spec can be touched by many changes. A change can touch many specs. Neither owns the other.

Why git history isn't enough

The instinctive response is: "We have git. Changes are tracked. What more do we need?"

Git history tracks what changed. It doesn't track:

Why the change was made
Whether the change was intentional or accidental drift
Which contract (behavioral commitment) was affected
Whether proof obligations changed
What the migration or compatibility implications are
Whether this change is part of a larger effort or standalone

When a human reads a git log, they can sometimes reconstruct this from commit messages and PR descriptions. When AI reads a git log, it gets a sequence of diffs with variable-quality commentary. It has no reliable way to distinguish "intentional contract change" from "implementation refactor" from "accidental behavior change."

Explicit change records solve this by classifying intent alongside implementation.

The change record

A change record is a lightweight document that captures what's changing and why. It lives in its own folder alongside optional supporting material:

docs/changes/
  CR-001-repository-bootstrap/
    change.md
    tasks.md          # optional: implementation breakdown
  CR-002-quality-baseline/
    change.md
    tasks.md

Each change record covers problem, motivation, scope (in/out), proposed contract delta, affected artifacts, and risks. It also classifies the change -- is this adding new behavior, modifying existing behavior, or an internal quality improvement? Is it breaking for consumers? Does it deprecate something? These classifications let both humans and AI reason quickly about impact without reading the full record.

When is a change record required?

Not every commit needs a change record. The overhead would kill adoption. The rule is a six-question test:

A change record is required if any answer is yes:

Does public or externally observable behavior change?
Does any acceptance criterion change, get added, removed, or deprecated?
Do proof obligations change materially?
Does the implementation introduce a new component, boundary crossing, runtime dependency, or integration?
Does responsibility move between modules or layers in a way future work must understand?
Does rollout, migration, or compatibility handling need explicit coordination?

If all answers are no, it's a simple fix. Fix it, commit it, move on.

Examples of simple fixes that don't need a CR:

Typo or comment correction
Bug fix that restores already-specified behavior within the same module
Local performance improvement with no contract or structure change
Test stabilization when the proof obligation itself doesn't change
Logging improvement within an existing flow

Examples of small changes that still need a CR:

Adding a new config flag visible to consumers
Changing timeout behavior that users can feel
Introducing a new database table or integration
Splitting logic into a new module that changes responsibility boundaries

The change package as workbench

Here's where the approach differs from traditional change management.

During active implementation, the change record is the workbench -- the central coordination surface. But the spec and verification map move ahead to the target state before implementation catches up.

The sequence:

Create the change record. Document what's changing and why.
Update spec.md to the target state. The spec now describes what the system should do after the change, not what it currently does. This intentionally creates a temporary mismatch.
Update verification.yaml. The proof map reflects the new contract. Some tests don't exist yet.
Write or update tests. Tests align with the new spec. They may fail because the old implementation doesn't satisfy the new contract.
Implement. Make the tests pass.
Verify. All tests pass, all quality gates pass.
Re-establish alignment. Confirm that specs, verification map, tests, and implementation all agree.

The key insight: specs move first. The living spec represents the intended target contract during active work, not the current implementation state. The change record tracks what's in flight. When the change completes, everything realigns.

This avoids the two common failure modes:

Spec becomes stale (can't happen -- spec moves before code)
Spec change feels like ceremony (it's part of the change flow, not separate from it)

Temporary misalignment is intentional

This point deserves emphasis because it's counterintuitive.

In the middle of a change, the spec says one thing and the implementation does another. Tests may be failing. That's fine. The change record exists to track this in-progress state. The spec is the target, not a description of current reality.

The rule is: temporary in-progress misalignment can be acceptable. Done means alignment is restored.

This only works with discipline. The change must close. Alignment must be verified. Specs that moved ahead but never got implemented are drift, not progress.

A real example

From the SitePilot2 bootstrap, CR-002 (development quality baseline) shows this pattern in a real change:

Problem: Even with a Rust project in place, contributors lack a shared local workflow. Quality expectations are documented but not enforceable.

Proposed contract delta:

Spec delta: The repository gains an explicit local development workflow. Quality policy documentation changes from hypothetical commands to actual baseline commands. The repository baseline includes a Bun-first Playwright toolchain for browser proof.

Verification delta: Add proof that documented local commands execute successfully. Add proof that quality and tech-stack docs reflect the implemented toolchain. Add proof that sample Playwright tests pass.

What happened:

Playwright scaffolding was added
CI workflow was created running all quality checks
Local developer commands were defined and documented
quality-policy.md was updated from aspirational to actual
docs/tech-stack.md was updated to reflect real tooling

Status log:

2026-03-08 - created
2026-03-08 - activated: Playwright baseline scaffolding added
2026-03-08 - updated: normalized CI to Bun-based installation
2026-03-08 - updated: defined canonical Cargo commands and Bun wrappers
2026-03-08 - updated: expanded CI to run full quality baseline
2026-03-08 - verified: all docs synchronized, bun run verify passes
2026-03-08 - merged

Each status log entry is a sentence. The whole change record is readable in two minutes. But it captures intent, scope, contract delta, and verification in a way that git history alone never would.

Branch alignment

Branches map one-to-one to change records:

One CR -> one branch
One branch -> one PR
One PR -> one observable contract delta

Naming convention: cr/001-repository-bootstrap, cr/002-development-quality-baseline.

This keeps spec changes, proof changes, and code changes visible as one coherent unit. A PR reviewer can look at the change record to understand what contract delta they're reviewing, rather than trying to reconstruct intent from diffs.

Mixed-change escalation

Sometimes work starts as a simple fix and expands. You're fixing a bug, and you realize the fix requires changing an acceptance criterion. Or you're refactoring, and you discover the module boundary needs to move.

The rule: if work starts as a simple fix but expands into contract or structural change:

Stop treating it as exempt
Create a CR immediately
Capture the already-discovered delta
Continue only after readiness is re-evaluated if the new scope is material

This prevents the common pattern where "quick fixes" silently evolve into undocumented contract changes.

Supporting artifacts

Not every change needs the same documentation depth. Trigger rules keep overhead proportional to complexity:

design.md is mandatory when:

More than one viable implementation approach exists
A new dependency, component, or architectural boundary is introduced
The change spans multiple feature packages
A security, performance, or reliability tradeoff must be chosen

tasks.md is mandatory when:

Implementation requires more than three dependent steps
Rollout or migration must happen in sequence
Multiple specs must change in a controlled order

ADR input is mandatory when:

The change revisits a durable technology choice
The change alters a cross-cutting architectural rule

Simple additive changes may need only change.md. Complex cross-cutting changes may need all supporting artifacts. The trigger rules prevent both under-documentation and over-documentation.

What this costs

Honest accounting:

A simple change record takes ~10 minutes to write
A complex one with tasks.md takes ~30 minutes
Updating specs before implementation takes ~5-15 minutes depending on the change
Re-establishing alignment at the end takes ~5 minutes

Against this: every future developer (human or AI) who touches the affected feature can understand what changed, why, and how the contract evolved. The audit trail is explicit, not reconstructed from git archaeology.

The tradeoff sharpens when AI is doing most of the implementation. AI can generate code in seconds. The bottleneck is ensuring that code satisfies the right contract. Change records make the contract explicit. Without them, you're back to reviewing diffs and hoping you can reconstruct intent -- which is the trust problem from Part 1.

Drift: the real enemy

The biggest risk to living specs isn't that they change -- it's that they drift. Code changes without spec updates. Tests pass but don't cover new behavior. Quality gates exist but aren't enforced.

Drift is silent. Each individual change is small enough to ignore. Over weeks, the spec describes a system that doesn't exist anymore.

Detection examples:

Acceptance criteria with no linked tests
Tests tagged to deleted criteria
Behavior changes with no spec or change-record update
Quality checks required by policy but absent in CI
ADR commitments violated by module structure

Some drift can be caught deterministically (missing test linkage, absent CI checks). Some requires judgment (does this behavior change constitute a contract change?). The approach uses automation where possible and review questions where not.

The PR review checklist makes this concrete:

Did the contract change? If yes, where is the change record?
Did acceptance criteria change? If yes, where is the updated proof mapping?
Does the implementation satisfy the updated contract without introducing undocumented behavior?

These questions are as important when reviewing AI-generated PRs as human-generated ones. More important, arguably, because AI doesn't flag its own contract violations.

Bootstrapping a Project with AI and Specs

Juhani Ränkimies — Mon, 09 Mar 2026 19:42:19 +0000

Theory is useful. Seeing it work on a real project is better.

This post walks through bootstrapping a project using spec-driven development with AI tooling. The project is real -- a SaaS product called SitePilot2 -- and the artifacts shown are the actual artifacts generated during the bootstrap. Nothing has been cleaned up for presentation.

The starting point

An empty repository. A product idea. An AI assistant (OpenCode with GPT 5.4) as the primary development tool.

The goal: establish a project baseline where AI has enough structured context to work reliably on future features, with change management and quality enforcement in place before writing any product code.

Step 1: Bootstrap the artifact structure

The first action isn't writing code. It's creating the context documents that AI will need for every future task.

A custom command (/sdd-init) handles this. It inspects the repository, discovers what exists, and creates the minimal artifact structure. The command follows explicit rules:

If docs/changes/ or docs/specs/ exists, use docs/ as the artifact root
If changes/ or specs/ exists at the repo root, use the repo root
Otherwise, create under docs/

For a fresh project, this produces:

docs/
  product.md
  structure.md
  tech-stack.md
  architecture.md
  quality-policy.md
  specs/
  changes/
  planning/
  adr/
  .templates/
    spec.md
    verification.yaml
    planning-item.md

The AI populates these based on what it can discover. For a new project, most content is placeholder. For an existing project, it reads package files, source code, CI config, and fills in what it finds.

Step 2: Fill in product context

The AI generates an initial product.md from a conversation about the product. Here's what came out for SitePilot2:

# Product: SitePilot2

## What

SitePilot2 is a SaaS product that helps non-technical business owners 
create and maintain professional business websites without external 
implementation help.

## For Whom

- Solo entrepreneurs operating locally
- Small agencies serving local clients
- Small teams that need multiple collaborators to maintain one or 
  more business websites

## Key User Problems

1. Launching a website is difficult for non-technical owners.
2. Ongoing maintenance is neglected because the team lacks web skills.
3. Long periods without updates lead to costly re-implementation 
   instead of incremental improvement.

This isn't documentation for documentation's sake. Every time AI touches this project in the future, it can load this file and know: simplicity for non-technical users is the primary constraint. That single piece of context prevents an entire class of over-engineering decisions.

Step 3: Make architecture decisions explicit

Before writing any code, twelve ADRs were created to capture key decisions:

ADR	Decision
ADR-001	Backend-driven UI with Datastar
ADR-002	Hexagonal backend architecture
ADR-003	Site-centered tenancy and collaboration model
ADR-004	Passwordless email OTP authentication for v1
ADR-005	Defer Rust web framework selection until Datastar spike
ADR-007	Playwright for UI interaction proof
ADR-008	HTML-first server rendering with reusable fragments
ADR-009	AWS SES for email delivery via port/adapter
ADR-010	Minimal role-based access model for v1
ADR-011	Security scanning baseline
ADR-012	Analytics via pluggable site-level integration

Some are accepted. Some are proposed. ADR-005 explicitly defers a decision (framework selection) until evidence from a spike is available.

The point: when AI later implements authentication, it loads ADR-004 and knows the decision is email OTP, not passwords. When it structures code, ADR-002 tells it hexagonal architecture. These aren't suggestions in a long design doc -- they're discrete, loadable decisions.

Step 4: Plan the work

Five planning items were created to sequence the bootstrap:

PLN	Goal	Status
PLN-001	Establish working Rust project and local workflows	Done
PLN-002	Framework selection spike (Datastar compatibility)	Active
PLN-003	Authentication (email OTP)	Proposed
PLN-004	First-time site creation and onboarding	Proposed
PLN-005	Ongoing site management	Proposed

Planning items aren't feature specs. They answer "what work is worth doing and in what order" -- a different question from "what must this feature do." PLN-001 and PLN-002 must complete before feature work starts. PLN-003 through PLN-005 are sequenced by dependency.

Step 5: Execute through change records

Now implementation begins -- but through change records, not ad-hoc coding.

CR-001: Repository bootstrap

The first change record creates the Rust project baseline:

---
id: CR-001
title: repository bootstrap
status: implemented
change_type: additive
branch: cr/001-repository-bootstrap
planning:
  - PLN-001
---

Scope is explicit:

In scope:

Create initial Rust project structure
Add a minimal runnable binary
Add initial test layout and smoke test
Update structure documentation

Out of scope:

Web framework selection
Real product features
Production deployment

The implementation was minimal by design:

Cargo.toml: Standard binary project, no dependencies
src/main.rs: Placeholder with comments indicating future architecture
tests/smoke_test.rs: Integration test verifying the binary builds and runs
docs/structure.md: Updated to reflect actual state

A branch cr/001-repository-bootstrap was created, a PR opened, and the change merged. The change record documents what happened and why.

CR-002: Development quality baseline

The second change record establishes the quality enforcement baseline:

---
id: CR-002
title: development quality baseline
status: merged
change_type: internal-quality
branch: cr/002-development-quality-baseline
planning:
  - PLN-001
---

This change:

Added Playwright scaffolding with Bun as package manager
Created CI workflow running rustfmt, clippy, cargo check, cargo test, and Playwright
Defined local developer commands (bun run verify chains all checks)
Documented environment conventions

The quality-policy.md was updated from aspirational to actual:

## Mandatory Automated Checks

### Formatting
- **Tool**: `rustfmt`
- **Command**: `cargo fmt --all -- --check`
- **When**: On every pull request and before merge

### Linting
- **Tool**: `clippy`  
- **Command**: `cargo clippy --all-targets --all-features -- -D warnings`
- **When**: On every pull request and before merge

After CR-002 merged, every future change has automated quality enforcement. The system verification lane from Part 1 is operational.

What the bootstrap produced

After two change records and one day of work, the project has:

Product context that AI can load to understand what the system is for
Engineering context (structure, tech stack, architecture, quality policy) that tells AI how to operate safely
12 ADRs capturing decisions AI needs to respect
5 planning items sequencing future work
2 completed change records with full audit trail
CI pipeline enforcing formatting, linting, type checking, tests, and browser proof
Templates for future specs, verification maps, and planning items

And the actual implementation? A placeholder binary and a smoke test. Almost no code.

That's the point. The value of the bootstrap isn't code -- it's context and infrastructure. When the first real feature gets implemented, AI starts with structured knowledge about the product, architecture, tech choices, and quality requirements. It doesn't start cold.

What the AI did vs. what I did

Being honest about the division of labor:

AI generated:

Initial drafts of all context documents (product.md, structure.md, tech-stack.md, architecture.md, quality-policy.md)
ADR drafts based on architectural discussions
Change record structure and content
Cargo project scaffolding
Playwright setup and CI workflow
Documentation updates

I did:

Decided what the product is and who it's for
Made architectural decisions (hexagonal, Datastar, OTP)
Reviewed and corrected AI-generated artifacts
Decided the sequencing (what to do first, what to defer)
Decided when to stop (minimal bootstrap, not over-designed)

The human role was contract design and judgment. The AI role was execution and documentation. This is the division of labor from Part 1 playing out in practice.

What's missing

Two things this bootstrap deliberately doesn't have yet:

No feature specs. The docs/specs/ directory is empty. Feature specs arrive when feature work begins (starting with PLN-002's framework spike and then PLN-003's authentication).
No filled verification maps. Templates exist, but no concrete spec-to-test mapping because there are no features to map yet.

These aren't gaps -- they're sequencing. The bootstrap establishes context and infrastructure. Features build on that foundation.

The cost

Total overhead for the documentation approach versus just coding:

~1 hour for initial context documents (product, structure, tech stack, architecture, quality policy)
~30 minutes per ADR (most were quick decisions with clear rationale)
~15 minutes per change record (problem, scope, verification delta)
~15 minutes per planning item

For a bootstrap that took about a day total, roughly half was documentation and half was implementation. That ratio will shrink as features get built -- context documents are a one-time investment, and change records for feature work are smaller than bootstrap scaffolding.

Whether that investment pays off depends on what comes next. If the project dies after bootstrap, it was wasted ceremony. If it grows into a real product with months of AI-assisted development, the context documents will save far more time than they cost.

What AI Needs to Know (and What It Doesn't)

Juhani Ränkimies — Mon, 09 Mar 2026 19:41:15 +0000

Ask an AI coding assistant to implement a feature. Give it access to your whole codebase. Watch what happens.

It reads too much. Or too little. It picks up conventions from one module and applies them where they don't belong. It misses architectural boundaries because they're implicit. It generates code that works but doesn't fit because it lacks context about why the system is shaped the way it is.

The problem isn't AI capability. It's context management.

The context problem

AI agents don't understand your system the way a developer who's worked on it for months does. A tenured developer has absorbed product intent, architectural constraints, technology choices, module boundaries, and unwritten conventions through osmosis. They know what matters without being told.

AI has none of this ambient knowledge. Every session starts cold. What the AI can work with is exactly what you give it -- no more, no less.

This creates two failure modes:

Too much context. Dump the entire repo into the prompt and the AI drowns. It can't distinguish product requirements from implementation details, current conventions from legacy code, stable architecture from experimental branches. Signal gets lost in noise.

Too little context. Point the AI at a single file and it works in a vacuum. It makes locally reasonable decisions that violate global constraints. It duplicates utilities that already exist. It breaks architectural rules it doesn't know about.

The sweet spot is selective context loading: give the AI exactly the knowledge it needs for the task at hand, organized so each document answers one clear question.

A layered knowledge model

The approach that works in practice organizes project knowledge into layers, each serving a different purpose. When the AI needs to implement a feature, you don't give it everything -- you load the layers relevant to that task.

Layer 1: Product context

What question it answers: What is this product and who is it for?

This is the document most teams skip and AI most needs. It captures:

What the product does
Who the users are
What problems it solves
What's explicitly out of scope

Without this, AI makes product decisions by inference. It guesses at user intent from code patterns. Sometimes it guesses right. Often it doesn't.

A real example from a project bootstrapped with this approach:

SitePilot2 is a SaaS product that helps non-technical business owners create and maintain professional business websites without external implementation help. It combines AI-assisted onboarding, guided content generation, and ongoing site maintenance workflows.

Three sentences. Enough for an AI to know that "simplicity for non-technical users" is the product constraint, not "flexibility for developers."

Layer 2: Engineering context

What question it answers: How do I operate safely inside this repository?

Four documents cover this:

structure.md -- where code goes, what modules do, dependency boundaries. When AI needs to add a new handler, it knows to put it in src/infrastructure/ not src/domain/.
tech-stack.md -- approved technologies, preferred libraries, forbidden choices. Prevents AI from pulling in a new ORM when one is already chosen.
architecture.md -- high-level system shape, components, data flow. Tells AI that the system uses hexagonal architecture before it generates code that couples the domain to the HTTP framework.
quality-policy.md -- mandatory automated checks and how to run them. AI knows it needs to pass rustfmt, clippy, and cargo test -- not just make the feature work.

Layer 3: Feature package

What question it answers: What exactly must this feature do?

This is where the spec-driven approach from Part 1 lives:

spec.md -- problem, user story, acceptance criteria with stable IDs, invariants, non-goals.
verification.yaml -- maps each acceptance criterion to specific tests.
design.md (optional) -- explains how a non-trivial solution will satisfy the contract.

The key distinction:

spec.md defines what must be true
verification.yaml defines how that truth is proven
design.md explains how the solution works

These live together because they describe the same feature from different angles. An AI implementing that feature needs all three; an AI working on a different feature needs none of them.

Layer 4: Technical decisions

What question it answers: Why was this decision made, and what are the consequences?

Architecture Decision Records (ADRs) capture decisions that are expensive to revisit: framework choices, authentication strategies, data model commitments. They record the decision, alternatives considered, rationale, and consequences.

ADRs are not the whole design system. They capture why, not the full current shape. But when AI is about to make a decision that conflicts with an existing ADR, having that context loaded prevents costly mistakes.

A project might have ADRs like:

ADR-001: Backend-driven UI with Datastar
ADR-002: Hexagonal backend architecture
ADR-004: Passwordless email OTP authentication for v1

When AI starts implementing authentication, loading ADR-004 tells it the decision is OTP via email, not passwords. Without that context, it defaults to whatever pattern is most common in its training data.

Layer 5: Change management

What question it answers: What is changing and why?

Change records track how the system evolves. They're separate from specs because:

spec.md is current truth -- what the system must do right now
change.md is historical delta -- what's changing, why, and what it affects

This distinction matters for AI because it prevents a common failure: AI reading a change record and treating a proposed change as the current contract, or reading an old change record and implementing something that's already been superseded.

Layer 6: Planning

What question it answers: What work is worth doing and in what order?

Planning items describe goals, priorities, and sequencing. AI needs this when selecting or proposing work, but not when implementing an already-defined feature.

Why the split matters

If these concerns are collapsed into one large design document, agents either miss important context or load too much irrelevant material.

The split lets agents load only what they need:

Product intent when defining behavior
Repo structure when editing code
Tech constraints when choosing tools
The specific feature package when implementing behavior
ADRs when a decision touches an existing architectural commitment
Change records when evaluating whether behavior is intentionally changing

This isn't just theory. In practice, the difference between "implement this feature given the whole codebase" and "implement this feature given the spec, the architecture doc, the structure guide, and the tech stack" is the difference between fighting the AI and collaborating with it.

The minimal shape

A repository doesn't need all of this on day one. The minimal useful shape is:

docs/
  product.md
  structure.md
  tech-stack.md
  architecture.md
  quality-policy.md
  specs/
    <feature>/
      spec.md
      verification.yaml
  changes/
    CR-001-descriptive-slug/
      change.md
  adr/
    ADR-001.md
  planning/
    PLN-001.md
tests/
src/

Start with the five core documents. Add specs and change records as you build features. Add ADRs when you make significant decisions. The structure grows with the project.

What this doesn't solve

Context management helps AI make better decisions, but it doesn't eliminate the need for verification. A well-informed AI still needs its output checked against contracts and quality gates. The artifact model reduces how often AI goes wrong; the spec and proof model catches it when it does.

The two work together. Without good context, you write specs and AI still struggles. Without specs and proof, you provide context and AI still produces unverifiable output. You need both.

Practical implications

If you're working with AI coding assistants today:

Write a product.md. Even three paragraphs about what your system does and who it's for will improve AI output more than any prompt engineering trick.
Document where code goes. A structure.md that says "handlers go in src/handlers, domain logic goes in src/domain, never import infrastructure from domain" prevents an entire class of AI mistakes.
State your tech choices. If you've chosen Axum over Actix, say so. If you've decided on Turso over Postgres, say so. AI defaults to popularity, not your decisions.
Keep quality policy explicit. Don't rely on AI knowing to run clippy or that you require 80% test coverage. Write it down where the AI can read it.

These four documents take an hour to write. They pay for themselves in the first week of AI-assisted development.

The Trust Problem: Why Code Review Breaks When AI Writes the Code

Juhani Ränkimies — Mon, 09 Mar 2026 19:40:05 +0000

Something breaks when AI starts writing most of your code.

Not the code itself -- that's often fine. What breaks is how you know it's fine.

The old trust model

For decades, the trust model for software has been code review. A human reads the diff, reasons about what it does, checks it against what was intended, and either approves or pushes back. The reviewer's judgment is the quality gate.

This works when a human writes code at human speed. The reviewer can match the pace of production. They can hold the intent and implementation in their head simultaneously. They have time to think about edge cases, architectural fit, and whether the change actually solves the stated problem.

What changes with AI

AI generates code faster than humans can meaningfully inspect it. This isn't a theoretical concern -- it's the daily experience of anyone using Cursor, Copilot, or Claude Code on non-trivial projects.

The practical result:

Volume overwhelms review. A 200-line AI-generated diff takes the same review effort as a 200-line human diff, but AI produces them in seconds. The bottleneck shifts entirely to the reviewer.
Plausibility replaces correctness. AI output looks reasonable. It passes a quick scan. It often compiles and even passes existing tests. But "looks reasonable" is not the same as "does what was intended."
Intent becomes invisible. When a human writes code, the reviewer can usually reconstruct intent from the diff -- naming choices, structure, comments reveal what the author was thinking. AI-generated code has no intent. It has statistical patterns.
Cumulative drift goes unnoticed. Each AI-generated change might be individually acceptable. Over weeks, the codebase drifts in ways nobody explicitly chose. Architecture erodes. Conventions fragment. Nobody can explain why the system looks the way it does.

The honest version: most developers using AI assistants have already stopped doing thorough code review of AI output. They scan it, run the tests, and merge. The old trust model is already broken in practice. We just haven't replaced it with anything explicit.

The wrong response

One common response is to try harder at code review. Slow down. Read every line. Understand every choice.

This doesn't work for the same reason manual testing didn't scale -- it requires effort proportional to output volume, and the volume is growing. You can't outrun AI generation speed with human review effort.

Another response is to trust the AI. It's getting better. It mostly works. Ship it.

This works until it doesn't. Until the AI confidently implements something you didn't ask for, or subtly changes behavior in a way that passes tests but violates a business constraint that was never written down. The cost of these failures grows with system complexity.

What replaces code review?

The question isn't whether AI can write good code. It often can. The question is: how do you know the code does what it should?

Code review answered this by having a human verify intent against implementation. If that doesn't scale, something else needs to carry the trust.

The answer is contracts and proof.

A contract defines what must be true -- in concrete, testable terms, written before implementation.
Proof demonstrates that the contract holds -- through automated tests, quality checks, and verification that can run without human judgment.

This isn't new. It's the spec-and-test model that's been around for decades. What's new is that with AI doing the implementation, this model shifts from "nice to have" to "necessary." When you can't rely on reviewing implementation, you must be able to rely on verifying outcomes.

Spec first. Proof second. Code third.

The operating model is simple:

Spec first. Define what the change must accomplish. Write acceptance criteria in concrete, testable terms. Be explicit about what's in scope and what's not.
Proof second. Map each criterion to automated verification. Write or update tests before implementation. Define the quality gates that must pass.
Code third. Implementation comes last and is free to change as long as the proof still holds. AI can generate it, refactor it, rewrite it entirely -- the contract and proof are what matter.

The human role shifts. You're no longer primarily a code reviewer. You're a contract designer and proof architect. You decide what must be true. You design how to verify it. AI handles the implementation.

Two verification lanes

One lesson from working this way: there are two kinds of trust you need, and they require different verification.

Feature verification proves the system does what the spec says. This is the obvious one -- acceptance tests, integration tests, behavioral scenarios. Did the feature work? Does it handle the edge cases? Does it respect the boundaries?

System verification proves the codebase remains healthy. This is the one that erodes silently -- linting, type checking, security scanning, architectural constraints, dependency hygiene. The system can pass every feature test and still be rotting structurally.

Both are mandatory. Passing feature tests is not enough if the code violates architecture or introduces security vulnerabilities. Passing quality gates is not enough if the required behavior is missing.

When AI writes code, it optimizes for making tests pass. It does not inherently care about architectural consistency, security posture, or maintainability. Both lanes need automated enforcement, not just one.

What this looks like in practice

A concrete example. You're adding a health endpoint to a Rust web service. Under the old model, you'd write the code, write a test or two, open a PR, and a colleague reviews it.

Under spec-driven development:

Spec: "The service exposes GET /health returning 200 with {"status": "ok"}. The endpoint requires no authentication. Response time must be under 50ms."
Verification map: AC-1 maps to an integration test. AC-2 maps to an auth-bypass test. AC-3 maps to a performance assertion.
Tests: Written or updated to match the spec. They may initially fail.
Implementation: AI generates the handler. The tests pass or they don't. If they pass, you don't need to read the handler line by line. The contract is satisfied.
Quality gates: rustfmt, clippy, cargo check, security scan -- all green. The system is still healthy.

The AI's implementation is accepted based on passing proof, not on how convincing the code looks.

What good looks like

Specs talk about user outcomes and system behavior, not implementation.
Tests are traceable to requirements. You can point at any test and say which acceptance criterion it proves.
CI can show which requirements are proven by which checks.
Refactoring is safe because verification protects intent, not implementation.
AI can move fast without turning the codebase into an unreviewable black box.

Anti-patterns

Some things look like spec-driven development but aren't:

Acceptance criteria that describe implementation. "Use a HashMap for caching" is not a contract. "Repeated queries for the same key return cached results within 5ms" is.
Tests with no requirement linkage. A test suite that passes tells you something. A test suite where each test maps to a specific acceptance criterion tells you much more.
Code coverage as a proxy for contract coverage. 90% line coverage means nothing if the untested 10% contains the critical business logic. Requirement traceability matters more than coverage percentages.
Quality checks treated as optional. If linting, type checking, and security scanning aren't mandatory gates, they'll erode when AI accelerates output.

The honest version

This approach has real costs. Writing specs takes time. Maintaining verification maps is overhead. When you're moving fast on a solo project, it can feel like ceremony.

The tradeoff is explicit: you invest in contracts and proof upfront so you can trust AI output without reading every line. Whether that tradeoff pays for itself depends on your context -- system complexity, team size, how much AI is generating, how costly a behavioral mistake would be.

For a weekend project, it's probably overkill. For a system you're building to last, where AI is writing most of the code, the question isn't whether you need a trust mechanism beyond code review. The question is what that mechanism should be.

This series explores one answer.

SvelteKit/CDK exercise plan

Juhani Ränkimies — Sun, 11 Apr 2021 05:45:21 +0000

I've dabbled with an adapter that deploys SvelteKit project to a CDK stack, but deploying the sample page doesn't really test the adapter much.

So, to find (and hopefully fix, too) at least some of the weak spots of my custom CDK adapter, I'll develop a simple app featuring passwordless sign-in and profile picture. The app will protect users from themselves by rejecting reckless profile pictures, like cats and adult content. It'll be hosted on prudent-profile.com.

It shouldn't be too complicated, but still exercises new areas of the adapter:

applying svelte kit in more realistic scenario
session cookies with Cloudfront
handling non-JSON request payload
external dependencies in SSR bundle
more involved CDK stack
- DynamoDB for session management
- SES for confirmation emails
- Rekognition to ensure "quality" of profile images
- DNS, TLS certificates, ...

DIY SvelteKit CDK adapter

Juhani Ränkimies — Mon, 05 Apr 2021 23:52:09 +0000

Update on 2021-10-30

You should also check out my SvelteKit-CDK adapter.
It covers everything discussed in this article. While not even close to stable, it's cleaner and has better structure. And has a wrapper for Lambda@Edge, too.

Below are notes of me putting together sveltekit and AWS CDK. Explanations are minimal. Familiarity with both SvelteKit and CDK is probably required to follow.

At the moment @sveltejs/kit version is 1.0.0-next.71, and the adapter interface is not stable, so this solution is likely to break as time passes.

1. Init SvelteKit project

~$ mkdir sveltekit-cdk
~$ cd sveltekit-cdk/
~/sveltekit-cdk$ npm init svelte@next
   ...
   (I chose typescript/CSS/no eslint/no prettier)
   ...
~/sveltekit-cdk$ npm install
~/sveltekit-cdk$ git init
~/sveltekit-cdk$ git add .
~/sveltekit-cdk$ git commit -m "init svelte"

2. Init CDK project for adapter

~/sveltekit-cdk$ mkdir adapter
~/sveltekit-cdk$ cd adapter
~/sveltekit-cdk/adapter$ npx cdk init --language typescript
~/sveltekit-cdk/adapter$ git add .
~/sveltekit-cdk/adapter$ git commit -m "init CDK"

3. Replace node adapter with a dummy adapter

This is our dummy adapter (adapter/adapter.ts)

import type { Adapter } from '@sveltejs/kit'

export const adapter: Adapter = {
    name: 'MAGIC',
    async adapt(utils): Promise<void> {
        console.log('TODO...')
    }
}

To be able to use typescript for the adapter without extra compilation steps, lets add a little ts-node wrapper (adapter/index.js)

require('ts-node').register()
module.exports = require('./adapter.ts').adapter

Finally, node adapter is replaced in svelte.config.js with our adapter

- const node = require('@sveltejs/adapter-node');
+ const cdkAdapter = require('./adapter/index.js')


-       // By default, `npm run build` will create a standard Node app.
-       // You can create optimized builds for different platforms by
-       // specifying a different adapter
-       adapter: node(),
+       adapter: cdkAdapter,

To make ts-node wrapper work, I had to comment out "module": "es2020", from tsconfig.json. Full commit here.

And try it out

$ npm run build

> sveltekit-cdk@0.0.1 build /workspaces/sveltekit-cdk
> svelte-kit build

vite v2.1.5 building for production...
✓ 18 modules transformed.
.svelte/output/client/_app/manifest.json                            0.67kb
.svelte/output/client/_app/assets/start-d4cd1237.css                0.29kb / brotli: 0.18kb
.svelte/output/client/_app/assets/pages/index.svelte-27172613.css   0.69kb / brotli: 0.26kb
.svelte/output/client/_app/pages/index.svelte-f28bc36b.js           1.58kb / brotli: 0.68kb
.svelte/output/client/_app/chunks/vendor-57a96aae.js                5.14kb / brotli: 2.00kb
.svelte/output/client/_app/start-ff890ac9.js                        15.52kb / brotli: 5.29kb
vite v2.1.5 building SSR bundle for production...
✓ 16 modules transformed.
.svelte/output/server/app.js   70.57kb

Run npm start to try your app locally.

> Using MAGIC
TODO...
  ✔ done

4. Capture Svelte output

Svelte files are copied to a place that is easy to include to CDK stack.

export const adapter: Adapter = {
    name: 'MAGIC',
    async adapt(utils): Promise<void> {
-        console.log('TODO...')
+        const contentPath = path.join(__dirname, 'content')
+        rmRecursive(contentPath)
+        const serverPath = path.join(contentPath, 'server')
+        const staticPath = path.join(contentPath, 'static')
+        utils.copy_server_files(serverPath)
+        utils.copy_client_files(staticPath)
+        utils.copy_static_files(staticPath)
    }
}

Svelte kit provides nice utilities for storing the files to desired folders. Here, the SSR implementation is put to server folder, and will be later deployed to a lambda function. And client and static files are stored to static folder, and will be later deployed to S3.

Full commit

5. Create a Lambda wrapper for SSR

This lambda handler maps the API gateway request and response to what SSR implementation expects.

import { URLSearchParams } from 'url';
import { render } from '../content/server/app.js'

export async function handler(event) {
    const { path, headers, multiValueQueryStringParameters } = event;

    const query = new URLSearchParams();
    if (multiValueQueryStringParameters) {
        Object.keys(multiValueQueryStringParameters).forEach(k => {
            const vs = multiValueQueryStringParameters[k]
            vs.forEach(v => {
                query.append(k, v)
            })
        })
    }

    const rendered = await render({
        host: event.requestContext.domainName,
        method: event.httpMethod,
        body: JSON.parse(event.body), // TODO: other payload types
        headers,
        query,
        path,
    })

    if (rendered) {
        const resp = {
            headers: {},
            multiValueHeaders: {},
            body: rendered.body,
            statusCode: rendered.status
        }
        Object.keys(rendered.headers).forEach(k => {
            const v = rendered.headers[k]
            if (v instanceof Array) {
                resp.multiValueHeaders[k] = v
            } else {
                resp.headers[k] = v
            }
        })
        return resp
    }
    return {
        statusCode: 404,
        body: 'Not found.'
    }
}

And it needs to be bundled for deployment to lambda


export const adapter: Adapter = {
    name: 'MAGIC',
    async adapt(utils): Promise<void> {
        const contentPath = path.join(__dirname, 'content')
        rmRecursive(contentPath)
        const serverPath = path.join(contentPath, 'server')
        const staticPath = path.join(contentPath, 'static')
        utils.copy_server_files(serverPath)
        utils.copy_client_files(staticPath)
        utils.copy_static_files(staticPath)
+  
+       const bundler = new ParcelBundler(
+            [path.join(__dirname, 'lambda', 'index.js')],
+            {
+                outDir: path.join(contentPath, 'server-bundle'),
+                bundleNodeModules: true,
+                target: 'node',
+                sourceMaps: false,
+                minify: false,
+            },
+        )
+        await bundler.bundle()

    }
}

Full commit here.

6. Create CDK Stack

This is a barebones stack for deploying the site. The only non-trivial parts are the routing configuration that is generated from the contents of the static folder, and that I configured CDN to pass session cookies through to SSR handler.

import * as cdk from '@aws-cdk/core'
import * as lambda  from '@aws-cdk/aws-lambda'
import * as gw from '@aws-cdk/aws-apigatewayv2'
import * as s3  from '@aws-cdk/aws-s3'
import * as s3depl from '@aws-cdk/aws-s3-deployment'
import { LambdaProxyIntegration } from '@aws-cdk/aws-apigatewayv2-integrations'
import * as cdn from '@aws-cdk/aws-cloudfront'
import * as fs from 'fs';
import * as path from 'path';


interface AdapterProps extends cdk.StackProps {
  serverPath: string
  staticPath: string
}

export class AdapterStack extends cdk.Stack {
  constructor(scope: cdk.Construct, id: string, props: AdapterProps) {
    super(scope, id, props);

    const handler = new lambda.Function(this, 'handler', {
      code: new lambda.AssetCode(props?.serverPath),
      handler: 'index.handler',
      runtime: lambda.Runtime.NODEJS_14_X,
    })

    const api = new gw.HttpApi(this, 'api')
    api.addRoutes({
      path: '/{proxy+}',
      methods: [gw.HttpMethod.ANY],
      integration: new LambdaProxyIntegration({
        handler,
        payloadFormatVersion: gw.PayloadFormatVersion.VERSION_1_0,
      })
    })

    const staticBucket = new s3.Bucket(this, 'staticBucket')
    const staticDeployment = new s3depl.BucketDeployment(this, 'staticDeployment', {
      destinationBucket: staticBucket,
      sources: [s3depl.Source.asset(props.staticPath)]
    })

    const staticID = new cdn.OriginAccessIdentity(this, 'staticID')
    staticBucket.grantRead(staticID)

    const distro = new cdn.CloudFrontWebDistribution(this, 'distro', {
      priceClass: cdn.PriceClass.PRICE_CLASS_100,
      defaultRootObject: '',
      originConfigs: [
        {
          customOriginSource: {
            domainName: cdk.Fn.select(1, cdk.Fn.split('://', api.apiEndpoint)),
            originProtocolPolicy: cdn.OriginProtocolPolicy.HTTPS_ONLY,
          },
          behaviors: [
            {
              allowedMethods: cdn.CloudFrontAllowedMethods.ALL,
              forwardedValues: {
                queryString: false,
                cookies: {
                  forward: 'whitelist',
                  whitelistedNames: ['sid', 'sid.sig']
                }
              },
              isDefaultBehavior: true
            }
          ]
        },
        {
          s3OriginSource: {
            s3BucketSource: staticBucket,
            originAccessIdentity: staticID,
          },
          behaviors: mkStaticRoutes(props.staticPath)
        }
      ]
    })

  }
}

function mkStaticRoutes(staticPath: string): cdn.Behavior[] {
  return fs.readdirSync(staticPath).map(f => {
    const fullPath = path.join(staticPath, f)
    const stat = fs.statSync(fullPath)
    if (stat.isDirectory()) {
      return {
        pathPattern: `/${f}/*`,
      }
    }
    return { pathPattern: `/${f}` }
  })
}

Check full commit to see how cdk deploy is invoked and parameters passed to the stack

$ export ACCOUNT=234......23
$ export REGION=eu-north-1
$ npm run build
> sveltekit-cdk@0.0.1 build /workspaces/sveltekit-cdk> svelte-kit build

vite v2.1.5 building for production...
✓ 18 modules transformed.
.svelte/output/client/_app/manifest.json                            0.67kb
.svelte/output/client/_app/assets/start-d4cd1237.css                0.29kb / brotli: 0.18kb
.svelte/output/client/_app/assets/pages/index.svelte-27172613.css   0.69kb / brotli: 0.26kb
.svelte/output/client/_app/pages/index.svelte-f28bc36b.js           1.58kb / brotli: 0.68kb
.svelte/output/client/_app/chunks/vendor-57a96aae.js                5.14kb / brotli: 2.00kb
.svelte/output/client/_app/start-ff890ac9.js                        15.52kb / brotli: 5.29kb
vite v2.1.5 building SSR bundle for production...
✓ 16 modules transformed.
.svelte/output/server/app.js   70.57kb

Run npm start to try your app locally.

> Using MAGIC
✨  Built in 1.45s.

adapter/content/server-bundle/index.js    83.97 KB    1.14s
  ✔ done
AdapterStack: deploying...
[0%] start: Publishing 77fee73b537c2786a56a5ae730eecc3d1121be2512b210c0ad7f92a87ba52125:current
[25%] success: Published 77fee73b537c2786a56a5ae730eecc3d1121be2512b210c0ad7f92a87ba52125:current
[25%] start: Publishing e9882ab123687399f934da0d45effe675ecc8ce13b40cb946f3e1d6141fe8d68:current
[50%] success: Published e9882ab123687399f934da0d45effe675ecc8ce13b40cb946f3e1d6141fe8d68:current
[50%] start: Publishing c24b999656e4fe6c609c31bae56a1cf4717a405619c3aa6ba1bc686b8c2c86cf:current
[75%] success: Published c24b999656e4fe6c609c31bae56a1cf4717a405619c3aa6ba1bc686b8c2c86cf:current
[75%] start: Publishing 9ab01d8ba7648b72beed50ec3fad310aef1e1af2bf56f3912d53a56e03579ece:current
[100%] success: Published 9ab01d8ba7648b72beed50ec3fad310aef1e1af2bf56f3912d53a56e03579ece:current
AdapterStack: creating CloudFormation changeset...
  0/18 | 11:07:37 PM | REVIEW_IN_PROGRESS   | AWS::CloudFormation::Stack                      | AdapterStack User Initiated
  0/18 | 11:07:43 PM | CREATE_IN_PROGRESS   | AWS::CloudFormation::Stack                      | AdapterStack User Initiated
  1/18 | 11:08:16 PM | CREATE_IN_PROGRESS   | AWS::IAM::Role                                  | handler/ServiceRole (handlerServiceRole187D5A5A) 
  1/18 | 11:08:16 PM | CREATE_IN_PROGRESS   | AWS::S3::Bucket                                 | staticBucket (staticBucket49CE0992) 
  1/18 | 11:08:16 PM | CREATE_IN_PROGRESS   | AWS::IAM::Role                                  | handler/ServiceRole (handlerServiceRole187D5A5A) Resource creation Initiated
  1/18 | 11:08:16 PM | CREATE_IN_PROGRESS   | AWS::CloudFront::CloudFrontOriginAccessIdentity | staticID (staticID76F07208) 
  1/18 | 11:08:16 PM | CREATE_IN_PROGRESS   | AWS::ApiGatewayV2::Api                          | api (apiC8550315) 
  1/18 | 11:08:16 PM | CREATE_IN_PROGRESS   | AWS::CDK::Metadata                              | CDKMetadata/Default (CDKMetadata) 
  1/18 | 11:08:16 PM | CREATE_IN_PROGRESS   | AWS::IAM::Role                                  | Custom::CDKBucketDeployment8693BB64968944B69AAFB0CC9EB8756C/ServiceRole (CustomCDKBucketDeployment8693BB64968944B69AAFB0CC9EB8756CServiceRole89A01265) 
  1/18 | 11:08:16 PM | CREATE_IN_PROGRESS   | AWS::Lambda::LayerVersion                       | staticDeployment/AwsCliLayer (staticDeploymentAwsCliLayerCF83B634) 
  1/18 | 11:08:17 PM | CREATE_IN_PROGRESS   | AWS::IAM::Role                                  | Custom::CDKBucketDeployment8693BB64968944B69AAFB0CC9EB8756C/ServiceRole (CustomCDKBucketDeployment8693BB64968944B69AAFB0CC9EB8756CServiceRole89A01265) Resource creation Initiated
  1/18 | 11:08:17 PM | CREATE_IN_PROGRESS   | AWS::S3::Bucket                                 | staticBucket (staticBucket49CE0992) Resource creation Initiated
  1/18 | 11:08:18 PM | CREATE_IN_PROGRESS   | AWS::CDK::Metadata                              | CDKMetadata/Default (CDKMetadata) Resource creation Initiated
  1/18 | 11:08:18 PM | CREATE_COMPLETE      | AWS::CDK::Metadata                              | CDKMetadata/Default (CDKMetadata) 
  1/18 | 11:08:18 PM | CREATE_IN_PROGRESS   | AWS::CloudFront::CloudFrontOriginAccessIdentity | staticID (staticID76F07208) Resource creation Initiated
  4/18 | 11:08:18 PM | CREATE_COMPLETE      | AWS::CloudFront::CloudFrontOriginAccessIdentity | staticID (staticID76F07208) 
  4/18 | 11:08:18 PM | CREATE_IN_PROGRESS   | AWS::ApiGatewayV2::Api                          | api (apiC8550315) Resource creation Initiated
  4/18 | 11:08:18 PM | CREATE_COMPLETE      | AWS::ApiGatewayV2::Api                          | api (apiC8550315) 
  4/18 | 11:08:20 PM | CREATE_IN_PROGRESS   | AWS::ApiGatewayV2::Stage                        | api/DefaultStage (apiDefaultStage04B80AC9) 
  4/18 | 11:08:22 PM | CREATE_IN_PROGRESS   | AWS::ApiGatewayV2::Stage                        | api/DefaultStage (apiDefaultStage04B80AC9) Resource creation Initiated
  4/18 | 11:08:22 PM | CREATE_COMPLETE      | AWS::ApiGatewayV2::Stage                        | api/DefaultStage (apiDefaultStage04B80AC9) 
  5/18 | 11:08:32 PM | CREATE_IN_PROGRESS   | AWS::Lambda::LayerVersion                       | staticDeployment/AwsCliLayer (staticDeploymentAwsCliLayerCF83B634) Resource creation Initiated
  5/18 | 11:08:33 PM | CREATE_COMPLETE      | AWS::Lambda::LayerVersion                       | staticDeployment/AwsCliLayer (staticDeploymentAwsCliLayerCF83B634) 
  9/18 | 11:08:34 PM | CREATE_COMPLETE      | AWS::IAM::Role                                  | handler/ServiceRole (handlerServiceRole187D5A5A) 
  9/18 | 11:08:35 PM | CREATE_COMPLETE      | AWS::IAM::Role                                  | Custom::CDKBucketDeployment8693BB64968944B69AAFB0CC9EB8756C/ServiceRole (CustomCDKBucketDeployment8693BB64968944B69AAFB0CC9EB8756CServiceRole89A01265) 
  9/18 | 11:08:37 PM | CREATE_IN_PROGRESS   | AWS::Lambda::Function                           | handler (handlerE1533BD5) 
  9/18 | 11:08:37 PM | CREATE_IN_PROGRESS   | AWS::Lambda::Function                           | handler (handlerE1533BD5) Resource creation Initiated
  9/18 | 11:08:37 PM | CREATE_COMPLETE      | AWS::Lambda::Function                           | handler (handlerE1533BD5) 
  9/18 | 11:08:38 PM | CREATE_COMPLETE      | AWS::S3::Bucket                                 | staticBucket (staticBucket49CE0992) 
 12/18 | 11:08:39 PM | CREATE_IN_PROGRESS   | AWS::Lambda::Permission                         | api/ANY--{proxy+}/AdapterStackapiANYproxy1E757BCE-Permission (apiANYproxyAdapterStackapiANYproxy1E757BCEPermission4DD3BE97) 
 12/18 | 11:08:39 PM | CREATE_IN_PROGRESS   | AWS::ApiGatewayV2::Integration                  | api/ANY--{proxy+}/HttpIntegration-addabd80f5f992d479db94f5bda52ee5 (apiANYproxyHttpIntegrationaddabd80f5f992d479db94f5bda52ee5449897FD) 
 12/18 | 11:08:40 PM | CREATE_IN_PROGRESS   | AWS::IAM::Policy                                | Custom::CDKBucketDeployment8693BB64968944B69AAFB0CC9EB8756C/ServiceRole/DefaultPolicy (CustomCDKBucketDeployment8693BB64968944B69AAFB0CC9EB8756CServiceRoleDefaultPolicy88902FDF) 
 12/18 | 11:08:40 PM | CREATE_IN_PROGRESS   | AWS::Lambda::Permission                         | api/ANY--{proxy+}/AdapterStackapiANYproxy1E757BCE-Permission (apiANYproxyAdapterStackapiANYproxy1E757BCEPermission4DD3BE97) Resource creation Initiated
 12/18 | 11:08:40 PM | CREATE_IN_PROGRESS   | AWS::S3::BucketPolicy                           | staticBucket/Policy (staticBucketPolicyA47383C0) 
 12/18 | 11:08:41 PM | CREATE_IN_PROGRESS   | AWS::ApiGatewayV2::Integration                  | api/ANY--{proxy+}/HttpIntegration-addabd80f5f992d479db94f5bda52ee5 (apiANYproxyHttpIntegrationaddabd80f5f992d479db94f5bda52ee5449897FD) Resource creation Initiated
 12/18 | 11:08:41 PM | CREATE_COMPLETE      | AWS::ApiGatewayV2::Integration                  | api/ANY--{proxy+}/HttpIntegration-addabd80f5f992d479db94f5bda52ee5 (apiANYproxyHttpIntegrationaddabd80f5f992d479db94f5bda52ee5449897FD) 
 12/18 | 11:08:41 PM | CREATE_IN_PROGRESS   | AWS::IAM::Policy                                | Custom::CDKBucketDeployment8693BB64968944B69AAFB0CC9EB8756C/ServiceRole/DefaultPolicy (CustomCDKBucketDeployment8693BB64968944B69AAFB0CC9EB8756CServiceRoleDefaultPolicy88902FDF) Resource creation Initiated
 12/18 | 11:08:41 PM | CREATE_IN_PROGRESS   | AWS::S3::BucketPolicy                           | staticBucket/Policy (staticBucketPolicyA47383C0) Resource creation Initiated
 12/18 | 11:08:41 PM | CREATE_COMPLETE      | AWS::S3::BucketPolicy                           | staticBucket/Policy (staticBucketPolicyA47383C0) 
 12/18 | 11:08:43 PM | CREATE_IN_PROGRESS   | AWS::ApiGatewayV2::Route                        | api/ANY--{proxy+} (apiANYproxy1413EA65) 
 12/18 | 11:08:43 PM | CREATE_IN_PROGRESS   | AWS::ApiGatewayV2::Route                        | api/ANY--{proxy+} (apiANYproxy1413EA65) Resource creation Initiated
 12/18 | 11:08:44 PM | CREATE_COMPLETE      | AWS::ApiGatewayV2::Route                        | api/ANY--{proxy+} (apiANYproxy1413EA65) 
 13/18 | 11:08:50 PM | CREATE_COMPLETE      | AWS::Lambda::Permission                         | api/ANY--{proxy+}/AdapterStackapiANYproxy1E757BCE-Permission (apiANYproxyAdapterStackapiANYproxy1E757BCEPermission4DD3BE97) 
 14/18 | 11:08:58 PM | CREATE_IN_PROGRESS   | AWS::CloudFront::Distribution                   | distro/CFDistribution (distroCFDistributionB272DD5C) 
 14/18 | 11:08:58 PM | CREATE_COMPLETE      | AWS::IAM::Policy                                | Custom::CDKBucketDeployment8693BB64968944B69AAFB0CC9EB8756C/ServiceRole/DefaultPolicy (CustomCDKBucketDeployment8693BB64968944B69AAFB0CC9EB8756CServiceRoleDefaultPolicy88902FDF) 
 14/18 | 11:09:00 PM | CREATE_IN_PROGRESS   | AWS::Lambda::Function                           | Custom::CDKBucketDeployment8693BB64968944B69AAFB0CC9EB8756C (CustomCDKBucketDeployment8693BB64968944B69AAFB0CC9EB8756C81C01536) 
 14/18 | 11:09:02 PM | CREATE_IN_PROGRESS   | AWS::CloudFront::Distribution                   | distro/CFDistribution (distroCFDistributionB272DD5C) Resource creation Initiated
 15/18 | 11:09:04 PM | CREATE_IN_PROGRESS   | AWS::Lambda::Function                           | Custom::CDKBucketDeployment8693BB64968944B69AAFB0CC9EB8756C (CustomCDKBucketDeployment8693BB64968944B69AAFB0CC9EB8756C81C01536) Resource creation Initiated
 15/18 | 11:09:05 PM | CREATE_COMPLETE      | AWS::Lambda::Function                           | Custom::CDKBucketDeployment8693BB64968944B69AAFB0CC9EB8756C (CustomCDKBucketDeployment8693BB64968944B69AAFB0CC9EB8756C81C01536) 
 15/18 | 11:09:07 PM | CREATE_IN_PROGRESS   | Custom::CDKBucketDeployment                     | staticDeployment/CustomResource/Default (staticDeploymentCustomResource41B995BA) 
 16/18 | 11:09:39 PM | CREATE_IN_PROGRESS   | Custom::CDKBucketDeployment                     | staticDeployment/CustomResource/Default (staticDeploymentCustomResource41B995BA) Resource creation Initiated
 16/18 | 11:09:39 PM | CREATE_COMPLETE      | Custom::CDKBucketDeployment                     | staticDeployment/CustomResource/Default (staticDeploymentCustomResource41B995BA) 
16/18 Currently in progress: AdapterStack, distroCFDistributionB272DD5C
 18/18 | 11:11:19 PM | CREATE_COMPLETE      | AWS::CloudFront::Distribution                   | distro/CFDistribution (distroCFDistributionB272DD5C) 
 18/18 | 11:11:20 PM | CREATE_COMPLETE      | AWS::CloudFormation::Stack                      | AdapterStack 

 ✅  AdapterStack

Stack ARN:
arn:aws:cloudformation:eu-north-1:3123....123:stack/AdapterStack/b653b540-9663-11eb-b7b2-0eab76d49478

Hurrah!!

juranki / diy-sveltekit-cdk-adapter

An exercise on deploying SvelteKit with CDK

Cover photo by Alistair MacRobert on Unsplash