DEV Community: Peter

No pipeline, no oil spills

Peter — Mon, 06 Jul 2026 19:32:54 +0000

At some point in the last decade, shipping a web application started requiring a
build step. Then a second one. Then a config file for the bundler, a config file for
the CSS processor, a config file for the linter that runs before the bundler, and a
CI definition that orchestrates all of them in the right order.

Every one of those steps is a dependency. Every dependency has a version. Every version
will, eventually, break something.

When I started building Smeldr, I made a deliberate choice: no build pipeline. Not
"we will add it later." Not "we use a lightweight one." None. The build tool is
go build. The output is a single binary. That is the whole pipeline.

KISS, taken seriously

Keep It Simple is easy to say. It is harder to actually do when the ecosystem keeps
offering you tools that each solve a real problem. Webpack solves module bundling.
PostCSS solves CSS compatibility. PurgeCSS solves stylesheet size. Each is reasonable
on its own. Together they form a chain where a breaking change in one link stops
deployment.

Simplicity is not about being clever. It is about counting the things that can go
wrong and removing as many as you can. A pipeline with five steps has five places to
fail. A pipeline with zero steps has zero.

The question I kept asking was: does this tool solve a problem I actually have, or a
problem the tool introduced by existing?

No vendor lock-in

Build pipelines accumulate platform-specific config. A Vercel deployment looks
different from a Fly.io deployment. A Netlify function is not a plain HTTP handler.
Before long, the pipeline is not just a build tool, it is an implicit contract with
a specific platform.

A Go binary does not care where it runs. Linux on a VPS, a container on any
orchestrator, a bare metal server in a data center. No platform-specific config.
No adapter layer. The deployment target is: somewhere that can run a process.

That is a decision you can change later without rewriting anything.

Deployment risk

The riskiest moment in any software project is deployment. Something that worked
locally is moving into production. The fewer differences between those two environments,
the lower the risk.

A build pipeline is a set of differences. The bundler version on your laptop versus
CI versus the version from six months ago when the last deployment happened. The
environment variables that PostCSS needs to find its config. The Node version that
the build tooling requires, quietly different from the one in production.

With go build, the binary that runs on your laptop is the binary that runs in
production. There is no transformation step that can introduce a discrepancy. You
test the artifact, you ship the artifact.

A deferred cost

A build pipeline is often justified as a time saver. Configure the bundler once,
and development goes faster.

That framing is mostly correct. The bundler does save time on the specific problems
it was designed to solve. The time it costs shows up later, distributed across every
upgrade cycle, every dependency audit, every CI failure that turns out to be a version
mismatch between the bundler and a plugin.

You are not eliminating the cost. You are deferring it, and adding interest.

The pipeline was supposed to give you time back. For some software it does. For a
lot of software it turns out to borrow that time from your future self instead.

What it costs

There are real trade-offs. No build pipeline means no tree-shaking for JavaScript, no
CSS minification by default, no hot module replacement during development.

The boundary is not "backend versus frontend." smeldr.dev has frontend JavaScript and
still ships without a bundler. The boundary is further out than people assume: it is
the point where you are building a large interactive single-page application whose
JavaScript genuinely benefits from tree-shaking, code splitting, and hot module
replacement. Static assets served over standard HTTP, and CSS served as-is, do not
need any of that.

The honest version: if you are building a JavaScript-heavy single-page application,
you need a bundler and you should have one. The build pipeline exists because it solves
real problems for a specific class of software.

The question is whether your software is in that class, or whether you acquired a
pipeline because that is what software acquires.

go build is the pipeline

Smeldr compiles with go build. The binary embeds templates and static assets via
embed.FS. There is no separate asset pipeline, no manifest, no fingerprinting step.
The binary is self-contained.

This is not a backend-only claim. The project's site, smeldr.dev, runs on Smeldr. It
has interactive frontend features and no build pipeline. Two categories of JavaScript,
neither of which requires a bundler.

The first is a third-party 3D animation: 110k particles, WebGL2, a file too large
and complex to write inline. That one is vendored and served as a static file with
<script src defer>. One HTTP request, no transformation.

The second is everything else: navigation toggle, copy buttons, devlog tag filtering,
a mobile drawer, dark mode with localStorage persistence. These live as plain
JavaScript inside Go templates. They embed into the binary with the same embed.FS
that embeds the HTML. No separate asset pipeline, no manifest. The compiler includes
them the same way it includes everything else.

Two different categories of frontend code. The same answer for both.

Deployment is: copy binary, restart process. Or build a container image in one
Dockerfile stage. Or use fly deploy. The platform does not matter because the binary
makes no assumptions about it.

When a dependency updates, go get and go build tell you immediately if something
broke. There is no intermediate tool to negotiate with. The compiler is the build
system, and it has been maintained by Google since 2009.

The shoulder tension disappears when you do not need most of the pipeline. Not
because pipelines are bad engineering, but because the best tool for the job is often
the one you do not have to configure, maintain, and debug at 2am.

Smeldr is open source, written in Go, no build pipeline required.

The AI era needs typed data, states, and relations. CMSes almost got there first.

Peter — Fri, 26 Jun 2026 11:32:14 +0000

The content management systems of the 2000s and 2010s solved a real problem. They gave
content a shape: defined types, structured fields, lifecycle states. A blog post was
not just a row in a table. It was a thing with a title, a body, a status, a
publication date. It could be in Draft or Published or Archived. You could list all
published posts. You could prevent a draft from being served to readers.

This was good thinking. Typed data and explicit states make software more correct and
more predictable. The CMS world figured that out early.

But CMSes were built for one kind of operator: a human working through a browser. The
API was an afterthought. Relations between content items were baked into the UI or
bolted on as plugins. The whole system assumed a person was making the decisions.

That assumption is changing. I started thinking about this in February, and started
building.

The premise was simple: agents need the same things CMSes were built around, typed
data, explicit states, relations. But through a protocol, not a UI, and with enforcement, not just convention. An agent that talks to a typed content layer knows
what fields exist, knows what state transitions are valid, and gets a typed error when
it tries something illegal. The lifecycle is not in the prompt. It is in the layer.

Here is what that looks like in practice. An agent calls preview_impact before archiving a source document:

tool: preview_impact target_type: source target_id: "src-42" → { "count": 4, "dependents": [...] }

The agent sees that four published posts cite this source before it acts. That is not a prompt instruction. It is a query against the typed relation graph.

State transitions are enforced the same way. Calling publish_post on an Archived item returns a typed error: invalid state transition. The agent does not need to be told this in the prompt. The layer refuses.

Custom state machines, where you define your own lifecycle stages like Draft, Review, Approved, Published, are on the roadmap. The built-in states are the foundation that makes them possible.

I had been building this for a couple of months when Andrej Karpathy posted about his
LLM Wiki. His pattern: instead of running RAG over documents every time, have an agent
build and maintain a persistent wiki of structured, interlinked markdown files that
compounds over time. His framing was: "Obsidian is the IDE. The LLM is the programmer.
The wiki is the codebase."

It was a good confirmation that the need is real. Agents need persistent, structured,
queryable knowledge. Not a raw database. Not a chat history. Something shaped.

But it also showed clearly where markdown stops. There is no enforcement in a markdown
file. There is no state machine. There is no way to say "this decision is Active and
blocks these goals" and have that mean something to the agent beyond text it was told.
Relations are backlinks, great for a human reading a graph view, but not a typed edge
a system can query and act on. And it is local, one developer, one machine.

What if you took those same ideas and built them with enforcement instead of convention?

Typed content means the agent knows what fields exist and what they accept. Explicit
state machines mean invalid transitions are rejected at the protocol level: an agent
cannot publish a draft that has not been through review, because the framework refuses
the transition, not because the prompt told it not to. Typed relations between items
form a persistent edge graph the agent can query: what depends on this item, what
decisions are related to this goal, what jobs produced this output.

The access layer is MCP. The agent calls tools, not endpoints. The tools carry the
shape and the constraints.

A few things this is not. Graphiti (from Zep) is a temporal knowledge graph that extracts entities and relations from conversational episodes using an LLM. Good for agent memory derived from unstructured input, built on Neo4j. LangGraph orchestrates how an agent reasons, not what it operates on. New MCP servers expose APIs, they do not enforce state machines.

The distinction that matters: Graphiti derives structure. Smeldr enforces it. If you need to extract a graph from past conversations, Graphiti is the right tool. If you need a typed, stateful layer that an agent operates through, with transitions that are rejected at the protocol level rather than in a prompt, that is a different problem.

These are complements for most systems, not competitors.

This is where the use cases go beyond content management.

Relations and edges can model "this article cites this source," but also "this decision
blocks this goal" or "this agent job produced this output." The same primitives that
power a content graph can power orchestration, memory, context management. An agent
that starts a session can query the graph for active goals, related constraints, and
decisions that are still live. It works within a structure that was built for it to
reason over, not a structure it has to interpret from prose.

CMSes touched this space and stopped at the browser. Karpathy's wiki takes it further
but stays in flat files. The next step is typed edges with enforced lifecycle, queryable
by agents through a protocol designed for them.

That is what I am building with Smeldr: an open source Go framework where content
types have explicit lifecycle states, relations between items are typed edges in a
persistent graph, and agents interact through MCP tools that enforce the rules rather
than expose raw data.

It started as a content backend. The further I get into it, the more it looks like
something more general: a typed, stateful graph that agents can safely operate a whole
system through.

The CMS people were onto something. Karpathy is onto something. I think the next piece
is putting enforcement and typed relations underneath it.

Smeldr is open source, written in Go, no build pipeline required.

Anthropic described the right way to build MCP servers. Gut feeling confirmed.

Peter — Wed, 17 Jun 2026 09:45:14 +0000

I make a lot of design decisions on gut feeling. Is this the right way to structure MCP tools? Should the transport be remote or local? How much context should an agent get about the fields it's writing to?

You make your best call, ship it, and move on.

About six weeks ago, Anthropic published their recommendations for production-ready MCP servers. I read through it and felt that quiet satisfaction you get when someone else independently arrives at the same place. Every single point mapped to something already in Smeldr.

Here's how:

1. Build remote servers, not local/stdio

Anthropic's recommendation: deploy servers that run remotely. Local stdio-only servers can't reach web, mobile, or cloud-hosted agents.

Smeldr ships with HTTP+SSE transport. The MCP server runs as a standard HTTP server. An agent running anywhere connects over the network with a bearer token.

2. Group tools around intent, not raw endpoints

Anthropic's recommendation: fewer tools focused on what users want to accomplish, not mirrored one-to-one from your API surface.

Smeldr generates tools grouped around content lifecycle intent. For a Story type you get create_story, update_story, publish_story, archive_story, list_stories, get_story.

The agent doesn't need to know about routes, database rows, or state transitions. It calls publish_story and the framework handles the rest: lifecycle validation, 404 enforcement for non-published content, sitemap update.

3. Ship rich tool semantics

Anthropic's recommendation: use MCP's richer features to give agents better context about what tools do and what fields mean.

Smeldr adds semantics at the struct level:

type Story struct {
    smeldr.Node
    Title   string `smeldr:"required,min=3" smeldr_description:"The headline of the story"`
    Excerpt string `smeldr:"required"       smeldr_description:"1-2 sentences used in listing and as meta description"`
    Body    string `smeldr:"required"       smeldr_format:"markdown"`
}

smeldr_description tells the agent what a field is for. smeldr_format tells it what format to use. These are baked into the MCP schema generated from the struct. Every tool call carries this context automatically.

4. Standardised authentication

Anthropic's recommendation: implement standardised auth to avoid unexpected re-authentication and enable fast first-time setup.

Smeldr uses BearerHMAC tokens. Every MCP call is authenticated with a signed bearer token. Token management is available via MCP tools, so an agent with the right role can provision access for other agents.

OAuth 2.0 is live - Claude.ai and ChatGPT connections both verified. For self-hosted deployments, token-based auth gets you running in minutes.

That's the whole list. The problem made these answers obvious. It's always good when the spec agrees.

Originally published on smeldr.dev