DEV Community: Ken Mazaika

Your AI Voice Guide Probably Isn't Doing What You Think (Run the Control Test)

Ken Mazaika — Tue, 20 Oct 2026 20:12:25 +0000

My agent handed me a draft that opened with a scene from my own life:

On October 19, I wrote down one rule for every overnight OpenClaw job I run: "work on this overnight" is a request, not a scheduler.

I never wrote that sentence. There was no October 19 writing session, no notebook, no rule I sat down and recorded. The agent invented it, because my voice guide told it to open on a concrete, countable instance of my own work.

The draft passed the guide.

That's a bug in the file, but it isn't the interesting one. The interesting one is that I had no way to know whether the file was doing anything at all — and I'd been running it for a month.

The month of credit

Twenty-odd rules. A paragraph cap. A seven-question sign-off at the end of every draft. Everything I published went through it, and every time a draft came out better than the last one, I credited the guide.

I never ran the same sample with it and without it. Not once.

Without a control, a guide gets credit for everything: a draft improves and the guide did it, a draft gets worse and the topic was hard. That's not a voice system. It's a mood with a filename.

The control test

Hold everything still, change one thing.

One post: a 663-upvote r/OpenClaw thread, tip three — "work on this overnight doesn't work the way you think."
One brief: a short essay about that post, 150–200 words, no headers.
Three runs: no guide, the full 20-odd-rule guide, a trimmed 8-rule guide.

The Reddit post is the subject. The essay is the sample. Same model, same brief, same day.

The result

Text	Words	Sentences	Mean sentence	sd	Em dashes / 1k
No guide	185	11	16.8	5.4	10.8
Full guide	163	5	32.6	6.2	0.0
Trimmed guide	183	11	16.6	5.2	5.5
My published posts	—	—	15.2	10.3	10.8

The no-guide version is genuinely good. It opens on the lesson, uses two em dashes, runs sentences from eight words to thirty-five, and invents nothing.

The full guide produced five sentences averaging 32.6 words, zero em dashes, and a fabricated opening. It isn't sloppy — it's compliant. The self-specificity rule demanded a concrete personal moment and the no-fabrication rule forbade inventing one. The first rule won, because a concrete first sentence is checkable and "don't invent a memory" isn't.

The trimmed guide lands on my published shape: mean 16.6 against a corpus mean of 15.2.

The honest size of the win

The trimmed guide beat no-guide on two things: it opened on the number instead of the lesson, and it stopped sooner. That's the whole delta — about thirty seconds of a reader's attention.

So the defensible claim is narrower than the one I'd been making:

A voice guide is a filter for AI idioms. It is not a transfer function for your voice.

Mine caught the phrases I hate — the "it's worth noting," the forced triads, the recap conclusion. That's a real job. It just isn't the job I thought I was paying for.

The eight-rule version I kept

What survived is small enough to read in one sitting, which is the point:

Minimal voice guide

The five spine rules

1. Open on the concrete thing. The first sentence names the tool, number, file, or result. No framing,
   no backstory, no "in today's…".
2. One idea per section. If a later passage repeats an earlier beat, cut the later one.
3. Receipt, then verdict. Name the artifact or number, then one line on what it means. A stat never ends
   a paragraph.
4. Operator-active first person. "I ran it, it did X." Not "it returns / it packages."
5. Stop when the lesson is done. No recap, no FAQ, no motivational close.

The three voice rules

6. No AI idioms. No "not X but Y" / "it's not just X, it's Y", no forced triads, no em-dash pileups. An
   em dash only when it replaces a comma or colon and makes the sentence clearer; never as a rhythm tic.
7. One owned opinion, stated plainly. No both-sides mush. One inline caveat max, only where a claim
   needs it.
8. Let sentence length follow the thought. Short punch, then a longer explanation. Don't perform
   burstiness, and don't use rhythm as a substitute for a point.

The never list

Words: leverage · utilize · delve · seamless · robust · holistic · transformative · game-changer ·
revolutionize · unlock · "in today's…" · "it's important to note" · "at the end of the day" · "dive in" ·
"in conclusion".

Moves: "not X but Y" / "it's not just X, it's Y" · forced triads · em-dash pileups · rhetorical-question
filler · recap conclusions.

The three questions

1. Does the first paragraph name the concrete thing?
2. Does every claim have a receipt or an owned opinion?
3. Would I say this out loud to a peer?

Three things got cut, and each one is a lesson:

The paragraph cap. It was unenforceable next to the length target and the rhythm rule — three constraints arguing over the same sentence.
The self-specificity language. It bought the invented opening. "Be concrete" and "don't fabricate" are not compatible instructions unless you say which one wins.
The em-dash ban became a permit. The old file talked me out of punctuation I use in every post I actually like.

Run it on your own guide

The kit is a blank template, one Reddit post, one prompt that writes the essay three ways, and the worked example. Clone it, fill the template with the rules you already use, run the prompt, and read the three essays side by side.

Kit: https://gist.github.com/kenmazaika/c74400587ea6579ab8f20c41e5927394
The guide that failed, in full: https://gist.github.com/kenmazaika/f6c1e5c5f351668fe7d54b9bad692aea

If your guide can't beat the no-guide version, its rules haven't earned their place. Now you know that in about twenty minutes instead of a month.

What I'd tell you if you only read one line

Test the file before you trust the file. A voice guide that has never been run against its own absence is a preference you're calling a system — and the cost is invisible, because it's paid in your cadence.

Originally published at engineering.kenmazaika.com/blog/give-your-agent-your-voice.

My Voice Agent Replied in 8 Seconds. Two Settings, Not the Model.

Ken Mazaika — Wed, 07 Oct 2026 23:18:14 +0000

I run OpenClaw as my main agent harness, with the voice layer on Discord. When I first turned voice on, I said hello and waited about eight seconds for a reply. Eight seconds is long enough to assume it doesn't work.

It works. The delay was two configuration defaults. Neither was the model.

OpenClaw is the open-source agent harness I run my workflow on; the voice layer sits on Discord. The config keys are OpenClaw's, but the cause — turn-taking defaults — is generic.

Two defaults caused most of the delay

A fixed silence wait. captureSilenceGraceMs defaults to 2000 ms. It waits two full seconds after you stop talking before it decides your turn is over. Normal conversation leaves a few hundred milliseconds. Two seconds reads as a pause.

A full-agent round-trip on every turn. The realtime voice model consulted the entire agent before it spoke. I'd say "hello"; OpenClaw would run the whole agent — tools, memory, the lot — and only then would the voice layer talk. That round-trip is the larger half of the delay — the same failure I wrote about from the theory side: the pause lives in the turn-taking, not the LLM.

Both are turn-taking settings, not model quality.

The config

Everything sits under channels.discord.voice in ~/.openclaw/openclaw.json. Before → after:

Setting	Before (default)	After	Why
`captureSilenceGraceMs`	`2000`	`800`	Wait a beat, not two seconds
`realtime.consultPolicy`	`always`	`auto`	Voice layer handles the conversational filler; call the agent only when the turn needs it
`realtime.bargeIn`	(on)	`true`	Pinned — cut it off mid-sentence
`realtime.minBargeInAudioEndMs`	`250`	`0`	Interrupt with no 250ms tail gate
`realtime.instructions`	ends `…conversational. Never open with filler.`	ends `…conversational.`	Lets it use a short backchannel ("one sec") while an agent consult runs
`model` (agent behind voice)	`openai/gpt-5.6-terra`	`deepseek/deepseek-v4-flash`	Cheaper, faster reasoning behind the realtime front end

The one that mattered most was consultPolicy: "auto". The realtime model (gpt-realtime-2.1) is only the voice layer — turn-taking, barge-in, playback. The reasoning comes from the agent, which the realtime model calls as a tool. On "always", every turn called the agent before producing audio. On "auto", the voice layer handles the conversational filler itself and calls the agent only when the turn needs it.

The block, after:

"channels": {
  "discord": {
    "voice": {
      "enabled": true,
      "mode": "agent-proxy",
      "captureSilenceGraceMs": 800,
      "realtime": {
        "provider": "openai",
        "model": "gpt-realtime-2.1",
        "speakerVoice": "cedar",
        "providers": {
          "openai": { "apiKey": "***}" }
        },
        "instructions": "Always speak English unless the user is clearly speaking another language to you. Keep spoken replies short, natural, and conversational.",
        "consultPolicy": "auto",
        "bargeIn": true,
        "minBargeInAudioEndMs": 0
      },
      "model": "deepseek/deepseek-v4-flash"
    }
  }
}

You need an API key for the realtime provider. OpenAI here; Grok if you want to price that side.

Result

The realtime model answers first, then reports what it called. The pause is gone and the back-and-forth is responsive.

Cost

One session, over the drive from home to the office: $3.25, mostly input — the base listening. Roughly thirty cents a minute on the realtime model while you talk.

Known issues

Over Bluetooth, reply audio cuts out in a way music doesn't. The link is less stable than it should be.
Long dictation and quick back-and-forth are different modes. This setup is good at the back-and-forth; for long dictation I use a separate dictation tool.

If voice on your agent feels slow, check the silence grace and whether the voice layer consults the full agent every turn before you blame the model. If you've hit a different turn-taking bottleneck, I'd like to know which one.

AI Wrote a GPU Kernel 18 Faster Than Humans. Now Who Reviews It?

Ken Mazaika — Thu, 16 Jul 2026 03:59:38 +0000

Last week an AI-generated GPU kernel ran 18.71× faster than an optimized PyTorch baseline.

The model—Fable 5—didn't just edge past the human implementation. It lapped it. Claude Opus 4.8 reached 14.4×. GLM-5.2 hit 11.14×. GPT-5.5 managed 4.34×. Fable's kernel was in a different tier entirely.

The exciting read: AI is starting to improve the low-level machinery that makes AI itself cheaper and faster. Specialized performance work that once required rare expertise just got dramatically easier to explore.

The uncomfortable read: what happens when the best implementation is also the one nobody on your team would have written—or can fully explain?

That question is about to land on every engineering team that ships AI-generated code.

The Benchmark Problem

A benchmark shows the kernel ran fast under tested conditions. It doesn't show:

How it behaves across different GPU hardware
How it handles numerical edge cases
What happens under months of production changes
Whether it degrades gracefully when inputs shift

The person who wrote it can't answer these questions either. The AI generated this code through a process that doesn't leave a reviewable chain of reasoning. There's no commit message that says "I chose this approach because X."

So the reviewer's job just got harder—not easier.

The Real Shift

I've been watching this pattern across engineering teams this year. The argument is moving from "can AI generate working code?" to "can our org absorb generated code without breaking quality, morale, or judgment?"

The GPU kernel story makes the tension concrete:

One side says the code ran, it was measured, it won. Stop moving the goalposts.
The other side says somebody still has to know where it can fail and take responsibility when it does.

Both are right.

AI can make implementation cheaper while making proof more expensive. Senior engineers may write less code but spend more time designing adversarial tests, checking assumptions, planning rollbacks, and deciding whether an impressive result is safe enough to ship.

That's not the disappearance of engineering work. It's engineering work moving into review—and raising the stakes of who's qualified to perform it.

The Question Nobody's Answering

If AI does more of the building, how do engineers learn enough to review what it produces?

Senior engineers learned by building systems, making mistakes, debugging failures, and taking the call when something broke. If junior engineers begin as supervisors of generated work, they may learn how to move output through a pipeline without developing the instincts needed to know when that output is wrong.

One comment on a thread about this put it well:

"You can't conduct an orchestra without knowing music."

Companies should not preserve manual coding because suffering builds character. But they do need to identify which parts of implementation create judgment before automating those experiences away. Otherwise, they may create extremely productive junior engineers and discover a few years later that they did not create senior engineers.

I write about engineering management, AI adoption, and what actually changes when tools shift. If this landed, I send a weekly post covering stories like this with the management angle. You can find it here.

Here's What You Can Learn In 10 Minutes That Will Be Useful For The Rest Of Your Programming Career

Ken Mazaika — Wed, 01 Mar 2017 21:26:23 +0000

There is one remarkably simple trick you can learn in only a few minutes that will be useful for the rest of your future as a programmer. And there's a critical reason why this one small trick is so significant that is important to understand

The 10 Tab Rule

In programming, you're going to run into problems, error messages, and situations in which your program isn't doing what you think it should. How you react to these scenarios will be the difference between being an okay programmer and an amazing one.

The “10 Tab Rule” is a simple process that can solve almost every problem you'll encounter as a programmer. What's the rule?

When problems arise, do these 3 things:

Articulate the problem in a well-thought-out search query
Search it using Google (or another popular search engine)
Open each of the top 10 results in new tabs. Read or skim each of the tabs, then return to your code.

This simple routine– which will take roughly 10 to 15 minutes– will help you solve almost all of your problems as a developer. The difference between experienced and inexperienced developers is this: experienced developers immediately acknowledge what they don't know and set out to find the answers, while inexperienced developers often times don't have the knowledge nor the humility to begin looking for answers.

It's a subtle mentality switch, but it's important. Beginners often have the mentality of:

“I don't know, and I feel stupid because of it.”

However, experienced developers have an entirely different mentality…

“I don't know, let's figure this out as quickly as possible.”

And it turns out, with Google, nearly all of the questions you could have about anything are at the touch of your fingertips.

Turning to Google sounds easy in theory, but it's pretty unlikely that going to Google's homepage will answer your question. Instead, a huge part of being a good developer is coming up with a reasonably effective twenty- to fifty-character description of your problem.

20–50 letters isn't a lot of room to communicate the problem. And searches like, “my app doesn't work anymore” might be 26 letters, but won't lead you any closer to a meaningful solution to your problem.

Before you are able to use the internet to solve your problems, you need to fully understand the problem first.

The most important skill that software developers cultivate over time is the ability to solve problems using two specific steps:

First, fully understanding the problem with your code.
Second, looking for the solution to the problem based on your understanding.

It's far too common to look for the solution to a problem before you fully understand it, and doing so will likely be a frustrating process. If you encounter an error message you've never seen before, a quick search for the text of the message can give you a lot of the context around the problem.

When writing complex algorithms and business logic, there is one specific problem that will account for nearly every single error message you'll see.

And this problem plagues both those starting out and people who have been programming for decades.

It is incredibly common to think your computer program is doing one thing when it's actually doing something else.

It's your job as a programmer to make no assumptions about what your program is doing, and use all the tools available to you to verify that each of the many assumptions you have about how your program is working is true.

Thinking that a variable is set to one thing when it's actually something else is very common.
Thinking a certain method returns a certain value when it actually returns a different one is common, too.
Thinking a function does one thing when it does something different altogether is another common one.

They're all variations of the same problem: thinking your code works one way when it works in a different way.

When this happens, it is your job to put on your detective hat and determine exactly which line of code is doing the wrong thing.

In ruby, you can use tools like puts, bye_bug, or pry.

In JavaScript, you can use console.log to get the job done.

Nearly every programming language has tools built into it to allow you to figure out which line of code isn't behaving the way you think it should.

A HUGE part of becoming a software developer is understanding the tools at your disposal for understanding why you are having a problem.

Once you identify the disconnect between what you think the code is doing and what the code is actually doing, fixing the problem is usually pretty straightforward. And the ultimate solution: figuring out the line of code you don't understand, and doing effective searches to research what is actually happening in your code.

As you grow as a developer, the “10 tab rule” will become the “8 tab rule,” and eventually just turn into one or two Google searches that you need to execute to find the solutions to your problems.

But the important lesson to take away is that understanding the problem is usually the hard part.

Once you understand the part of your program that isn't doing what you think it is, finding the solution becomes pretty easy.

Thanks for reading this post! If you liked it, I'd appreciate it if you shared this post on Facebook or Twitter!

FYI: This post originally appeared on the Firehose blog, where I write stories about, learning to code, career advice, and making it happen.