DEV Community: Ayoub Hammoudi

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.