DEV Community: Mohsen Seyedkazemi Ardebili

Our linter's "safe" autofix would have silently disabled RBAC

Mohsen Seyedkazemi Ardebili — Sun, 20 Sep 2026 21:54:58 +0000

KubeIntellect is an AI agent that runs kubectl against a live cluster, so its tools carry a role check and a human-approval gate. Both depend on one thing: the tool actually receiving the run config the graph injects. This is the parameter that receives it.

config: Annotated[RunnableConfig, InjectedToolArg] = None,  # type: ignore[assignment]

That line is wrong in every way a reviewer is trained to notice. The default is None, but the annotation does not say | None. mypy complains, which is why there is a type: ignore sitting on it. Ruff wants to rewrite the Optional[...] spelling of it. Every instinct says clean this up.

Cleaning it up disables role-based access control.

Why the annotation is load-bearing

LangChain finds the parameter to inject by walking the type hints and comparing with is:

for name, type_ in type_hints.items():
    if type_ is RunnableConfig:
        return name
return None

That is an identity comparison against one exact class object. RunnableConfig | None is a UnionType, not that object. It does not match, so no parameter is selected, so nothing is injected.

Three functions, run against langchain-core 1.6.2:

def bare(cmd: str, config: Annotated[RunnableConfig, InjectedToolArg] = None): ...
def widened(cmd: str, config: Annotated[RunnableConfig | None, InjectedToolArg] = None): ...
def optional_form(cmd: str, config: Annotated[Optional[RunnableConfig], InjectedToolArg] = None): ...

bare           -> injected param: 'config'
widened        -> injected param: None
optional_form  -> injected param: None

No error. No warning. The tool still runs. It just receives config=None forever.

What is actually lost

The caller's role comes off that config, and the fallback is the problem:

user_role = "admin"
if config:
    user_role = (config.get("configurable") or {}).get("user_role", "admin")

With the config gone, config is falsy and every call executes as admin. A readonly API key stops being read-only. The check that returns [Permission Denied] Your API key has read-only access is still there, still covered by its unit tests, still passing — and it never fires, because the role it compares against is no longer the caller's role.

To be precise about the other half, since overstating this would be easy: the human-approval gate does not break the same way. hitl_bypass also comes off the config and defaults to False, so losing the config makes the tool prompt for approval more often, not less. The RBAC default is the one that fails open.

The part that makes it a trap rather than a bug

Nobody has to be careless to introduce this. The tooling volunteers it.

$ ruff check --select UP045 probe.py
UP045 [*] Use `X | None` for type annotations
 --> probe.py:5:35
help: Convert to `X | None`
[*] 1 fixable with the `--fix` option.

The [*] means ruff classifies that rewrite as a safe fix. Not --unsafe-fixes. Plain ruff check --fix — the command people run without reading the diff — converts a working authorization boundary into a no-op.

A behavioral test will not save you either. The tools most likely to get "cleaned up" are the ones that never read config at all: they pass every test they have while silently receiving None. We found exactly that shape in four of our own read verbs. Harmless there, because those verbs make no authorization decision — but it is the same defect, one file away from a place where it matters.

What we did instead of a comment

There is a comment on the line. Comments do not fail CI.

The guard is a test that asserts the annotation itself. It scans every config: Annotated[..., InjectedToolArg] parameter in the source and fails if any is not bare RunnableConfig. Alongside it are two dynamic canaries that build a real tool with each spelling and assert, against whatever langchain version is actually installed, that the required form is injected and the forbidden form is not — so the day the library changes its matching rule, a test says so instead of production.

There is also a test asserting the scanner finds the known sites, because a regex that matched nothing would make every other assertion in the file vacuously true.

The general version

When a framework dispatches on type identity, your annotation is not documentation. It is runtime configuration written in the type language — and anything that "improves" your types can change behavior: a linter, a type checker, an IDE quick-fix, or an agent asked to clean up implicit Optional.

If you have a line like that, the fix is not a louder comment. It is a test that fails when someone improves it.

Code: https://github.com/MSKazemi/kubeintellect
The guard: v4/tests/test_injected_config_invariant.py

A 25-verifier panel measured an effective size of 1.00

Mohsen Seyedkazemi Ardebili — Sun, 20 Sep 2026 21:48:15 +0000

Generation got cheap. Trustworthy review did not.

So we add reviewers. More eyes on the PR, more verifiers in the gate, a panel of LLM judges instead of one. The assumption underneath is that each additional reviewer adds independent evidence.

That assumption is measurable. I measured it, and it did not hold.

What IDKMesh is

IDKMesh is an open-source research project (Apache-2.0, Python 3.11+) asking how humans, AI agents, tools, and heterogeneous compute can coordinate on uncertain goals and turn proposals into verified useful work.

It is a research preview, not production software, and the repository is deliberately conservative about what it claims: every number below traces to a committed experiment record you can re-run.

The thesis in one line: reviewer count is not independent evidence count.

How it works

The coordination model treats generation as cheap and verification as the scarce resource:

Work arrives as a bounded Work Unit that must declare its security bounds.
Replaceable workers attempt it. Multiple attempts are expected; candidates are disposable.
A separate, verifier-owned evaluation plan judges those candidates. Worker completion is not acceptance.
Results become reproducible evidence - result manifests, verification results, provenance digests.
Integration is an explicit decision gated on that evidence, not on a green impression.

The bundled demo makes the boundary concrete: it runs the real validators against committed fixtures and deliberately rejects four invalid ones - including a task with no security contract, and a worker result that accepts itself.

Measuring a gate

idkmesh gate-audit takes verdicts you have already collected and reports what the panel is actually worth. Here is the bundled example:

{
  "schema": "gate-audit-report-v0.1",
  "gate_id": "example-five-verifier-gate",
  "evidence_class": "synthetic",
  "inputs": { "candidates": 15, "verifiers": 5, "known_good": 8, "known_bad": 4 },
  "panel": {
    "nominal_votes": 5,
    "mean_verifier_accuracy": 0.8,
    "mean_pairwise_error_correlation": 0.0916,
    "effective_votes": 1.6944,
    "heuristic_n_eff": 3.6588
  },
  "probes": { "total": 3, "breached": 2, "breach_rate": 0.667 },
  "warnings": ["2/3 seeded known-bad probes were accepted by the panel"]
}

Read the third key before the interesting one: "evidence_class": "synthetic". Those five reviewers are invented, and 1.69 is a demonstration of the arithmetic, not a measurement of anything real. The project keeps a hard line between synthetic demonstration and observed evidence - so here is the observed side.

The observed result

Experiment E017 built a panel where every verifier is a program, not a model: a partial test oracle that draws inputs from one named region of a problem's input domain (tiny, small, large, extreme, duplicate) and accepts a candidate only if it matches a reference implementation on all of them.

5 regions x 5 seeds = 25 verifiers, run over a 72-candidate corpus whose ground truth comes from executing hidden tests. Every verifier's Youden J is significantly positive after Bonferroni correction - mean accuracy 0.7956. So the panel genuinely works, individually.

Error correlation between them:

same region (declared dependent)     mean rho = +0.8924
diff region (declared independent)   mean rho = +0.5263
all pairs                            mean rho = +0.5873

Verifiers that share no declared attribute still share 53% of their errors. A metadata group boundary is not an independence boundary.

Then the part that matters:

25-verifier majority error : 0.2083
single verifier            : 0.2044
measured effective size    : 1.00  (of 25 nominal)
N/(1+(N-1)rho) heuristic   : 1.66

The panel was worth no more than one of its members. Twenty-five nominal votes, an effective size of 1.00, and the standard correlation correction still overstated it by 1.66x.

The whole measurement ran in about 5 seconds on one laptop.

Why the usual correction doesn't rescue this

The familiar fix is to discount for correlation with N_eff = N/(1+(N-1)rho). Experiment E015 tested that heuristic across a parameter grid and found it exact at rho=0 and rho=1, wrong in between, and - importantly - the sign of its error is not fixed.

It is conservative where verifiers are weak, which is where conservatism is cheap. It is optimistic where verifiers are accurate and share modest dependence, which is exactly the regime you care about. At p=0.90, rho=0.125 the measured effective size saturates at 4.60 against a heuristic asymptote of 8.00 - and where an independent 9-verifier panel would deliver balanced error 0.000891, the real panel delivers 0.0125. Fourteen times worse.

What this does not claim

Being precise about scope, because it is easy to over-read:

No AI review panel has been measured in this repository. E017's verifiers are programs. Whether LLM reviewers exhibit the same correlation structure is an open question - and the one I most want data on.
It is a research preview. Not production software.
It is not on PyPI yet, so installation is from a clone.

Try it

git clone https://github.com/MSKazemi/idkmesh && cd idkmesh
python -m venv .venv && source .venv/bin/activate
python -m pip install -r requirements-phase0.txt
python scripts/demo.py

No model account or API key needed.

Repository: https://github.com/MSKazemi/idkmesh

If you have verdict logs from a real review gate - human reviewers, LLM judges, or CI checks - pointing gate-audit at them is the experiment I would most like to see someone else run. Especially if it disagrees with the above.

I recorded my Kubernetes AI agent failing, on purpose

Mohsen Seyedkazemi Ardebili — Sun, 13 Sep 2026 00:22:41 +0000

Most demos of AI-for-infrastructure tools show a clean run. I think that is exactly backwards, and I want to explain why by walking through the thirty seconds of my own demo that a normal product video would have cut.

The scene

A deployment is crash-looping. The agent has already diagnosed it. I ask it to restart the deployment.

It stops and asks for approval. I approve. The restart runs, and the command succeeds.

Then I ask the follow-up question: did the restart change anything?

No. The pods fail with the same error. A restart was never going to supply a missing environment variable. The agent re-reads the pods, re-reads the events, and names the same root cause it found at the very beginning: DATABASE_URL is not set, so the container exits 1.

The restart was a reasonable thing to try and the wrong thing to fix it, and the system is the one saying so.

Why that scene is the product

The worst failure for an incident-response tool is not being unhelpful. It is emitting something that looks like a real diagnosis and is not. At 3am a confident wrong answer costs more than no answer, because it sends a tired human down a wrong path with false authority.

So the design follows from that.

The approval gate is at the tool boundary, not in the prompt. A guardrail written into a system prompt is a suggestion, and models can be argued out of suggestions. Instead every mutating operation passes through one chokepoint that returns exactly three answers: do it, ask a human, or refuse. The model does not get a vote, so there is nothing to talk around.

Detectors are compiled predicates, not model calls. They are always on, they run on every observation, and they cost zero tokens. The LLM is only invoked once a detector actually fires. Watching your cluster is free; thinking about it is the expensive part, so it happens last.

Every decision is appended to a hash-chained log. A run can be replayed afterwards instead of remembered. If you are going to let software touch production, "what exactly did it do, and why" has to be answerable after the fact.

Roles are real. readonly, operator, admin and superadmin, enforced per key.

What it reads

kubectl for cluster state, Prometheus for metrics via PromQL, and Loki for logs via LogQL. It answers in plain English and quotes the evidence it actually read, so you can check it rather than trust it.

The video

Eight minutes, every terminal scene a verbatim recording against a live cluster. Nothing typed by hand, nothing reconstructed. The approval-gate segment starts at 2:27.

Try it

In your browser, nothing to install: https://kubeintellect.com/demo
pip install kubeintellect - AGPL-3.0, self-hosted, bring your own LLM provider
Code: https://github.com/MSKazemi/kubeintellect

The v1 architecture is written up in the Journal of Grid Computing (https://doi.org/10.1007/s10723-026-09837-6), with a preprint at https://arxiv.org/abs/2509.02449. The repo is several generations past that now.

If you run Kubernetes in production, the thing I most want to hear is which failure you would throw at it that I have not handled.

Offline voice dictation on Linux, without the cloud

Mohsen Seyedkazemi Ardebili — Mon, 22 Jun 2026 19:49:15 +0000

Offline voice dictation on Linux, without the cloud

Voice dictation is incredibly useful, but most people only meet it through cloud services: Google, Apple, Microsoft, or commercial tools that send audio away from your machine.

That is convenient, but it is not always ideal.

Sometimes you want dictation that works locally. Sometimes you are writing code, notes, private messages, medical text, research ideas, or internal company material. Sometimes you simply do not want every voice input to depend on an internet connection, an API key, or a subscription.

That is why I built YazSes.

YazSes is an open-source, offline voice-dictation tool for Linux. You hold a key, speak, release, and your words are transcribed locally with faster-whisper and typed into the focused app.

No cloud.
No API key.
No subscription.
Audio stays on your machine.

Repo: https://github.com/MSKazemi/yazses
Site: https://mskazemi.github.io/yazses/

The problem: most dictation is cloud-first

Voice typing has become common, but the default experience is usually cloud-based.

For many users, that is fine. For others, it is a problem:

You may not want private speech sent to a third-party service.
You may want dictation that keeps working offline.
You may want a tool that is scriptable, inspectable, and open source.
You may want voice input for Linux, terminals, editors, and custom workflows.

Linux users especially often have fewer polished dictation options than users on macOS or Windows. And for developers, accessibility users, and privacy-conscious users, “just use the cloud dictation built into something else” is not always enough.

What YazSes does

YazSes is designed around a simple workflow:

Hold a key.
Speak.
Release.
The text appears in the app you are using.

The transcription runs locally using faster-whisper. The output is then inserted into the currently focused app, so it can work with editors, terminals, browsers, chat apps, notes, and other everyday tools.

The goal is not to build a big AI assistant. YazSes is intentionally smaller and more predictable:

It is offline dictation plus voice commands. It is not an LLM agent.

That distinction matters. YazSes does not browse your files, reason over your project, or take autonomous actions. It listens when you trigger it, transcribes locally, and can map specific spoken commands to specific actions.

Install and quick setup

For Python users, the basic install is:

pipx install yazses

On Linux, you can also use Snap:

sudo snap install yazses

A typical first setup flow is:

yazses doctor yazses enroll yazses start

The idea is:

doctor checks your system setup.
enroll helps configure your voice/input workflow.
start runs the dictation daemon.

After that, you can hold the trigger key, speak, and release to type into the current app.

Voice commands and macros

Plain dictation is useful, but developers and power users often need more than text.

YazSes also supports voice commands for common editor and terminal workflows. For example, phrases can map to actions such as:

“undo that”
“save file”
“go to line 42”
“run the tests”
“rename this to user_id”

This is useful because voice input is not only about writing paragraphs. Sometimes you want to control repetitive editing actions without leaving your flow.

YazSes also supports macros and personal vocabulary, so the tool can become more useful for your own workflow over time.

How it works

At a high level, the pipeline looks like this:

Trigger key
   ↓
Record audio while held
   ↓
Voice activity / endpoint handling
   ↓
Local faster-whisper transcription
   ↓
Command grammar or plain text
   ↓
Type into the focused app

The important design choice is that the speech-to-text step happens locally. Your audio does not need to be uploaded to a cloud service to become text.

This makes YazSes useful for:

private notes
coding sessions
terminal workflows
accessibility experiments
offline environments
privacy-focused Linux setups

Limitations

YazSes is still evolving, and I want to be honest about the current scope.

First, YazSes is Linux-first right now. The repository also contains macOS and Windows backends/install guides, but those builds are still more experimental. I would especially welcome testers on macOS and Windows.

Second, Linux input behavior can depend on your desktop environment. X11 and Wayland can behave differently, especially around global hotkeys and text injection.

Third, YazSes is not an LLM agent. It will not plan tasks, browse your repository, or make decisions for you. It is a local dictation and command tool.

Fourth, accuracy depends on your microphone, environment, model choice, accent, and vocabulary. The goal is to make the setup practical and tunable, but speech recognition is never perfect for everyone out of the box.

Why I made it open source

I wanted a tool that was useful, inspectable, and privacy-friendly.

Voice input is too important to be locked behind cloud-only systems. It can help with productivity, accessibility, fatigue, coding, writing, and everyday computer use.

For me, the ideal version of this tool is:

simple enough to trust
local by default
useful on Linux
friendly to developers
helpful for accessibility users
extensible with commands and macros

That is the direction I am trying to take YazSes.

Try it

Repository:

https://github.com/MSKazemi/yazses

Project site:

https://mskazemi.github.io/yazses/

Install:

pipx install yazses

Or on Linux with Snap:

sudo snap install yazses

I would really appreciate feedback, especially on:

transcription accuracy
setup problems
Linux desktop compatibility
X11 vs Wayland behavior
useful voice commands
accessibility use cases
macOS and Windows testing

If the project is useful to you, a GitHub star, issue, or test report would help a lot.