DEV Community: Takafumi Endo | ROUTE06

AIC: Packages Need an Interface for Coding Agents

Takafumi Endo | ROUTE06 — Mon, 10 Aug 2026 06:57:18 +0000

I develop several tightly related repositories at the same time.

Some are reusable SDKs for declarative schemas, infrastructure, stateful workflows, and other domain abstractions. Others are applications that consume several of those SDKs together.

The development loop constantly crosses package boundaries.

 SDK A ──────┐
             │
 SDK B ──────┼──▶ application
             │        │
 SDK C ──────┘        │
    ▲                 │
    └──── feedback ───┘

I've already written about why I don't think this requires a monorepo, and why I prefer the repository itself to carry the current source of truth:

I won't repeat those arguments here.

This post starts one layer later.

As these SDKs became more agent-aware, each package started needing to tell coding agents how it should be used.

I was already using project-local surfaces such as .claude/, .codex/, AGENTS.md, and package-specific skills. They are useful. Explicit project-local context works.

The maintenance was the awkward part.

When an SDK changed, I would tell the agent to update the corresponding instructions, rules, or skills in the consuming repository.

That worked too.

But after doing it repeatedly across several packages and repositories, I noticed something:

My repeated update instructions had quietly become an undocumented protocol.

Which files should change?

Which source is canonical?

What should be copied?

What should only be referenced?

What belongs to the package, and what belongs to the consuming repository?

How should different coding-agent harnesses receive the same package knowledge without creating independent copies?

I initially thought I needed a better synchronizer.

I now think the problem is one layer higher.

Packages already have an interface for programs. They increasingly need an interface for coding agents.

I've been calling the protocol I'm using for that interface AIC — Agent Index Convention.

It is still a draft from my own development environment. The exact mechanics will change.

The boundary it describes feels much more stable.

The missing package interface

Packages already know how to introduce themselves to programs:

package name
version
API
types
schemas
config
CLI

A coding agent needs another set of facts:

where is the current manual?
which rules matter?
which skills are available?
which files are generated?
which commands are safe?
which host-specific configuration applies?

I think of this as the package's agent-facing interface.

The problem appears when several packages expose that interface inside the same host repository.

Without a shared convention, each package tends to solve the problem independently.

package A ──▶ AGENTS.md
package B ──▶ CLAUDE.md
package C ──▶ .claude/skills/
package D ──▶ .codex/...

Each integration can be perfectly reasonable in isolation.

Composition introduces a different set of problems.

Concern	Failure mode
Ownership	one package overwrites human or provider-owned context
Freshness	copied instructions drift from the installed package
Discovery	harnesses load different files and directories
Composition	every package assumes it owns the shared surface

This stopped looking like documentation management.

It started looking like package composition.

The AIC model

AIC separates three actors:

Provider package
      │
      │ declares agent-facing assets
      ▼
Host repository
      │
      │ exposes them through actual harness loading paths
      ▼
Coding agent

A Provider is a package that supplies agent-facing context.

A Host is the repository consuming that package.

The provider ships its agent-facing source with the package:

provider-package/
├── agent-index.json
├── AGENTS.md
└── skills/

A minimal manifest might look like:

{
  "schema": "agent-index/v1",
  "package": "@scope/schema-sdk",
  "version": "0.14.0",
  "summary": "Declarative schema toolkit",
  "manual": "AGENTS.md",
  "skills": [
    {
      "name": "schema-design",
      "src": "skills/schema-design"
    }
  ],
  "instanceConfig": {
    "source": "declarative",
    "readFrom": "schema.config.json",
    "format": "json",
    "fields": ["runtime", "validation"]
  }
}

agent-index.json is not another manual.

It declares:

identity
version
canonical manual
discoverable assets
host-resolved facts

The useful change for me is that the maintenance contract becomes declarative.

Instead of repeatedly telling an agent:

Update the Claude and Codex instructions
to match the latest SDK behavior.

it can inspect a structure closer to:

provider
  ├── canonical manual
  ├── skills
  ├── resolved host config
  └── target loading semantics

The update no longer depends on how well I happened to describe the maintenance task that day.

Inject, reference, or materialize

This distinction has probably been the most useful part of AIC in actual use.

Not all agent-facing assets should cross the package boundary in the same way.

Class	Example	Operation
Index	identity, version, pointers, resolved config	inject
Referenced	manuals, detailed rules	keep with provider
Materialized	harness-discovered skills	copy deterministically

                  ┌── Index  ─────▶ inject
Provider package ─┼── Manual ─────▶ reference
                  └── Skill  ─────▶ materialize

I originally wanted one mechanism for all three.

Actual loading semantics made that abstraction wrong.

Reference what can remain version-bound

Copying a manual into the host creates two independently changing truths.

installed package   v0.14
copied manual       v0.13

I've hit enough package version-skew problems elsewhere that I don't want to recreate the same class of bug in the agent-context layer.

Here it is worse than ordinary stale documentation.

A stale instruction consumed by an agent that can edit code and run commands is executable misinformation.

The agent may not be hallucinating at all.

It may be behaving perfectly according to the wrong version.

So the canonical manual stays with the installed package.

The host stores a pointer, not another copy.

In practice, this has been one of the more durable AIC decisions: upgrading the package does not require another manual copy to somehow remain synchronized.

Materialize what discovery requires

Skills are different.

If a harness discovers a skill only by scanning a particular directory, mentioning its package path is not equivalent to putting it where the harness looks.

The asset needs physical presence.

So the rule I use is:

Reference when read access is enough. Materialize when discovery requires presence.

That is more useful than either "copy everything" or "never copy."

Context placement should follow actual loading semantics, not an aesthetically uniform abstraction.

Of the AIC decisions I've been testing, this asymmetry is one of the ones I currently trust most.

One host index, many providers

Each provider contributes a small namespaced block to the host index.

### Agent index: `@scope/schema-sdk` v0.14.0

- Manual: read `node_modules/@scope/schema-sdk/AGENTS.md`
- Skills: managed under the harness discovery path
- Host config: validation=strict

Several providers can coexist:

AGENTS.md
│
├── human-owned content
├── @scope/package-a
├── @scope/package-b
└── @scope/package-c

The central invariant is:

A provider owns its namespace, not AGENTS.md.

Updating package B may update B's block.

It may not:

rewrite human content
move package A
modify package C
regenerate the whole file

Materialized assets follow the same rule: each provider gets its own collision-safe namespace.

This is also something I've been able to test rather than only describe.

In the implementations I'm using, foreign provider blocks are preserved rather than normalized into the current provider's representation. Repeating a sync with the same input is tested as a no-op. Providers can also share lock state without one provider flattening another provider's private fields.

Those details are intentionally boring.

But they are the difference between saying "multiple providers can coexist" and actually letting them coexist.

The packages do not need pairwise integrations.

Package A does not need to know package B exists.

Package B does not need a plugin for package C.

They compose because they share an ownership rule.

Coordination is expensive. Namespaces are cheap.

This is the point where AIC stopped feeling like a synchronizer to me.

It started feeling like a package protocol.

Harness-specific files are derived surfaces

AIC is not an argument against .claude/, .codex/, or other harness-specific locations.

I use them because they are useful.

The problem was maintaining them independently.

I want:

                       ┌── AGENTS.md
                       │
provider source ───────┼── Claude adapter
                       ├── Codex adapter
                       ├── skill discovery adapter
                       └── other thin adapters

not:

manual
├── Claude copy
├── Codex copy
├── Cursor copy
└── another copy

Harness-specific files are derived surfaces.

The canonical package knowledge remains singular.

This also gives the design an escape hatch.

If a harness eventually provides a better native mechanism for consuming package-owned instructions or skills, the adapter should disappear.

The package boundary does not have to.

The adapter layer is expendable. The boundary declaration is not.

That distinction matters because harness behavior will probably change faster than package contracts.

Sync should be boring

AIC currently has lifecycle operations roughly like:

agent-index sync
agent-index check
agent-index remove

The most important property is idempotence.

same provider
same version
same source
same managed host state
       │
       ▼
     no-op

Running sync twice with identical inputs should not produce a second write, timestamp churn, or Git diff.

For materialized assets, AIC tracks both sides:

provider source ── hash ──▶ sourceHash
host copy       ── hash ──▶ destHash

That distinguishes:

provider upgraded
host copy locally edited
nothing changed

Those states should not all result in "copy again."

The original asset is materialized byte-for-byte. Provenance sits beside it rather than being injected into skill frontmatter, scripts, or templates.

I don't want sophisticated reconciliation here.

I want deterministic ownership with boring failure modes.

There is another reason I care about determinism:

agents are maintainers too.

A human can often infer that two slightly different layouts represent roughly the same convention.

An agent benefits more from:

one format
one ownership rule
one lifecycle
one source of truth

The easier the maintenance structure is to inspect mechanically, the less the next agent session has to reconstruct from prose.

Determinism does not eliminate drift

This is one place where implementation made the tradeoff clearer.

A protocol can define what should be synchronized without guaranteeing that every synchronization happens immediately.

I've had cases where a package version and its managed agent state temporarily diverged because a manual step was missed.

That is exactly the class of problem AIC is intended to make detectable.

It is also evidence that declaring the protocol does not magically remove its maintenance cost.

The current split is deliberate:

Operation	Responsibility
`preflight`	cheap version-staleness repair
`check`	full version and integrity verification
`sync`	explicit verification and regeneration

The common path stays cheap.

The stronger path stays explicit.

I prefer that to turning every CLI startup into a full filesystem integrity scan.

Generated agent state belongs in Git

I commit the generated index, materialized skills, and lock/provenance state.

A change like:

- ### Agent index: `@scope/schema-sdk` v0.13.0
+ ### Agent index: `@scope/schema-sdk` v0.14.0

changes what the agent can discover.

A changed materialized skill can change what the agent can do.

I want those changes visible beside the dependency update that caused them.

So I think of AIC output more like this:

Artifact	Reviewable state
lockfile	dependency resolution
generated schema	structural contract
migration plan	intended transition
agent index / skill	agent operating context

Generation isn't the problem. Invisible generation is.

Preflight repairs; it doesn't claim ownership

Keeping generated state fresh naturally leads to automatic repair.

This is where I've become deliberately conservative.

I don't want dependency installation to silently rewrite host-owned files.

I also don't want the first execution of an SDK CLI to decide by itself that the repository has opted into agent integration.

So AIC distinguishes adoption from maintenance.

first encounter
    └──▶ warn / explicit sync

existing provider + stale version
    └──▶ repair own namespace

managed content locally edited
    └──▶ preserve + warn

CI / read-only filesystem
    └──▶ don't mutate

removed or disabled provider
    └──▶ stay removed

The invariant is:

Automation may maintain established ownership. It should not invent ownership.

There is a tradeoff.

Preflight needs an execution opportunity.

If a dependency is upgraded but the relevant provider CLI has not run yet, materialized state can temporarily remain stale.

I accept that window today.

The alternative would be making package installation mutate the host automatically, which I currently consider the worse ownership boundary.

Teams that need a stricter guarantee can run check explicitly or in CI.

So preflight does not eliminate drift.

It makes the common repair path cheap while leaving full integrity verification explicit.

This also removes another piece of my old workflow.

I no longer want this:

Please update the agent files after this SDK change.

to be part of the development procedure.

If the relationship is structural, the update rule should be structural too.

Where this actually works today

There is an important qualification.

The providers I'm using AIC with today are part of the same development environment.

I control both sides of the protocol.

That gives me something useful: I can test whether independently versioned packages actually compose through the same rules.

It does not yet prove that unrelated third-party package authors will adopt them.

So today I would describe AIC as a working convention inside one ecosystem, not an ecosystem-wide standard.

The distinction matters because much of the eventual value of a protocol comes from network effects.

That is the part I have not demonstrated yet.

There are a few other current assumptions.

Referenced assets require an installed package

A manual that stays inside the installed package is only useful once the dependency is actually available.

On a fresh clone before dependency installation, the pointer can temporarily lead nowhere.

I currently accept that because the reference is meant to describe the installed package state.

It does mean AIC is not a substitute for dependency availability.

AIC does not invent universal discovery

AIC relies on an entry point the harness already loads — for example AGENTS.md, an import into it, or a harness-specific discovery directory.

It does not solve "how does every possible coding agent discover AIC?" from first principles.

That is intentional.

I would rather adapt to real loading behavior than introduce another mandatory bootstrap mechanism.

Materialized assets expand the trust boundary

A referenced manual is information.

A materialized skill can influence what an agent actually does.

That makes third-party providers a different trust problem from packages I control myself.

Content hashes tell me whether an asset changed.

They do not answer who should be trusted to supply that asset.

That is one of the areas I would want to make more explicit before treating agent-index/v1 as a third-party ecosystem contract.

What I expect to survive

Agent harnesses are moving quickly.

Native packaging for instructions, skills, or package-owned agent context may eventually absorb some of what AIC adapters do today.

If that happens, I don't want to defend the current synchronization machinery for its own sake.

The parts I expect to survive are smaller:

declare the agent-facing package boundary

own only your namespace

keep canonical knowledge version-bound

separate reference from discovery-required materialization

make derived state deterministic and reviewable

respect prior host ownership decisions

The adapter layer is expendable.

The boundary declaration is the interesting part.

That is also why I don't want to freeze the schema too early.

Before asking unrelated providers to adopt it, I would rather make the convention boring inside the repositories I already operate:

fewer drift incidents
fewer manual repair instructions
fewer conventions that exist only in my head

If that keeps working, the format has evidence behind it.

If the ecosystem converges on a better native mechanism, AIC should become a thin adapter to that mechanism rather than compete with it.

What is still draft

The parts I currently think are structural:

packages need an explicit agent-facing interface
multiple providers need namespace ownership
canonical manuals should remain version-bound to their packages
referenced and discoverable assets need different persistence semantics
harness-specific surfaces should be derived rather than independent sources of truth
synchronization should be deterministic and reviewable
maintenance structures should be easy for agents themselves to inspect
automatic repair should respect established ownership

The parts I expect to change:

the exact agent-index.json schema
workspace and nested-repository scoping
harness adapters
skill discovery paths
preflight policy
integrity and trust rules for third-party providers

For a while, I thought I needed a better way to tell coding agents to keep .claude/, .codex/, manuals, and skills synchronized.

Eventually I realized that the repeated instruction was itself the missing specification.

Packages already know how to introduce themselves to programs.

AIC is my attempt to give them a small, composable way to introduce themselves to coding agents.

Installing OpenTelemetry Won't Close Your AI Agent's Feedback Loop

Takafumi Endo | ROUTE06 — Tue, 04 Aug 2026 06:25:36 +0000

I recently did a lightweight review of how OpenTelemetry (OTel) is being used across three repositories under development at my company:

An AI agent application built primarily with Node.js and AWS Lambda
An Electron-based desktop application
A TypeScript SDK and compiler for developers

All three are works in progress. This article is a snapshot of the development environments and codebases at the time of the review, not an assessment of finished products. I used Claude Code to inspect dependencies, configuration, and selected execution paths, so the depth of the review also varied by repository.

I focused on three questions:

Are we actually using the OpenTelemetry mechanisms that exist in the codebase?
What makes adoption or operation difficult?
Can the resulting telemetry help Claude Code or Codex implement and verify changes?

The background: I have been experimenting with ways to make code, documentation, and runtime behavior easier for coding agents to understand, to get more reliable results from tools such as Claude Code and Codex. I understand OTel's value as a way to give telemetry from different services a shared meaning and a shared causal structure. What I have not yet developed is a confident sense of when to introduce it and how to wire it into the everyday development loop.

My conclusion up front is simple:

Installing OTel is not the goal. Telemetry becomes part of an AI-assisted development loop only when it is actually generated, accessible to the agent, correlated as one execution, and comparable before and after a change.

Along the way, I will propose six conditions for agent-usable observability — standardization, propagation, discoverability, controllability, accessibility, and comparability — that I now find more useful than asking "do we have OTel?"

"It exists," "it emits," and "the agent can use it" are different states

The three repositories were in very different states:

Repository	State at the time of review
AI agent application	No direct OTel usage; relies on structured logs, metrics, X-Ray, and audit records
Desktop application	A Collector and related environment variables exist, but the application emits little or no telemetry to them
SDK and compiler	OTel integration is implemented as an opt-in feature, but internal usage is limited

The most useful distinction was between three separate states:

An observability mechanism exists
It actually produces telemetry
An AI agent can use that telemetry to make a decision

A running Collector does not help if the application never emits spans. An integration API does not help if nothing calls it.

One repository showed the shape of the problem clearly. A tracing middleware existed — typed, exported, and documented — but the application's middleware pipeline never included it. Everything about the module looked "done," yet the system produced zero trace data. A coding agent grepping the repo would find a plausible-looking observability layer, and nothing to read at runtime.

This was not specific to OTel. A custom trace system in another repository had the same gap: trace types and debugging features existed, but the middleware was not connected to the runtime.

The underlying failure mode: we treat the implementation of an observability mechanism as completion, without verifying that it produces evidence and that someone — or something — actually consumes it.

OpenTelemetry's core value

OpenTelemetry is a vendor-neutral framework for generating, collecting, and exporting signals such as traces, metrics, and logs. The OpenTelemetry Collector provides a common pipeline for receiving, processing, and forwarding telemetry to one or more backends.

From the perspective of a coding agent, two parts are especially valuable.

Shared meaning

Semantic Conventions standardize not only attribute names, but also their types, meanings, and units across common domains such as HTTP, databases, RPC, and messaging. When the same concept is represented by the same attribute across repositories, Claude Code or Codex has less project-specific naming to infer.

Shared causality

Context propagation carries trace context across process and network boundaries so that distributed operations can be connected as one causal chain. Individual logs may be searchable, but if an API request, an async job, a worker execution, and an audit event cannot be associated with the same operation, it is hard to establish what actually caused a failure.

To me, the core value of OTel is not that it creates more telemetry. It gives telemetry from different execution environments a shared vocabulary and a common correlation key.

An agent can read a system without OTel

The first repository did not use OTel at all — yet it was the easiest for the agent to inspect.

It had structured logs, cloud metrics, X-Ray traces, audit records, and a data pipeline that allowed operational data to be re-queried with SQL. Some of the available datasets and analysis procedures were described as repository-level contracts.

In that kind of system, a coding agent can inspect runtime behavior just fine.

So in the repositories I reviewed, OTel was neither a necessary nor a sufficient condition for AI-readable observability. The real requirement was that telemetry be structured, actually generated, reachable by the agent, and joinable as one execution.

AI readability depends on where the data appears

The review also revealed a much more basic requirement:

Can Claude Code or Codex reach the data with the tools already available in the session — Read, Grep, and a shell?

In one repository, a lightweight trace written into the workspace as JSON and Markdown was the easiest runtime artifact for the agent to use. A richer trace existed in cloud storage, but reaching it required authentication, environment setup, network access, and waiting. That made it far less likely to be used in a loop measured in seconds.

For the development loops I reviewed, accessibility looked roughly like this:

Local files and stdout
  > Read-only MCP, CLI, or SQL access
  > An authenticated cloud UI

This is not a universal ranking — cloud telemetry is essential for production incidents. But when an agent edits and validates in a tight loop, immediate local access wins.

Fortunately, OTel makes the local path cheap. OTel SDKs commonly provide development exporters that write telemetry to the console or stdout — the Python SDK, for example. The Collector's debug exporter can print telemetry locally, while the Collector Contrib distribution also provides a file exporter. Third-party terminal viewers such as otel-tui let you inspect OTLP locally without any backend. When introducing OTel, wiring up a dev-mode path to stdout or local files first — before any remote backend — gives the agent something to read on day one.

Six conditions for agent-usable observability

This is the framework I now use instead of "is OTel installed?":

Condition	Question
Standardization	Are attribute meanings, types, and units defined?
Propagation	Can the same execution be followed across HTTP and async boundaries?
Discoverability	Can the available attributes and datasets be enumerated programmatically?
Controllability	Can time ranges, result limits, and permissions be safely constrained?
Accessibility	Can the agent read the data within its implementation loop?
Comparability	Can the state before and after a change be evaluated under the same conditions?

Different layers of the stack serve different conditions:

OTel is particularly strong at standardization and propagation
Collectors and backends support processing, storage, and controllability
MCP servers, CLIs, SQL interfaces, and local files support discoverability and accessibility
Queries, tests, and analytical models that evaluate changes support comparability

No single layer closes the development loop by itself.

OTel does not define domain meaning

Semantic Conventions primarily standardize infrastructure concerns. They do not fully express domain-specific events from an AI agent system, such as:

A guard rejected an operation
A hazardous action required approval
The system returned a correctable error
A particular next action became available
A decision was based on a specific piece of evidence

Adopting OTel does not remove the need for custom attributes and repository-level schema contracts. Work is continuing on GenAI-related conventions in the Semantic Conventions repository, including conventions for GenAI clients and MCP — but that still does not mean every agent- or workflow-specific concept can or should be standardized.

A native execution trace may also carry richer information than an OTel span: correction codes, permitted next actions, references to evidence, state transitions, replay information. In such systems, OTel should not necessarily replace the native trace. A more natural separation:

Keep domain-specific execution data in the native trace
Project shared operational meaning and cross-system causality into OTel

The OTel representation may be a deliberately lossy projection of the richer native trace.

Do not put internal IDs directly into `traceparent`

The SDK and compiler repository exposed a concrete integration problem.

Suppose the system uses human-readable internal identifiers such as:

trace_0001
run_abc

Those values cannot be placed directly into the Trace ID or Parent ID fields of traceparent. Under the W3C Trace Context specification, the Trace ID must be 32 lowercase hex characters and the Parent ID 16, and all-zero values are invalid. A naive conversion produces something like:

00-0000000000000000000000trace_0001-run_abc000000000-01

A compliant receiver must ignore the invalid traceparent, so the downstream operation may start a new trace or remain uncorrelated — propagation silently fails.

The cleaner design:

Let the tracer generate valid OTel Trace IDs and Span IDs
Preserve the internal execution ID as a span attribute
Make the two identifiers joinable at query time

And note: the existence of a propagation helper does not prove propagation works. Test it across a real service boundary and confirm the resulting spans land in the same trace.

OTel and audit evidence serve different purposes

Introducing OTel does not mean replacing existing logs, audit records, or native traces:

Data	Primary purpose
Spans	Latency, errors, and distributed causal analysis
Metrics	Aggregation, trends, and alerts
Logs	Detailed event and exception search
Audit records	Accountability, critical actions, and tamper evidence
Native traces	State transitions, corrections, and deterministic replay

Audit records that require tamper detection or deterministic replay should not be moved into sampled OTel spans. OTel is a common observability layer, not an audit ledger.

MCP can become the agent-facing query layer

Standardized telemetry is not enough; the agent also needs a safe interface for querying it.

At the time of writing, Grafana provides an official MCP server and documents connecting Claude Code and Codex CLI to observability data. Sentry provides an official MCP integration for exposing issue and error data to coding agents.

A useful division of responsibility:

OTel provides shared meaning and causality
MCP, CLI, and SQL interfaces provide the agent-facing query surface

But a query interface is not automatically safe or useful. It still needs read-only access, controllable time ranges and result limits, discoverable attributes, repeatable queries, and before-and-after comparison — the six conditions again, viewed from the interface side.

The coding agent is also a telemetry source

One more angle worth noting for readers using Claude Code: the agent is not only a reader of telemetry.

Claude Code supports OTel export of its own metrics and events — sessions, token usage, tool executions — enabled via environment variables such as CLAUDE_CODE_ENABLE_TELEMETRY=1 and OTEL_METRICS_EXPORTER / OTEL_LOGS_EXPORTER (with console available as an exporter for local debugging). Events emitted while processing a single user prompt share a prompt.id attribute, so a prompt's API calls and tool executions can be correlated in the backend. See the official monitoring documentation for details.

This closes an interesting circle: the same standardization and propagation that make your system readable to the agent can also make the agent's behavior readable to your team.

The hard part is often the data boundary, not instrumentation

When introducing OTel, configuring an SDK or Collector may not be the hardest part. The harder question is what should be recorded and where it should be sent.

URLs, SQL statements, exceptions, prompts, tool arguments, and user data can unintentionally appear in telemetry. The OpenTelemetry guidance on handling sensitive data recommends avoiding collection of sensitive information where possible, and describes removing or transforming data with Collector processors (attribute, filter, redaction, transform).

However, moving all redaction responsibility into the Collector can make critical policy invisible from the application repository. Collector configuration should be versioned, reviewed, and tested alongside the application — or the application should at least maintain a clear contract describing which attributes may be collected.

OTLP export is also a new egress path. In environments with restricted networking, connectivity to a Collector or remote backend becomes part of the architecture and security design. Adding observability can mean adding a communication boundary.

Cloud telemetry introduces a time gap

When an agent uses cloud telemetry to validate a change, there is an unavoidable sequence:

Change
→ Build
→ Deploy
→ Execute
→ Export telemetry
→ Ingest into the backend
→ Query

Depending on the architecture, stable query results may take tens of seconds to several minutes. A local loop measured in seconds and a cloud loop measured in minutes are different feedback cycles, and a practical setup combines both:

Deterministic local tests
Local trace files
Smoke tests in a development environment
Before-and-after comparisons using cloud telemetry

Requiring the agent to deploy and wait for ingestion after every change makes the everyday loop unnecessarily heavy.

The order I would use today

Based on this review, I would approach agent-readable observability in this order:

Connect instrumentation to a real execution path so telemetry is actually generated
Make development output readable through local files or stdout
Propagate trace context across HTTP, queues, and workers
Keep business and execution IDs as separate attributes, not inside standard trace IDs
Define Semantic Conventions and custom attributes as repository-level contracts
Establish policies for sensitive data, cardinality, and sampling
Provide read-only access through MCP, CLI, or SQL
Make before-and-after comparisons repeatable under the same conditions

I would not begin with comprehensive auto-instrumentation. It is easier to evaluate OTel by picking one important path and completing the entire chain:

Generate → Propagate → Store → Query → Compare

An AI agent does not need to stare at a large number of spans. It needs to determine what changed because of its own modification, and verify that conclusion again under the same conditions.

OTel is a common language, not the finished system

The three repositories in this review are still under development, and their implementations will change. Even so, one distinction became much clearer: having OTel, generating telemetry, and making that telemetry usable by an agent are three different stages — and only the last one closes the loop.

Turning telemetry into part of an AI-assisted development loop requires more than instrumentation: it also requires access paths, domain schemas, data boundaries, and repeatable before-and-after evaluation. The right starting point is therefore not comprehensive instrumentation, but one minimal path where telemetry is reliably generated, accessible to the agent, and comparable across a change.

OTel is not the finished form of observability for coding agents.

It is one of the strongest common languages available for building telemetry that is structured, correlated, and reproducible enough for them to use.

Why My Local Coding Agent Could Act but Couldn't Finish

Takafumi Endo | ROUTE06 — Wed, 29 Jul 2026 07:53:24 +0000

There was a month where I blew through my token budget without noticing. Claude Code and Codex, running most of the day, on a codebase I was exploring more than editing. The ceiling I'd set turned out to be a number I'd passed weeks earlier, and I found out by getting the bill.

So I did the thing I'd been putting off, and ran a coding agent on my own machine to see what happened.

The short version:

Qwen Code, driving a quantized Qwen against a local llama.cpp server, built the UI fine. A video-site clone from scratch: header, sidebar, grid, watch page, all of it.
Then it couldn't work out why the thumbnails and video files weren't being served. Almost every tool call executed cleanly. The investigation made no progress.
It was also slower than Claude Code or Codex, and my best guess for why is repeated prompt processing rather than generation speed. I'll say what would actually settle that when I get there.

None of this is a benchmark. These are notes on where my thinking has drifted, written down mostly so I can find out where it's wrong.

Where my framing was off

The story I'd been telling myself was that token prices are going up. I can't really support that. Unit prices haven't broadly risen; my consumption did, and the shape of agentic coding is why. A turn in these loops can carry the system prompt, the tool definitions, the files already read, and the history along with it, so usage climbs with your setup as much as your effort.

I wrote on Medium that token spend only becomes an asset when you redesign the work around it. My first response to the bill wasn't to switch models. It was to notice that most of the tokens went into finding things, and to build a terminal emulator with tree-sitter and LSP folded in, so the agent could get deterministic answers to "who calls this." That became the graphs argument, and it comes back at the end meaning something I hadn't intended.

Two reasons to go local, and I'd rather not mix them

Cost. Frontier APIs charge per token; local open-weight inference doesn't. This is what got me looking, and on my hardware it doesn't hold: what I stop paying in dollars comes back as wall-clock and retries, which are scarcer than money.

Locality. Some work wants to be near the actor, being private, high-churn, latency-sensitive, or offline-capable, and that holds regardless of what a token costs. This one I believe, and it's the same state-gravity reasoning I keep landing on elsewhere.

Same hardware, different conclusions. I'd rather not borrow the second to prop up the first.

What I had wrong about Qwen

Qwen3-Coder-Next is described by its team as being for coding agents and local development, with emphasis on long-horizon runs, tool use, and recovering from failed execution. That last item is a loop property rather than a generation property, and a telling thing to optimise for. Apache 2.0 throughout, which for anything pointed at a real codebase is a gate that comes before capability.

I'd also been repeating that Qwen Code is a Gemini CLI fork. It did start as one, and in lineage terms still is, but it stopped syncing upstream early and has grown its own subagents, hooks, and MCP support. What matters here is that it's backend-agnostic: the same harness points either at a local endpoint or a commercial API, which is as close to a controlled comparison as I get on one laptop. Qwen also describes it as reaching feature parity with Claude Code, which is worth holding loosely, since feature parity and outcome parity are separate claims.

`3B active` is a compute number, not a memory number

The correction that most changed how I read model announcements. Activated parameters govern compute per token; total parameters govern the memory to hold the weights. Qwen3-Coder-Next activates around 3B and still has 80B in total, which at 4-bit is on the order of 40 GB for weights alone, before runtime overhead, KV cache, and the context you actually wanted. On a 64 GB machine that makes it a candidate rather than a comfortable one, and the margin thins exactly where I'd want it. It cuts the other way too: I'd filed myself under "small quantized models only," and the quantized 30B-odd class in fact runs with real headroom at this size.

Loading a model and running it comfortably over a long context are two different capabilities, and only the first appears in a requirements table.

Which is why I care about this tier rather than the top of the range. What decides whether local inference becomes normal is what runs on a machine a working developer already bought.

The sessions

Two sittings in April, an evening and then the following afternoon. They weren't the same task: the first picked up a half-finished short-video feed clone and carried on, the second built a video site from scratch. Different tasks, different days, different models, so nothing here is controlled. It's a log rather than an experiment.

Setup
Machine	MacBook Pro · M2 Max · 64 GB unified memory · macOS 26
Runtime	`llama-server`, llama.cpp b8680, Metal
Agent	Qwen Code 0.14.5, over the OpenAI-compatible endpoint
Models	Qwen3-Coder-Next (80B total, IQ4_XS) · Qwen3.6-35B-A3B (unsloth dynamic Q4_K_M GGUF, ~21 GB)
Context	131,072, compaction at 50%
Flags	`--jinja -ngl 99 -c 131072 -b 512 -ub 256`

Two notes on that. In this setup --jinja was needed for Qwen Code's tool calls to work at all, and depending on GGUF metadata llama.cpp may also want an explicit tool-aware chat template. The prompt batch is small, 512 with a micro-batch of 256, because anything larger died with a Metal compute error. That one matters later: batching governs how fast context gets ingested, and I had throttled it before I started measuring.

Session	Task	wall-clock	tool calls	reissued
Evening, day 1	feed clone, resuming	~1h25m	151	31
Day 2, first	video site, from scratch	~3h20m	154	11
Day 2, second	same, continued	~1h20m	240	8

"Reissued" just means the agent sent the call again. The logs don't separate malformed arguments from non-zero exits from failing tests, and a command that fails and then gets fixed is arguably the harness working, so the column reads better as friction than as an error rate. Day one is muddier still, with dozens of server-side compute errors that belong to the runtime rather than the model.

The part it couldn't finish

The second session is the one I keep thinking about. The UI came out, and came out well: header, sidebar with the full nav, category chips, a video grid with channel names and view counts and duration badges, and a watch page with player, title, subscriber count, like and dislike, share, description. All of it correct.

What never loaded was the contents of public/. Every thumbnail in the grid was a broken-image icon with its alt text showing through, and the player sat on a black frame with a spinner reading 0:00 / 0:00. A complete site with nothing in the slots.

The last hour or so of that session is the agent chasing that one 404, and the shape of it is the part worth looking at:

observed: thumbnails return 404
  │
  ├─▶ restart the dev server ....... call ok · 404 remains
  ├─▶ try a production build ....... call ok · 404 remains
  ├─▶ flatten the directory layout . call ok · 404 remains
  ├─▶ rewrite the database paths ... call ok · 404 remains
  └─▶ drop the SQL approach ........ call ok · 404 remains
                                     │
                                     └─ each call accepted and run,
                                        none of them establishing
                                        which path was being served

Much of that final session went into that loop. My last message in the log is a flat "this isn't working."

So the pair of numbers I keep returning to is this: of 240 tool calls, 232 went through without needing to be reissued, and the bug was still there at the end. That's a per-call rate, not a measure of how finished anything was. It had the competence to reproduce a large, fiddly interface from scratch, then couldn't work out why a static file wasn't being served, a smaller and much more boring problem than the one it had just solved. It kept generating plausible fixes for the wrong layer.

I'd call that a diagnosis problem rather than a generation one: forming and discarding hypotheses about a system it built itself, with no cheap way to check any of them. Which is the honest answer to whether a quantized local coder can ship a non-trivial front end. It can produce a lot of good code and still not close the last inch.

My prior experience makes me suspect Claude Code would have got out of that hole faster, and this run offers no evidence for that comparison: no matched run, nothing held constant, no recording, so there's no row for it in the table. It's a narrow suspicion anyway. Not about code quality, but about how quickly the loop notices it's fixing the wrong thing. I mention it because leaving it out would flatter the local run.

As for the time

"It's slower" turned out to be doing no work at all. Any of these could be the culprit:

time to first response
prompt processing throughput, meaning how fast it ingests context
output token generation speed
number of tool calls and reissues
context length and compaction behaviour

Published write-ups on agentic coding point at the same place. In a loop like this, each turn can require the server to process the system prompt, the tool definitions, the retained file context, and the conversation so far all over again, so the same material gets worked through dozens of times in one task, and prompt processing can eventually dominate generation.

call 1   [ system · tools · files read · history ] ──▶ one short action
call 2   [ system · tools · files read · history ] ──▶ one short action
call 3   [ system · tools · files read · history ] ──▶ one short action
  ⋮               re-read in full, longer each time
×240

   writing   a few hundred tokens per call
   reading   the entire transcript, per call

Meanwhile decode speed on my hardware class keeps improving, going by the numbers runtimes are publishing for Apple Silicon. The axis being optimised hardest is the one I'd already stopped waiting on.

The bottleneck may be less about the model writing than the model re-reading.

I want to be exact about that sentence's status. All I have is wall-clock, call counts, and reissues. What would settle it is cumulative prompt time against decode time, prompt tokens against tokens generated, and how much of each prompt came from cache, all of which llama-server reports and none of which I collected. So: leading suspect, consistent with how these harnesses behave, not demonstrated here. If prompt time turns out to be a minority of the total, the explanation doesn't hold.

If it does hold, the tooling detour means something I hadn't intended. Vague context is charged twice locally, once in tokens and once in wall-clock, every loop. Handing an agent short deterministic facts instead of files to re-read is a cost optimisation against a metered API; on hardware I own it becomes a latency optimisation, and I'm the one sitting there for it. The way that second session ended is the same argument from the other side: an agent that could cheaply ask which file was being served wouldn't have spent an hour fixing one that wasn't.

I wanted to blame quantization

Behaviour was less stable than I'm used to, with tool calls going sideways and loops not recovering cleanly, and my instinct was to file it under quantization. That instinct was mostly a wish for a tidy story.

Quantization does affect quality, and published comparisons show that two schemes at the same bit width can behave measurably differently, which is why I named both of mine. But the candidates I can't separate go well past it. The base models' tool-use ability, chat-template fit, sampling settings, context bloat over a long run, the runtime, the throttled batch size, the quantization recipe. That's a list of things to check rather than a cause, and most of it I can change without swapping models.

The same caution applies across the two sessions. Qwen3-Coder-Next is the model my own arithmetic said would fit but not comfortably, and it reissued roughly one call in five while throwing repeated Metal errors, where the smaller one ran much more cleanly. Memory pressure is my leading explanation, but it was a different model on a different task with a different 4-bit recipe, so I'd read it as suggestive. What survives is that bit width alone explains nothing.

Swappability is an investigation virtue, not a production one

Fixing a local OpenAI-compatible server as the execution layer is what made this tractable: the runtime stays put and I recombine around it. It may also be why it broke.

Look at those candidates again and notice how many are interface problems rather than capability problems. Template fit, tool-call formatting, sampling defaults, context compaction. Those are seams. A stack where one organisation post-trains the model and ships the agent doesn't have seams there, because the model was trained against that harness's tool loop, on its own tool schema, with its own recovery behaviour. The interface has been tested as one product.

So the view I've drifted to, an impression from use rather than something measured, is that model and harness are better evaluated as a single unit, and that the OpenAI × Codex and Anthropic × Claude Code advantage may come not only from model quality but from having no seam to misfit.

Cursor is the interesting exception, having stayed model-flexible while also training its own model against its own editor and tools. Notably it built that on someone else's open checkpoint, which suggests the load-bearing part is the co-design rather than owning the pretraining.

Objections I'd raise myself

"Your bottleneck is the runtime, not the model." Probably partly true, and I handed you the evidence: I was running a throttled prompt batch to stop Metal crashing, which sits directly in the path of the thing I'm complaining about. Whether it's the cause, I can't say without the prefill numbers.
"Your test flatters the local model." Agreed. A front-end build is generous work, being well-specified and verifiable, and it still didn't finish. A long refactor across an unfamiliar repo is where this would compound worst.
"Just rent a cloud GPU." The option I'm least able to assess. It removes the memory ceiling and hands you ops, utilisation risk, and cost modelling in return. I notice I keep not choosing it.
"The gap is closing, so this post expires." Probably. That's rather the point of re-running the test.

Where this leaves me

Either the open tier keeps compressing until a long local loop is comfortable, or the coupled stacks keep pulling ahead in ways a swappable arrangement can't track. I'd prefer the first, and I'm not confident enough to plan around it. Meanwhile the on-device direction is already being built into Apple's and Google's frameworks as a split rather than a migration, with private, low-latency work on the device and the heavy inference elsewhere, which makes the question which parts route where rather than local or hosted. Doing all of this by hand reads like the phase before that.

So I keep reinstalling. Every few months, same test, same laptop, and I write down where it broke. It hasn't changed what I open on a Tuesday. It has changed what I think I'm buying when I do, which is less about tokens and more about something that can work out which file is actually being served. Next time I'll log the prompt timings, and then I'll know whether any of this is true.

Why Legacy Rewrites Need a Judge, Not a Better Prompt

Takafumi Endo | ROUTE06 — Tue, 28 Jul 2026 07:59:03 +0000

Lately I keep getting asked about legacy replacements.

It's become one of the more common conversations I have, and the framing is almost always the same: AI can rewrite this now, can't it? The demand is clearly rising, and I don't think the premise is wrong. A coding agent can rewrite a legacy application startlingly fast. Producing the new code has stopped being the bottleneck.

What hasn't moved is the ability to say the new system behaves like the old one. That turns out to be a claim nobody has the evidence to make — about either system.

So when one of these comes up now, analyzing the old code is no longer where I'd start. That's not the obvious move: the default is to understand the old system first, then rebuild from that understanding. It's the order every plan I've seen begins in, and it's the order we tried, with a coding agent doing the analysis. The honest summary is that it didn't converge.

The approach I've drifted into instead:

Record the old system's observable behavior as an executable suite, accept that suite as the specification for the migration scope, and let coding agents implement against it until it's green.

Test-driven modernization, with the legacy system acting as the oracle — not supplying the tests. The scenarios, the observation points, and the normalization rules are all still mine to design. What the old system supplies is the expected values.

This isn't advice, and it isn't a claim that any of this is solved. It's the most practical hypothesis I've got after watching the obvious approach fail to converge.

Where I've landed for now (and expect to keep revising):

Source analysis produces interpretations. Execution produces comparable evidence.

For a declared scope, the coverage contract plus the recorded results plus the tests are the specification — not because they're complete, but because they were accepted.

The coding agent is the replaceable part. The harness that judges it is the asset.

The deliverable that matters isn't the new code. It's the evidence someone can sign a cutover against.

First I tried just pointing the agent at it

The version I built before this one had no harness in it at all.

Claude Code, pointed straight at the legacy codebase. I put real effort into the scaffolding — skills for the recurring analysis moves, prompt structures that held up across sessions, work plans that decomposed the system into ordered units, and a loop: analyze a region of the old code, write the equivalent in the new stack, review, move on. Not a naive setup, and I still think it was the right thing to try first.

It worked, partially. That's the awkward part — it produces something. You get a new implementation that is recognizably the same application, and on a good day a reviewer nods at it.

What it didn't produce was a reason to believe it. Three things kept going wrong, and they turned out to be the same thing wearing different clothes.

The token cost per unit of confirmed behavior was miserable. The loop spent most of its budget re-reading code it had already read, re-deriving conclusions it had already reached, and writing long analysis prose so the next step could consume it. Enormous input, and the output was a paragraph of interpretation — expensive tokens buying a plausible reading of a stored procedure.

Fidelity was something we checked by eye. Two screens side by side, two sets of records lined up, a squint. "Looks right." There is no number in that sentence. Nobody could say which side effects were verified and which weren't, or whether yesterday's slice was still passing. And volume defeats attention long before it defeats the agent: nobody eyeballs the four hundredth order-status transition carefully.

Nothing ratcheted. A slice that had been reviewed and accepted could quietly regress while the next one was in progress, and we'd find out at integration, or later. Manual review doesn't leave anything behind that can re-run itself.

The diagnosis I eventually landed on: I was trying to solve a measurement problem with better prompts. Every iteration of skills and plans was an attempt to make the agent's interpretation more convincing. What I needed wasn't a more convincing interpretation. It was a mechanism that could disagree with the agent without a human squinting at two screens.

So I stopped improving the analysis and started building the measurement. What follows isn't a design reasoned out in advance — it's what the failure of the first approach pointed at.

Behavior was never in one place

The analysis-first approach doesn't converge, and it isn't because the agent reads badly. It's that the behavior isn't gathered anywhere.

Some is in application code. The rest is in stored procedures, triggers, nightly batch jobs, a permissions table that three screens read differently, a scheduler entry nobody owns, an external service returning a shape the docs don't mention, and operational rules that live in a person. A Java / JSP + Oracle + nightly batch + mail system doesn't have a specification; it has an accumulated set of effects. You can read all of it and still not know the ordering, or which branch fires in production, or that invoice rounding differs by one path.

But you can run it — drive a business scenario against the running system and record what comes out the other side. Recording alone doesn't make that authoritative, though. It needs provenance (which build, which data set, which run), stable semantics across repeated runs, and an accepted policy that lets that run serve as the baseline. Human judgment belongs at the scope, policy, and cutover boundaries, not on every field of every run — putting a person in the inner loop is how this stops scaling at exactly the volume where it starts to matter.

A green suite also proves only the scenarios it contains, which is the obvious objection and deserves answering here rather than at the end. So the loop needs a second gate: evidence that the surfaces, journeys, data effects, error paths, and boundaries the scope requires are actually represented. Coverage here isn't a percentage, it's a contract about what had to be present. Which makes "the suite is the specification" a slogan; the accurate version is that for a declared scope, the coverage contract, the tests, and the attested legacy results together form the executable specification.

The comparator may normalize representation. It may not forgive behavior.

The harness runs each scenario against both systems and compares. Which sounds obvious right up until you try to compare two systems that were supposed to differ. IDs are new. Timestamps are new. Row ordering is unspecified. The new UI's implementation and DOM are deliberately different, even where the user-visible behavior has to stay equivalent.

So a comparator that demands equality is useless. But the fix is not a comparator that forgives things — this is what I got wrong at first, and it's the distinction the whole apparatus rests on.

Representation is generated IDs, request timestamps, encodings, the order of unordered collections, and metadata proven to be non-semantic. Note the proven: "this field looked incidental" is how a business rule gets discarded. What the comparator cannot do is decide that a behavior may change or disappear. That decision exists and is frequent, but it's a migration-policy decision that moves part of the scope outside strict translation, recorded with what was decided and by whom.

Layer	What it's allowed to decide
Normalization	representation only — the same behavior, differently expressed
Migration policy	intentional change or removal, outside strict translation mode

Two rows, deliberately. A permissive mode can carry a narrowly scoped exception — but never as a normal path to green. The moment "ignore this difference" becomes routine vocabulary, a green result turns into something you can negotiate your way into, and the apparatus is just an expensive way to feel reassured.

One scenario, end to end

Abstractly this all sounds tidy, so here's a single slice as it actually moves. Order creation, standard path, item in stock.

The legacy run, recorded:

scenario  order.create / standard / in-stock
legacy    build=legacy-2019.11  data=masked-set-3  run=8f2c

  screen      list refreshed, new row at top, status "pending approval"
  api         201  {order_no: "O-2024-000123", total: 150000}
  db          orders +1, order_lines +1, inventory_reservations +1 (qty 10)
  permission  approver check evaluated → allow
  events      OrderCreated
  batch       nightly invoice job picks it up (t+1)
  mail        order-received → customer address

The new implementation, first pass:

PASS  screen, api status, orders, order_lines, permission, batch, mail
DIFF  api.order_no              expected O-2024-000123   actual O-2026-000001
DIFF  inventory_reservations    expected 1 (qty 10)      actual 0

Two diffs, and they are not the same kind of thing:

order_no   generated id       → normalized (shape asserted: O-YYYY-NNNNNNN)
qty on     inventory reserve  → semantic; NOT normalizable

The first resolves. The second is behavior, so it becomes a task rather than a rule:

Expected:  inventory reservation created: 1 (qty 10)
Actual:    inventory reservation created: 0
Repair:    Add inventory reservation to order creation.
           Preserve idempotency.
           Do not modify billing or shipping modules.

Agent implements, harness re-runs, and the slice closes with something a human can sign:

order.create / standard / in-stock          PRESERVED
  evidence     legacy run 8f2c, new run c41a, 7 observed effects, 0 unresolved
  normalized   order_no, created_at, DOM structure
  policy       none applied

That last block is the actual product of the exercise. Not the code — the row that says which run, how many effects, what was normalized away, and whether anyone changed the rules to get here.

Rigor compresses, again

Note what the agent received: not a description of a system, but a diff and a scope constraint. In the first approach the equivalent input was paragraphs about how the legacy inventory module probably works — long, hedged, expensively derived, partly wrong. Here it's two numbers: shorter, and grounded in an observed run.

Same aphorism as the graph post, arriving from another direction. The more precisely the behavior was captured, the fewer tokens it takes to say what's broken. Capture costs up front and then stops costing on every iteration — the opposite of re-reading the codebase each round.

Which leaves the loop itself unremarkable, and that's the point: red-green-refactor, except the green came from a system that already exists.

The agent writes the code; the harness decides if it's right

The discipline is a trust-boundary question: the agent must not be the thing that judges its own work.

Claude Code, Codex, whatever comes next — interchangeable. The stable asset is everything around it: scenario definitions, execution adapters per stack, both runners, result normalization, behavior comparison, repair-task generation, evidence storage. Agents are strikingly good at producing a plausible "all tests pass," so the comparator, the normalization rules, and the evidence store are the pieces I want deliberately authored, small enough to review, and boring. The bespoke, agent-assisted part stays on the side where a mistake surfaces as a failing scenario rather than a silent pass — otherwise you've built an unsoundness that reads as safety.

The capture layers are mostly plumbing: browser driving for screen behavior (Playwright), boundary capture for APIs, before/after snapshots for the database, tracing for execution paths and side effects, stubbed sinks for batch and mail and events, JSONL and Parquet for evidence, SQLite and DuckDB for working state and diff analysis. Swap any of it for your equivalent; the tools matter less than they look like they do. What matters is that the output is a normalized record that can be replayed and compared — and that, rather than the language or the stack, is what decides whether a system can be migrated this way.

Two honest caveats there. A stubbed sink proves the system issued the right request at the boundary; it does not prove the mail arrived or the settlement cleared. And traces are not proofs of equivalence — internal routes should change in a rewrite. What traces buy is explanation: why a diff happened, which observations were missing, which side effects nobody thought to record.

What "complete" has to mean

No suite proves everything a system can do, so "complete" isn't available in the honest sense. What's available is an operational definition: for this scope, these surfaces and these effects had to be present, and the coverage contract says so explicitly. Everything else gets a bucket rather than silence:

PRESERVED     verified equivalent
INTENTIONAL   changed by policy, recorded and attributed
REMOVED       withdrawn by policy, recorded and attributed
UNVERIFIED    known unknown, still open

The middle two are outcomes of policy decisions, not comparator settings — the same separation as before, arriving at the sign-off document. And UNVERIFIED is the bucket that earns the whole scheme: a migration always has behavior nobody captured, and the difference between a good and a bad project is whether that list exists and gets looked at. It's also where faithfully-reproduced legacy bugs go to be argued about. You will reproduce them; the answer is to move them into INTENTIONAL deliberately rather than discover them later.

This is also why the unit of work is a slice — customer registration, order creation, invoice generation — rather than the system. Two hundred red scenarios at once tell you nothing, and progress becomes a count of slices with evidence attached, which is a harder number to fool yourself with than percent-complete.

What I'd defend

AI made implementation cheap. It did not make correctness cheap, and it made proving nothing easier at all. So the artifact I care about on these projects isn't the generated code. It's the executable specification that can reject the generated code — and the useful property is that nobody in the loop is judging their own output.

I'd hold the specifics loosely. The first approach didn't fail because it was stupid; it was reasonable given what the tools did at the time, and the tools moved. That'll keep happening. If agents get materially better at holding a whole system's behavior in view, or capturing behavior gets cheaper than I think it can, parts of the structure above stop earning their keep and I'll be building something else. What I'd defend is narrower than the design: the correctness of a rewrite has to be decided by something other than the thing that wrote it.

What I want is for a cutover to stop being a judgment call made on confidence and become something the evidence says — what was preserved, what changed by decision, and what nobody has checked yet.

If the behavior is captured properly, you don't have to ask anyone to be brave about the release.

Why Athena/Iceberg Tends to Make Code the Spec

Takafumi Endo | ROUTE06 — Tue, 21 Jul 2026 03:45:35 +0000

Every time this comes up, someone credits the same setup: Athena on Iceberg is where "the code is the spec" — where you open Git and read the whole system, catalog to transforms to schema, without logging into anything. In my experience they're not wrong.

What I want to argue is that they're right for mostly the wrong reason.

The reason people reach for is the engine — serverless, open format, nothing to provision. But the thing that actually keeps code as the spec, when it does, is something you could have applied to almost any engine. And the thing that breaks it, when it breaks, has nothing to do with Iceberg at all.

So here's the split I've landed on, for now: whether "code is the spec" holds is about 90% discipline and 10% engine. Athena/Iceberg earns that 10% honestly — but 10% is all it earns, and I keep watching people mistake it for the whole thing. (Just where my own tinkering has led — not advice.)

I should say up front that I'm still in the middle of this. What the best declarative setup for an agent actually looks like — how you turn a system into a spec it can read and act on without guessing — is something I'm actively testing, not something I've settled. Read what follows as a working idea at a particular moment, written down partly so I can find out where it's wrong.

To see where the 10% actually lives, it helps to notice that a stateful system always keeps two copies of itself.

The spec has two copies

One copy is declared: the code you wrote, the schema you committed, the transforms in dbt, the catalog in Terraform. The other is realized: the state the engine accumulates while running — statistics, physical layout, caches, maintenance history, tuning knobs someone set at 2am.

"Code is the spec" is really a claim about the distance between those two. When the declared copy explains almost everything about the realized one, you can reason about the system by reading Git. When it doesn't, you can't.

Some of that state is declarable — you can pin a distribution or sort strategy in DDL, dbt, or Terraform. But plenty of it isn't, or drifts away from what you declared: which strategy the engine is actually using once automatic optimization kicks in, when the last vacuum finished, whether statistics are fresh, which materialized view is stale, whether that partition is really being pruned. To answer those you log in and ask the running system. Now your spec is half in the repo and half in someone's head.

So the real question isn't "is my code readable." It's: how much of the truth escaped the code into runtime state I can't see? I've started calling that the hidden-state surface area. Shrink it and the code stays the spec. Let it grow and the code becomes a hopeful sketch.

I argued a while back that rigor compresses — the more precisely you can state a fact, the fewer tokens it takes to hand over. This is the same idea pointed at a platform instead of a function: the smaller the hidden-state surface, the shorter and truer the account of the system you can hand to anyone, human or agent.

Why this is mostly discipline

Here's the part I want to be honest about first, because it's the 90%: the engine doesn't make your system legible. Declarative rigor does.

A catalog expressed as data contracts, transforms as a single dbt DAG, infra as Terraform — that's what makes design intent followable in code. And it's almost entirely engine-agnostic. You can point all of it at Redshift and get something a newcomer can read top to bottom. You can also build an Iceberg-on-Athena setup that's an undocumented swamp of hand-run ALTERs and orphaned partitions nobody dares touch.

I've done both. The readable one wasn't readable because of the storage format. It was readable because the rules were declared, in one place, and enforced. "Iceberg, therefore legible" is a claim I'd push back on if someone else made it — so I should hold myself to the same standard.

If you do nothing else, do this part. It's where the leverage is.

But the engine sets the difficulty

Now the 10% — small, but not nothing. Given equal discipline, engines differ in how much state they insist on keeping inside themselves versus how much they externalize where you can see it. That doesn't decide whether you can make code the spec; it decides how much discipline it costs to keep it that way.

Athena on Iceberg externalizes an unusual amount. The stuff that's normally locked inside a proprietary engine — snapshot history, the manifest of what files exist, the current schema, the partition spec — lives as open metadata that isn't confined to one vendor's internal system tables. You can read it through standard metadata tables ($snapshots, $manifests, $history), through the catalog, or straight from object storage. It's still state, and it still changes at runtime — but the format is open and portable, so the same facts stay reachable from more than one tool.

Redshift keeps more of that truth behind its own interfaces. Materialized-view freshness, VACUUM/ANALYZE history, statistics, workload-management tuning, and — with automatic table optimization or AUTO distribution — the effective physical layout, which can shift with data volume regardless of what you declared. It's all observable; you just query the system views for it.

	Athena / Iceberg	Redshift
Visible in Git / code	Terraform, dbt, contracts, SQL/YAML	Terraform, dbt, DDL, contracts
Runtime state lives...	open metadata (snapshots, manifests, schema, partition spec)	engine-internal: MV freshness, vacuum/analyze history, stats, effective dist/sort under `AUTO`, tuning
To inspect it you...	read open metadata tables, the catalog, or object storage	query the engine's system views
Compute infra to manage?	no dedicated warehouse compute	provisioned: yes · serverless: mostly abstracted
Hidden-state surface	typically smaller, more externalized	typically larger, more engine-bound

The honest framing: it's not that one is readable and one isn't. Both expose their state — the difference is how. One hands you facts in an open format that multiple compatible tools can inspect; the other hands them back through its own interfaces. Same level of legibility, less engine-specific discipline required to preserve it — not necessarily less operational work overall. That's the whole 10%. (This is for the batch-oriented, per-tenant workload I keep describing; a giant, high-churn Iceberg estate grows its own large state surface — manifests, small files, snapshot sprawl, catalog commits, cross-engine compatibility — and the gap narrows.)

Why I actually care: the guesser downstream

Here's where it stops being an aesthetics argument for me.

The real line isn't S3 versus a database. It's this: a fact exposed through an inspectable interface the agent can actually reach is verified; a fact outside its observable context must be estimated. A Redshift VACUUM history the agent is allowed to query is verified; an Iceberg snapshot it has no catalog access or tooling for is a guess. The engine doesn't decide it — reachable evidence does. What Iceberg tends to do is make that evidence easier to expose safely and portably: open metadata is simple to grant read access to without also handing over the keys to a live warehouse.

And the consumer of those facts, more and more, is an agent. These days I'm rarely the one reading the schema first — Claude Code or Codex is, running in the repo, editing a migration, rewriting a transform. What it can see is the declared copy plus whatever interfaces I've wired it into; everything else it infers. The larger the hidden-state surface — or the harder its evidence is to reach — the more of my system the agent is quietly guessing about, and the more defensive lines I tack onto prompts: "check the effective sort strategy first," "don't assume the MV is fresh," "verify before you migrate." When the fact is reachable, it can state it flatly and move on; when it isn't, the best it can do is hedge — and hedging costs tokens and trust.

And this isn't OLAP-only. The agent touches both tiers — on OLTP it edits schema, writes migrations, reasons about a tenant_id guard; on OLAP it changes a dbt model, reads a partition spec, checks whether a snapshot rolled forward. The same question decides it either way: can it reach the evidence for what it's about to do? Legibility-for-agents is one property spanning the whole platform, not a warehouse feature.

It's the same move I make everywhere else

Once I saw "shrink the hidden-state surface" as the goal, I noticed I was already doing it at the architecture level, not just the table level.

The platform I work on keeps three kinds of state deliberately apart — durable relational truth in Postgres, hot disposable state in DynamoDB, private local work in per-user SQLite — and the thing I'm most careful about isn't any one store. It's the crossings between them.

OLTP  (write / update)                 OLAP  (read / aggregate)
┌───────────────────────────┐          ┌──────────────────────┐
│ control-db (Postgres)      │          │ Athena / Iceberg      │
│   durable, relational      │          │   S3 Tables (open     │
│ operational_state (Dynamo) │  ==3==>  │   metadata mart)      │
│   hot, TTL'd               │  bridges │ DuckDB (local)        │
│ metadata.db (SQLite)       │          │                       │
│   local, private           │          │                       │
└───────────────────────────┘          └──────────────────────┘
     the only sanctioned OLTP→OLAP paths are three named bridges,
     and Postgres reaches the lake through exactly one VPC Lambda.

The point of narrowing the crossings to a countable few — and letting Postgres reach the analytics lake through a single path — is the same point as preferring open metadata. Every uncounted pathway is hidden state: a way the system can be true in production in a shape the code never described. Three named bridges I can hold in my head. Twenty accidental ones I cannot, and neither can an agent.

Same principle at two scales: make the crossings and the state legible, so the code keeps describing the system. That the pattern reappears from a single table up to the whole control-plane-to-lake boundary is, honestly, most of why I trust it — though that's a hunch I hold loosely, not a thesis I'd defend to the death.

And this is where I've started spending real budget on purpose. Making OLTP and OLAP legible to an agent — declared schemas, reachable metadata, counted crossings, a system view the agent is actually allowed to query — used to read as tidiness, a nice-to-have for when you had time. With Claude Code and Codex doing more of the actual editing, it's stopped feeling like tidiness and started feeling like the interface I hand the most productive worker on the team. An hour spent making a fact reachable is an hour I don't spend, over and over, writing "be careful, verify this" into prompts — and the payoff compounds every time the agent runs. So I treat agent-legibility as infrastructure worth building, the way you'd invest in tests or types, not polish applied at the end. Whether it fully pencils out depends on how much of your work the agents are really doing; for the amount they're doing in mine, it already has.

Objections I'd raise myself

"So you're saying Iceberg is more readable than Redshift." No — I'm saying it externalizes more state, which lowers the discipline cost of legibility. A disciplined Redshift shop beats a sloppy Iceberg one every time. The 90% dominates; the engine only sets the exchange rate.
"Open metadata isn't zero hidden state." Correct. Compaction, small-file cleanup, maintenance jobs — Iceberg has operational state too. It's smaller and observable-from-outside, not absent. If I implied "no hidden state," that's overreach.
"Athena/Iceberg has its own tax." It does — and it's not about S3 consistency (object storage is strongly consistent now). It's concurrent-write conflicts, catalog commit semantics, small files, compaction, snapshot expiration, and orphan-file cleanup. Athena needs OPTIMIZE/VACUUM against Iceberg tables too. Legibility isn't free; I'm trading one set of runtime concerns for another, and I want that trade stated plainly, not smuggled in.
"This is just a warehouse-vs-lakehouse take in disguise." Partly. But the axis I care about isn't performance or cost — it's the size of the gap between declared and realized. Two separate arguments; I don't want to lean on the popular one to prop up mine.

Where this leaves me

The design goal I keep circling back to is small: shrink the distance between what the code says and what's true at runtime — because that distance is precisely where humans and agents are forced to guess.

Most of the shrinking is discipline: declare the rules, put them in one place, enforce them — the 90%, and no engine does it for you. The last 10% is picking tools that don't quietly hoard state inside themselves, but hand you their truth as metadata you can read, crossings you can count, facts you can verify. Do the 90% and almost any engine can be the spec; do the 10% too and the code stays the spec with less of you holding it together by hand. That's the honest version of what people reach for when they credit Athena/Iceberg — not that the engine makes code the spec, but that it asks less of you to keep it that way.

I want to be honest about how provisional this still is. I don't think anyone, me least of all, has settled what declarative management and code-as-spec should look like once the primary reader is an agent rather than a person. I'm running my own small experiments — which facts to externalize, which interfaces to expose, where the verified/estimated line should sit — and expect to be revising this for a while. The 90/10 is a heuristic I find useful today, not a law I'd stand behind tomorrow.

That, for now, is the shape I'm designing toward — a little more on purpose, a little less out of habit, and still figuring out the edges.

The Agent Runtime Got Heavy: Rethinking Sandboxes with Codex App Server

Takafumi Endo | ROUTE06 — Wed, 15 Jul 2026 03:06:18 +0000

Once an AI agent moves past being a chat box — reading and writing files, installing dependencies, running tests, watching them fail and retrying — the model alone stops being a product. The agent needs a place to work:

a filesystem
a shell and process execution
language runtimes and libraries
dev tools like Git
long-running processes
execution logs and diffs
permissions and an approval UI
state that survives between sessions

On the web, the usual way to provide this is to spin up an isolated container or microVM per user. AWS, Cloudflare, and Vercel all offer good services for exactly this. But should every agent product own a cloud sandbox?

I wrote before, in The Wrapper Got Heavy, that the thing we used to dismiss as a thin "wrapper" has become a heavy runtime — a sandbox plus an agent loop plus state gravity. This post is something like the sequel. If the runtime got heavy, the next question is where you run it — in the cloud, or on the user's own machine.

Lately I've been recommending a different shape more often. For a single-user agent, I first consider running Codex or Claude Code inside a desktop app. This isn't just "local is cheaper." Moving execution onto the user's PC changes more than infra — it changes how you design file access, state, latency, and the permission UI. Treat what follows as a working thesis, not a final verdict.

TL;DR

For single-user AI agents, a desktop app can be a more natural runtime than a cloud sandbox.

You can use the user's existing environment and compute instead of provisioning a second one in the cloud, and Codex App Server lets you reuse a serious agent loop rather than rebuilding it.

But Codex isn't an SDK — treat it as an embedded runtime that needs version pinning and compatibility management.

Cloud sandboxes have already come a long way

Let me say it up front: cloud sandboxes aren't bad. For public services that must safely run code from many untrusted users, a strong isolation boundary in the cloud is essential.

AWS AgentCore Runtime assigns a dedicated microVM per session. Each session has its own kernel, memory, and filesystem, and on completion the microVM is destroyed and its memory sanitized. The underlying Firecracker is a KVM-based lightweight microVM with under 5 MiB of overhead per VM (AWS's Tools writeup).

Cloudflare Sandbox SDK exposes command execution, file operations, background processes, and port forwarding as an API. You do need to understand its lifecycle: by default it stops after 10 minutes of inactivity and starts fresh next time, so ordinary local disk state is lost — you push durable state out to something like R2.

Vercel Sandbox gives you an isolated Linux microVM (Firecracker) with streaming, file management, network policy, and snapshots in the SDK. Persistent sandboxes are the default: on stop the filesystem is snapshotted, and it's restored on resume.

The hard part isn't "starting a VM"

When you build a sandbox in the cloud, the hard part isn't the boot API. In a real product you also have to solve:

Area	What you have to design
Lifecycle	start, sleep, resume, destroy, timeout
State	persistence, snapshots, caching
Transport	WebSocket, SSE, reconnect, output streaming
Security	network limits, secrets, privilege escalation
Placement	region, cold start, session affinity
Ops	logs, metrics, audit, crash recovery
Cost	CPU, memory, storage, egress, idle time
UX	approvals, progress, diffs, interruption, retries

For example, Cloudflare Containers can take a while to start from a stopped state, and you have to account for routing follow-up requests to the right instance — and for it possibly restarting in a different location. Even AgentCore sessions require carrying a session ID so requests reach the same microVM; lose it and you hit a cold start (microVM stickiness).

None of this is a flaw of the cloud. It's the complexity required to let many untrusted users share one fleet of servers. The question is whether a single-user desktop product actually needs that complexity.

On the desktop, the user's PC is already a finished runtime

A developer's machine already has the working repo, Git history and credentials, language runtimes and dependency caches, Docker and local databases, SSH config, an IDE, and plenty of storage, memory, and sometimes a GPU.

The cloud approach has to recreate all of that in a separate environment, keep it in sync, and persist/restore it as needed (clone, install deps, inject secrets, hand results back). Granted, there are options like Vercel Sandbox where persistence is the default, or Cloudflare's R2-based backup/restore — but the shape of "stand up a separate environment and sync it" remains. On the desktop, you just launch the agent in that directory. No network file sync, no upload to remote storage, no image build required. CPU, memory, and storage aren't metered and billed by a cloud provider to the app vendor — they're resources the user already owns.

One important caveat: even though the Codex or Claude Code process runs locally, LLM inference does not run on a local GPU. File and command operations are local; the model conversation goes over the network. A local GPU can help with workloads the agent kicks off — builds, ML, image processing — but for a single-user agent that's rarely the main draw. The bigger, more mundane wins are fast operations over large local files (parsing, indexing, searching, embedding) on the local SSD, and the user's existing toolchain working as-is.

So what a desktop setup lets the provider avoid, or greatly reduce, is the ongoing cost of sandbox CPU/memory/disk, durable storage, egress, orchestration, and monitoring infra. In return you take on distribution, updates, per-OS support, and the security design of local execution. So this isn't "local is always cheaper" — it's that the cost of compute and the burden of complexity shift from the provider to the user's machine. Even so, not having to run a per-user execution platform is a big deal, I think.

PTY brings interactive local execution into the app

When you embed a tool like Claude Code or Codex CLI in an app, calling child_process.exec() isn't always enough. These CLIs do interactive things: streaming progress, waiting for input, adapting to terminal width, ANSI control sequences, signals like Ctrl+C, and keeping long-lived processes alive.

That's where you need a PTY (pseudo-terminal). Microsoft's node-pty uses forkpty on macOS/Linux and ConPTY on Windows to make a child process believe it's attached to a real terminal. For display you can use xterm.js (the same one VS Code's integrated terminal uses). The overall shape looks roughly like this:

┌────────────────────────────────────────────┐
│ Desktop UI  (Chat / Diff / Approval / Term) │
└──────────────────┬─────────────────────────┘
                   │ restricted IPC
┌──────────────────▼─────────────────────────┐
│ Privileged Host Process                    │
│  Project / Permission / PTY / Audit        │
│  Codex App Server Client                    │
└──────────────┬─────────────────┬───────────┘
               │ stdio JSONL     │ PTY
        ┌──────▼──────┐   ┌──────▼──────────┐
        │ codex       │   │ shell / tools   │
        │ app-server  │   │ tests / servers │
        └──────┬──────┘   └─────────────────┘
               │
        OS-level sandbox → Local filesystem

Note that talking to Codex App Server itself does not require a PTY. App Server connects over ordinary stdio (JSONL); the PTY is for user-facing terminals and interactive child processes (shells, dev servers, progress-drawing CLIs). App Server does have its own PTY-backed command-execution API, but that's separate from the connection transport.

Codex is well suited to embedding in a desktop app

The specific reason I reach for Codex is Codex App Server. It's a local server process for driving Codex's agent machinery from a custom client — not just a prompt-sending API. It handles thread creation/resume/fork/persistence, turn start/interrupt/mid-turn input, approval requests for commands and file changes, streaming of execution events and diffs, config, ChatGPT login, and integration with MCP and Skills.

App Server holds threads as a long-running child process and connects over bidirectional JSON-RPC. A single input produces many events, and when approval is needed the server asks the client and pauses the turn until it answers. The integration pattern is clean: bundle the per-OS Codex binary, pin a verified version, launch it as a child process, and exchange JSONL over stdin/stdout. Codex's own desktop app and VS Code extension use the same shape.

The connection itself is light. You launch the bundled (version-pinned) Codex binary with the app-server subcommand as a child process and connect over standard I/O — stdio is the default transport, so you don't open a network port. Then you read the child's stdout line by line as JSONL: send an initialize request once per connection, and after you get its response, send the initialized notification (it's sent by the client, not returned by the server). Then call thread/start with the working directory (cwd), a sandbox mode (e.g. workspace-write), and an approval policy (e.g. on-request). That brings up one thread, and from there events — model output, diffs, approval requests — flow back on stdout.

In practice you add request-ID-to-Promise mapping, crash handling and restarts, event ordering, backpressure, and handling turns that are suspended for approval. That last set is where the "light" first impression ends — a restart racing an in-flight turn, or the initialization flow itself, is where the real work (and the surprise I hit below) lives. You can generate types matching your bundled binary with codex app-server generate-ts, which makes it easy to pin the binary/client combination. There's also a WebSocket transport, but it's officially experimental/unsupported; inside an app, keeping ports closed and using stdio is simpler and safer.

You get Codex's own local sandbox

Running the agent locally is not the same as letting the model do anything it wants with the user's privileges. Even locally, Codex combines an OS-enforced sandbox and approval policy:

macOS: Seatbelt
Linux / WSL2: bubblewrap (bwrap) + seccomp (falling back to a bundled helper that relies on user namespaces if bwrap isn't present)
Windows: a native sandbox using a dedicated low-privilege user, filesystem boundaries, and the firewall when run in PowerShell; the Linux sandbox when run in WSL2

In the standard workspace-write + on-request setup, going outside the working directory or reaching the internet requires approval. Sandbox and approvals are two separate dials: the former controls what's technically possible, the latter controls when to stop and ask. You don't have to build per-OS sandboxes from scratch — the execution side rides existing boundaries. App Server also returns approval events as structured data, so instead of making users type y at a raw log, you can build a product-native approval dialog.

Even so, embedding Codex isn't simple

Having written up the upsides, I should be honest that embedding it carries a real cost of keeping up.

When I recently upgraded Codex to the 0.144 line, an implementation that had been working stopped working, and recovery took real effort. I can't be sure the cause was only a specific change on Codex's side. Around the same time, users reported cases like app-server crashing right after launch in an environment bundling 0.144.0-alpha.4, and — after a desktop-app update — trouble with in-app browser control and with how running services were handled on restart. These are user reports, not a confirmed root cause or a documented spec change, but they point at the same thing: not just the agent's protocol but its updates and process lifecycle now need verifying.

This is exactly why the earlier "pin the binary version and generate schemas from it" matters. One distinction worth drawing: backward compatibility of the JSON-RPC protocol and compatibility of the whole runtime including process management are not the same thing. Even with a stable message contract, lifecycle-level incompatibilities can bite — binary replacement mid-update, a running turn racing a restart, stale runtimes lingering, missing helper binaries.

In our own case, the root cause wasn't the JSON-RPC protocol at all — it was the initialization flow. After initializing, App Server tried to connect to Remote Control, but our embedding context had no ChatGPT auth, so it retried forever and hung — presenting as won't start / freeze / a flood of errors. And the trap: setting -c features.remote_control=false did nothing — it's treated as an unknown key, silently a no-op. The switch that actually worked was an internal environment variable, CODEX_INTERNAL_APP_SERVER_REMOTE_CONTROL_DISABLED=1. The config surface and the runtime's real behavior had diverged, and the only working knob was undocumented and internal — which is precisely the kind of failure you don't get from an SDK, and do get from a runtime you embed.

What I took from this: don't treat Codex App Server like an ordinary SDK. Codex is a runtime you embed in your app. You want to pin, test, and be able to roll back the binary, schema, config, launch method, and process lifecycle as a single compatibility unit. In fact OpenAI itself describes bundling per-platform binaries and pinning to a tested version in its VS Code extension and desktop app. An upgrade is something to verify and then switch to, not something to follow unconditionally — that's my current operating stance.

Separate the UI process from the execution process

"Local" doesn't mean "safe." The agent's process sits close to the user's files, credentials, SSH config, and browser data — so the app's own privilege separation matters.

With Electron, don't let the renderer touch Node.js or the PTY directly. Enable the renderer sandbox and context isolation, and keep privileged operations in the main process or a narrow preload API. Expose to the renderer only vetted operations — start a thread, approve, interrupt, subscribe — and never a way to run arbitrary shell commands or read/write arbitrary paths. Manage the PTY and App Server on the privileged side. Tauri is the same idea: define per-command permissions and capabilities and minimize what the WebView is granted.

The UX advantages of the desktop shape

More than the infra savings, I think the UX difference is what really matters.

The files are already there. No waiting on upload or sync; you work directly against the current tree, including uncommitted diffs and local-only config.
You reproduce in the same environment. A problem that only happens on the user's machine can be investigated with the same OS, deps, and local services.
Big file operations are fast. Search and Git-history walks finish on the local SSD, without one HTTP call per operation.
Existing tools just work. The user's already-configured linters, test runners, Docker, Xcode, Android SDK, and so on are all available.
Approvals are easier to make meaningful. You can tie an approval for a write target, a network destination, or a command to the OS file picker and notifications.

The desktop shape has clear weaknesses too

It isn't always the right shape. Objections I'd raise myself:

If the machine stops, the agent stops. Sleep, power loss, and disconnects all hit it. Claude Code's Remote Control lets you steer from another device while execution stays local, but that's different from a cloud environment that keeps running while your machine is off. For long-running work you can combine SSH or a managed remote environment and split UI from execution.
Environment variance is large. Shell, paths, permissions, PTY, and package management differ per OS. "You can leverage the user's environment" and "you can't reproduce it" are two sides of the same coin.
Distribution and updates become a compatibility problem of their own. A cloud sandbox lets the provider update the runtime centrally, in one place. On the desktop you need a delivery pipeline that pins — and can roll back — the binary, schema, config, and launch method as one compatibility unit, and threads that unit through auto-update, not just development. (We track Codex versions with a weekly workflow and a lockfile-pinned version.)
You're close to secrets. A local agent can reach more sensitive data than a disposable cloud environment. Don't skip the working-directory boundary, network limits, approvals, and audit logs.
Not for running anonymous users' code. Playgrounds, online IDEs, coding tests, generated-UI previews and the like still need a cloud sandbox.

Which should you choose

Roughly, I'd think about it like this:

Requirement	Better fit
A single user operating their own files	Desktop
Leverage an existing local dev environment	Desktop
Handle lots of local files fast	Desktop
Investigate a problem specific to the user's machine	Desktop
Keep running while the machine is off	Cloud
Run anonymous users' code	Cloud
Guarantee an identical environment for everyone	Cloud
Update the runtime centrally, without per-client compatibility work	Cloud
Use centrally managed secrets	Cloud / managed remote env
Concentrate high-end GPU usage	Cloud / dedicated remote env

In a real product, a hybrid is natural: everyday work on Desktop + Local Codex, long or heavy jobs on a remote environment or Cloud Sandbox, untrusted code in a Cloud Sandbox, review and approval in the Desktop UI.

There's another axis worth using: the client form factor. Even within one product, I'd lean the desktop app toward a serious runtime — the side that embeds the heavy local work environment — and lean the web browser toward lightweight features — pushing heavy execution to a cloud sandbox and keeping the browser to viewing, approvals, and light tasks. The point is to separate where the heavy runtime lives from where you keep only a light surface.

This continues the argument from The Wrapper Got Heavy. Now that the runtime is heavy, the design question isn't "which client calls the model" but "where does that heavy runtime live, and where does the state gather?" By state gravity I mean the pull that draws the runtime toward wherever the state — the repo, dependencies, auth, caches, running processes — already collects. Seen that way, heavy execution belongs where the hardware and state naturally gather — the desktop app — while the browser stays a light window onto it.

Wrapping up

A capable agent needs a runtime with files, a shell, libraries, processes, and state. Providing that on the web means a large substrate — microVMs or containers, durable storage, network controls, lifecycle management — and AWS, Cloudflare, and Vercel provide it powerfully.

For a single-user desktop app, though, the user's PC is already a high-performance, persistent agent environment. Launch Codex or Claude Code from a desktop app with PTY support and you reuse the existing files, tools, caches, and compute. And Codex App Server exposes threads, events, diffs, approvals, auth, and config over bidirectional JSON-RPC, with embedding into local apps and IDEs officially in scope. That Codex carries its own OS-level sandbox is another implementation win.

Before building a cloud sandbox, it's worth asking once: does this agent really need to run on the provider's servers? If it operates the user's own files and tools, the first candidate might not be a web app plus a microVM. Desktop × PTY × Codex is becoming a practical default for this class of agent — at least, that's my current view.

Service and Codex App Server specifics reference the official docs as of July 2026; this area moves fast, so check the latest before relying on any detail.

Designing Schema Boundaries for AI Agents

Takafumi Endo | ROUTE06 — Wed, 08 Jul 2026 10:48:44 +0000

An agent can now change your whole persistence stack in one pass.

Ask Claude Code or Codex to "add a plan_tier to accounts and wire it through," and it will read the repo, edit the Drizzle schema, generate a SQL migration, update the dbt source, touch a model, regenerate the TypeScript types, add a test, run the build, read the failure, and fix it. Multi-file, coherent, green. A year ago that was an afternoon; now, in a well-shaped repo, it's a prompt.

For a while I read that as pure upside — schema changes stopped being bottlenecked on how fast a human can hand-write a migration. Now I think the upside came with a quieter inversion: the same speed that makes good changes cheap makes unsafe changes cheap too. And the unsafe ones are exactly the kind that pass review, because they look consistent.

I've written before about handing agents short, verified facts instead of asking them to be careful. This is the same argument aimed at the database — the place where a confident wrong move is most expensive. It's a working theory, not a universal rule.

Where I've landed for now (and expect to keep revising):

Agents making schema changes cheap is good. It's not the problem.

The problem is that the change is cheap while the verification boundary is still shaped for the human-migration era.

The dangerous change isn't the one that fails to build — it's the one that builds fine and quietly breaks a contract downstream.

What's missing isn't a better prompt or a stricter reviewer. It's a compiler that lowers every declaration onto one contract graph and judges the change against it.

One definition up front, so the rest reads cleanly: by contract compiler I mean a tool that reads every declaration of persistence shape — ORM schema, SQL DDL, dbt artifacts, object manifests, SDK types — lowers them into one graph, and evaluates a change against it as a set of operational hazards. Not a migration runner, not a codegen step. A judge.

The new reality: the agent writes the schema

It's worth being concrete about how wide the blast radius of a single "small" schema change already is. When an agent touches one column, the coherent version of that change spans:

Drizzle / Prisma / SQL DDL  →  migration plan     →  dbt source
        ↓                            ↓                    ↓
   app types / SDK          backward compat?         dbt models
        ↓                            ↓                    ↓
   API contract             RLS / tenant guard      Parquet export → S3/R2

(I write migration plan rather than migration on purpose: whether you're SQL-first or ORM-first, the migration is a derivative of a desired state, and it's the desired state the graph should be built from.)

An agent will happily update all of those in one commit, and it will make them look mutually consistent. That's the impressive part. It's also the trap: internal consistency across the files it edited says nothing about consistency with the things it didn't — the live database, last week's published artifact, the SDK a client already pinned, the PII policy that lives outside the repo.

So the interesting question stopped being "can the agent implement the change?" It obviously can. The question is: who verifies the contract graph the change lives in?

The hazard is the green build

Here's the shape of the risk, because it's not the one people reach for first. The scary agent change isn't the one that throws a compiler error — you'll catch that. It's the one where everything is green and the damage is semantic:

nullable quietly tightened, so old rows now violate a constraint that only bites on the next write.
a type narrowed — text → varchar(32) — that truncates in production and nowhere else.
an enum or code value removed or remapped, so historical rows decode or compare differently.
a rename modeled as drop-plus-add, which reads to every downstream consumer as data loss.
a PII column newly exposed to an analytics model and, three hops later, sitting in a Parquet export.
the dbt source left stale, so the model builds against a schema that no longer exists.
a dataset's Parquet schema changed without a version bump, over-writing current so yesterday's reader silently gets today's shape.

Many of these slip straight through a CI that only asks whether the SQL parses and the build passes. Wire in dbt contracts, source tests, migration lint, Atlas, or integration tests and some of them get caught — but the default "does it build" pipeline doesn't ask whether the change is destructive, backward-incompatible, or contract-breaking. In the human era that gap was survivable — changes were slow, and a reviewer's eye covered a lot of it. Speed removes the slack. When agents can produce these changes repeatedly, "a human will notice" stops being a control.

The failure I most want to avoid is the one that reads as safety. A green build on a breaking change is exactly that.

The lightweight stack is great — and it doesn't close the loop

I want to be fair to the tools this sits on, because I like them a lot.

dbt is genuinely good at the analytics side of this. Model contracts let you declare the shape a model must return — the column names and types — and at least the build fails when the logic drifts from that shape. (How far the constraints are actually enforced depends on the data platform, but as an analytics-output contract it's strong.) dbt-duckdb lets you run the whole DAG against an in-memory DuckDB inside a CI job, and its external materialization exports CSV/JSON/Parquet straight to a location you choose. Pair that with S3/R2 and you get a lightweight publish layer: compile the transformation, test it locally, publish the result, no long-running warehouse required.

The important detail isn't that the file lands in a bucket. It's that the artifact becomes another contract surface: a schema hash, a versioned path, a manifest, and a current pointer that consumers may already be reading. Overwrite that pointer with a new shape and you haven't "updated a file" — you've changed a contract other systems depend on, silently. Hold that thought; it's where a hazard I'll later call UNTRACKED_LATEST_OVERWRITE comes from — a name from this article's own vocabulary, not a standard.

But dbt's contract is an analytics-output contract. dbt can declare sources, test them, and watch their freshness — but that isn't ownership of the ops database's lifecycle. Indexes, constraints, RLS, triggers, extensions, tenant boundaries, PII classification, the app's ORM types — all of that lives upstream of the source block, managed by Drizzle, Prisma, Atlas, or hand-written DDL. dbt sees a projection of it and trusts the projection.

So the loop isn't closed. The analytics contract depends on an ops contract that nothing verifies it against — and the agent is now editing both ends at once.

What's missing is a harness

We already accepted this idea on the agent side. Nobody runs a raw model against a shell; you wrap it in a harness — the loop that orchestrates tools, prompts, permissions, and execution. OpenAI has used the language of an agent loop and harness around Codex CLI.

My claim is small: schema changes need a harness for the same reason agent loops do — an untrusted author producing fast, plausible actions against a system where mistakes are expensive. The author being a model rather than a human doesn't change the requirement; it sharpens it.

The shape I keep arriving at is four roles:

Author     human or agent writes desired state
           SQL DDL · Drizzle · Prisma · Atlas HCL · dbt SQL + YAML
              │
Observer   reads live state
           DB introspection · dbt artifacts · S3/R2 manifests · registry · pointers
              │
Compiler   lowers everything into one IR
           table · column · constraint · source · model · artifact · policy
              │
Evaluator  turns diffs into decisions
           safe · warning · blocked · requires-human

The Author is deliberately untrusted. I don't care whether a person or a model wrote the migration — I care what the Compiler and Evaluator say about it. That single stance is what makes the whole thing agent-ready: you don't have to trust the writer if you can judge the write.

Which is exactly why the Observer matters as much as the Author. The live database and the authored declaration have to be independent inputs. If the compiler only reads the migration the agent produced, it's grading the agent's story about the world — not the world. The whole point is to check the write against a state the writer didn't get to narrate.

Lower to an IR, don't diff strings

The declarations are all different renderings — SQL DDL, TypeScript, a Prisma schema, HCL, dbt's SQL + YAML + manifest.json, a DuckDB catalog, a Parquet schema, an object key. Compare any two as text and it breaks on the first reformat. So the Compiler lowers each into a common intermediate representation and compares that:

// illustrative, not a real schema — the point is which fields exist, not the format
type Column = {
  name: string
  type: string
  nullable: boolean
  semantic?: string      // 'email' | 'money' | 'tenant_id' | …
  sensitivity?: string   // 'public' … 'restricted'
  pii?: boolean
  lineage?: Ref[]        // where it came from, where it flows
}

A table carries analogous facts (keys, constraints, indexes, access policies); an analytics model carries its dependencies, its output columns, and how it materializes. The exact shape isn't the interesting part — what matters is that ops objects, dbt models, and published artifacts all land in one vocabulary the evaluator can reason over.

The point that took me a while: the IR is a unit of judgment, not an output. Types, validators, SDK clients, sources.yml, Parquet schemas, policy bundles — those are all derived from it. dbt's manifest.json is, in effect, the analytics-side IR you already have; the missing half is lowering the ops side into the same shape so the two can be compared at all. Whatever the agent writes, in whatever format, ends up flowing through one evaluator.

Hazards, not diffs

A diff tells you what changed. It can't tell you whether that's safe — and safe/unsafe is the only thing a gate actually needs. So the Evaluator turns a diff into a classified hazard with its blast radius attached, and emits it as structured data, because the readers are CI and an agent as much as a person. Something along these lines — the exact fields matter less than the idea:

{
  "status": "blocked",
  "hazards": [
    {
      "type": "COLUMN_DROP",
      "severity": "critical",
      "object": "ops.users.email",
      "affected": [
        "dbt.source.raw_users",
        "dbt.model.mart_users",
        "sdk.User.email",
        "artifact.customer_segments.v1"
      ],
      "reason": "column is still consumed by downstream models"
    }
  ],
  "nextAction": {
    "kind": "expand_contract",
    "requiresHumanDecision": true
  }
}

CI's question stops being "is there a diff" and becomes "what's the highest severity, and does anything here need a human." The vocabulary of hazards is finite and worth naming, though I won't try to enumerate it here — a column drop that's still consumed downstream, a type narrowing, an enum remapped, PII that reaches an export without a policy, a published artifact whose schema changed under a live pointer. They group loosely by where they originate: the ops schema, the analytics models, or the published artifacts. (The names I give them across this post are my own shorthand, a design vocabulary for the argument, not a standard.) Let the agent implement. Don't let it past the Evaluator.

Make the Boundary Machine-Readable

Everything above works with a human author too. Here's what changes when the author is a model — and it's the part I find most underrated. Give the agent the contract, not vibes.

If the harness can judge a change, it can also tell the agent the rules before the change. Instead of a paragraph of "please be careful, watch for breaking changes," you give it something machine-readable: which classes of change are pre-approved (adding a nullable column, an index, a test), which are off-limits without a deprecation path (dropping a column, exposing PII without a policy, overwriting a live pointer), and what the migration policy is (breaking changes go through expand–contract; a dataset shape change forces a version bump). The specific encoding doesn't matter much; treating the boundary as data the agent can read does.

Now the instruction isn't "fix it nicely." It's: change this so no hazard exceeds warning; if a critical is unavoidable, don't implement — return a plan. The agent iterates against structured feedback (a hazard verdict) instead of against a green checkmark that means nothing. Breaking changes come back as expand–contract plans, not as a DROP COLUMN that happened to compile.

This is the same thing I keep chasing in every one of these posts. The reason I stopped tacking "don't guess, verify, watch for false negatives" onto every prompt isn't that I started trusting the agent more. It's that the facts I hand it — and now the actions I allow it — carry their own guarantees. When "you may not expose PII without a policy" is a blocked action and a blocking hazard, I don't have to ask the agent to respect it.

Which points at the shift underneath all of this. The scarce skill is no longer writing the migration — an agent will write ten before lunch. The scarce skill is defining the contract that decides whether a migration is safe. That's the part that doesn't get cheaper when the model gets better; if anything it gets more valuable.

A few patterns fall out of this once the boundary is a compiler rather than a reviewer's attention — which is the point where "what does this look like in practice" deserves its own section.

What I would put in CI

None of this is real until it's a gate. What I want is for the harness to run like any other CI check — except that the question it asks is a different one. The loop, end to end:

AI agent
  │ proposes change
  ▼
Author files
  Drizzle · Prisma · SQL · dbt · SDK
  │
  ▼
Contract Compiler
  ops IR · analytics IR · artifact IR
  │
  ▼
Hazard Evaluator
  safe · warning · blocked · requires-human
  │
  ├── safe ──────────────▶ merge
  ├── warning ───────────▶ review
  └── blocked ───────────▶ agent gets structured feedback,
                            returns a plan instead of a change

The principle, not a spec: the gate compiles the proposed state and the live state into the same IR — independently — joins the dbt and artifact sides onto that graph, and returns a hazard verdict rather than a build result. It blocks on critical, routes the ambiguous cases to a human, and lets the safe majority through untouched. The mechanics of how you introspect the database or where you read the last published manifest are the boring, swappable part; the load-bearing idea is that CI evaluates a graph, not a syntax tree.

A few principles keep the gate calm to live with rather than something people route around: begin from a plan, not a diff; don't let the analytics source definitions and the ops schema drift into two hand-maintained copies of the same truth; and treat a published artifact as versioned and its live pointer as a deliberate move, not an overwrite. How you implement each is a taste question; that you don't skip them isn't.

The shift in one line: CI stops asking whether the migration builds, and starts asking whether the contract graph is still safe.

Objections I'd raise myself

"This is just linting / dbt contracts / Atlas." Those exist and they're good — Atlas flags destructive ops changes, dbt contracts pin analytics output. What none of them does alone is carry a pii label from an ops column to a Parquet export, or block a publish on that basis. The gap is the edge between the tools, which is precisely where an agent editing both ends creates trouble.
"Why not just give the agent more context?" Because the missing thing isn't context volume, it's a decision boundary. More repo text doesn't tell the agent whether a column drop is safe — the answer isn't in the files it's reading; it's in the graph across them. A contract graph can decide it; a bigger window just lets the agent read more of the question.
"You're just distrusting the model." The opposite. Distrust would be forbidding agents from touching schema. This lets them touch everything — and makes the boundary a compiler instead of my nerves. I'd apply the same harness to myself.
"Over-engineering for a three-table app." Yes. Below some size, a human reading the diff is the right control. The harness earns its keep exactly when change volume outruns human attention — which is the situation agents create.
"Hazard rules will have false positives." They will, and a conservative gate that occasionally blocks a safe change is a trade I'll take over one that occasionally ships a silent breaking one. But "tune toward missing fewer real hazards" isn't enough on its own — a gate that cries wolf gets muted, and a muted gate is worse than none. So the real requirement is that false positives be explicit, suppressible with evidence, and tracked as policy exceptions rather than quietly tolerated. An override should leave a record, not a shrug.

Where this is going

I came in through "agents make schema changes cheap" and walked out at something more structural: SQL DDL, an ORM schema, a dbt model, a Parquet schema, an S3 manifest, and an SDK type are all renderings of one contract — and in the agent era, the author of every one of those can be a model moving fast. Manage them as separate files reviewed by tiring humans and the speed becomes a liability. Lower them to one IR, judge changes as hazards, and hand the agent the boundary as context — and the speed goes back to being the gift it was supposed to be.

I hold the strong version loosely. The four-layer split and the IR-first stance feel more right the more I sit with them; the exact hazard taxonomy and how far to automate the boundary versus leave it to review are edges I'm still finding. And maybe for an analytics-first shop the honest answer is still a warehouse and shared Postgres with a careful reviewer, and this is a monorepo-shaped preference more than a law.

But the direction feels clear enough to design toward. Let the agents write the schema — the migrations, the models, the types, all of it. Just don't let the safety of it rest on how the diff happens to look on a given afternoon.

Agents should write schema changes. Whether a schema change is safe should be decided by a contract compiler — not by vibes, and not by whoever happens to be reviewing at 6pm.

AWS Is Not Simpler. Agents Just Got Better at Reading It.

Takafumi Endo | ROUTE06 — Tue, 07 Jul 2026 09:46:03 +0000

I optimized my architecture for the wrong model.

I used to think black-box infrastructure was the right abstraction for AI-driven development.

Vercel, Supabase, Cloudflare Workers — a sharp contract in front, a managed backend behind — felt like the obvious fit. The less an agent had to reason about, the fewer places it could get lost. Give it a clean interface, hide the messy backend, move fast.

I still think that was right for the agents we had last year. I don't think it's right for the agents we're starting to use now.

The shift is not that AWS got simpler. It didn't. Setup still takes longer, CI/CD takes more work to wire, and cost control has real limits. The shift is that agents got better at reading complexity — and once an agent can actually use a large structured context, the things I treated as overhead (resources, provider schemas, IAM policies, explicit queues, explicit alarms, explicit networks) become the highest-signal context I can hand it.

To keep this concrete, I'm holding the tool constant. This is HCL/Terraform on AWS vs HCL/Terraform on Cloudflare — same language, same workflow, two providers.

The inversion

Agents are…	Best served by…
Context-poor (last year's loops)	Black boxes — shrink the surface, hide the backend
Context-rich (now)	Inspectable systems — describe everything as code

The one-line version:

The better agents get at reading, the more valuable explicit infrastructure becomes.

I didn't become more pro-AWS because AWS got easier. I became more pro-AWS because agents got better at reading it.

Same Terraform, two providers

The interesting comparison isn't AWS-elegance vs Cloudflare-elegance. It's how much of the infrastructure topology and operational contract an agent can reconstruct from the HCL plus the provider schema alone.

	Terraform × AWS	Terraform × Cloudflare
Provider maturity	AWS provider is about as battle-tested as IaC gets; enormous public corpus of modules/examples	v5 is a ground-up, OpenAPI-generated rewrite — improving fast, but breaking and still stabilizing on a short cadence
Schema faithfulness	AWSCC is auto-generated from the CloudFormation resource schema, so it tracks CloudFormation coverage closely and picks up new services fast	Generated from OpenAPI; solid for resources, but Workers abstractions sit above what HCL expresses
What's visible in HCL + schema	Most of the infra topology and operational contract — queues, roles, permissions, schedules, alarms, networks, data-plane wiring	That a binding exists — but its behavior lives in `wrangler.json`, Worker code, D1 migrations, `package.json`, framework conventions
Infra shape reconstructable from HCL?	Infra shape: largely yes. App semantics: no.	Infra shape: only partially. App semantics live elsewhere.
Terse-prompt tolerance	High — common patterns are well-represented	High for small stacks; drops once Workers + D1/R2/KV/DO/Queues/bindings interact

The Cloudflare row isn't a knock — it's the crux. A Terraform file can tell an agent that a binding exists. It can't, by itself, explain how that binding is used, where responsibility sits between Worker code and storage, how migrations relate to runtime behavior, or which framework conventions are doing invisible work. With AWS-via-Terraform, far more of the infrastructure topology and operational contract is visible through the same artifact: queues, permissions, schedules, alarms, networks, roles, policies, data-plane wiring. The application still matters — Lambda code, migrations, and API specs are not in the HCL either — but the infra shape is less hidden from the agent. That's not because AWS is simpler; it's because AWS puts more of the operational contract into the same inspectable artifact.

Cloudflare is a different bet, not the wrong one

Workers, D1, R2, KV, Durable Objects, Queues, and framework-native deploy form a genuinely coherent platform. For cost, speed, and operational lightness it's one of the best balances available, and I reach for it happily.

It just isn't optimized around the same kind of explicitness. Cloudflare is improving Terraform — v5 is a real, OpenAPI-generated step up in coverage and API alignment — but its more interesting strategic move is elsewhere: intent-based, framework-native provisioning (VoidZero/Vite, Astro), where you read intent from the framework and provision the infra. In its VoidZero acquisition framing, Cloudflare describes a future where a single Vite deploy command detects an app's need for a database or object store and provisions resources like D1 or R2 with no manual dashboard step. That's a coherent future. It's simply a different bet from "everything explicit as code," and it's why HCL-on-Cloudflare underdetermines the system today. Evaluate Cloudflare as framework-native infra, not as Terraform that happens to target the edge.

The safety boundary (this is not "walk away")

Inspectable substrate is half the story. The other half is a loop that closes correctness with plan, policy, and tests — not with the model's confidence. Two Terraform-specific studies make the same point: surface success is not the same as being correct.

Looks like success	What actually happened	Study
Structured schema knowledge made the model a much better coder	Baseline overall success was 27.1%; with injection, technical validation reached 75.3% and overall success 62.6% — but intent alignment plateaued, the "Correctness–Congruence Gap." Valid HCL ≠ the infra you asked for.	Nekrasov et al., 2025
One-shot security "fixes" made the flagged issue disappear 83% of the time	Only 10% were actually clean, and 57–71% were deceptive fixes — the scanner went green, the hole stayed open.	TerraProbe — Alsaid et al., 2026

TerraProbe in particular was run the way you shouldn't ship: first-pass, minimally-prompted repairs, not a high-context, closed-loop workflow. That's the point — it's evidence for the loop, not against agents. Nekrasov et al. make the complementary case: even when structured knowledge improves validity, valid HCL still isn't the same as the infra you intended. A green check is not proof. So the substrate feeds a closed loop:

#	Stage	On failure
1	NL request	—
2	Pull provider schema + module docs (via MCP)	—
3	Generate HCL	—
4	`fmt` / `validate` / `plan`	plan diff → back to 3
5	Policy scan — Checkov / tfsec / OPA / Conftest	violation → back to 3
6	Cost estimate	—
7	Smoke test in an ephemeral env	—
8	Apply — with human review	—

The loop is the point: a plan diff or a failed policy check routes back to regeneration, never forward to apply.

Pulumi is the interesting exception here: it keeps most of the AWS schema substrate (its providers are bridged from the same Terraform providers) but swaps HCL for a real language — so the agent gets the compiler and type system as an extra oracle. The risk is the mirror image of the power: real languages also let agents get clever, so you lean harder on preview, policy-as-code, and tests to keep it declarative in spirit.

Why this isn't an AWS victory lap

I'm not returning to AWS because it's lighter. It isn't. Environment setup takes longer, CI/CD takes more work, cost control is harder than on a tightly scoped platform, and there's more surface area — more IAM, more policy, more wiring, more ways to be wrong.

But that surface area is also more explicit. For human-only development, the explicitness often felt like drag. For AI-driven development, it increasingly feels like leverage. The infrastructure I used to hide from the model is becoming the infrastructure the model needs to read.

That's the real shift.

Cloudflare may still win the intent-native path. Vercel and Supabase may still be the right answer when the contract is small and the backend should stay out of sight. But for enterprise requirements, complex systems, and agents that need to make grounded changes across infra and application code, HCL-on-AWS is hard to beat — not because it's elegant, but because it leaves more of the system inspectable as code.

Opaque platforms were useful when agents were context-bound. Explicit infrastructure becomes useful when agents are context-rich. We're crossing that line now.

If you've made the opposite call — betting on intent-native, framework-first infra for agentic dev — I'd like to hear how it's holding up. That's the fork I'm least sure about.

You Can't Review an Agent. You Can Review a Plan.

Takafumi Endo | ROUTE06 — Mon, 06 Jul 2026 09:45:05 +0000

A harness for AI-era Terraform.

I'm building one. For a while now I've been developing a harness for infrastructure-as-code as a private SDK and compiler — the layer that sits between whoever proposes a change (a person, an agent, CI) and whatever actually reaches production. This post isn't the tool. It's the thinking underneath it, and the few pieces I've become most convinced by while building it. (Notes from inside the work — where I've landed so far, not advice.)

The problem that sent me down this road is easy to state and easy to underrate.

A version of it happened recently. An agent fixed some Terraform; the PR read clean — tidy diff, sensible resource names, a plan output that looked exactly like what I'd asked for. It got approved. And then, at apply time, a different plan ran than the one that was reviewed: apply had re-planned against state that moved in between, and the diff that touched production wasn't quite the diff anyone had read.

Nothing broke, that time. But that near-miss is the whole reason the harness exists.

Because the danger was never "the agent writes bad HCL." Agents write perfectly good HCL; I let them. The danger is the distance between the plan a human reviewed and the plan that actually runs — and once agents are the ones proposing changes at volume, that distance is the thing I most want to nail shut.

Where I've landed for now (and expect to keep revising):

What AI-era IaC needs isn't AI that can apply. It's a structure where every change — human or agent — is evaluated at the same boundary, and only a reviewed plan ships.

The unit of trust isn't the agent. It's a specific, reviewed plan, bound byte for byte.

You can't review an agent. You can only review a plan.

Instructions to an agent can be broken. A CI gate can't be talked out of it. Put guidance in the prompt; put the guarantee in the gate.

Terraform/OpenTofu don't go away. You wrap them in a harness; you don't replace them.

Your repo has non-human authors now

For years IaC had a comfortable shape: a human writes HCL, a human reads the plan, the same human or a teammate runs apply. The author and the applier were the same kind of thing — a person: slow, few, accountable. Reviewing the author and reviewing the change were nearly the same act.

That assumption is quietly breaking, and it's breaking because of who's holding the keyboard. GitHub's Copilot coding agent, OpenAI's Codex, Claude Code in GitHub Actions — agents now open issues, push branches, and answer review comments in the repo, and standards like MCP and AGENTS.md are there so they can read your docs, state, and conventions and act on them. The detail that matters isn't any one of those tools; it's the implication: the IaC repo stopped being a place only humans edit. It's a place agents propose changes too.

And here's the part you can't review your way out of: you can read one agent's PR carefully, but you cannot review the agent. It isn't a colleague who earns standing over quarters; it's a process that opens the next PR just as confidently whether or not the last one was sound. Confidence is flat. Correctness isn't.

Reviewed and applied are two different facts

So "get the agent to write Terraform" solves the easy half. The half that matters is: what evaluates the change, and is it the same thing for everyone?

terraform plan reads remote state and produces a diff against your config. Save that plan and apply it, and Terraform runs exactly those actions with no further prompts. Don't save it — re-plan at apply time — and the gap reopens: state may have drifted, a variable may have moved, and the diff that runs is no longer the diff that was read. That's the near-miss from the top, in one sentence.

So the thing worth binding isn't the PR. It's the plan. Call it a plan fingerprint — an identifier over the saved plan, bound together with the findings it was reviewed against and a signature, so apply can refuse anything whose fingerprint doesn't match an approval record. That core — plan, findings, signature — is the part I lean on today. What I want folded into the identifier is wider: the plan JSON, the variables, the policy bundle, the workspace, the provider lock, and the toolchain (Terraform/OpenTofu version, provider versions, runner image, state version), because a plan is only as reproducible as the environment that produced it. I'm still widening what goes in; the honest state is a solid core and a growing edge.

One caveat worth stating early: the fingerprint can be public, but the artifact behind it probably shouldn't be. Saved plans and plan JSON can carry sensitive values, so treat them as sensitive build artifacts, not something to paste into a PR comment.

The fact I want the gate to be able to state flatly looks less like a paragraph and more like this:

IAC.PLAN_DRIFT   approval=#4821   severity=high   quality=verified
  claim:   applied plan ≠ approved plan
  cause:   apply re-planned against state changed after approval
  bind:    plan_hash + findings + signature   (+ vars/policy/toolchain: target)
  next:    reject apply | re-request approval on new fingerprint

A pattern-match can only hedge — "this might not be the reviewed plan, please double-check." A fingerprint comparison states one thing flatly: this is not the plan you approved. The rigorous check is the shorter one.

The harness, in four boxes

I keep drawing the same four boxes, so I've stopped pretending they're incidental.

Author      what do we want / why       (humans and agents write here)
Compiler    how is it implemented       (HCL today: Terraform / OpenTofu)
Observer    what is true right now       (state, drift, DB, audit, cost, history)
Evaluator   are we allowed to do it      (policy, fingerprint, approval, signature)

Author — intent. What do we want, and why. Both humans and agents write here, freely.
Compiler — translation. Intent into whichever engine you run — swappable by design, though today that's the HCL engines (Terraform/OpenTofu).
Observer — reality. More on this below; it's the layer most people under-build.
Evaluator — judgment. The only layer that can say no.

The load-bearing idea: Author and Compiler can be as smart or as sloppy as they like, because nothing they produce reaches production without clearing the Evaluator. You move safety out of "trust the writer" and into "verify the plan" — which is precisely the move that survives the writer becoming an agent. Most of what I'm building lives in the Compiler and Evaluator boxes; the other two are where it plugs into the world.

And to be clear about the engines underneath: Terraform, OpenTofu, and Pulumi are genuinely excellent — I reach for them daily, and the harness wraps them rather than replacing them. But none of them was designed AI-first; each still assumes a human author, a human reviewer, and a human at the apply prompt. That's not a criticism so much as headroom. The engines are great, and there's still real room for the layer above them — and, eventually, the engines themselves — to evolve into something an agent can be trusted to drive.

Observer isn't monitoring

The layer I see skipped most is Observer, usually collapsed into "we have some dashboards." But in an AI-era harness it's doing something specific: giving every actor — human or agent — a grounded picture of the world before they propose against it. Drift was already a problem when only humans touched the cloud; once agents and external tools change things through the API, an out-of-band change the Observer can't see is a blind spot the whole harness inherits. (Recent research is even throwing LLM agents at reconciling out-of-band changes back into code, which tells you it isn't solved.)

What I want Observer to actually gather:

Terraform/OpenTofu state, and cloud provider inventory
drift detection, and CloudTrail / audit logs
DB schema state
cost data, and security posture
policy-violation history, and incident / change history

With that, an agent references not just "the current code" but "the real environment," "the intent," and "what went wrong last time."

One gate, no side doors

A harness only works if there's no side door. The same boundary has to apply to the human on their laptop, the agent in the repo, the local CLI, and the CI runner — identically.

Concretely, three disciplines carry most of it:

One policy bundle, everywhere. The rules that run in pre-commit on a laptop are the same rules, same version, that gate the plan in CI. If local and CI can disagree, the local path becomes the bypass.
Approve a fingerprint, not a PR. Save the plan, hash it, and let apply consume only a plan whose fingerprint carries a signed approval. A PR can be approved and then have its plan change underneath it; a fingerprint can't.
Split the plan role from the apply role. The job that plans can propose; the job that applies accepts nothing but an approved fingerprint. HCP Terraform already leans this way — run stages, policy checks, run tasks, separable plan/apply permissions. The harness isn't new primitives; it's refusing to let anyone route around them.

BEFORE — raw AI x Terraform

  AI Agent --HCL--> terraform apply --> production
  (review, policy, plan-binding, role split: all fuzzy)


AFTER — through the harness

  AI Agent / Human
     | intent
     v
  Author --> Compiler --> terraform plan / tofu plan
                              |
                              v
                         Evaluator (policy + fingerprint)
                              |
                              v
                 Signed approval + plan fingerprint
                              |
                              v
                        Apply role --------> production

A rule in a prompt is only a wish

The failure mode I most want to avoid is safety that lives in a sentence.

"Please don't create a public S3 bucket" in an AGENTS.md is a wish. OPA turning the plan JSON into a decision that fails CI is a fact. Same intent, completely different load-bearing capacity. AGENTS.md and MCP make the Author and Compiler layers stronger — better context, fewer dumb diffs — but they don't make anything safe; they make it more likely to be good, which is not the same claim. Instructions can be broken — by a prompt injection, a confused tool call, a model that just… doesn't. So: put the guidance in AGENTS.md, and the guarantee in the Evaluator.

The Evaluator rules I reach for:

diffs containing delete / replace / drop → no auto-apply
public ingress → denied without an explicit, logged exception
high DB sensitivity → encryption, audit log, backup, private network required, or the plan fails
plan fingerprint ≠ approval record → apply refused
missing / expired / under-privileged approval → apply refused

One rule I want but haven't shipped: a stricter policy profile for agent-authored changes than for human ones — routing by author type mechanically, rather than trusting anyone less by vibe.

And once agents sit inside CI, the attack surface grows (OWASP keeps an Agentic-AI risk list for exactly this). Four minimums I wouldn't ship without:

Separate read-only tools from mutating tools. Let the agent read provider docs and state; don't hand it apply-class operations directly.
Separate plan from apply. The agent proposes up to a plan. Apply goes through signed approval and a CI gate.
Separate CI job permissions. Plan jobs get the plan role; apply jobs get the apply role and accept nothing but an approved plan.
Put policy in code, not the prompt. Don't ask for no public S3 — detect it in the plan and fail.

The through-line: stop asking whether to trust the agent, and make its output mechanically evaluable instead.

A `destroy` is the `DROP COLUMN` of infrastructure

This is where it stops being a generic "AI + Terraform" post, because the database people already solved a version of it.

A DROP COLUMN is a destructive change: irreversible, backward-incompatible, exactly what you don't ship in one move. Atlas detects destructive changes and fails CI over them; the expand-contract pattern — add the new shape, migrate, and only then, separately, remove the old — exists so the dangerous half never rides along with the safe half. Tools like Bytebase wrap the whole thing in review, approval, rollout, and audit rather than letting anyone touch prod directly.

Infrastructure has the same hazards and mostly none of the discipline. A destroy, a forced replace, a deleted stateful resource — these are the DROP COLUMN of infra. So here's the rule I borrow: destructive infra changes shouldn't be one-shot. Today the harness enforces that as a hard stop — a destructive change is a critical hazard that can't clear the gate without explicit human approval. The direction I'm pushing toward is the database's fuller two-phase discipline: expand, migrate, then contract, each step approved on its own. The stop exists now; the mechanical two-step is where I'm headed.

Make it concrete. These three simplified plan entries are not equal, even if a shallow policy sees them as the same category of destructive change:

replace   aws_db_instance.main
delete    aws_s3_bucket.logs
destroy   aws_kms_key.customer_data

A generic "no destructive changes" rule treats them as one category. But the Evaluator shouldn't reason about the verb — it should reason about what the resource means. Here's the reading I'm building the Evaluator toward — polished more than it currently is, but the direction is the point:

destroy aws_kms_key.customer_data
  classification = confidential
  stateful       = true
  recovery       = hard          # key loss = data loss
  blast_radius   = production
  => DENY. expand-contract required: new key -> re-encrypt -> retire old, each approved

delete aws_s3_bucket.logs
  classification = internal
  stateful       = true
  recovery       = medium        # lifecycle-archived elsewhere
  blast_radius   = production
  => HOLD. require explicit retention check + second approval

Now the gate isn't guessing from a keyword; it's deciding from the resource's meaning — at least, that's the target. I want to be honest about where the line falls in what I've actually built: the database-side version of this is real — a schema's sensitivity already propagates into required controls — while deriving infra-side labels like recovery and blast_radius to the precision shown above is still partly ahead of me, not fully behind. The move I like even more is where those labels come from: propagate intent across the boundary. If a schema is labeled confidential, deletion-protected, RPO-strict, that intent shouldn't stop at the database —

DB schema intent
  classification = confidential
  rpo            = 5min
  deletion       = protected
        | propagate
        v
Infra requirement
  KMS encryption . PITR backup . deletion protection
  private endpoint . audit logging
        | enforce
        v
Policy gate
  any of these unset  ->  plan fails

Put plainly: the same way you don't let a DROP COLUMN through on a whim, you don't let a destroy through on an agent's confidence. Most "AI IaC" writing stops at "the agent can write HCL." The interesting seam is one layer down — where application semantics, DB constraints, and infra safety turn out to be the same dependency seen from different angles.

Sign the plan, not the checkmark

Software supply chains already made this move — SLSA provenance, artifact attestations, signed build provenance: verifiable claims about who made what, under whose authority. If a build artifact deserves that, an infra change deserves it at least as much, and an AI-involved one most of all.

So an approval isn't a green checkmark. It's a signed statement — the same core-vs-target split as the fingerprint above: the load-bearing fields today are the plan, its findings, and the signature; the fuller record below is the shape I'm building toward:

Field	Meaning
commit SHA	which source change
plan hash	which plan was approved
plan JSON hash	the exact diff evaluated
policy bundle hash	which rules judged it
workspace / env	dev / stg / prod
actor	AI, human, CI job, service account
reviewer identity	who approved
approval reason	why it was allowed
expiry	how long the approval is valid
signature	tamper-evidence, non-repudiation

Now "who approved this change, against which plan, having seen which policy result" has an answer you can verify months later — not reconstruct from memory and Slack scrollback. Call it non-repudiation for the AI era.

Objections I'd raise myself

"This is just CI/CD with extra steps." Partly. The step that carries the weight is binding approval to a fingerprint, not a PR. That one substitution is most of the value.
"Agents can be trusted more than this implies." Maybe, eventually. But the harness costs about the same whether the agent is excellent or awful, and it fails safe either way. I'd rather not stake the blast radius on the model being good this week.
"plan/apply roles and policy gates already exist." They do. I'm not claiming new primitives — I'm claiming one boundary for everyone, human and agent, CLI and CI, with no privileged bypass.
"Expand-contract for infra is over-engineering." For a weekend project, yes. For anything with a stateful resource you'd grieve losing, the DB people already learned this the expensive way, and I'd rather borrow the scar than earn my own.

Where the harness leaks

Three honest edges. The Compiler layer fragments — OpenTofu is going its own way as a CNCF project, and Pulumi and CDKTF aren't HCL at all; the harness only helps if the Evaluator can read every engine's plan format. Drift is a genuinely open Observer problem — an Observer that can't see out-of-band change is a harness with a blind spot. And every gate is a place a rushed team adds a bypass; an "emergency skip" used weekly is theater. If the escape hatch isn't itself logged, signed, and rare, none of the above holds.

Self-driving isn't unattended

The last decade of IaC went hand-crafted → declared. The next one is going declared → self-driving — and "self-driving" is going to get read as "unattended apply." I think that's the wrong reading. Self-driving infrastructure isn't an agent holding the apply button. It's an agent proposing freely into a harness where only a reviewed, fingerprinted, signed plan reaches production.

What matters in AI-era IaC was never that the agent can write HCL. It's that whatever it writes passes through intent, implementation, observation, and evaluation — Author, Compiler, Observer, Evaluator — and that only a reviewed plan lands in prod.

Don't put the caution in the prompt. Put it in the gate.

That's the shape I keep building toward — still wrong in places I haven't found yet.

AI Agents Don't Need a Monorepo. They Need a Readable Codebase

Takafumi Endo | ROUTE06 — Thu, 02 Jul 2026 01:56:10 +0000

For an AI, a monorepo is good — concentrated context is more efficient, everything in one place. But lately I've stopped asking whether a project is monorepo or multirepo. The repo boundary is no longer the unit I care about most. The coordination boundary is — and underneath even that, one plainer thing: whether the codebase is readable to the agent at all.

By readable I mean something concrete: the agent can infer responsibility from names, find the right files fast, see where boundaries are, and verify a change with predictable commands. That holds in a monorepo and a multirepo alike — and it decides more than the repo shape does.

The situation I'm writing about is the solo-or-small-team case: one person orchestrating many agents, with little time spent negotiating boundaries with other humans. So the question I ask first is — can I run several agents on this codebase at once without them, or me, becoming the thing everyone waits on?

I once wrote that the writer moved back to the edge — agents living inside the work environment, pulling state toward them. This is the sequel. The writer didn't just relocate. It multiplied. When writers multiply, the constraint that matters in a design changes too.

Not advice, and not "monorepo is over." One person's notes, written mostly to find where they're wrong.

Where I've landed for now (and expect to revise):

monorepo is still good for AI — concentrated context is more efficient.

But the real question isn't monorepo vs multirepo. It's how little your structure obstructs human + agent parallelism.

On a team, human coordination is the bottleneck, and it caps how many agents any one person can actually run.

Solo, with clear responsibilities and in/out contracts, multirepo works just as well — clone into a parent directory and implement across it.

Before any of that: directory layout, naming, and feature names have to be AI-readable. That precondition matters more than the repo shape — in a monorepo and a multirepo.

monorepo helps — when "same place" is machine-readable

monorepo genuinely helps agents. Code, types, tests, dependencies, design decisions in one place; change an API and its downstream app in one commit; reason across boundaries. That's real.

But Nx keeps warning that repos merely dumped into one directory aren't a monorepo — they're code collocation: no boundaries, unstructured tooling, irrelevant tests running. What turns collocation into a benefit is the layer on top — affected-only build/test, a dependency graph, CODEOWNERS, enforced API boundaries.

So the value isn't "same place." It's same place, made machine-readable. That distinction runs through everything below.

The bottleneck is coordination, not the repo

When several people share one repo, their work collides. To avoid that, tasks, responsibilities, and review units get carved to fit human collaboration. That's correct — because the human is the bottleneck. But it also caps how many agents one developer can run. If you can drive ten agents but review-and-consensus only clears three, your effective parallelism is three.

When one person owns the whole repo, that ceiling lifts. You dispatch agents on your own judgment, across features, with no review queue in the way. You spend the parallelism directly. A concrete afternoon looks like this:

Agent A — update the API contract
Agent B — fix the frontend calls to match
Agent C — write the migration and seed data
Agent D — chase the failing tests and typecheck

Four changes moving at once, all mine to reconcile — no one to sync with first. That's the shape of work this whole post is about.

	Team, shared repo	Solo, many agents
Bottleneck	Human coordination (review, consensus)	Attention, verification, tooling
What sets the repo boundary	Coordination units	Whatever the agent reads well
Effective parallelism	Capped by review throughput	Capped by your attention, machine, and tooling
Right shape leans toward	Boundaries that fit people	Boundaries that fit agents

That gap is why the monorepo-vs-multirepo axis stopped feeling central to me. The center is the coordination boundary — and it doesn't have to line up with the repo boundary. Teams cut repos to match coordination. Solo-with-many-agents, coordination nearly vanishes, so you can draw repo lines however you like. The only constraint left is: can the agent explore, change, and verify without getting lost?

Claude Code and Codex already assume this — worktrees running a feature and a bugfix as separate checkouts at once, tasks executing in independent sandboxes. One human orchestrating many agents, treated as a first-class workflow.

At scale, "sees everything" backfires

Counterintuitively, seeing everything in a big monorepo often hurts. Anthropic's large-codebase guidance notes that a giant root CLAUDE.md and stray file reads fill the context window and degrade cost and performance; the fix is per-directory CLAUDE.md, read-deny rules, code intelligence, sparse worktrees. Research points the same way — agents don't solve more just by reading more, because broad context doesn't automatically become useful structure, and can even drop performance.

What agents need isn't full visibility. It's fast paths to the structure that matters — true in monorepo and multirepo alike. The problem was never size by itself. It's undirected size. Large is fine when the map is good; large without a map is just noise.

Before any of this: the structure has to be readable

Here's the part I actually care about most, and it sits underneath everything above. Whether you land on monorepo or multirepo, none of it works if the directory layout, the naming conventions, and even the feature names aren't legible to the agent. That precondition is more fundamental than the repo shape — it's what makes a monorepo worth its concentration and a multirepo worth stitching together.

Repo structure is itself a fact you hand the agent — rigor compresses. Vague structure burns tokens on guesses; machine-readable structure lands in a line. Reports back this up — LLM-friendly structure maps improving accuracy and cutting completion time, text+structure hybrids trimming input tokens, AGENTS.md alone reducing runtime and token spend. The numbers are workload-dependent, so I don't take them literally, but the direction is consistent.

So the order of operations is the opposite of how the debate usually runs. Pick the repo shape last. Make the structure readable first.

The repo is physical. The workspace is operational.

Readable first — then the question becomes how to keep it readable when the code is split across repos. The unit shifts from repo to workspace. Claude Code's --add-dir pulls sibling repos into one session; Nx points at "synthetic monorepo" infrastructure to view across repos. The idea: repos can be split, but the agent sees one meaningful workspace.

My old line — clone several repos locally, open the parent directory, implement across them in one context — fits here. But the parent directory alone is weak. What earns its keep is the thin layer above it:

Layer	What it is	Why the agent needs it
`AGENTS.md` / `CLAUDE.md`	Instructions at root + per directory	Tells the agent where to look, not just what the project is
Workspace manifest	Which repos exist, how they connect	Turns a folder of clones into one workspace
Cross-repo dependency map	What depends on what	Lets the agent trace impact across repos
Unified verify commands	`test` / `lint` / `typecheck` / `build` / `dev`	One way to check work, everywhere
Contracts	API schema, event schema, migrations	Makes boundaries machine-checkable, not assumed

With that layer, multirepo behaves like a synthetic monorepo. Without it, even a clean monorepo wastes context.

Objections I'd raise myself

"multirepo is just heavier ops." Half true — migration fan-out, cross-repo visibility, dependency tracking. My claim is conditional: when the coordination boundary disappears, multirepo + parent workspace beats a team-shaped monorepo more often. Not always.
"contracts rot." The load-bearing objection. The moment a contract drifts from the code, the synthetic workspace is a fiction. So contracts have to be enforced in CI, not kept as a promise humans remember.
"don't generalize solo to teams." I don't. Teams need coordination; carving repos to fit it is correct. My one point: the right shape moves with coordination cost. Fewer people, more agents per person → the scale tips toward workspace + contracts.
"synthetic monorepo is fragile." It is. Clones under a parent directory collapse fast without a manifest and a dependency map. Tooling is still thin here, and I'm feeling my way.

A checklist that earns its place

Not exhaustive — roughly the order I've found things matter.

Area	Do this
Structure	`apps/` `packages/` `services/` `libs/` `contracts/` — responsibility legible from the name
Agent instructions	`AGENTS.md` / `CLAUDE.md` at root and per directory
Contracts	API / event schema, DB migrations, input/output contracts, made explicit
Verify	Standard `test` / `lint` / `typecheck` / `build` / `dev` commands everywhere
Boundaries	CODEOWNERS, public API, import boundaries, dependency rules
Parallelism	Assume worktree / sandbox / branch-naming from the start
Multirepo	Parent workspace manifest + cross-repo dependency map
AI readability	A separate "where to look" doc for agents, apart from the human README

The shape, in one line

monorepo is still a good way to colocate context — for an AI, concentration is efficiency. But the win isn't the monorepo. On a team, split responsibilities so humans don't block each other. Solo with many agents, clear contracts let a multirepo do the same job. And underneath both, the thing that actually decides whether an agent thrives is the same: is the structure readable?

The writer moved to the edge, then multiplied. What paces the multiplied writer is no longer where the code lives. It is how far humans and agents can move without waiting on each other — and how quickly an agent can find its way around before it moves at all.

Repo design in the AI era isn't about where you put the code. It's about how readable the structure is, and how little you obstruct the parallelism between humans and agents. Held loosely — a view I plan to keep testing as I design against it.

Let Aurora Sleep: Multi-Tenant SaaS Cost, Reconsidered with AI IaC

Takafumi Endo | ROUTE06 — Tue, 30 Jun 2026 10:21:48 +0000

For most multi-tenant SaaS, the default still rhymes: PostgreSQL on Aurora, behind an API, in a private subnet. Stable, well-understood, the shape you'd draw on a whiteboard.

But I keep feeling a mismatch between what that shape costs and what it actually does while a product is small or bursty. A lot of the time, Vercel + Cloudflare + Supabase or Neon would give me similar real-world performance for less. And yet I get pulled back to AWS and Aurora — not for raw performance, but for enterprise requirements: VPC isolation, audit posture, "it has to live in our AWS org."

What changed for me is the third option in that fork. It used to be "cheap edge stack or heavy AWS stack." Now there's a middle path: keep the AWS/Aurora skeleton the enterprise wants, but redesign it so it stops costing like it's always on — and reach that redesign by sparring with an AI against a real dev deployment, instead of needing to already be an infra specialist.

Here's the whole idea in one picture:

BEFORE — everything flows through Aurora
  Client ── API ── VPC App ── Aurora (always warm)
                      │
                      └── NAT ── OpenAI        (NAT always provisioned)

AFTER — Aurora only for control/commit
  Client ── CloudFront / S3            viewer & artifacts (no DB)
         └─ Hot Lambda ── DynamoDB     hot path / cache / counters (no DB)

  Control actions ── VPC Lambda ── Aurora        (wakes on purpose)
  LLM calls ──────── non-VPC Lambda ── OpenAI     (no NAT, no DB)

One scoping note up front: this is primarily for dev, internal tools, bursty early-stage SaaS, and low-frequency enterprise environments — not a blanket "let your production database sleep" recommendation for steady, high-traffic workloads. It's an optimization for a specific shape of usage, not a rejection of the proven production default.

Not a "Postgres is over" piece, and not a best-practice writeup either. This is something I'm still validating — a design space I mostly reached by sparring with Claude Code and Codex while keeping one eye on cost-performance, then deploying to dev to see what actually held. Notes on where my thinking has drifted, written down mostly so I can find out where it's wrong. If anything here is useful, take it as "you can stumble into shapes like this too," not "do it this way."

Where I've landed for now:

The cost pain usually isn't Aurora. It's making Aurora the center of every request.

Demote Aurora to a thin control plane — canonical state, commit, approval, audit — and let it sleep.

Push viewing, LLM hot paths, and ephemeral state to S3 / CloudFront / DynamoDB / non-VPC Lambda.

What makes this reachable for non-specialists is declarative schema + IaC + AI, validated agilely in dev.

The default bills like it's always on

The textbook shape — CloudFront → ALB/API Gateway → app → Aurora, pool model with tenant_id everywhere and RLS for isolation — is fine. The problem is what accretes around it to make it reliable: always-on Aurora, RDS Proxy, NAT Gateway, readers, VPC endpoints, logs.

For dev or a 1–30 person workload, the fixed cost of reliability is wildly out of proportion to the traffic. You're paying ledger-grade rent to store scratch work deleted in an hour.

The mismatch isn't "Aurora is expensive." It's "Aurora is expensive when it can never go idle."

Here's the cost shape the redesign is chasing — not exact dollars, but where the fixed costs go:

BEFORE                              AFTER
- Aurora always warm               - Aurora wakes only for control/commit
- NAT always provisioned           - No NAT for LLM egress
- RDS Proxy holding connections    - No Proxy in the sleep path
- DB hit on health/viewer/LLM      - Viewer/LLM/health paths stay DB-free

The reframe: Aurora as a thin control plane

Don't put Aurora in the path of every request.
Make it a thin control plane: canonical state, approval, audit, commit.
Move viewing, LLM execution, short-lived state, and delivery
to S3 / CloudFront / DynamoDB / non-VPC Lambda.

There's a system of work — high-churn, disposable, fine to lose — and a system of record — money, contracts, audit, singular and strict. The mistake is paying record-grade prices for work-grade state. So split by job:

Layer	Job
S3	artifacts, reports, raw payloads (cheap bulk)
CloudFront	viewer delivery — keeps reads off Aurora
DynamoDB	projections, cache, locks, progress, counters (hot path)
Aurora	tenant, RBAC, manifest, lineage, approval, audit, rollups
non-VPC Lambda	outbound LLM calls — no NAT, never touches the DB

Once viewing and the LLM hot path stop touching Aurora, it stops waking for trivia. That, more than any price knob, moves the bill.

One discipline keeps DynamoDB from quietly becoming a second source of truth: anything stored there should be either TTL-bound, recomputable from Aurora/S3, or an explicit live counter with a reconciliation path. If a value is none of those, it probably wants to be in Aurora.

Sleep-first only works if the app lets Aurora sleep

Aurora Serverless v2 can scale to zero in supported configurations (min_acu = 0), and while paused, compute charge goes to zero (storage still bills). The flag is the easy part; the discipline is not poking it awake.

Bad:  set min=0, but login/health/LLM/viewer all read Aurora -> never sleeps
Good: only login, admin, manifest commit, rollups, audit wake it on purpose

Two silent traps: in this sleep-first setup, RDS Proxy works against you — it keeps database connections around, which prevents pause — and any open user-initiated connection does the same. So sleep-first wants no Proxy, a small pool, short idle timeouts. (None of this is a knock on RDS Proxy in general; it's doing exactly its job, which happens to be the opposite of what you want here.)

The goal isn't to make Aurora cheap by configuration; it's to make the application structurally capable of not needing Aurora most of the time. The min_acu = 0 flag only pays off once the app no longer reaches for the DB on every request.

No NAT: separate "can reach data" from "can reach the internet"

Dropping NAT is usually pitched as savings (it bills per hour and per GB). The better reason is blast radius:

A Lambda that can touch the data cannot go out.
A Lambda that can go out cannot touch the data.

One function with both powers, if compromised, can read and exfiltrate. Split it: a VPC control Lambda reaches RDS but can't egress; a non-VPC egress Lambda calls the external LLM but has no line to the DB. Cheaper and smaller blast radius at once. (Caveat: an /ask flow hands tenant context to the egress function, so minimize the payload, forbid logging it, keep a request_id audit trail.)

The point isn't that non-VPC is magically safe. The egress Lambda still touches the OpenAI key and whatever prompt/context you pass it, so it still deserves a narrow IAM role, a single-purpose secret, no broad Secrets Manager or S3 read permissions, and strict logging rules. The win is narrower and more durable: it cannot both read the database and ship it somewhere.

And the boundary only holds if the network isn't the only thing keeping the egress Lambda away from the DB. Aurora has to be private, its security group must not allow the egress path, and the egress Lambda must have no Data API access or broad Secrets Manager permissions that would quietly recreate a database path through IAM. "Not in the VPC" is necessary, not sufficient.

The part that makes this AI-friendly: declarative schema

This design means making the same placement call constantly: canonical Aurora? DynamoDB cache? S3 artifact? hot path? allowed to wake the DB?

Migration-history schema fights you here — to know what is, you replay what happened (001_create… 006_revert…). Declarative schema flips it: you describe the desired current state and let the tool diff it. Both you and the AI read one artifact that says what should be true now.

It doesn't abolish prod migrations — the loop is declarative -> plan -> reviewed migration -> apply -> drift check. You think in declarative state; you apply via migration. That's what fits AI-assisted work: the AI reasons over a stable description, not a changelog.

You don't have to be an infra specialist up front

This is the claim I most want to make — and hold most loosely.

A sleep-first, no-NAT, projection-driven design used to need someone who lived in AWS networking. The wall wasn't the idea; it was getting VPC routing, IAM boundaries, and serverless wiring all correct. Most of this design, honestly, isn't something I knew up front — it's where I drifted by sparring with Claude Code and Codex against a real dev deployment: "does this Lambda actually have egress?", "what wakes Aurora here?", "where's the tenant boundary?" With IaC describing the whole thing as code, the feedback is a deployed stack you can poke, not a whiteboard argument — and that's what let me reach a shape like this at all.

It costs more than a managed edge platform and burns dev cycles. But infra design became something you validate agilely rather than get right up front from expertise alone.

To be precise about the claim: AI doesn't remove the need for infrastructure expertise. It changes the iteration loop — from "know the answer upfront" to "generate, deploy, inspect, and correct faster." You still need the judgment to know what to inspect; you just acquire it by iterating instead of having to bring all of it to the whiteboard.

The honest caveat: the AI will confidently produce wiring that's "plausible but subtly wrong" — a security group more open than you think, a function you believe is sandboxed but isn't. So the loop must include verification you can eyeball: probe the egress, confirm what wakes the DB, read the plan diff. And be clear-eyed that demoting Aurora is really distributed-systems-ification — you trade fixed cost for consistency, projections, and sync. It's a tradeoff, not a free win.

When this stops being the right call

Aurora awake < ~100h/mo:  min_acu=0 + wake-ahead — keep going
~100–250h/mo:             compare against RDS db.t4g.micro/small
> ~250h/mo:               always-on RDS, or Aurora min_acu=0.5
prod-like / heavy validation: Aurora min_acu=0.5

Judge total cost (ACU + NAT + Proxy + endpoints + DynamoDB + S3 + Lambda + CloudWatch), not Aurora alone. For bursty dev, killing Aurora compute and NAT usually wins; for steady production, often it won't. These aren't universal thresholds — they're decision triggers for my environment, and they move with region, log volume, and DynamoDB/S3 usage.

What I'd actually measure

Numbers beat vibes here. If I were deciding whether this is paying off, these are the signals I'd watch:

Aurora awake hours per month (the headline number)
which endpoints wake Aurora — and whether any are supposed to be DB-free
NAT hourly cost avoided by moving egress out of the VPC
DynamoDB counter / reconciliation lag — how stale the cheap layer gets
p95 login latency right after a cold resume (the resume-tax you're accepting)
count of unexpected DB calls from hot paths (this should trend to zero)

Objections I'd raise myself

"You've rebuilt a distributed system to avoid a DB bill." Sometimes, yes. The boundary I try to hold is: only move work-grade state out of Aurora. If a flow needs cross-store transactions, strict read-after-write semantics everywhere, or complex reconciliation, it probably belongs back in the path. The moment you're reaching for distributed consistency to keep the cheap layer correct, you've moved the boundary too far.
"Stale auth will bite you." The sharp edge. JWT + DynamoDB cache is fine for low-risk reads, but role/budget changes, manifest commits, approvals, and any tenant-data-injecting /ask must consult canonical Aurora. "Fast but stale permissions" is how you ship an authz incident.
"The warmup endpoint is a footgun." A public /warmup doing select 1 leaks almost nothing — but it's a button that wakes Aurora, and a public one can be hammered until sleep-first is meaningless. Behind WAF/rate-limit, single-flight, no-op when recently warm.

A checklist before you try this

If you want to see whether your workload fits, run down these before touching anything:

Is your workload bursty / intermittent (not steady high traffic)?
Can viewer reads be served without touching Aurora (CloudFront/S3/DynamoDB)?
Can LLM calls run outside the VPC, with no DB access?
Can the DynamoDB state be TTL-bound, recomputable, or reconciled?
Can you tolerate resume latency on the paths that do wake Aurora?
Do you have metrics for what wakes Aurora, so you can catch leaks?
Is your schema declarative, so you (and the AI) reason over current state, not history?

If most boxes are unchecked, the boring always-on RDS/Aurora is probably still the right call — and that's fine.

Still figuring out the edges

The shift isn't any one AWS feature. It's that the boundary between "only an infra specialist could safely build this" and "a product engineer can reach it by sparring with an AI against a dev deployment" has moved a lot.

Enterprise gravity toward AWS and Aurora is real and isn't leaving. But it no longer forces the always-on, NAT-heavy, everything-through-the-DB default. Keep Aurora as the vault — strict, singular — let it sleep, and run the workbench at the edge, with explicit events carrying workbench changes back into the control plane. Whether this particular shape survives more validation, I don't know yet. What I'm fairly sure of is that the path to trying designs like it is now something you can iterate into — with AI and IaC, deploying and inspecting — instead of having to know it cold beforehand.

If you've run something like this in production — or watched it fall apart — I'd like to hear where it broke for you.

The Wrapper Got Heavy: Why ChatGPT Clones Are Runtime Problems Now

Takafumi Endo | ROUTE06 — Fri, 26 Jun 2026 03:00:39 +0000

A year ago, "it's just a ChatGPT wrapper" was a dismissal. You'd hear it about a startup and know what it meant: an LLM API call, a little RAG, file upload, a chat box on top. Thin. Replaceable. Probably dead the next time the base model shipped a feature.

I keep coming back to that phrase, because it stopped being true in a way I didn't notice happening. The thing you'd be wrapping is no longer a model with a chat UI. It's a fast, stateful web application with its own agent loop, its own sandbox, its own artifact system. The wrapper didn't get easier to build as the models got better. It got heavier.

The simple interface hides the hard part. A ChatGPT-shaped product is not just an API call with a chat box around it; it's the accumulation of many product and infrastructure decisions that make execution feel safe, stateful, and immediate. The model is the part you can buy. The surrounding runtime is the part people had to design.

What gets me is the timescale. It's been roughly a year, and the question actually worth arguing about has moved out from under us — from "is this just a wrapper?" to "where does the sandbox even run?" The pace is faster than I can comfortably track. And the part I keep finding fun is that it all bends toward the practical, not away from it: every one of these shifts makes the tools more usable, more real, closer to something you'd actually ship. Surprising and, honestly, a good time to be building.

This isn't a "wrappers are over" argument, and it isn't advice. It's me writing down where my thinking has drifted while trying to build these things myself — partly so I can find out where it's wrong. Read it as one person's notes.

What "wrapper" used to mean

The old shape was honestly small. Roughly:

prompt → LLM API → (RAG retrieval) → response
        + file parsing on the side

The whole game was prompt design, a retrieval index, and some glue. You could stand it up in a weekend. The reason "wrapper" was an insult is that the surface area was tiny — the model did the hard part, and you did the part anyone could redo.

The leverage point was the prompt and the context you stuffed into it. I've written before that token spend only becomes an asset when you redesign the work around it. Back then, "the work" was mostly the prompt. There wasn't much else in the box.

Two things that are easy to blur

Before going further, it's worth separating two things, because the rest of this post depends on not mixing them up.

The first is the consumer surface: ChatGPT's Data Analysis, Canvas, and Agent mode; Claude's artifacts and browser agents. These are managed sandboxes the platform owns end to end. You can't bring your own; you can only observe their shape.

The second is the developer engine: Codex's CLI / app-server / SDK, and Claude Code's headless mode and Agent SDK. These expose the agent loop as something you can drive from your own code.

They're the same product family seen from two sides. The lesson you take from each is different:

The consumer products reveal the shape of the architecture — sandboxed analysis, artifact surfaces, browser/terminal agents.
The developer tools reveal the build strategy — don't rebuild the agent loop; drive the existing engine and own the boundary, the policy, and the domain compiler around it.

Keep those two lines in mind. The first half of what follows is about the shape. The second half is about the strategy.

The sandbox is the actual product surface

The clearest way I've found to see the shape is to stop looking at ChatGPT as "a model" and look at it as a set of execution environments, each with a network boundary around it. Strip the marketing and the consumer surface decomposes into tiers:

Surface	What it really is	Network	Closest analogy
Plain chat	inference + retrieval, no shell	n/a	the old "wrapper"
Data analysis	stateful Python/Jupyter-like sandbox on uploaded files	no direct external web/API calls	short-lived compute sandbox
Canvas	code edit + render/preview sandbox	policy-gated (workspace/admin)	preview environment
Agent mode	remote browser + code interpreter + limited terminal + connectors	restricted + confirmations	a managed virtual computer

What strikes me, laid out like this: none of these is only a model feature. Each is a product/runtime feature that depends on model behavior but is mostly a managed sandbox with a deliberate trust boundary — what can run, what it can reach, when a human has to confirm. The design center isn't "a better prompt." It's managed sandbox + network boundary + user confirmation + tool isolation.

And notably, it is not "trust a user-supplied container as your production sandbox." There's no devcontainer.json you hand in and have it boot as your runtime. The isolation is the point, and the isolation is theirs, hand-built per surface. That's the part a thin wrapper can't fake — and the part that's now the bulk of the work.

So the leverage point moved. It used to be the prompt. The model call used to be the product; now it's the commodity-shaped component inside a much heavier runtime.

Runtime choice is really a state-gravity decision

The moment you decide your wrapper needs to run something — execute the code it wrote, render the component, hold work state between turns — you've inherited an infrastructure decision you can't shortcut. And the heart of it isn't "which platform is fastest." It's where the state lives.

It helps to notice that "state" here isn't one thing. An agentic product juggles at least four, with different gravity:

1. conversation state        — turns, plan, tool-call history
2. workspace filesystem state — the repo/files the agent edits
3. artifact / render state    — the live canvas, the preview
4. connector / auth state     — credentials, permissions, approvals

The real design question is which of these lives inside the sandbox, close to the actor, and which gets pushed back to a durable store (a DB, object storage, Git). This is the same state gravity model I keep running into: high-churn work state wants to be close to whatever reads and writes it most; the durable record stays central. (It's telling that Codex exposes SQLite-backed state for agent jobs and exported results via sqlite_home — the workbench is local, the ledger is elsewhere. The pattern keeps reappearing.)

Choosing a platform is choosing that gravity, and none of the options hands it to you for free:

Vercel — Fluid Compute killed the "too short-lived for agents" complaint (300s default, up to 800s, 30-min beta), but it still isn't a stateful repo-workspace sandbox out of the box, so a code-running agent needs extra design on top.
Cloudflare — Durable Objects are great for per-entity conversation state (SQLite-backed, one writer each); less of a fit, alone, as an arbitrary-code sandbox or a cloned repo.
AWS — Fargate gives real per-task isolation. Beyond that you're assembling: the pattern I'd reach for is a session-scoped, disposable VM per agent run — something you build on the primitives rather than buy off the shelf. Maximum control, maximum assembly.
Roll your own — gVisor / Firecracker, your own warm pools and snapshots. The most control, the deepest hole.

Whichever you pick, you spend real days on cold-start latency, warm pools, and the network policy before a single user-visible feature ships. The wrapper used to be the prompt. Now part of the wrapper is a sandbox you have to operate — and the network boundary is not a checkbox. A good concrete example: Codex cloud runs a two-phase model — the setup phase has network access to install dependencies, then the agent phase runs offline by default, and secrets are removed before the agent phase even starts. That separation of setup egress from agent egress, with secrets scoped to setup, is exactly the kind of boundary you end up rebuilding yourself if you roll your own runtime.

Don't rebuild Codex or Claude Code — drive them

Chat-with-a-sandbox is heavy but reachable. The coding agents — Claude Code, Codex — are a different tier, and this is where the build strategy from earlier pays off. The honest move is to stand on the engines that already exist rather than reimplement the loop.

Codex is the clear example because the engine is exposed. codex exec runs the agent non-interactively — single session to completion, events streamed as JSONL via --json, a built-in sandbox (read-only by default, workspace-write when you opt in), approval gating you can set to never for unattended runs. codex app-server runs the same core as a server over stdio / WebSocket / Unix socket, which is how IDEs and SDK clients drive it — the Python SDK, for instance, controls the local app-server over JSON-RPC, while codex exec --json is the simpler non-interactive path. Claude Code has its own headless mode (claude -p) and Agent SDK in the same spirit.

One caveat I'd flag honestly: you can speak the app-server protocol, but treat it as a fast-moving integration surface, not yet a boring, stable production ABI — the docs mark it as primarily for development/debugging, and the WebSocket transport is still hardening. Build on it, but expect it to move.

The lesson I take from this: the agent loop, the tool orchestration, the apply-patch system, the sandbox enforcement — that's a frontier-grade engine, and the leverage is in driving it, not rebuilding it. Trying to hand-roll the equivalent loop is the new version of trying to hand-roll dominators in a static analyzer: technically possible, almost always the wrong place to spend your rigor.

The part worth owning — and how thin the moat really is

So where's the defensible work, if the model is a commodity and the agent loop is borrowed?

Honestly, I'm not sure "defensible" is the right word, and I want to resist making my own work sound safer than it is. Here's the most honest version I have.

The durable idea — more durable, I think, than any tooling that implements it — is an epistemology: typing the facts you hand an agent by how you know them. Is a claim verified (it follows from a model you built, with evidence) or estimated (a pattern guessed it)? What's its provenance? I care about this because an agent handed grounded, labeled facts has to guess less, and a fact that carries its own confidence is worth more than a longer context window.

The tooling I've built around that — an SDK and compiler aimed at Codex and Claude Code, turning messy domain data into typed, sourced facts — is just my current implementation of the idea, not a moat. And I should take my own earlier objection seriously: if platforms absorb the commodity layer, why wouldn't they absorb this too? They might — a generic facts-grounding layer is exactly the kind of thing that gets commoditized next. There's a second pressure cutting the same way: as models get better at deriving global facts unaided, the need for hand-built verified/estimated scaffolding could shrink, not grow.

So I won't claim a moat. The narrower thing I will claim — more defensible for being narrow — is that the facts that matter most are tied to your domain: your invariants, your private data, the specific thing that's dangerous in your system. That's the part a general platform doesn't have and a smarter model can't infer from nothing. Owning the pipeline that produces those facts buys trustworthy agent output now, on your actual problem. Whether that's a lasting edge or a temporary one, I don't know. The honest reason to build it isn't defensibility — it's that it makes the agent's answers true today.

Objections I'd raise myself

"Wrappers are still easy — most apps don't need a sandbox." True, and plenty of good products are still a chat box over an API. My claim only covers the frontier-shaped slice — runs code, renders artifacts, holds work state, feels instant. Outside it, "just wrap it" is still accurate, and I don't want to inflate the rest into something heavier than it is just to dignify the work.
"This is build-vs-buy, nothing new." Partly. What's new is that the buy side moved. You used to buy the model and build the app. Now you also buy the agent engine and the sandbox platform, and the build is the orchestration, the boundary, and the facts pipeline between them.
"Won't the platforms just absorb all of this?" Probably some of it. Managed agent sandboxes will get boring the way managed Postgres did, and a generic facts-grounding layer is a plausible next thing to be commoditized. I don't have a clean rebuttal — only that the specific facts tied to your domain and private data are the slowest part to absorb. That's a thinner claim than "I have a moat," and I'd rather state the thin true one.
"You're building on a borrowed engine and a rented sandbox." Yes, and it makes the strategy less stable than I'd like. The app-server isn't a frozen ABI; the platform sets the gravity, not me. I'm not standing on bedrock — I'm standing on a fast-moving layer and trying to stay close to it. The wager is that staying close beats trying to own the whole stack. It's a wager, not a fortress.

Where this is going

The best developers at OpenAI and Anthropic are improving the consumer product relentlessly, and you can't out-ship them on their own surface — the chat, the sandbox, the artifacts, the latency move every few weeks. Matching that head-on is a losing race.

So the move is two-handed, and I'll admit it isn't a stable one. One hand keeps up: drive codex exec and app-server, Claude Code's headless mode, whichever sandbox platform's gravity fits — ride the improvements instead of fighting them. The other hand grounds the facts your agent runs on. Neither hand is holding bedrock; both sit on layers that move, one rented and one possibly temporary. The wager is only that staying close to the frontier while owning your domain's facts beats the alternatives — not that it's safe.

The phrase aged in an interesting direction. "Just a wrapper" used to mean thin, replaceable, not really engineering. For the frontier-shaped slice, it now means a state-gravity decision and an orchestration layer over a borrowed engine. (For everything else, "just wrap it" is still true, and that's fine.) The model call used to be the product. Now it's the commodity inside the product — and the easy part is the part you no longer build.

That's the pull I keep feeling: stop trying to reproduce the giants, stay close to the layer that keeps moving, and stay honest about how much of the advantage is real versus borrowed.

DEV Community: Takafumi Endo | ROUTE06

AIC: Packages Need an Interface for Coding Agents

The missing package interface

The AIC model

Inject, reference, or materialize

Reference what can remain version-bound

Materialize what discovery requires

One host index, many providers

Harness-specific files are derived surfaces

Sync should be boring

Determinism does not eliminate drift

Generated agent state belongs in Git

Preflight repairs; it doesn't claim ownership

Where this actually works today

Referenced assets require an installed package

AIC does not invent universal discovery

Materialized assets expand the trust boundary

What I expect to survive

What is still draft

Installing OpenTelemetry Won't Close Your AI Agent's Feedback Loop

"It exists," "it emits," and "the agent can use it" are different states

OpenTelemetry's core value

Shared meaning

Shared causality

An agent can read a system without OTel

AI readability depends on where the data appears

Six conditions for agent-usable observability

OTel does not define domain meaning

Do not put internal IDs directly into traceparent

OTel and audit evidence serve different purposes

MCP can become the agent-facing query layer

The coding agent is also a telemetry source

The hard part is often the data boundary, not instrumentation

Cloud telemetry introduces a time gap

The order I would use today

OTel is a common language, not the finished system

Why My Local Coding Agent Could Act but Couldn't Finish

Where my framing was off

Two reasons to go local, and I'd rather not mix them

What I had wrong about Qwen

3B active is a compute number, not a memory number

The sessions

The part it couldn't finish

As for the time

I wanted to blame quantization

Swappability is an investigation virtue, not a production one

Objections I'd raise myself

Where this leaves me

Why Legacy Rewrites Need a Judge, Not a Better Prompt

First I tried just pointing the agent at it

Behavior was never in one place

The comparator may normalize representation. It may not forgive behavior.

One scenario, end to end

Rigor compresses, again

The agent writes the code; the harness decides if it's right

What "complete" has to mean

What I'd defend

Why Athena/Iceberg Tends to Make Code the Spec

The spec has two copies

Why this is mostly discipline

But the engine sets the difficulty

Why I actually care: the guesser downstream

It's the same move I make everywhere else

Objections I'd raise myself

Where this leaves me

The Agent Runtime Got Heavy: Rethinking Sandboxes with Codex App Server

Cloud sandboxes have already come a long way

The hard part isn't "starting a VM"

On the desktop, the user's PC is already a finished runtime

PTY brings interactive local execution into the app

Codex is well suited to embedding in a desktop app

You get Codex's own local sandbox

Even so, embedding Codex isn't simple

Separate the UI process from the execution process

The UX advantages of the desktop shape

The desktop shape has clear weaknesses too

Which should you choose

Wrapping up

Designing Schema Boundaries for AI Agents

The new reality: the agent writes the schema

Do not put internal IDs directly into `traceparent`

`3B active` is a compute number, not a memory number

A `destroy` is the `DROP COLUMN` of infrastructure