Anvil

Cross post

Building Anvil

Anvil did not start as a 'stack'. It still isn't, really, it is three independent projects that have a bunch in common and compliment each other quite nicely, so I decided to bundle them in a monorepo. This also makes it easier to keep the shared pieces in sync, and to make sure the projects are actually useful together.

The Anvil app started as a custom agentic coding harness inspired by T3Code: a practical way to run agents
inside real projects without pretending a chat window was the whole development environment. I wanted something that
could understand a repository, stay attached to a work item, preserve context across a delivery
loop, and help me move from intent to implementation without scattering the important details
across terminals, tabs, issue trackers, and whatever note I had optimistically named
plan-final-2.md.

That first version was deliberately narrow. It was built around the job I needed it to do: help
agents work inside software projects with enough grounding to be useful and enough structure to be
reviewable.

Over time, that narrow tool started pulling in more of the surrounding workflow. Not scope creep for the fun of it,
but because the lines between what counts as workflow, productivity and context all blurred into one, so having one place
where the work is planned, defined, implemented, checked, and reviewed became more useful than a tool that only ran agents.
I also really liked seeing the development of Claude's code review and codex similar features too. Only...they felt a bit lacking?
And in Claude's case, extremely expensive. So I built things like the code review feature which runs customisable rubrics against the codebase,
a PR or a commit, and has a pleasant UI to either post the feedback to the PR or action it.

Code does not happen in isolation. It sits inside tickets, docs, branches, pull requests, design
notes, deployment constraints, production incidents, and the tiny archaeological record of decisions
that live in a repo. If an agent only sees the current prompt, it is under-informed. If a developer
has to manually reconstruct context every time, the tool is not carrying enough weight.

From harness to ADE

The name I keep coming back to is an ADE: an agentic development environment.

That sounds a bit grand, so the useful definition is simpler: Anvil is becoming the place where the
work item, repository, agent session, and development context sit together.

The original harness was about running agents. The ADE shape is about supporting the whole path from
problem to reviewed change:

• understand the work item
• inspect the relevant repository state
• plan the change against real constraints
• make the implementation
• run checks
• review the diff
• capture the reasoning
• connect the output back to the work item system

That loop is useful for developers, obviously. But the target is wider than developers.

A product person should be able to understand what changed and why. A tester should be able to see
the acceptance criteria, the affected area, and the risks worth checking. A technical lead should be
able to review the work without piecing the story together from five separate systems. A support
person should be able to connect a customer issue to the code path that actually changed.

The point is not to make everyone write code. The point is to make the development context less
fragmented.

Repository awareness is the grounding layer

The most important Anvil idea is still repo awareness.

Agentic coding gets much better when the agent can read the project before making claims about it.
That sounds obvious, but a lot of AI tooling still behaves as if a confident answer is roughly
equivalent to an inspected codebase. It is not. Confidence without repo context is just a well-lit
guess.

Anvil treats the repository as the grounding layer. The agent should know the file tree, current
diff, conventions, scripts, tests, docs, and local project rules. It should understand whether a
change belongs in an existing module or whether the new abstraction it is about to invent is solving
a real problem.

That grounding matters because the work item alone is not enough. Tickets are useful, but they are
usually compressed versions of reality. The repo contains the real constraints: the old migration,
the wrapper nobody wants to touch, the half-finished test helper, the auth boundary that has to
remain a real boundary.

Anvil works best when the work item and repository context are held together. The ticket says what
the change is for. The repo says how it can actually fit.

The workspace idea

The workspace concept borrows heavily from VS Code.

That is intentional. VS Code got something very right: a workspace is not just a folder. It is the
local operating context for a piece of work. Files, settings, extensions, terminals, tasks, source
control, and developer habits all gather around that boundary.

Anvil uses a similar idea, but aims it at development context rather than only editing context. A
workspace can hold the repo, linked work items, agent sessions, notes, checks, and eventually more
of the surrounding SDLC state.

That matters because software teams rarely work on "a repo" in the abstract. They work on a
workspace shaped by the current project, product area, branch, issue, environment, and release
target. If Anvil can preserve that shape, agents can do more than answer prompts. They can work
inside the same frame as the people around them.

Then came Anvil Registry

Anvil Registry came from a different but related concern: supply-chain security.

npm install is a lot of trust hidden behind a short command. It can run lifecycle scripts. It can
pull hundreds of packages into a project before anyone has looked at what changed. It can turn a
typo, a compromised maintainer account, a package-confusion mistake, or a suspicious new release
into executable code on a developer machine or CI runner.

That problem exists with or without agents. Most teams already rely on a huge amount of third-party
code, and the install path is one of the places where trust becomes execution very quickly. Anvil
Registry started as a set of countermeasures for that problem: put a deliberate control point in
front of dependency installs, make package decisions inspectable, and avoid treating upstream
registry traffic as harmless just because it is normal.

Anvil Registry puts a controlled gateway between package managers and upstream registries. The
gateway speaks the npm registry shape that existing tools already understand, then applies policy
before tarballs are handed over. In practical terms, it is trying to solve a few connected problems:

• make install traffic inspectable instead of invisible
• cache package metadata and tarballs so decisions are tied to the artefact that was actually seen
• apply deterministic policy before code reaches the project
• queue deeper analysis outside the hot install path
• give humans explainable decisions, reports, and override controls
• provide a safer local path for unknown repositories through the Node Base devcontainer image

The architecture is deliberately boring in the places where boring is a virtue. Package managers
ask Registry for metadata and tarballs. Registry checks policy and package identity, proxies and
caches upstream artefacts, records decisions, and hands work to an analysis worker. The worker can
inspect manifests, package contents, provenance signals, file trees, lifecycle script usage, and
other risk indicators. The CLI and admin surfaces then give people a way to explain a decision,
scan packages, warm caches, review reports, and manage overrides.

The important line is authority. AI-assisted review can help summarize suspicious patterns or point
at things worth checking, but it does not get to be the enforcement layer. Deterministic policy owns
the gate. Humans own the judgement.

That makes Registry useful on its own, even if there is no agent anywhere near the repo. It gives
developers and teams a more inspectable install path, a place to encode policy, and a way to review
exceptions without pretending every dependency decision can live in someone's head.

That project pushed Anvil beyond "how do agents edit code?" into "what infrastructure does agentic
development need around it?"

The agentic angle is a bonus, but it is a real one. Agents can move quickly through unfamiliar
repositories, which means dependency changes can become part of a larger automated edit loop. In
that world, having a checkpoint in front of install traffic matters even more. "The model probably
noticed" is not a security boundary.

It was also the first time I built a substantial project using Codex /goal. That became its
own post because the process mattered: write the spec first, let Codex work against a concrete
target, keep running checks, and keep the human decision-making where it belongs. I wrote more about
that build in Building Anvil Registry With Codex.

Registry is part of the same larger bet as Anvil Desktop: better delivery requires better context.
Sometimes that context is a work item and a diff. Sometimes it is package identity, provenance,
tarball contents, and install policy.

Now Anvil Cloud

Anvil Cloud is the piece I was slowest to describe properly, because it sounds like a hosted-agent
story if you say it too quickly.

It is not that.

The motivation is more specific: agents work best when the world they are editing is small,
explicit, and inspectable. Cloud infrastructure is usually the opposite. A useful app quickly runs
into auth, data, files, jobs, logs, queues, environment variables, deploy state, gateways, IAM, and
provider-specific defaults. Those are awkward enough for humans. They are a very sharp surface for
generated code.

There are a few interesting projects circling this problem from different directions. SST
makes full-stack infrastructure much more approachable by defining app resources in code and keeping
those resources linked to the application. Lakebed pushes toward an
agent-native shape: small TypeScript apps with a CLI/runtime that an agent can create, inspect, and
deploy without wandering through a cloud console.

I found SST to be amazing, but agents constantly trip over nuance as soon as you get to any sort of level of
complexity. Lakebed is a very interesting approach, and I really love the pitch of 'a shitty cloud for shitty apps'.
But I wanted something that could be used for production apps, not just a playground. I wanted a shape that could be used
for real work, but still small enough to be inspectable, testable, and reviewable before it becomes real infrastructure.

Anvil Cloud is my version of that problem space, built around the Cell contract rather than
raw infrastructure.

An Anvil Cell is a small TypeScript app unit. It can contain server handlers, client UI, schema,
endpoints, jobs, workflows, services, mounted agents, and declared capabilities. The important bit is
the boundary: Cell code should use Anvil runtime primitives like ctx.db, ctx.files, ctx.env,
ctx.log, jobs, and workflows. It should not import AWS SDKs, SST, CDK, Terraform, Pulumi, or raw
provider resources just to build a small app.

The platform pieces exist to make that boundary useful:

• Runtime runs the same request contract locally, in tests, and behind deployment adapters.
• Builder emits the server bundle, client bundle, manifest, generated client metadata, and build output.
• Guard checks imports, direct environment access, outbound fetches, and undeclared capabilities before the app turns into provider work.
• Lens and the CLI expose manifests, logs, auth state, database state, workflows, services, and diagnostics in forms humans and agents can inspect.
• Deployment adapters map the Cell's capabilities to provider resources. AWS is the first adapter, but AWS is not the app contract.

Cloud's job is not to "run an agent somewhere". It is to give agents and developers a smaller
application model that can become real infrastructure without making the app author hand-roll the
provider machinery.

Cloud is early alpha. The local runtime, builder, Lens, CLI, auth, workflow, service, agent, and AWS
preview work are moving together, but the important thing is the contract. If a Cell can
be built, checked, inspected, and planned before it touches a provider, the system has a fighting
chance of being useful without becoming a very confident infrastructure accident. This feels like a solved
problem with terraform and SST, but those tools are not designed for agentic development. How many times have
you deployed using terraform only to later find your lambda is missing a permission that is only needed at runtime?
Or your SST app is failing because the agent generated a resource that is not actually supported by the provider?

Where this is going

The direction is clear enough now.

Anvil started as an agentic coding harness because that was the immediate problem. It is becoming an
ADE because the real problem is broader: development with agents needs clear boundaries around the
work, the code, the dependencies, and the runtime.

Anvil Registry added a boundary around dependency ingress.

Anvil Cloud adds a boundary around the apps agents and developers build: the Cell contract, the
runtime, the manifest, the checks, the inspection surface, and the adapter path to real providers.

Together, they point at a more complete environment for building software with agents involved, but
not with judgement outsourced to them. Developers should get deeper repo-aware assistance. Product,
QA, support, and technical leadership should get clearer context. Teams should get a delivery loop
with fewer mystery steps and more things you can inspect before they matter.

The aim is to keep the useful parts of agentic development grounded: tied to the repo, checked
against the work, explicit about risk, and boring enough to review before it reaches production.