If you’re familiar with this series of short essays you already know this but for the new folks tuning in “Vetuu” is the massively multiplayer online roleplaying game (an MMORPG) I've been making at nights and weekends, and I am, for the record, a design engineer. I've spent twenty-five years on the other side of the tech jargon, deciding how a product should talk to a real person. So when I first started building AI native and the agent went full engineer on me, I'd pretnend to myself that I understood what it was saying but in all honesty I was losing the thread, BUT still quietly trusting it’s output anyway.

That last part is the one that should worry you.

The stuff that kept tripping me up was always the same small handful of things:

• File paths quoted like they explained themselves.
• Acronyms it assumed I already knew.
• Its own private shorthand (it had numbered its review rounds and started saying "R3" at me like that meant something).
• Abstract little phrases like "failure mode" and "blast radius" standing in for a plain account of what actually went wrong.

If I can't follow the sentence, I can't catch the lie in it.

None of it is malicious. It's just what falls out of a very capable thing that learned to write mostly from engineers writing for other engineers. But here's the problem, I'm still the one who's supposed to be checking its work and if I can’t read the reciepts then we’re screwed.

How I wanted to be talked to

So I wrote down how I wanted to be spoken to. Not what to say, the manner of saying it. Talk to me like an older brother who's been doing this for years and genuinely wants me to understand what I'm building. Be warm. Be straight. Teach me the thing as we go instead of assuming I've already taken CS. And when I'm about to do something dumb, say so in plain words, not "this may introduce risk."

Underneath all of that sits one test that does most of the heavy lifting for me: would someone who isn't an engineer follow this sentence without already living inside my head? If not, rewrite it. There’s also some smaller rules coming along for the ride… the first time a genuinely technical word has to show up, pair it with a plain definition, and after that we’re cool because I learned the definition in context. Say it once, the way a good teacher would, then trust me with it.

A checker that runs before it speaks

Writing the rule down for the agent didn't make it stick, which in hindsight I should have seen coming. I'd get a lovely plain-spoken paragraph, and then the jargon would quietly creep back. I won't pretend I know exactly why (my honest guess is that most of what these models learn from is written that way to begin with), but the drift was real. The rule was the easy bit. Making it hold was an actual pain in the ass.

So the first thing I built is almost embarrassingly simple. Before the agent sends me anything substantial, it runs its own draft past a plain list of jargon I've flagged before. The list doesn't rewrite a single word for it. It just points at each offender and suggests a plainer one, and then the agent has to do the rewrite itself before the message ever reaches me. No model, no waiting, just a dumb fast check. Its weakness is real though, and I like that about it honestly beacuse it speaks to my love for simplicty. It only knows the words already on the list.

A catcher that learns from us

Which is why the next piece matters more. At the end of every working session, a second script reads our actual conversation back and learns the new jargon, the stuff the first list had never seen. It does it from two tells:

1. The moments I stopped and asked what something meant. When I say "wait, what's a handler?", it catches the word I tripped on, then grabs the agent's very next sentence, the one where it finally explains the thing plainly, and keeps that as the rewrite.
2. The moments the agent corrected itself mid-thought. Any time it writes something like "the dispatcher, meaning the part that decides where each message goes," it's quietly admitting to itself that the first word needed help but also making sure to hand over the plain version in the same breath.

Both of those get folded back onto the list. So this session’s confusion becomes next session’s plain English. It learns my vocabulary by watching where I get lost, and it didn't cost me penny to build.

The scans I don't run myself

Two more scans go hunting for whatever slips past. The first runs on a timer (the kind of scheduled task engineers call a cron job). Once a day, while I'm happily asleep, it reads the last day's committed writing and asks a cheaper, faster model to flag the jargon. It costs me about two dollars a year, which turns out to be a pretty awesome return on investment.

The second only runs when something looks off. If a long session comes back almost perfectly clean, that's suspicious in itself. It usually means the agent used jargon confidently and I just never pushed back. So when I close out a session like that, it quietly ships its own half of the conversation (never mine) off for a harder look, and deletes it again within seconds.

All of it feeds this one shared list, behind one shared set of guardrails, so the pieces can't drift apart and start contradicting each other. Drift is the modern enemy of our time and I keep running into it head first. There's one rule in there that remains foundational: a word as common as "system" or "function" is never allowed onto the list. Put something that ordinary on a blocklist and it would flag nearly every sentence ever written, and the whole thing seizes up.

The two paragraphs at the end

My favourite bit comes right at the end of a session. Whatever we did that day, however far into the weeds it went, the agent has to sign off with exactly two short paragraphs of plain English. The first tells me what I actually have now. Not which files changed, but what exists tonight that didn't this morning, and who it's for. The second tells me how it works and when it'll bite, and it has to land on something concrete and soon, a moment I'll genuinely run into this week.

No file paths. No "I've updated the thing." No step-by-step replay of the day. Just the two paragraphs your buddy drops in Slack on their way out the door. It's the single moment where a whole day of fiddly, dense work gets turned back into something I can take in at eleven at night, which, let's be honest, is usually when I'm reading it.

Why this is design work

This is the part I keep wanting to say to other designers. Almost none of this is really engineering, even though it looks like it from the outside. Deciding how a tool addresses the person using it, what it's allowed to assume they know, which word to reach for when two would do, what a warning should sound like at eleven at night, that is the work I've been doing for twenty-five years with copy and buttons and empty states. The user changed. The craft didn't.

George Orwell wrote a whole essay about this in 1946, well before any of us had an agent to push around. His last rule for plain English was almost exactly the test I ended up giving mine: never reach for a jargon word if an everyday one will do. I just pointed the same idea at a machine and gave it a few scripts to keep it honest.

A couple of honest caveats, because this kind of writing ages like milk. The model I'm running will be called something else by the time you read this. The two-dollar scan will cost something different. The little scripts will rot. None of that is the point. The point is the rule, and the rule is older than all of the machinery I wrapped around it.

So if you're building with these things, that's the one piece of advice I'd actually stand behind. Teach it to talk to you like a person. You'll catch more of what it gets wrong, and you'll dread opening the laptop a little less.