DEV Community: Ayoub Hammoudi

257 clones in two days. 1 star. 0 issues.

Ayoub Hammoudi — Thu, 05 Nov 2026 20:33:32 +0000

257 clones in two days.

1 star. 0 issues. Not a single "hello".

We've all been on the other side of that silence. You find a tool, clone it, try it late at night. It almost works. You close the tab, because asking feels like bothering a stranger.

So I'm not reading those numbers as a win yet. I'm reading them as 66 people standing at a door that looked closed.

Here it is, wide open:

Half-formed idea, "is this a stupid question?" Discussions. It isn't.
Found a bug? A two-minute issue template.
Want to send code? CI, CodeQL and security checks run on every PR. Strict on purpose: when it's green, you can be bold.

One rule, and it applies to me first: a change to the routing comes with a measurement. Opinions don't change the table. Not even mine.

To the 66: thank you for trying it. Now tell me where it broke.

github.com/spar-x-fr/spar-x-skills

"Mandatory user verification" on DEV is a scam. Here's how to spot it in 30 seconds.

Ayoub Hammoudi — Wed, 04 Nov 2026 19:09:50 +0000

If you got tagged by "Support Bot" on DEV, don't click.

It took one look at the profile:

The name isn't "Support". It's Cyrillic letters dressed as Latin ones: "Suрроrt Воt".
The account was created on Nov 4: 0 posts, 41 comments when I looked.
It tags 10 people per comment, in alphabetical order, ten at a time. Nobody at DEV works through the alphabet by hand.
The username has already changed: my notification says salemsalem123, the profile now says supportbot123.

No real platform verifies you through a stranger's comment, and none needs your card for it.

Clicked but typed nothing? Close the tab, clear that site's data, check your downloads.

Authorized something or typed a password? Revoke the app and change the password now.

Entered your card? Call your bank.

Then flag the account: profile, then "Flag" or "Mark as Spam".

Check the profile before the link. It takes ten seconds, and it would have stopped this one cold.

I burned a week of Claude quota in 3 days. Then I found the setting eating it.

Ayoub Hammoudi — Tue, 03 Nov 2026 19:58:38 +0000

I burned a full week of my Claude Ultra quota in 3 days.

My first instinct was to blame the model. So I did what any normal person would do: I benchmarked my own AI, and I let a script grade every answer so I couldn't lie to myself.

100 runs later, I had a number I didn't believe.

Same problem. Same model. Ten times the price.

A routing algorithm with mandatory stops and a toll quota. Opus solved it correctly both ways:

at the lowest effort: $0.19
at the highest effort: $2.03

I reran the logic in my head looking for what the $1.84 had bought. Nothing. Same verdict from the grader, and a much longer wait.

Past medium, the bars only do one thing: get longer. max cost up to 9.3 times high, for the same result, and took 4 to 7 times as long.

That should have been the headline. It wasn't, because of what the cheapest model did next.

2 cents

I gave Haiku, on its lowest effort, a task I expected it to fail: write a regex engine from scratch, without re.

Then I compared it with Python's re on 3,000 random patterns.

It matched all of them. Three runs out of three. For $0.02.

And I had been paying Opus to find values in files.

Then I checked my everyday work

Finding a value in a repo. Renaming across files. Fixing a parser. The boring work that fills a week, and that I was running on the most expensive brain I had.

$0.352 became $0.041. 88% less, and the same 6 passes out of 6.

Before you turn everything down

Don't. This is the part most cost posts skip.

These tasks were well specified, and something could check the answer. That is exactly where low effort is safe. When nothing can check the work, like design or review, the numbers say nothing, and my samples are small. My credit also ran out mid-benchmark, so 21 runs were excluded and Haiku is only partly measured on the hard tasks.

So the lesson was never "use the cheap setting". It was this: when a check proves the result, the check guarantees the quality, not the effort.

So we built rightsize

It's that sentence turned into a Claude Code skill. Free and open source. It picks the model and effort for every step, and saves the heavy thinking for the work that truly needs it.

It also runs only the tests a change touches (0.7 s instead of 11.4 s on a 40-module repo), and ships an audit that reads your local transcripts and shows where your tokens went. Nothing leaves your machine. I recommend it, unless you prefer not knowing.

/plugin marketplace add spar-x-fr/spar-x-skills
/plugin install spar-x-skills@spar-x-skills

github.com/spar-x-fr/spar-x-skills, maintained with Zakaria Khchiche.

It costs nothing. But you can pay us in GitHub stars, the only currency Claude hasn't found a way to burn yet.

PHP forgot to forget. Node.js remembered the random.

Ayoub Hammoudi — Fri, 23 Oct 2026 10:58:15 +0000

On 21 October, PHP and Node.js published security advisories on the same day. Two unrelated bugs in two runtimes that run a large part of the web. Read side by side, they are the same bug turned inside out: one runtime kept something it had promised to throw away, the other froze something it had promised would never repeat.

PHP forgot to forget

PHP's oldest promise is that every request starts clean. Nothing survives from one request to the next. It is why most of us stopped thinking about memory the day we wrote our first <?php.

CVE-2026-109619, "RCE via stale global state" (CVSS 9.2), breaks that promise. PHP keeps global state for errors, sessions, objects and extensions, and some of it can point into memory owned by the current request. That state has to be reset before the request memory is released.

A fatal error can skip the reset. So can running out of memory, which ends the request the same way. The request heap is freed, the worker's global still points at it, and a later request that lands on the same worker can read a pointer into memory that no longer belongs to anyone.

Its sibling, CVE-2026-109618, "RCE via OOM corruption" (also 9.2), sits on the same exit path. PHP leaves an out-of-memory error with longjmp(), and some code was never written to be abandoned halfway. The fix says a lot: PHP no longer jumps out on the spot. It raises a soft out-of-memory error at the next safe point in the VM, and keeps an immediate hard _exit() for a higher threshold.

The fault was never in the happy path. It was in the moment everyone treats as over: the crash.

Node.js remembered the random

Node's bug runs the other way. A startup snapshot freezes the heap of a warmed-up process so the next start can skip the warm-up. Single executable applications can ship one too.

CVE-2026-106074 describes what happens when that heap already holds random data. crypto.randomUUID() and randomInt() keep a cache of pre-generated entropy, the snapshot saves it, and every process started from it repeats the same values.

I wanted to see it, so I tried it on the Node 22.16.0 I had installed.

// entry.js
const { randomUUID } = require('node:crypto');
randomUUID();
require('node:v8').startupSnapshot.setDeserializeMainFunction(() => {
  console.log(randomUUID());
});

$ node --snapshot-blob snap.blob --build-snapshot entry.js
$ for i in 1 2 3; do node --snapshot-blob snap.blob; done
ef9885a2-6c01-4412-abfd-85d0ea1888aa
ef9885a2-6c01-4412-abfd-85d0ea1888aa
ef9885a2-6c01-4412-abfd-85d0ea1888aa

There is something quietly insulting about reading the same "random" UUID three times.

Then I counted. Across two processes started from the same snapshot, the first 127 UUIDs were identical, and so were the first 1023 values from randomInt(). The 128th UUID was different.

Those numbers are not an accident. randomUUID() fills a buffer for 128 UUIDs at a time (kBatchSize = 128). One was used before the snapshot, so 127 were frozen with the heap. randomInt() reads 6 bytes per attempt from a 6 KiB cache: 1024 slots, one used, 1023 frozen.

The fix is short. While Node builds a snapshot, it registers a callback that zero-fills both caches and resets their offsets after user serialization, and again before user deserialization, because microtasks and exit handlers can refill them in between.

What I take from it

Neither bug lives in code anybody reads twice. "Every request starts clean" and "random is different every time" are not features. They are assumptions so old that nobody writes them down, and you can't test what you never wrote down.

Both become cheap to test once you say them out loud. Build the snapshot, start it twice, assert the UUIDs differ. Kill request N with a fatal error and look at what request N+1 sees.

Mostly it reminded me where to look. The expensive bugs rarely sit in the path we watch. They wait in the moments we consider finished: the crash, the shutdown, the cleanup, the boot.

Patch

PHP: 8.2.35, 8.3.36, 8.4.27, 8.5.12
Node.js: 22.23.4, 24.22.1, 26.12.1

If you ship single executable applications, rebuild them: an SEA carries its own copy of Node, so upgrading the one on the machine does not patch it. Snapshot blobs have to be rebuilt anyway, since Node refuses to load a blob made by a different binary.

Sources: the Node.js October 2026 security releases, and the php-src advisories GHSA-6wmf-4rv5-p3rp and GHSA-w8hw-w9fx-j79w.

I am Ayoub Hammoudi, a backend and AI platforms engineer in Paris. More of my work is at github.com/Ayoubhm07.

My first Apache Kafka PR deleted three lines. I almost deleted the wrong one.

Ayoub Hammoudi — Tue, 20 Oct 2026 19:43:07 +0000

Deleting a duplicate line is the safest change in software. Nothing can break, because nothing changes. I believed that right up until I measured it.

The door

Apache Kafka does not run its CI for a first-time contributor. A pull request from someone the project has never merged gets a labeler and a triage bot, and the real build waits until a committer approves it. When I looked, one first-timer's pull request had been sitting for five days with two check runs, no comment and no review.

So a first pull request there is not a chance to impress anyone. It is a chance to be trusted once.

Before I found anything, I chased three families of defects and came back empty. A scanner for malformed SLF4J placeholders across 3,911 production files found zero. Leftover JUnit 4 imports: zero files. And a family of ByteBuffer.array() fixes, where five pull requests from three contributors were stuck on one question from a committer:

Did we verify if this is a real-world scenario before drafting this PR?

That question stayed with me for everything that followed.

The find

What survived was small. In build.gradle, three test dependencies were declared twice inside the same block:

core              libs.apachedsCoreApi        lines 1221 and 1230
connect:runtime   project(':server-common')   lines 3842 and 3847
connect:runtime   project(':server')          lines 3840 and 3848

Gradle resolves a configuration as a set, so the second declaration does nothing. Delete it and move on.

Except that every pair has two lines, and you have to pick one.

The wrong one

For core I picked line 1221. It looked like the stray one, alone between two unrelated dependencies, while 1230 sat neatly at the head of the apacheds* group. Keeping 1230 made the file look tidier.

Then I did what that committer's question asks for. I generated the dependency report for both test configurations of both projects, before and after, and compared them.

The resolved sets were identical: 73, 104, 125 and 171 modules, not one difference.

The :core report was not. Fifteen lines had moved. org.apache.directory.api:api-all jumped from position 150 to 87, ahead of apacheds-core-api. Removing line 1221 had pushed apachedsCoreApi behind another declaration, and the report follows declaration order.

On the JVM, order is not cosmetic. When two jars on a classpath ship the same class, the first one wins. These two artifacts both come from Apache Directory and probably share no classes.

Probably is not a word I wanted to put in front of a reviewer.

The right one

So I removed the later line of each pair instead: 1230, 3847 and 3848. Every declaration that remains keeps its position, and the classpath order stays exactly as it was.

The four reports came back byte-identical, at 241, 418, 498 and 760 lines. Both modules compiled their tests, check passed without the test task, rat passed at the root, and WorkerTest ran 140 tests with no failures as a spot check on the connect side.

The description ended up far longer than the diff. One paragraph in it explains why the later line and not the earlier one. It answers the question before anyone has to ask it.

A committer approved it the next morning with two words, "Thanks, LGTM", and merged it a moment later.

What I took from it

A deletion is not a non-event. It has a position, and in a build file position is behaviour. "It resolves to the same set" and "it builds the same classpath" are two different claims, and only the first one was true of my first choice.

The other lesson is about proportion. In a project you have never touched, the size of the change and the size of the proof have nothing to do with each other. A three line diff with a boring, byte-identical proof is easy to merge. The same diff with "should be a no-op" is a question a busy committer has no time to answer.

The rule I keep now is simple. When you remove a duplicate declaration, remove the later one.

The pull request is apache/kafka#23786. How I look for these defects in the first place is in an earlier post.

I am Ayoub Hammoudi, a backend and AI platforms engineer in Paris. More of my work is at github.com/Ayoubhm07.

Playwright recorded my 25 fps animation at about 9. The fix was to stop recording.

Ayoub Hammoudi — Mon, 19 Oct 2026 18:36:28 +0000

I needed a short video of my portfolio for LinkedIn: the opening animation, a swordsman who cuts the screen in two, then a fast scroll through every section. Playwright records video in one option, so I started there.

The first video looked fine in stills

recordVideo on a browser context gave me a 25 fps WebM. Every frame I pulled out of it looked right. I had only checked stills. Played back, it stuttered, and the first person who watched it saw it at once.

Measuring it frame by frame told the real story:

the opening: 65% of frames identical to the one before
the swordsman: 63%
the scroll: 79 of 200 transitions were a freeze followed by a jump

That is about 9 real frames per second inside a 25 fps file. The recorder is fed by the browser's screencast, which hands over a frame only when the compositor has one ready. On a heavy page it has fewer, and the gaps are filled with repeats. Nothing fails. The video is just wrong.

Stop recording, start stepping

If the browser cannot keep up in real time, take real time out of the equation. Every CSS animation and transition on a page is a Web Animation, reachable through document.getAnimations(), and a paused animation can be placed at any instant by setting its currentTime. So the capture becomes a loop: advance every animation by exactly 40 ms, take a screenshot, repeat. 25 frames per second by construction, however long each screenshot takes.

// injected with context.addInitScript, before the page loads
const seen = new WeakMap();
let t = 0;
window.__step = (dt) => {
  t += dt;
  for (const a of document.getAnimations()) {
    if (a.timeline && a.timeline !== document.timeline) continue;
    let s = seen.get(a);
    if (!s) {
      s = { start: t - dt, offset: a.currentTime || 0 };
      seen.set(a, s);
      a.pause();
    }
    a.currentTime = s.offset + (t - s.start);
  }
};

Animations that start later, like the swordsman when his IntersectionObserver fires, are picked up on the next step and join the same clock.

Scrolling gets the same treatment: one scrollTo per frame along an eased curve, instead of a smooth scroll that the recorder samples whenever it can.

for (let i = 1; i <= frames; i++) {
  const y = Math.round(target * easeInOut(i / frames));
  await page.evaluate((y) => {
    window.scrollTo({ top: y, behavior: 'instant' });
    window.__step(40);
  }, y);
  await page.screenshot({ path: `frames/${String(n++).padStart(5, '0')}.jpg`, type: 'jpeg', quality: 95 });
}

The frames go to ffmpeg as an image sequence. The new video has zero frozen frames in the opening, the descent and the scroll.

The traps

A timer that ignores your clock. The opening has a 7-second safety timeout that removes it if its end event never arrives. Each captured frame costs far more than 40 ms of real time, so that timer would have fired long before the virtual clock got there. I neutralised that one timeout in the capture script. Anything driven by setTimeout or requestAnimationFrame runs on wall time, not on yours: the text-scramble effect on my headings plays faster in the video than on the site, and I left it that way.

Scroll-driven animations already have a clock. Animations bound to animation-timeline: view() follow the scroll position, so setting their currentTime makes no sense. The loop skips anything whose timeline is not document.timeline. Driving the scroll drives them.

One frame can lie. A section flashed white for a single frame. In real time nobody would see it. In a 25 fps video it reads as a glitch. A frame-difference pass over the whole video found it, and I cut it.

The upload has opinions too. LinkedIn's composer previewed my WebM, then dropped it as soon as I clicked Next. The same frames encoded as H.264 MP4, in yuv420p with standard colour range, stayed.

What I take from it

A screen recorder answers "what did the screen show?", and on a busy page the honest answer is "less than you asked for". For a demo, the better question is "what should the screen show at 40 ms, at 80, at 120?". The Web Animations API lets you ask it directly.

And watch the playback, not the stills. Every still I checked was perfect.

The 19-second result is in my LinkedIn post, and the site itself is at ayoubhammoudi.com.

I am Ayoub Hammoudi, a full-stack engineer in Paris working on data and AI platforms. More of my work is at github.com/Ayoubhm07.

My fix was one line. Code review found two holes in it.

Ayoub Hammoudi — Fri, 16 Oct 2026 16:48:20 +0000

The bug I fixed in Microsoft Agent Framework did not crash anything. That is what made it worth fixing.

When the framework called Gemini without streaming, the response knew which model had answered. When it made the same call with streaming, the model name could disappear on the way. The framework records its metrics through OpenTelemetry, and the model name is one of the dimensions those metrics are split by. On streamed calls, the token and duration histograms simply lost that dimension. Every request still succeeded. The per-model view of cost and latency just had a hole in it.

Why it happened

Each streamed chunk from Gemini may or may not carry a model_version. The streaming parser copied that field straight into the update, so a chunk without it produced an update without a model. The aggregator keeps the last non-empty value it sees, and there was nothing to catch up afterwards, so a stream whose chunks carried no version ended with no model at all.

The non-streaming parser, thirty-odd lines above, already handled this: it fell back to the configured model when the response did not name one. Two paths, same input type, different answers.

The one-line fix

So I proposed the obvious thing: apply the same fallback on the streaming path. One line, two tests, parity with the sibling.

It was wrong twice.

Hole one

I had raised this one myself, as an open question in the PR description: was the client's default model really the right fallback? The automated reviewer answered it. The fallback used the client's default model, not the model actually requested. A client configured for gemini-2.5-flash and called with gemini-2.5-pro for one request would label that request as Flash, metrics included. The model resolved for the request was already in scope where the stream was consumed, so the parser now takes it as an argument and falls back to that.

Hole two

Then the maintainer found the subtler one. Applying the fallback chunk by chunk could overwrite a version the server had already reported. If an early chunk said gemini-2.5-pro-002 and the final usage chunk carried no version, the aggregator, which keeps the last non-empty value, would replace the precise version with the requested alias gemini-2.5-pro.

The fix had to remember what the server said for the whole stream, not chunk by chunk:

fallback_model = model
async for chunk in response_stream:
    if chunk.model_version:
        fallback_model = chunk.model_version
    yield self._process_chunk(chunk, fallback_model)

and in the parser:

model=chunk.model_version or model,

What merged

Three iterations, four tests. One checks the version from a chunk is kept, one checks the fallback to the configured model, one the fallback to the requested model, and one replays the maintainer's exact case: an observed server version must survive a later chunk that omits it. The last one fails on the previous commit, which is the point of it.

What I take from it

My first version was not careless. It matched the sibling path exactly, it had tests, and it fixed the reported symptom. It was still wrong, twice. The first hole I had seen and left as a question. The second came from the maintainer.

That is the case for review in one PR. Not catching typos, but catching the second-order behaviour of a change: which value is in scope, what the aggregator does with it next, what a later chunk can undo. Observability bugs make this harder, because nothing fails. The only signal is a number that is quietly attached to the wrong thing, or to nothing.

If you run LLM calls behind OpenTelemetry, it is worth one test that compares a streamed call with a non-streamed one and checks every attribute, not just the status code.

The PR, with the full review thread: microsoft/agent-framework#9139

I am Ayoub Hammoudi, a backend and AI platforms engineer in Paris. More of my work is at github.com/Ayoubhm07.

AI did not erase deep understanding. It made it rare.

Ayoub Hammoudi — Thu, 15 Oct 2026 12:56:49 +0000

I hated AI.

Not on principle. Because I had spent years digging. Stack Overflow at two in the morning, GitHub issues, reading a file until I understood why it actually broke rather than why it appeared to. Effort was the filter. It was the thing that separated the people who could from the people who could not, and I had paid for my side of that line.

Then a kid with two months of experience started shipping a working project in five minutes.

I want to be precise about what I felt, because I think a lot of people feel it and do not say it. It was not fear of being replaced. It was something smaller and uglier: the suspicion that the thing I had bought with my nights had just been handed out for free.

The sentence that moved me

Two people changed my mind. One was a teacher of mine. The other was a friend of his. Separately, weeks apart, they said the same thing:

You are used to a manual gearbox. Somebody just handed you an automatic. Your advantage is not that you can drive. It is that you know what is happening under the hood.

I nodded politely and did not understand it for months.

What finally landed was the inversion hidden inside it. I had been reading the situation as a loss, as though a scarce skill had been devalued by mass production. The opposite was true. The skill had not been devalued. It had been made optional, which is a very different thing, and optional skills do not disappear. They become uncommon.

Scarcity, not erasure

Before, everyone had to dig. There was no other route from a stack trace to a fix. Because the effort was compulsory, it was also ordinary. Everybody around you had paid the same price, so the price bought you nothing in particular.

Today nobody is forced to. You can ship a feature without ever asking why the library behaves that way, and most of the time it works, which is exactly what makes it dangerous. The understanding is still there to be had. Almost nobody acquires it, because nothing in the daily loop requires it anymore.

That is the whole shift, and it runs the other way from how it is usually told. The supply of people who understand deeply is shrinking. The demand for them has not moved. Anyone who says this makes expertise worthless has the arrow backwards.

What it actually looks like

This is the part that sounds abstract until you have done it, so here is the concrete shape of it.

A model will hand you code that is syntactically perfect, idiomatic, well named, and wrong in a way that will not show up for six months. It will confidently call a method that behaves differently than its name suggests. It will reproduce a pattern from the project's most-copied file without noticing that the file is the one everybody complains about. It will give you the answer that is most common on the internet, which is not the same as the answer that is correct here.

None of that is caught by reading the output carefully. It is caught by already knowing the terrain. By having read the library, by recognising that two siblings in the same class disagree with each other, by having a sense of what this codebase does when it is healthy.

That sense cannot be prompted into existence. It is the residue of having dug, and it is the only part of the job that is getting scarcer rather than cheaper.

Where that leaves me

I use AI every day now. I stopped resisting it a while ago, and resisting it was never the interesting position anyway.

But I am not ahead because I use it. Plenty of people use it. I am ahead, on the days when I am ahead, because I can tell when it is wrong, and because telling when it is wrong is a thing I can only do about the parts of the stack I actually took the time to learn.

So the advice I would give my past self, the one who was quietly resentful watching a beginner ship in five minutes, is not "learn the tool". Everyone learns the tool. It is: keep digging in the places nobody is forced to dig anymore. That is where the margin moved.

I am Ayoub Hammoudi, a backend and AI platforms engineer in Paris. More of my work is at github.com/Ayoubhm07.

How I got seven fixes merged into Prefect, SQLGlot, Apache Beam, Kafka and Microsoft by asking one question

Ayoub Hammoudi — Wed, 14 Oct 2026 13:00:00 +0000

I had seven pull requests merged upstream: one in Prefect, one in SQLGlot, one in Apache Beam, two in Microsoft PyRIT, one in Microsoft Agent Framework and one in Apache Kafka. The largest was 78 added lines. Two of them added nothing at all and only deleted. The fastest went from issue to merge in 34 minutes.

None of that came from reading code hoping something would look wrong. It came from one question, asked over and over:

Where does this project do the same thing more than once, and which one disagrees with the others?

Mature codebases are full of families. Dialect generators. Notification blocks. Scorers. Serializers. Every family is a contract implemented N times, and a contract implemented N times is a contract that drifts. When one sibling drifts, the other siblings become your oracle. You are no longer arguing about what the code should do. The project already answered that, N minus one times.

The clearest case: a seed that never reached the query

SQLGlot transpiles SQL between dialects. Databricks has a UNIFORM(min, max, seed) function. So does Snowflake. Both are generated by sibling classes.

The Databricks parser stores that third argument in the seed slot of exp.Uniform. The Snowflake generator reads both gen and seed. The DuckDB generator reads only gen.

So a query transpiled to DuckDB silently lost its seed. ABS(HASH()) hashed nothing. Seed 5, seed 99 and no seed at all produced identical SQL. No exception, no warning, and a result that looks completely plausible until you need reproducibility.

Here is the part that matters for the method. I did not have to decide what the correct output was. I wrote in the pull request:

The two expected strings are not mine: tests/dialects/test_snowflake.py:3312-3334 already asserts them for the equivalent Snowflake input.

The project had already written down the right answer for the sibling. My test asserted the same strings for the dialect that got it wrong. A reviewer does not have to trust my judgement about SQL semantics. They only have to agree that two dialects reading the same parsed expression should not disagree.

Issue opened at 15:46. Merged at 16:20. Thirty four minutes, for a three line change.

The same shape, three more times

Prefect. Notification blocks let you set a bot name. One of them, NotifyMattermost, accepted the setting and never passed it to the request. Its siblings all did. The fix was sixteen lines with a test, and the expected behaviour came from the other blocks, not from me.

Microsoft PyRIT. SubStringScorer includes its text matcher's configuration in the scorer identity. DecodingScorer holds the same kind of matcher, at the same point of the same method, and did not. The consequence is not cosmetic: two scorers that return opposite verdicts for the same input shared one identity hash, so cached evaluation metrics could be reused across different behaviour. The sibling had already been fixed in a pull request that was merged. I copied the two lines it added into the class that had been missed.

Apache Beam. This one breaks the pattern, and it is worth including for that reason. A debug log reading ### Labels arrived in the Python BigQuery connector with the commit that added BigQuery Read API support, merged on 6 October 2021. My one line removal merged on 6 October 2026. Five years to the day, in a release path, printing a dataset label dictionary at warning level on every temporary dataset setup. There was no sibling to compare against here. There was just a line that no release should have contained. Zero additions, one deletion, one approval, no requested changes.

What this method is not

It is not scanning for theoretical defects.

I learned that bluntly, and at my own expense. On another project I prepared a clean, exhaustive change that removed a parameter no code reads across seven model families. Every call site checked, every live use preserved, the project's own type checker measured at the version they pin, the full suite run. Only after all of that did I sit down and read their contributing guide properly. It says, in writing, that they will close changes like mine:

Code agents often zero in on "theoretical bugs" found by code analysis that rarely if ever cause problems in practice. These are generally not worth fixing unless they can be exploited by an attacker.

I had spent a twenty three hour test run before reading the one page that decides whether the work was admissible at all. I opened it anyway. A maintainer closed it two minutes after a bot flagged it for review, without a word, which is exactly what that page says they will do. The CI on it was entirely green: sixteen jobs, 199,469 tests, zero failures.

That is a fair outcome and I would have done the same in their position. The lesson is not that the policy is wrong. It is that reading it costs ten minutes and belongs at minute zero, not after the suite.

A maintainer of a different project put the same bar as a question on the issue tracker: Did we verify if this is a real-world scenario before drafting this PR? He was reviewing one of five pull requests, from three contributors, all proposing the same category of change to the same family of classes. None of the five has been merged, and four are still open. Correctness of an API contract is not enough. Something has to actually go wrong.

The sibling question clears that bar by construction. If one implementation out of five behaves differently with the same data in hand, the breakage is reachable by definition. Someone is on that path right now.

The five questions, in the order I ask them

Where is the family? The interface, the base class, the registry, the dialect map. Anything implemented more than three times.
Does the project already state the right answer? An existing test asserting it for the sibling, a docstring that promises it, a schema that declares it. If nothing in the repository states it, you are about to argue about taste with someone who has merge rights, and you will lose.
Are the siblings actually in the same situation? This is where most candidates die, and it is the question people skip. If the sibling that behaves correctly never receives the data in question, it is not a witness, and you have no case at all.
Does it fail before and pass after? Write the test first, run it, keep the exact failure message. It costs one command and it is the most persuasive thing you can put in front of a reviewer.
Did you run what they run, at the versions they pin? Their linter version lives in .pre-commit-config.yaml, setup.py or the CI workflow, not in your head. One number produced with a newer tool invites a reviewer to dismiss the entire report.

The part nobody writes about

Everything above is the visible half. The other half is the work that produced nothing, and it is most of it.

That repository was Kafka, and I chased three separate defect families there before finding anything worth proposing. I wrote a scanner for malformed log placeholders and ran it across 3,911 production files: zero cases. I grepped the whole tree for leftover JUnit 4 imports: zero files. The third was the family of five pull requests above, already dead on a bar a maintainer had set.

What survived those three dead ends was three test dependencies declared twice in the same Gradle block. Zero lines added, three removed.

That is the method working, not failing. Seven merges did not come from being prolific. They came from killing candidates early, before writing anything, so the few that reached a maintainer were ones they could not reasonably refuse. Five of the seven were under forty lines. The effort was never in the fixing.

So if you take one thing from this: the skill being tested is not finding bugs. It is deciding, quickly and honestly, which of the bugs you found are worth another person's attention.

Everything I shipped is public and linked below. Every claim in this post can be checked against it.

I am Ayoub Hammoudi, a backend and AI platforms engineer in Paris. More of this work is at github.com/Ayoubhm07.