DEV Community: Rabah Laouadi

Why Green Tests Are Not Enough for AI Coding Agents#

Rabah Laouadi — Thu, 22 Oct 2026 06:33:33 +0000

Over the last few months, I’ve been spending more time working with AI coding agents. They are fast, useful, and in many cases they can fix small bugs or implement focused changes much faster than doing everything manually.

But while using them, I kept coming back to the same problem: how do I know that the evidence around the fix is actually meaningful?

It is easy to ask an agent to change some code, run a test, and return a green result. The problem is that a green test only tells me that the final version passed. It does not necessarily tell me whether the test was capable of detecting the original bug.

That difference sounds small, but it matters a lot.

Imagine an AI agent fixes a bug and adds a regression test. The final test run passes, so the change looks good. Now imagine that we take the exact same test and run it against the broken version of the code, and it passes there too.

In that case, the test is green, but it did not really prove the bug was fixed.

That is the kind of problem I wanted to handle more systematically.

The basic idea

The principle is simple:

Broken baseline + regression probe = FAIL

Fixed result + same regression probe = PASS

If the same probe fails on the broken version and passes on the fixed version, the evidence is much stronger.

If it passes on both, then the test may not actually be testing the bug we care about.

This idea became the basis for a small tool I’ve been building called AI Coding Agent Reliability Kit.

It is a Linux-first local workflow for reviewing AI-assisted bug fixes with stronger mechanical evidence.

The goal is not to replace code review, security review, or engineering judgment. The goal is to make the evidence produced around an AI-generated fix easier to inspect and harder to misinterpret.

What I wanted from the workflow

When I started working on this, I did not want another wrapper that simply runs a command and prints success or failure.

I wanted a workflow that would answer several questions around the change.

What was the agent allowed to modify?

Did it stay inside that scope?

Did the final verification command really pass?

Does the regression probe fail on the broken baseline?

Can the result be reproduced in a clean replay?

Can another person review the evidence without having to reconstruct everything manually?

These are basic questions, but once coding agents start making larger or more frequent changes, they become important.

Bounding the change before the agent starts

One of the things the kit does is define the task and the allowed paths before the coding work begins.

This is useful because an agent can sometimes fix the requested problem while also changing unrelated files. The final result may still work, but the change surface becomes larger than necessary.

For a focused bug fix, I usually want a clear boundary.

For example, if a task only needs a change in one source file and one regression test, then a modification to an unrelated README, configuration file, or another package should be visible immediately.

The kit tracks the declared scope and checks whether the final change stayed inside it.

If something changed outside the allowed boundary, that is reported instead of silently accepting the result.

Checking the final result is not enough

A normal workflow often ends after something like this:

pytest tests/test_bug.py

The command exits successfully, so the task is considered done.

That is useful, but for a regression fix I want one more piece of information.

I want to know what happens when the same probe is run against the known broken baseline.

A good regression probe should normally distinguish the two states.

For example:

Broken version: FAIL
Fixed version:  PASS

That is a much stronger signal than:

Broken version: PASS
Fixed version:  PASS

The second result does not necessarily mean the code is wrong. It means the evidence is weak.

That distinction is important.

The workflow should not pretend that a test proves something it does not prove.

Non-discriminating tests

This was one of the main reasons I built the kit.

A test can look perfectly valid and still fail to discriminate between the broken and fixed versions.

For example, imagine a function that is supposed to multiply two numbers but currently adds them.

The broken code might look like this:

def calculate(a, b):
    return a + b

The fix changes it to:

def calculate(a, b):
    return a * b

Now imagine the test only checks this:

def test_calculate_exists():
    assert callable(calculate)

The test is green after the fix, but it was also green before the fix.

It proves that the function exists. It does not prove that the bug was fixed.

This type of result should not be treated the same as a real regression test.

The kit detects this condition and reports the evidence as non-discriminating instead of treating the final green result as sufficient.

Scope violations

Another case I wanted to handle is when the actual code change is correct, but something outside the allowed scope is modified.

This can happen accidentally, or because an automated workflow touches another file during execution.

Suppose the agent is allowed to modify:

src/formatter.py
tests/test_formatter.py

The source fix and test may both be correct, but if the final change also modifies:

README.md

then the workflow should report that separately.

The important point here is that correctness and scope are different things.

A correct source fix does not automatically make an unrelated change acceptable.

The kit keeps those concerns separate so the reviewer can see exactly what happened.

Clean replay

Another feature I wanted was the ability to reproduce a result from a clean state when needed.

Sometimes a change passes because of something left behind in the working environment: generated files, caches, local state, or another uncommitted change.

A clean replay helps answer a simple question:

Can the same result be reproduced without depending on the current working directory state?

Not every task needs a full clean replay, but for changes where reproducibility matters, it gives the reviewer another useful piece of evidence.

Review summaries

One problem with automation is that it can generate too much output.

Raw logs are useful when investigating something, but they are not always the best way to review a change.

The kit produces a structured review summary that makes the main results easier to inspect.

A reviewer can see things such as:

Scope: PASS
Final verification: PASS
Broken baseline probe: FAIL
Fixed probe: PASS
Differential evidence: PASS
Replay: REPRODUCIBLE

If something fails, the summary should show that clearly instead of hiding it behind a successful final command.

The idea is to reduce the amount of reconstruction the reviewer needs to do.

Proof bundles and integrity

The workflow can also export proof material and verify its integrity.

This is useful when the evidence needs to be moved, archived, or reviewed later.

Instead of only saying that a command passed at some point, the workflow can preserve the relevant result records and verify that the expected material has not changed.

This is not meant to turn the tool into a security certification system. It is simply a way to make the evidence around a run more inspectable and reproducible.

What READY_FOR_REVIEW means

One thing I wanted to keep very clear is the meaning of the final status.

When the kit reports:

READY_FOR_REVIEW

it does not mean:

The code is definitely correct.

It does not mean:

The code is secure.

It also does not mean:

This is automatically production-ready.

It means that the configured mechanical evidence gates passed and the result is ready for a human reviewer to inspect.

That distinction is intentional.

I do not think an automated workflow should silently upgrade mechanical evidence into a semantic engineering judgment.

A human reviewer still needs to look at the actual change and decide whether it is correct for the system.

Why this matters more with coding agents

A human developer usually has some context in their head while making a change. They know what they touched, what they were trying to fix, and what assumptions they made.

With an AI coding agent, more of that work can happen automatically and quickly.

That speed is useful, but it also means it becomes easier to accept a result simply because the agent says the task is complete and the final test is green.

The faster the implementation becomes, the more useful it is to make the verification process explicit.

I do not see this as an argument against coding agents. I use them.

The point is that if agents are going to make more changes for us, then the evidence around those changes should become better as well.

Linux-first and local

The first version of the kit is intentionally simple in its environment assumptions.

It is designed for Linux and uses a local workflow with:

Python 3.10+
Git
a local project repository

I wanted the first version to stay focused instead of claiming support for platforms I had not properly validated.

Windows and macOS are not part of the validated V1 environment.

That may change later, but I prefer to be explicit about what has actually been tested.

What the kit is not

This tool does not try to prove that a program is correct.

It does not replace unit tests, integration tests, static analysis, security review, or a good human code review.

It also does not make a weak test strong automatically.

If the regression probe is poorly designed, the workflow can detect some types of weak evidence, such as a probe that passes on both the broken and fixed versions, but it cannot understand every semantic requirement of every project.

What it does is provide a stricter process around the evidence that already exists.

For me, that is the useful part.

The workflow in practice

A typical flow looks roughly like this:

Define the task and allowed paths.
Generate a bounded brief for the coding agent.
Let the agent implement the fix.
Run the declared final verification.
Check the resulting changes against the allowed scope.
Run the same regression probe against the broken baseline.
Reject the evidence if the probe does not distinguish broken from fixed.
Perform a clean replay when required.
Generate a review summary.
Export and verify the proof material if needed.
Hand the result to a human reviewer.

It is intentionally not a fully autonomous approval system.

The last step is still review.

A small example

Suppose the bug is in a slug function.

The broken implementation is:

def slugify(text):
    return text.strip().lower().replace(" ", "")

For this input:

Hello World

the broken result is:

helloworld

The required result is:

hello-world

The fix might be:

def slugify(text):
    return "-".join(text.lower().split())

And the regression probe:

def test_slugify():
    assert slugify("Hello World") == "hello-world"
    assert slugify("Two Words") == "two-words"

Now the useful part is not only that this test passes after the fix.

The stronger evidence is:

Broken baseline: FAIL
Fixed result:    PASS

That tells the reviewer that the probe actually detects the behavior being corrected.

Why I built it

The main reason is that I want to use coding agents more, not less.

But if I am going to delegate more implementation work to them, I want a better boundary between “the agent says it is done” and “there is enough evidence for me to review the result seriously.”

That is the gap this project is trying to cover.

It is still a first version, and I expect the workflow to evolve as I use it on more projects and find more edge cases.

For now, the focus is narrow: bounded changes, stronger regression evidence, reproducibility, and human review.

If that sounds useful for the way you work with coding agents, I published the first version here:

https://sovereign-system.itch.io/ai-coding-agent-reliability-kit

When a Compile-Fail Test Fails for the Wrong Reason

Rabah Laouadi — Wed, 02 Sep 2026 22:45:32 +0000

I found a test recently that was doing exactly what it was supposed to do: it failed to compile.

The problem was that it failed before it reached the thing I thought I was testing.

That was a useful reminder. With compile-fail tests, “the compiler rejected it” is not enough. The reason for the rejection matters.

I had a few cases like this while hardening some small Rust types. The production code was mostly fine. The stale part was the verification around it.

The examples below are simplified, and the type names are intentionally generic.

The compiler never reached the privacy boundary

Imagine a public type with a private field and const-generic bounds:

pub struct BoundedValue<const MIN: u64, const MAX: u64> {
    value: u64,
}

Code outside the defining module should not be able to construct it by writing the field directly. A compile-fail test for that boundary might start like this:

let _ = BoundedValue {
    value: 5,
};

It certainly does not compile.

But in the case I was reviewing, the omitted const parameters caused a type-inference error first. The compiler had rejected the program without actually proving that direct field construction was blocked.

The test looked healthy because it failed. The diagnostic told a different story.

Making the const parameters explicit removed the unrelated ambiguity:

let _ = BoundedValue::<0, 10> {
    value: 5,
};

Now the test can actually reach the privacy boundary.

That is a much better negative test. Not because it fails “more strongly,” but because it fails for the property I meant to check.

Stale syntax can hide the same problem

I ran into another version of this with a named-field byte wrapper.

Simplified:

pub struct ByteBlock<const N: usize> {
    bytes: [u8; N],
}

An old compile-fail case was trying to construct it using tuple-struct syntax:

let _ = ByteBlock([0u8; 32]);

Again, the compiler rejected it.

But that test was not checking field privacy. It was only demonstrating that ByteBlock was not a tuple struct.

The type had changed shape at some point, while the negative test had kept an older idea of the API.

If privacy is the thing I want to verify, the misuse needs to match the real shape of the type:

let _ = ByteBlock::<32> {
    bytes: [0u8; 32],
};

From outside the defining module, that gives the compiler a chance to reject the actual private-field access.

The old test contained a real compiler error. It was just evidence for the wrong claim.

This is easy to miss with `trybuild`

I like trybuild for this kind of testing. A compile-fail case is compiled separately, and the compiler output is compared with the expected .stderr file.

That makes regressions in diagnostics visible, which is useful.

It also means I need to be careful when accepting or updating those snapshots.

If a stale test starts failing for an incidental reason and I simply bless the new .stderr, I can preserve a broken test while making the suite green again.

That is not a problem with trybuild. It is a problem with what I am asking the test to establish.

I used to look at a successful compile-fail suite and move on fairly quickly. Now I read the diagnostic and ask whether it actually reaches the boundary named by the test.

A compile-fail test should make one clear claim

The rule I use now is simple: I want each negative test to have one intended reason to fail.

Before I accept one, I check:

Claim: What exact misuse is this test supposed to reject?
Reachability: Can the compiler reach that boundary without an unrelated error firing first?
Diagnostic: Is the observed error actually about the property I care about?
Currentness: Does the test still match the current API, type shape, imports, and trait surface?

This sounds obvious in hindsight. It becomes less obvious after a test suite has lived through a few rounds of refactoring.

A stale import can fail.

Old constructor syntax can fail.

Missing generic information can fail.

An operation that used to be forbidden may even become valid later.

The word “fail” does not tell me which of those happened.

Runtime failure is a different boundary

One other case was a useful sanity check.

Something like this:

SomeType::new(0).unwrap();

might panic at runtime if new(0) returns an error or None.

But the program itself can still be perfectly valid Rust and compile successfully.

So that is not compile-fail evidence. It belongs to runtime behavior.

Again, obvious once you say it out loud. But mixing compile-time and runtime expectations is surprisingly easy when old tests and old comments have been copied forward for long enough.

The bigger lesson was about verification code

What stuck with me was not the individual Rust errors. It was the fact that verification code can drift while production code keeps moving.

Tests encode assumptions too.

They encode assumptions about type shape, visibility, crate paths, trait surfaces, invariants, and what the API is supposed to forbid.

Those assumptions can go stale.

A missing test is easy to notice. A test that still “works” can be more misleading because it gives you confidence without checking the contract you think it checks.

That applies beyond compile-fail tests. Property tests can model an old semantic rule. Fuzz targets can exercise an obsolete API. Snapshot-based tests can preserve an error that no longer represents the intended boundary.

So I have become a lot more suspicious of verification artifacts during hardening work.

I do not just ask whether the test suite passes anymore.

For negative tests, I also ask:

Why did the compiler say no?

If the answer is not the boundary I meant to protect, the test is not done yet.

A Primitive Should Never Have an Opinion

Rabah Laouadi — Thu, 02 Jul 2026 23:33:53 +0000

I wasn't looking for a bug,I was auditing one of the foundational primitives in my infrastructure. The implementation was compact, the test coverage was solid, and nothing immediately stood out.
Then one small constraint caught my attention. It had nothing to do with Rust's type system or memory safety, The primitive was rejecting a mathematically valid value without violating a single structural invariant,The rejection existed for one reason only:
I had decided the value wasn't meaningful.

The Assumption

For a long time, I believed that low-level infrastructure should protect developers from making questionable modeling decisions. It felt like responsible engineering. If a value looked practically useless, why should a primitive allow it to exist? That assumption naturally led me to introduce another rule not because mathematics required it, not because memory safety depended on it, and not because Rust expected it, but simply because I believed it would prevent misuse. The idea seemed harmless. It survived code reviews, redesigns, and every test I threw at it. At the time, I was convinced I was making the primitive more disciplined. I wasn't.

The Question That Changed Everything

The more I examined the constraint, the less sense it made. It wasn't protecting memory safety, it wasn't preserving mathematical correctness, and it wasn't enforcing any structural invariant. Its only purpose was to police intent. That realization forced me to stop reading the implementation and start examining responsibilities instead. Somewhere along the way, I had quietly crossed an architectural boundary. One question immediately exposed it: Who gave this primitive the authority to decide what is meaningful? The answer was obvious. No one had. I had simply allowed a low-level primitive to take ownership of a decision that belonged entirely to the domain above it.

The Boundary

At first, the distinction felt philosophical. It wasn't. The more I traced responsibilities through the system, the more obvious it became that I had mixed two fundamentally different concerns. Structure is objective; meaning is contextual. One belongs to mathematics, the other belongs to people. A primitive exists to answer one question: Is this value structurally valid? Nothing more. The moment I asked it to answer a second question is this range meaningful? it quietly crossed an architectural boundary. It stopped enforcing structure and started enforcing policy.

The Redesign

One specific range exposed the flaw in my thinking. When I looked at

BoundedU64<0, u64::MAX>

I realized there was nothing structurally or mathematically invalid about it. The restriction existed for one reason only: I had unconsciously attached domain semantics to pure mathematics. The redesign itself was surprisingly small removing the restriction required only a few lines of code—but the architectural shift behind it was far more significant. The primitive didn't become weaker by accepting every structurally valid range; it became more honest about its own responsibility. Instead of trying to predict intent or enforce what I considered good modeling decisions, it returned to doing the one thing it was originally meant to do: guarantee structural integrity and leave every question of meaning to the layers built above it.

What Survived

Looking back, there was never a bug hiding inside the primitive. It behaved exactly as I had designed it to behave. The mistake was mine. I had asked infrastructure to answer a question that belonged entirely to the domain. That audit didn't change the implementation nearly as much as it changed my understanding of architectural responsibility. Since then, one principle has stayed with me whenever I design low-level systems: infrastructure owns structure, while meaning belongs to the domain. The boundary between the two is easy to blur, but once you recognize it, it becomes remarkably difficult to design foundational software any other way.

When a Constructor Became a Security Boundary

Rabah Laouadi — Mon, 22 Jun 2026 22:51:57 +0000

When a Constructor Became a Security Boundary

I was auditing the initialization layer of one of my Rust systems when I noticed something that looked completely harmless.

A constructor accepted an object that wasn't fully valid yet and relied on a later validation step to reject it if something was wrong.

At first, I didn't think much about it. The object would eventually be validated anyway.

Then it hit me.

For a brief moment, an impossible state existed inside the system.

It didn't matter that the state lived for only a few instructions. It didn't matter that validation would eventually reject it.

The invalid state had already been created.

That was the vulnerability.

The audit completely changed how I think about constructors. I no longer see them as functions that merely initialize data.

I now think of them as security boundaries.

A Pattern That Looked Correct

The constructor looked innocent enough.

pub fn try_new(header_length: u32, ...) -> Option {
if header_length < Header::SIZE as u32 {
return None;
}

Some(Self {
    header_length,
    // ...
})

}

At first glance, this seems perfectly reasonable.

Reject obviously malformed inputs and let a later validation step enforce the remaining invariants.

For years, this was implicitly my mental model:

Construct
↓
Validate
↓
Use

Nothing looked broken.

The problem is that this design allows an impossible object to exist, even if only temporarily.

And once an invalid state exists, all bets are off.

The Real Vulnerability

At this point, I stopped looking at the constructor and started looking at the object's lifetime.

The model was effectively this:

Construct
↓
Impossible state exists
↓
Validate later
↓
Use

The object may only live in an invalid state for a few instructions or a few microseconds.

That sounds harmless.

It isn't.

The problem with transient invalid states is not their duration.

The problem is their existence.

The moment an impossible state exists, every assumption built on top of your invariants becomes questionable.

An invalid object can:

leak into another subsystem,
trigger assumptions that later become bugs,
cause panic propagation,
violate invariants,
or create Time-of-Check to Time-of-Use (TOCTOU) style hazards.

None of these failures are guaranteed to happen.

That's what makes them dangerous.

They become architectural landmines waiting for future code to step on them.

I realized I had been treating validation as a repair mechanism.

It shouldn't be.

Validation should be the gate that prevents impossible states from ever entering the system.

A Different Mental Model

I no longer think in terms of:

Construct
↓
Validate
↓
Use

I think in terms of:

Validate
↓
Construct
↓
Use

Or even more simply:

Valid object
or
No object.

There should never be an intermediate state.

The Doctrine

This audit reinforced a principle that now governs my Rust designs:

Invalid states should not be repaired.

Invalid states should not be rejected later.

Invalid states should never exist.

Final Thoughts

I no longer design constructors to initialize data.

I design them to defend invariants.

Because the most dangerous bugs are often not memory corruptions.

They are the impossible states we accidentally allow to exist.

Why I Open-Sourced Only Layer Zero

Rabah Laouadi — Mon, 01 Jun 2026 05:02:57 +0000

Why I Open-Sourced Only Layer Zero

For the past months I’ve been building a deterministic infrastructure foundation in Rust.

Today I decided to publicly expose only the lowest layer of that system:

"sovereign-kernel"

This layer is intentionally minimal and highly constrained.

Its purpose is not “features”.
Its purpose is correctness.

The kernel focuses on:

"no_std"
zero allocation
deterministic serialization
ABI-stable primitives
invariant-enforced types
side-effect free behavior
fuzz-tested binary contracts

Why Layer Zero?

In most systems, instability begins at the foundation.

If primitive types become ambiguous:

serialization breaks
protocols drift
invariants leak
behavior diverges across platforms

So instead of starting from services or APIs,
I started from the lowest deterministic layer possible.

The goal was simple:

«Build primitives that remain predictable years later.»

Fuzzing the Kernel

One of the recent fuzzing sessions exposed a failure in chained XOR behavior inside a binary primitive.

The issue appeared during invariant stress validation.

The failing sequence:

let mut acc_even = h;

for _ in 0..8 {
acc_even = acc_even ^ h;
}

assert!(acc_even.ct_eq(&FixedHash::ZERO));

The fuzz target successfully detected an invariant violation during repeated mutation cycles.

After isolating the issue, the primitive behavior was corrected and the invariant contract stabilized.

This is exactly why fuzzing exists:
not just to crash software,
but to pressure-test assumptions.

Design Constraints

The kernel intentionally avoids:

heap allocation
runtime randomness
hidden state
implicit normalization
unsafe code
platform-dependent behavior

Every primitive is designed as a deterministic value object.

Why Publicly Release This?

Only Layer Zero is public for now.

The higher layers remain isolated until they mature further.

I wanted the public part to be the foundation:
the contracts,
the invariants,
the deterministic core.

Because infrastructure quality starts long before APIs.

GitHub:
https://github.com/Rust-Codes-Hub/kernel_layer_zero

14.8 Billion Fuzz

Rabah Laouadi — Mon, 01 Jun 2026 01:18:12 +0000

How 14.8 Billion Fuzz
Executions Exposed an XOR Invariant Trap in a Rust Kernel Primitive

For the past weeks, I’ve been building and stress-testing a minimal kernel layer for a long-term Rust infrastructure project.

The focus is intentionally narrow:

deterministic primitives
zero-allocation types
stable binary representations
no hidden runtime behavior
strict invariant enforcement

Recently, I ran a long adversarial fuzzing campaign against the kernel primitives.

The campaign crossed roughly 14.8 billion executions.

At first, the interesting part seemed to be the crashes themselves.

But the second crash turned out to be far more interesting than a typical memory bug.

The Crash

The fuzzer eventually stopped on this assertion:

assertion failed: acc_even.ct_eq(&FixedHash::ZERO)

At first glance, this looked like a potential issue in the XOR implementation of the hash primitive.

That would have been serious.

Especially in low-level deterministic infrastructure where algebraic guarantees matter.

The Investigation

The fuzz target contained a chained XOR stress test:

let mut acc_even = h;

for _ in 0..8 {
acc_even = acc_even ^ h;
}

The invariant incorrectly assumed:

«even XOR count ⇒ ZERO»

But there was a subtle mistake.

The accumulator was already initialized with "h".

That means the expression actually evaluated to:

h ^ h ^ h ^ h ^ h ^ h ^ h ^ h ^ h

Not 8 occurrences.

9 occurrences.

And XOR parity rules are strict:

even occurrences ⇒ ZERO
odd occurrences ⇒ ORIGINAL

So the primitive was correct.

The verification logic was wrong.

Why This Matters

This is exactly why long-running fuzzing campaigns are valuable even for “simple” primitives.

The goal is not only to find crashes.

The goal is to validate assumptions.

In low-level systems engineering, incorrect assumptions inside verification layers can become just as dangerous as implementation bugs themselves.

Especially when those primitives are intended to become foundational infrastructure components.

The Fix

The invariant was rewritten to start from ZERO instead:

let mut acc_even = FixedHash::ZERO;

for _ in 0..8 {
acc_even = acc_even ^ h;
}

Now the parity logic is mathematically correct.

Final Thoughts

One thing I’ve learned while building infrastructure software:

Most failures do not come from “complex” code.

They come from small assumptions that quietly survive code review, testing, and intuition.

Fuzzing is one of the few tools brutal enough to challenge those assumptions continuously.

And sometimes, the most valuable bug is the one that proves the primitive was right all along.

Even a Rust Progress Bar Can Become a Reliability Problem

Rabah Laouadi — Wed, 13 May 2026 18:34:12 +0000

While building CommitGuard, I realized something interesting:

even a simple CLI progress percentage can become dangerous under very large workloads.

At first I had the classic calculation:

let percentage =
(current_items * 100) / total_items;

Looks harmless.

And for many projects, it probably is.

But CommitGuard is designed for huge repositories, fuzzing workloads, and long-running scans. That forced me to think more carefully about integer arithmetic and long-term reliability.

The Overflow Problem

The dangerous part is this:

current_items * 100

If "current_items" becomes large enough, multiplication overflows before division even happens.

In Rust:

Debug builds panic.
Release builds wrap around.

That means your progress percentage may silently become incorrect while the program keeps running.

The code compiles perfectly.
But correctness is already gone.

Checked Arithmetic

In low-level and defensive systems, I strongly prefer explicit arithmetic checks.

Something like this:

let scaled =
current_items.checked_mul(100);

match scaled {
Some(value) => {
let percentage =
value / total_items;
}
None => {
// overflow detected
}
}

Why?

Because "checked_*" makes overflow visible instead of hiding it.

For long-term systems, silent corruption is usually worse than explicit failure.

Saturating Arithmetic

Another possible approach is saturating arithmetic:

let percentage =
current_items
.saturating_mul(100)
/ total_items;

This avoids crashes and prevents wraparound behavior.

However, saturation may still produce incorrect logical results once values hit the numeric limit.

So while it is safer than wrapping arithmetic, it is not always mathematically accurate.

Widening Arithmetic

For the progress calculation itself, I ended up widening the arithmetic:

let percentage = if total_items == 0 {
100
} else {
(
(current_items as u128 * 100)
/ total_items as u128
) as usize
};

Using "u128" here makes overflow practically impossible for realistic workloads while keeping the implementation allocation-free and extremely lightweight.

This was a good balance between correctness, simplicity, and hot-path performance.

Why I Avoided Heavy Progress Libraries

While profiling CommitGuard, I noticed many progress implementations rely on:

background threads
shared state
"Arc>"
heap allocations
constant terminal writes

For normal CLI tools, this is usually fine.

But for high-frequency scanning loops, tiny overheads accumulate very quickly.

Especially when progress updates happen millions of times.

So I kept the implementation intentionally simple:

no heap allocations
no background workers
no synchronization overhead
no hidden allocations in the hot path

I also throttle terminal updates to around every 250ms instead of constantly redrawing the screen.

That alone significantly reduces terminal I/O overhead.

Small Math Becomes Systems Engineering

One thing Rust keeps teaching me is this:

there is no such thing as “just simple code” in long-term systems.

A tiny arithmetic assumption can eventually become:

a panic
corrupted state
invalid metrics
undefined behavior
performance degradation

Especially under fuzzing or massive workloads.

The code may compile.
The tests may pass.
But systems programming starts where edge cases begin.
And honestly, that is one of the reasons I enjoy Rust so much.

14.8 Billion Fuzz Layer Zero Kernel

Rabah Laouadi — Sat, 09 May 2026 22:17:26 +0000

What 14.8 Billion Fuzz
Executions Revealed About My Rust Kernel Layer
Over the past few days, I ran a long adversarial fuzzing campaign against the minimal kernel layer of my Rust __infrastructure stack.
The target was intentionally small:

deterministic primitives
zero-allocation design
no_std compatibility
stable binary serialization
overflow-safe arithmetic
invariant-preserving types
The fuzzing campaign executed approximately 14.8 billion iterations.
Focus Areas
The testing focused on validating:
ABI stability
serialization roundtrips
algebraic correctness
normalization logic
overflow behavior
ordering consistency
mutation resistance

Results
The campaign successfully exposed:

2 crash cases
several edge-condition inconsistencies
missing algebraic symmetry in temporal primitives
All issues were discovered before public release.
One particularly interesting result was identifying an incomplete temporal algebra implementation:
"Timestamp + Duration"
"Timestamp - Timestamp"
were implemented, but:
"Timestamp - Duration"
was missing entirely.

The fuzzing process exposed this architectural gap immediately.
Why This Matters
Infrastructure primitives are often treated like simple utility code.
I believe this is a mistake.
Low-level primitives become the foundation for:

distributed systems
ledgers
event sourcing
databases
synchronization layers
audit systems

If the primitive layer is weak, every dependent system inherits that weakness.
Final Thoughts
Fuzzing is not just about finding crashes.
It is one of the best tools for validating architectural assumptions under hostile input conditions.
Especially for foundational systems software.

DEV Community: Rabah Laouadi

Why Green Tests Are Not Enough for AI Coding Agents#

The basic idea

What I wanted from the workflow

Bounding the change before the agent starts

Checking the final result is not enough

Non-discriminating tests

Scope violations

Clean replay

Review summaries

Proof bundles and integrity

What READY_FOR_REVIEW means

Why this matters more with coding agents

Linux-first and local

What the kit is not

The workflow in practice

A small example

Why I built it

When a Compile-Fail Test Fails for the Wrong Reason

The compiler never reached the privacy boundary

Stale syntax can hide the same problem

This is easy to miss with trybuild

A compile-fail test should make one clear claim

Runtime failure is a different boundary

The bigger lesson was about verification code

A Primitive Should Never Have an Opinion

The Assumption

The Question That Changed Everything

The Boundary

The Redesign

What Survived

When a Constructor Became a Security Boundary

When a Constructor Became a Security Boundary

A Pattern That Looked Correct

The Real Vulnerability

A Different Mental Model

The Doctrine

Final Thoughts

Why I Open-Sourced Only Layer Zero

14.8 Billion Fuzz

Even a Rust Progress Bar Can Become a Reliability Problem

14.8 Billion Fuzz Layer Zero Kernel

This is easy to miss with `trybuild`