DEV Community: Santiago yie

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?