Labs, Gremlins, and Other Bad Ideas That Somehow Work

I name my automations after gremlins. There is a Quartergremlin that scaffolds projects, a PulseGremlin that watches the backlog, and a Blogger Gremlin that drafts and reviews posts. Said out loud in a code review, this sounds like exactly the kind of thing that should be quietly walked back before anyone important hears it.

I expected the names to embarrass me eventually. Instead they survived every serious review I put them through, and the reason they survived turned out to be the whole point.

A cute name usually hides a vague job

The honest objection to naming your software after little monsters is not that it is unprofessional. It is that cute names are where vague responsibilities go to hide. “Ask the assistant” sounds friendly and means nothing. A mascot with a personality and no contract is just an unaccountable process wearing a hat.

I had been burned by this before, not with gremlins, but with the general move of giving a blurry capability a confident label. The label makes you feel like you have designed something. You have not. You have named a fog. The fog still does whatever it wants, only now it has branding.

A name without a contract is not an abstraction. It is a costume on an unaccountable process.

So the test for any of my gremlins was never “is the name fun.” It was “can I say, in four lines, exactly what this thing is allowed to do.”

What I tried: give the joke a contract or kill it

The rule I landed on is that a gremlin earns its name only if it can state a contract with four parts: its inputs, its outputs, the actions it is forbidden from taking, and the condition under which it stops. If it cannot fill all four, it is not a gremlin. It is a vibe with a mascot, and it does not get to ship.

Take the scaffolding one. Its inputs are a project idea and a classification. Its output is a fully wired, documented, validated project container. It is forbidden from touching certain files without human approval. And it stops the moment the container exists and passes its checks. It does not drift into writing product code, because writing product code is not in its contract. The name is friendly. The boundary is not.

What got weird: the bad ideas needed somewhere safe to be bad

Once contracts were the bar, a second problem appeared. Most gremlins start as bad ideas. You do not know in advance whether “have a small workflow watch the backlog and nag me” is useful or annoying. You have to try it, and trying it anywhere important means risking something important.

This is what the labs are for, and it took me a while to see them clearly. A lab is a bounded sandbox with its own container, its own paper trail, and a privacy boundary, deliberately kept separate from the factory that runs everything else. It is the place a bad idea is allowed to be bad. A ridiculous gremlin can be built, run, and quietly abandoned inside a lab without putting a scratch on the machinery that actually matters. The lab is not where good ideas go. It is where unproven ones go to find out which kind they are.

What worked: the three tiers, and a name you have to earn

What emerged was a model with three tiers, and keeping them distinct is what stops the whole thing from collapsing back into fog.

The first tier is functional roles: generic modes like builder, reviewer, or researcher. These are not named entities and not stored as definitions. You just use them. The second tier is factory agents: named, documented roles that operate on the system itself, like the scaffolding or review agents. The third tier is gremlins: named, bounded workflows that run inside the actual work and produce real artefacts, posts, reviews, scaffolded projects. A gremlin can be one agent or a team of them, but it is always a workflow with a contract, never a personality.

The discipline is that a name has to be earned. A functional role does not get a name. A factory agent earns one only after it has proven a stable, repeated job. A gremlin is named at the moment it gets a contract, not before. The playfulness is allowed precisely because the responsibility underneath it is plain.

The reusable part: pair the label with a plain responsibility

If you take one thing from this, take the pairing, not the gremlins. For any agent or automation you are tempted to give a name and a personality, write its four-line contract first: what goes in, what comes out, what it must never do, and when it stops. If you cannot write those four lines, you have not built a component yet. You have named a hope.

And give your bad ideas a lab. Not every automation deserves to touch your real system on day one. A bounded sandbox where a workflow can prove itself or quietly die is worth more than any clever prompt, because it makes being wrong cheap.

The names make people smile, which is fine, because the smile is not load-bearing. The contract is. Pair every playful label with a plain responsibility and you can be as whimsical as you like, right up until the moment the work has to be trusted, at which point the whimsy steps aside and the contract does the talking.