I’ll never forget that feeling—ingesting millions of metrics into a tool like Grafana or Honeycomb for the first time. Before that, I was blind. I was guessing. But suddenly, you build a dashboard, you correlate a spike, and the system reveals its soul to you.

It’s a profound shift in cognition. Those dashboards weren’t just charts; they were tools for getting answers. They changed the way I was able to think about the system. That “sight” is why observability matters, but it also made me realize how blind we still are when we’re actually writing the code.

Q: If observability gives us sight into the running system, why does development still feel like we’re back in the dark?

A: Because our IDEs are static. They are “read-only” in how they present information. This is where the idea of Moldable Development comes in. It’s the philosophy that the environment should adapt to the unique problem you’re solving.

If a standard debugger doesn’t explain your specific data structure, you shouldn’t just stare at text—you should write a tool that shows it to you. You “mold” the editor to fit the project. Even the folks at Oxide have discussed this—how writing your own custom debuggers can be more valuable when they lead development rather than just following it. It’s about building the “sight” into the process itself.

Q: People usually point to Glamorous Toolkit (GToolkit) when talking about this. Why aren’t we all using that?

A: GToolkit is a masterpiece, but it’s built in a cathedral most of us don’t visit: Pharo Smalltalk. It comes with 1,500 custom tools, which is incredible, but the friction is immense. You have to learn a language that feels “alien” to modern web devs, and LLMs—our primary coding partners now—struggle to help you write it. It’s a powerful island, but it’s isolated. You can’t easily bring that magic into your daily TypeScript or Go workflow.

Q: So how do we bring that “magic” to the tools we actually use?

A: You look at Swamp.

It is a stepping stone and result of the AI-Driven Development Lifecycle (AI-DLC). Swamp takes those core principles of moldable development—capturing state, modeling it, and creating custom views—but it does it where we live agentic cli like claude.

Q: How is Swamp different from just writing another CLI tool or a script?

A: It feels like an extension of your own nervous system. In GToolkit, you mold the IDE; in Swamp, you use the LLM to mold models that act as live extensions of your system.

Imagine you need to understand a messy API or a deep directory structure. Instead of writing a one-off script, you ask Swamp to model it. It builds a model, saves the state, and suddenly you can ask questions about that state. “Which services depend on this specific config?” or “Show me the blast radius if I delete this.”

It’s not just “Infrastructure as Code” (IaC). Traditional IaC is too rigid—it’s a set of frozen instructions. Swamp is a living cycle. You model, you ask, and then you create workflows to change the system based on those answers.

Q: Is this the end of traditional DevOps tools?

A: It makes them look like fossils. When you can model any API or shell output at the tip of your fingers and treat it as a first-class domain object, the old way of “writing YAML and praying” feels like the dark ages. It’s that same feeling of “sudden sight” I had with those first Grafana dashboards, but now I’m not just watching—I’m molding the world in real-time. It works like magic.