DEV Community: Santiago yie

Reinventing the Wheel

Santiago yie — Tue, 27 Oct 2026 13:55:52 +0000

For years I was told (and told others) not to reinvent the wheel. Fair enough, up to a point: nobody needs to rediscover that a circle spinning on an axle helps you move. The problem is that the saying assumes that when you build a new tool, you're arguing with that geometry. You almost never are. What you're building isn't the idea of a wheel. It's a wheel for a specific place.

And there was never just one wheel. A train wheel, a bike wheel and a shopping cart wheel all start from the same principle, but they solve very different problems. "Don't reinvent the wheel" hid an assumption: that the standard wheel, the one someone else designed, works for everybody.

For a long time it was good advice, simply because custom work was expensive. It took time, people and money. Software is no different. A tool built for a huge Silicon Valley company rarely understands how a small, local or personal project works. Instead of adapting to you, it makes you adapt to its view of the world.

Buy versus build used to come down to who could afford it. But with AI and open source, building costs a lot less, and the question shifts. It's no longer "does this exist?" but "does it exist for me, for what I do, the way I do it?" Seen that way, reinventing the wheel stops being a waste of time. It's a way to adjust, to learn and, along the way, to say who you are.

For a few reasons, I ended up building from scratch. Less for the result than for what happens along the way: that feeling that something is yours because you put it together. Psychology in the Global North has a name for this: the IKEA effect, our tendency to overvalue things we assemble ourselves.

But explaining the act of building your own tools with the name of a Swedish furniture store falls short. Making things with your own hands has a history everywhere. In the North it runs from the garage inventor to the maker movement, sometimes for fun and sometimes out of need. In the South, it was almost an instinct. Materials were scarce, imported spare parts cost a fortune, and whatever planned obsolescence declared dead still had to keep running. That's where you get Indian jugaad, Cuban technological disobedience, Brazilian gambiarra, or the classic Río de la Plata atado con alambre ("held together with wire"). They all share the same idea: treat the industrial object as raw material. Take it apart, stretch its life and make it work in a reality nobody designed it for.

Taking things apart to understand them

Partly out of curiosity and partly out of that old habit of opening up toys to see what's inside, I started building tools in my free time. Looking back, it fits nicely with what Ivan Illich called "convivial tools". Sounds academic, but the idea is simple: human-scale technology that leaves you in control, adapts to you and lets you learn, instead of locking you into a rigid system. I just wanted a quiet corner where I could be the architect of my own problems.

At first I wasn't trying to sell anything, or even show it. It was for me, to learn, and for the fun of it. I liked the freedom of building software without mastering every language, and seeing an idea working before I'd finished writing it down on paper. Over time they stopped being just mine, and now I'm opening them up as open source projects. What started as a personal whim now wants to grow and be shared.

That's how Adapta was born: a small RAG app for local use that connects to an OpenAI-compatible API endpoint. It's pretty simple. You pick a model and upload your documents. The app splits them into chunks, generates the embeddings and stores them in ChromaDB. It helped me understand the basics: what an embedding is, how semantic search works, and where the LLM fits into all of it. Transformers, to be honest, stayed pretty much a black box.

Then came Docket, a CLI for setting up agents inside a project folder. It started as a bash script, and after a lot of trial and error I moved it to Python. I wanted to understand, in plain terms, what an agent is and how you orchestrate one. For quite a while that path confused me more than it cleared things up. But I ended up with my own system for putting together teams of agents with different roles, and it's easy to adapt.

When building gets too easy

The third project came out of an old frustration. I tried a ton of project management apps, and none of them fit my projects, which aren't just software or websites. I wanted something versatile, and I didn't want to pay for yet another subscription.

So I started building a project management app in Rust Tack, local-only. I was aiming for the level of detail of the big platforms, but with my rules and my vocabulary. And it was surprisingly easy. A few prompts and it was done.

It left me with a weird feeling, like something was missing precisely because it hadn't cost me anything. And that's where the irony showed up. I write code every day; my thing is supposed to be understanding architecture and digging into the guts of systems. But with vibe coding (building working software by describing it in natural language), I found myself doing the same thing as anyone else: iterating, asking the chat to fix errors, and seeing what came out. I started out defending learning from scratch and ended up like someone building their first program. And it's fascinating how, on the surface, the act of creating got leveled out for everyone.

Of course, the magic doesn't last long. Vibe coding gets you started incredibly fast, but then you have to review the code, undo bad architecture decisions and secure the system. That takes a lot of rigor. Making a wheel that spins is easy. Making one that holds up a loaded train for years, without anyone ever thinking about it, is another story. Blindly iterating with the chat can quietly pile up vulnerabilities and structural problems you can't see. That's where craft matters. To build at the speed of imagination, you have to let go of fine control at the start, and make up for it with a ruthless architecture review at the end.

Since getting started cost nothing, I went looking for a bigger problem: what if I connected these boards so an agent could work with them? That's how I ended up with a small ecosystem of tools that talk to each other. They orchestrate specialized agents that read requirements, review code and check progress, without me having to hover over them all the time.

The wheel, again, but networked

Obviously there are already alternatives built by experts, with whole teams behind them and quite a few more zeros in the bank. Technically, I reinvented the wheel several times in a row.

If the privilege used to be being able to pay, now that building is almost free, the privilege has become curiosity, and the time to take apart what we use. But this isn't just a romantic win for open source.

The interesting part is that companies are also moving away from buying the closed package. More and more of them build their own tools and their own agent orchestration, tailored to their business and their rules. They do it for the same reason I did: a generic tool ends up imposing its way of working on you.

Reinventing the wheel isn't an isolated whim anymore. From someone alone in their free time to an entire company, a lot of people are redesigning it for the same reason. There's no single way to work, or to organize a project, or to do business, just as there was never a single wheel. Every team, every trade and every place has its own rhythms, its own vocabulary and its own ways of solving things. For a long time, tools asked us to leave all that at the door so we'd fit a standard. Now that building costs less, we have a chance to do the opposite: let the tool adapt to that diversity instead of erasing it.

A small confession, since it fits the theme: I wrote this in Spanish and used AI to help translate and polish it. A piece about building your own tools, assembled partly with someone else's. Sit with that.

Is Drupal Still a CMS? Its New Role in the Agentic Stack

Santiago yie — Wed, 19 Aug 2026 22:15:40 +0000

For most of its history, Drupal has been easy to describe: a CMS, or for developers, a content management framework.

That is still true. But in 2026, it is becoming incomplete.

Through projects such as AI Search, AI Agents, Tool API, and MCP Server, Drupal can now participate in RAG pipelines, expose application capabilities as tools, and allow external AI agents to interact with a site.

What makes this interesting is not that Drupal suddenly "has AI."

It is that much of the architecture agents need was already there.

Drupal already had the hard part

A mature Drupal application already knows how to represent structured entities, relationships, permissions, revisions, workflows, configuration, APIs, and services.

Drupal doesn't just store documents. It stores structured domain knowledge together with rules governing what can be done with it.

In the emerging agentic stack, that maps surprisingly well to three concepts: context, skills, and tools.

Drupal content can become context. AI Search can retrieve relevant entities through semantic search and feed them into RAG pipelines.

Drupal capabilities can become tools. Tool API can expose operations such as:

search_content(query)
create_article(data)
publish_content(entity_id)
create_taxonomy_term(vocabulary, name)

And higher-level combinations of tools, instructions, and domain rules can become something closer to skills: reusable capabilities for operating a particular Drupal application.

But there is another piece: the harness.

Drupal doesn't have to be the agent

This distinction matters.

An agent is more than an LLM with access to some tools.

The harness is the runtime around the model: the system that decides what context to provide, which tools are available, how many steps the agent can take, how failures are handled, when human approval is required, and when execution should stop.

That harness might live in an external coding agent, an automation platform, or a custom agent built with something like LangGraph.

Drupal can sit underneath it:

             Agent Harness
                  │
       ┌──────────┼──────────┐
       ↓          ↓          ↓
    Context     Skills      Tools
       │          │          │
       └──────────┼──────────┘
                  ↓
                 MCP
                  ↓
                Drupal
          ┌───────┼────────┐
          ↓       ↓        ↓
       Content  Actions  Permissions

This is where Drupal's role becomes more interesting.

Drupal does not need to replace the agent framework.

It can become the governed environment the agent operates against.

From CMS to context engine

Drupal's AI Search project integrates embeddings and vector search with Search API.

A Drupal site can therefore expose its structured content as semantic context:

Drupal entities
      ↓
Search API
      ↓
chunking + embeddings
      ↓
vector database
      ↓
semantic retrieval
      ↓
agent context

For organizations whose authoritative information already lives in Drupal, this removes an awkward duplication.

Instead of maintaining Drupal as the CMS and building an entirely separate knowledge system for AI, Drupal itself can participate in the retrieval architecture.

From APIs to agent skills

The other direction is action.

Tool API allows Drupal operations to be represented as structured capabilities. MCP Server can then expose those capabilities to external MCP-compatible agents.

An external agent could discover that a Drupal application provides tools for searching content, managing taxonomy, creating drafts, or triggering workflows.

The harness decides when to use them.

Drupal decides whether the operation is allowed.

That separation is important.

Giving an LLM unrestricted database access is easy. Giving an agent a small set of explicit, permission-aware capabilities is much safer.

And this is where some of Drupal's old complexity suddenly becomes valuable.

Entities, permissions, revisions, moderation, workflows, plugins, and configuration were originally designed to control what humans could do.

Now the same architecture can help control what agents can do.

So, what is Drupal now?

Drupal is still a CMS.

It is not suddenly a replacement for LangGraph, an agent runtime, or a general-purpose Agent SDK.

A more useful description is that Drupal is becoming a possible application and governance layer in the agentic stack:

Drupal entities     → context
AI Search           → retrieval
Tool API            → tools
Domain workflows    → skills
Permissions         → governance
MCP                 → interoperability
External runtime    → harness

That distinction matters.

Humans see pages, fields, forms, and workflows.

Applications see APIs.

LLMs see context.

Agents see tools and skills.

The harness sees an environment it can operate.

Drupal spent more than two decades building systems for structured knowledge, permissions, workflows, and controlled operations. AI agents now need many of those same things.

So perhaps the interesting question is no longer:

"Is Drupal still a CMS?"

It is:

"Could a CMS become the governed application layer behind AI agents?"

Drupal is starting to make a surprisingly strong case that it can.

I rewrote my AI-agent tool from Bash to Python. That was the easy doubt.

Santiago yie — Thu, 16 Jul 2026 18:27:14 +0000

There are, conservatively, nine thousand tools for running AI agents across your projects. This is number nine thousand and one. I know. Stay a second anyway.

Eighteen years of backend work, most of it PHP, most of it through agencies — which is a polite way of saying I've spent my career as a line item in someone else's staffing spreadsheet. Several projects at once, different clients, different timezones, "resource" being the official word for what I am on a good invoicing day. So when AI agents got good enough to do real work, I didn't wonder whether one could write code. I wondered how I'd wrangle a whole fleet of them across projects — which, I eventually noticed, is me trying to become the manager of a little spreadsheet of resources, after eighteen years of being one. The snake found its tail. I built it anyway.

Docket, then: a control plane for running OpenClaw agents across projects, made with heavy AI assistance on purpose — the point was to close my own gaps, not to prove I could type from memory. It started as a Bash CLI; it's now a tested Python package. On GitHub, beta, link at the bottom. This is me thinking out loud in public, not selling you anything.

And somewhere in that rewrite, the doubt everyone expected me to have — is Bash the right language? — died, and a worse one took its place. That worse one is what this piece is actually about. Let me get there honestly.

What I aimed for, not what I mastered

I want to say this before the vocabulary makes me sound like I know more than I do. I did not sit down understanding context isolation, or git worktrees per agent, or anti-corruption layers. I sat down wanting clean, stable, maintainable, tested code — and I steered an AI toward that shape until it held together.

The shape is real. My grip on every part of it is not the same.

What the shape does, plainly: OpenClaw is a local-first agent daemon, great at running one agent. Run a fleet and you hit problems it doesn't solve. Docket runs pods — a Lead that owns context and talks to me but never touches code, an Implementer that does, optionally a Reviewer and Tester. Each project is walled off from the others. Each agent has a hard spend cap that pauses it when the money runs out. Nothing risky happens without an approval gate.

That's the honest brochure. It reads like a product. Hold onto that feeling.

Doubt 1: is a control plane the right thing for one person?

I answered the Bash question by leaving Bash — no types, error handling by discipline, testing as a craft. Python gave me a safety net Bash structurally can't.

But what I built is Kubernetes-shaped thinking for a fleet of mostly-me. The people who build this shape are solving real multi-tenant problems. I'm one guy with a handful of projects; I could probably survive on a shell script and some discipline.

So did the problem need a control plane, or is building a control plane just how you learn control planes? I keep reaching for the flattering answer. I've stopped trusting myself when I do.

Doubt 2: is there a use case, when first-party tools are this good?

If Claude Code, Codex, and Antigravity all ship great orchestration, who needs mine? Nobody who lives inside one vendor. Each is a walled garden — Codex to GPT, Claude Code to Claude, Antigravity to Gemini. None will happily run a mixed fleet where the Tester is on a cheap model, the Implementer on Sonnet, and the Lead on a free tier, under one budget and one policy.

That's the niche. Whether anyone's standing in it is another matter. The story only gets compelling for a team with governance and audit needs — the exact kind of org I'm not, shipping alone. "A real use case" and "a use case with real people in it" turn out to be different claims.

Doubt 3: the tests I trust and the tests I can't write

The deterministic half is genuinely covered — config, isolation, cost math, gate logic, pinned against the old Bash behavior so the rewrite couldn't quietly change meaning. Coming from PHPUnit, that part was easy.

The other half: the thing dispatches LLM-driven agents, and LLMs don't return the same answer twice. A unit test works because f(2) is always 4. A Lead → Implementer → Reviewer → Tester run has no such guarantee. Testing that properly — eval harnesses, judge models, regression across the whole pipeline — is a second project the size of the first, and I haven't built it.

The tested half is the half I know how to be proud of. The untested half is the half that decides whether the thing actually works.

Doubt 4: should this be public at all?

Against: chasing a fast-moving daemon is brutal maintenance, I'm adjacent to three of the best-funded eng orgs alive, and a repo with one contributor is a diary with a license file.

For: nothing forced me to understand a feature like having to defend it in public and write down where it isn't true yet.

So it stays open — not because I'm sure, but because the reasons for it are ones I believe on good days, and the reasons against are ones I believe at 2am. I ship on the good-day logic and try not to check the star count.

The doubt the other four stand on

I built this with heavy AI assistance, on purpose. So some fraction of what I call understanding is really me having supervised a machine that already understood — well enough to review it, argue with it, throw out the wrong versions. That's not nothing; reviewing well might be the skill now. But it isn't the same weight as the PHP that lives in my hands, and I can't always find the line.

I'm writing this with the same kind of help. Somewhere in here is a sentence I'd have phrased worse alone, and I've lost the ability to point at it. An essay about not knowing what I learned, co-written with the thing I learned it from. Sit with that. I'm trying to.

Would I bet my career on Docket becoming the standard? No. Would I build it again? Yes — mostly because I still don't know what I learned, and the only way I can think to find out is to build the next one with less help, and see what falls over.

So here's the door. If you run OpenClaw fleets and this problem is already yours — the mixed-vendor mess, the budget that quietly runs away from you — come look, and come break it. I'd rather hear where it falls over from you than find out alone at 2am. The repo's below.

Docket is open source (Apache 2.0, beta) at github.com/yielab/docket. Independent project, not affiliated with OpenClaw or the OpenClaw Foundation.

The AI Agent Solved Drupal's Easy Problem. Nobody Asked About the Hard One.

Santiago yie — Tue, 14 Jul 2026 13:50:48 +0000

Drupal now has an AI agent that builds your site by chat. Type a sentence, it wires up a field, spins up a content type, configures a view. Stuff that used to eat an entire afternoon of clicking through admin screens now happens in a chat bubble.

Very slick. Very "the future is here."

It also requires PHP 8.1.

The version number is the whole story

That requirement is Drupal's extremely polite way of saying: this feature is not for you, specifically, if the institution you work with is still running software from the Obama administration. Drupal 7 shipped in 2011. PHP 8.1 didn't show up for another decade. If you've spent any time around government, nonprofit, or higher-ed Drupal installs, you already know exactly which sites that excludes — and it's not a small number.

So there's an immediate, practical split: newer Drupal 10/11 sites on modern PHP get a genuinely useful productivity tool. Everyone still running Drupal 7 or an early 8, which in my experience is a lot of institutions, gets nothing from this except one more reason the upgrade gap keeps widening.

What the agent is actually good at

Here's the part worth sitting with, though. The agent is genuinely good at the part of Drupal work that was always the boring part — field wiring, content type scaffolding, boilerplate views. That's real. I'm not being sarcastic about the "slick" part.

Which leaves the developer doing migration work holding exactly the part that was never really teachable: the instinct for which piece of a fifteen-year-old install is load-bearing, and which is scar tissue nobody removed. That instinct comes from having broken things on production sites, or from having read someone else's undocumented hook_update_N() at 2am and had to reverse-engineer why it exists.

Either that's the most secure seat in the room right now — the work an agent can't touch yet — or it's the last seat left before the room empties out entirely. Hard to tell which, from inside it.

The decision that got harder, not easier

Meanwhile the institutions I work with aren't just choosing between Drupal versions anymore, which is its own quiet shift. Migrate to 10 or 11, sure. But also: stay in the Drupal family at all, or take the "rip it out" option and leave for WordPress, or go static, or hand the whole thing to a headless setup an AI agent can plausibly assemble.

And underneath that, a second question nobody used to ask out loud: pay the traditional agency's markup, or hire a handful of contractors directly and coordinate it yourself, now that an AI assistant can plausibly do the project-management glue work an agency used to justify its cut with.

More options, more tools, more paths that technically work. And somehow the actual decision is harder to make than when there was just one obvious next version to upgrade to.

Dries Buytaert — Drupal's founder — ran an experiment recently asking an AI coding agent to recommend a CMS stack for a typical institutional project. Drupal's structured content model and explicit APIs should be exactly what an agent wants. But the agent flagged something it called "session-time risk" — too much friction in the first hour of getting a working, verifiable site up. Capability wasn't the blocker. The first-session experience was. That's a strange new axis to be judged on, and it's not one any of us were optimizing for a few years ago.

I don't know if that's a Drupal problem specifically, or just what "too much change, arriving all at once" does to any institution — regardless of which CMS, or which staffing model, happens to be running underneath it.

Curious whether other people doing long-running CMS/migration work — Drupal, WordPress, whatever — are seeing the same shift: not "will AI replace X," but "the menu of options got long enough that choosing well is now the hard part." What does that look like from inside a WordPress shop, or an agency that isn't CMS-specific at all?

My roommate partied all night in Rio. I ended up building local-first JS on the stairs.

Santiago yie — Tue, 30 Jun 2026 19:10:40 +0000

2012, Rio de Janeiro, Carnival week. I was playing digital nomad before that was a phrase anyone used — staying in a rented room, splitting it with a roommate who was still asleep at noon because the whole night had been spent out celebrating. Couldn't work inside without waking him up, so I took the laptop out to the staircase of the building instead. Client was in Bogotá: an equipment rental company whose reps needed to build quotes on the spot at venues with no WiFi. So the catalog, the pricing logic, the whole quote state lived in the browser — no server round-trip per calculation, just local storage doing the persistence. Local-first before "local-first" was a name anyone used for it. App itself was hosted on Heroku for whenever a connection did show up.

Samba through the wall the whole time. Carnival two blocks away. I tested it with my own WiFi off to make sure it actually held up with zero connection, then sent the client setup instructions for their reps and called it done.

Looking back, I'm not sure how much of that was a real engineering challenge and how much was just the tools of the time being clunky for something that's almost trivial now — local-first patterns are basically a checkbox in a lot of frameworks today, and I genuinely don't know if an agent would've had this solved in twenty minutes flat. Maybe the staircase was the hard part, not the code.

Anyone else have a "the deadline did not care what was happening outside" story?