DEV Community: Sergey Dobrov

AI Can Write the Code. Who Is Going to Learn From Its Bugs?

Sergey Dobrov — Tue, 13 Oct 2026 16:38:43 +0000

I'd been learning a piece with a piano trainer whose approach worked really well for me, and nothing else did it the same way. Then it went iOS-only. So I described what I wanted to a coding agent, and a few minutes later I had my own.

I haven't read a single line of its code, and I don't feel guilty about it.

It has no ads and no annoying UI. It does exactly what I need and nothing else. It changes only should I wish it to. Is its architecture scalable? It will never have a million users. It barely has one: me.

A lot of software was complicated only because it had to be general. Mine doesn't have to be, so it can be gloriously simple.

The case for never reading agent code

The claim goes roughly like this: if you're reading agent code, you're the bottleneck. A recent video, Claude Ultracode is super intelligence by Less Bitter, makes the strongest version of it. It showed a spec of about 2,700 lines, itself written by Claude from a voice memo, turned into a working distributed feature over roughly seven hours of agent work, with critics and tests along the way. The author's conclusion: code quality doesn't matter anymore. Apply enough pressure and keep what survives, like evolution.

He isn't alone. Gergely Orosz has said he sees code reviews fading away (source). Santiago (svpino) wrote in August that he'd gone two weeks without reading any AI-generated code and now designs verification for the whole system instead (source). A recent piece argues that code is the new assembly: an intermediate representation nobody needs to read (source).

I want to give this its due. For my piano trainer, it's simply right. Reading its code would buy me nothing: if it breaks, I'm the only one affected, and I'm not trying to get better at building piano trainers.

But "you don't need to read this code" and "understanding the implementation no longer matters" are different claims.

What code quality actually is

"Code quality doesn't matter" depends on what you think quality was. If it means taste, then sure, an agent doesn't care. But most rules that get dismissed as taste are literal readings of principles, and the principles still matter. Short functions, for example, were never about looks: they're easier to test, and an agent changing those tests later makes fewer mistakes too.

Or take DRY. It was never "no repeated lines". Its original definition, in Hunt and Thomas's The Pragmatic Programmer (1999), is about knowledge: each piece of it should have one authoritative representation. People called DRY an antipattern long before AI, because they took it literally. Duplicating coincidental code is fine. Duplicating a business rule creates an invariant nobody enforces: these copies must stay equal. Agents break that the same way people do. They update the copy they're looking at and miss the one that drifted after the copy-paste.

Brevity was never the point either; clarity was. And naming isn't cosmetic. A name is a claim about meaning, and models lean on those claims heavily. Strip the names, and models get measurably worse, even on tasks that should depend only on structure (source). If anything, names matter more for agents: a human compensates for a bad name with a year of familiarity, while an agent reads the code cold every session.

So very little of code quality ever existed only for human readers. It was always information and structure, and every reasoner needs both. What AI changes is how its absence fails. A human slogs through bad code and gets slower. An agent reads it fast, misunderstands it confidently, and acts. Which leaves the question the rest of this piece is about: who notices?

Where judgement comes from

I didn't learn about race conditions from the definition. I learned when code I was sure was deterministic gave different results, and I spent hours finding out why. After a few of those, you don't just know about synchronization. You feel it. You look at innocent-looking code and think: this will race.

Same with injection. "Never trust user input" is a sentence. Someone breaking your shiny new homepage by messing with GET parameters is an experience. After that, name = request.args["name"] makes you flinch.

That flinch comes from accumulated failed predictions: moments when your mental model collided with reality and lost. It's also why experienced engineers can reject an AI answer before they can explain why. They've seen that movie.

So I've started to think "should we review the code?" is the wrong question. What I'd rather know is where these collisions happen now, and who's around when they do.

The standard reply: nobody reads the assembly their compiler emits, so why read what an LLM emits? The standard answer is that compilers are deterministic and LLMs aren't. Yes, but I find a different answer more useful: every abstraction moves where judgement forms, and what matters is how much it leaks.

Compilers almost never leak in ways you have to reason about. Not reading assembly cost us very little.

Frameworks leak at the edges, and we can already see what that costs. Modern web frameworks escape output and ORMs parameterize queries by default. That's mostly good. But it means many developers never get burned by injection, so they never form the reflex the burn would have taught. The real lesson was that input is hostile everywhere, not only where HTML gets rendered. Without that reflex, the same developer writes open(os.path.join(root, request.args["file"])) and walks straight out of the project root. Or builds an SSRF from a URL parameter, or an open redirect. The protection covered one case; the reflex would have covered all of them.

AI-generated code is an abstraction that can leak anywhere. The cost of never colliding with it scales accordingly.

Tests aren't the environment

The video's evolution metaphor is appealing: don't demand a beautiful genome, apply pressure and keep what survives. But in evolution, the organism doesn't write its environment. The world judges it, and the organism has no say in what counts as success.

When the same kind of model interprets the spec, writes the code, writes the tests and fixes the failures, that's not natural selection. It's an optimizer grading its own homework. Adding critic agents helps less than it seems: models from the same family can share blind spots, so their errors are correlated, not independent (source). And sometimes the easiest way to make a test pass is to weaken the test.

Green CI means the implementation satisfies the tests. It doesn't mean it satisfies reality. Ten thousand tests cover the hypotheses someone thought of, and nothing else. A person who's been burned by concurrency asks what happens if two events arrive in the opposite order, and then an agent can write five hundred tests for it. Without that question, you get five hundred sophisticated tests of the happy path.

There is a version of this that really is evolution: ship to production, let real users and attackers hit it, read the complaints, fix, repeat. That environment is independent. It's also the most expensive test suite there is.

In the video, the spec was written by AI too. So the pipeline is vague intent, then an AI spec, AI implementation, AI tests, AI critics, CI.

Where does engineering knowledge enter that system? In his case the answer is easy: he has it. He's built software for years, knows his product, and can tell whether the result is right. He's the oracle.

A junior asking for "something like Uber" gets a fluent spec too. Nothing tells them what it's missing, because they don't know what they don't know. AI increasingly removes the need to formulate a solution, but someone still has to judge whether the formulation describes the right problem. The method works because of years of exactly the experience it would deny the next generation.

Specs age

The video's example is a single pass: one spec goes in, and seven hours later one working feature comes out. Nobody has to change that spec afterwards. Real systems live through dozens of revisions.

An AI-written spec of a few thousand lines that nobody fully read is a second codebase nobody owns. When requirements change, someone has to know which parts were real invariants and which were incidental choices. Which tests protect something that matters, and which just pin behavior that happened to exist.

It gets worse. When the spec changes, the agent updates code and tests together. The environment doesn't just fail to be independent; it co-evolves with the organism, under the same author. Green CI at revision twelve says nothing about an invariant from revision three whose test was "updated to reflect the new requirements".

Then there's Hyrum's law: with enough users, every observable behavior gets relied upon. We usually discuss it for APIs, where you can argue that consumers shouldn't depend on undocumented behavior. Users of a product are different. They learn where the export button is, what order the list comes in, which filter remembers its value. To them, all observable behavior is the behavior, and you can't tell them they were wrong to rely on it.

A human changing familiar code tends to make a minimal diff, so incidental behavior stays put by default. An agent satisfying a revised spec is free to restructure. Each regeneration is a fresh sample from the implementations that pass the tests, and everything the tests don't pin can drift: ordering, defaults, wording, timing, edge cases. Not because anyone decided to change them, but because nothing held them in place. Multiply that by every release cycle, and watch your support queue.

Nobody debugs it either

One objection I take seriously: you don't need to write code to get burned by it, and engineers on call for systems they didn't build learn plenty. But that only works if someone actually does the debugging. When nobody knows the code, debugging it yourself is expensive, so handing the bug back to the agent is the rational choice. Every time. Each handoff keeps familiarity at zero, which makes the next handoff even more rational. Each choice is sensible on its own. Together, they guarantee that nobody ever gets to know the code.

Agents are best at bugs that are local and reproducible. They get stuck on emergent ones: timing across services, data-dependent corruption, failures that only appear under real load. Those are the formative bugs, and that's when humans get pulled back in. At the highest stakes, with the least familiarity.

None of this is new. In 1983, Lisanne Bainbridge described it in "Ironies of Automation": automation takes over the easy cases, leaves operators the hardest ones, and erodes the skills they need for them. Aviation learned this the hard way. I suspect software is about to run the same experiment.

Addy Osmani described one half of this well: agents made writing code almost free, while understanding it still costs what it always did (source). I'd add the other half. The expensive part also includes becoming someone who can understand systems at all, and that happens mostly through the collisions we're now automating away.

Building software is getting cheap much faster than becoming an engineer is. That gap makes judgement more valuable, not less. If you know concurrency is dangerous, you ask for tests that replay events in every hostile order, and an agent writes five hundred of them in minutes. If you don't know, nobody asks, and the agent happily tests the happy path.

The bottleneck moves from writing code to knowing what should exist, noticing when it's wrong, and knowing which failures matter. Those are exactly the abilities you get from software personally screwing you over.

Knowing what should exist is the one I've seen junior and even mid-level engineers struggle with most. Many times I've had to ask "why do you need this?" over and over, until they realized they didn't. An agent rarely asks that question. It builds what it's told, quickly and well, so the unnecessary thing now costs minutes instead of days, and nobody is forced to notice it was unnecessary.

What I actually do about it

I don't think the answer is reviewing every line. Three things seem to work better, at least for me, though none of them is a complete answer.

Stay in the reasoning loop. As far as I can tell, what builds intuition is being present when reality contradicts your model, more than typing or even reading the code. You can stay present with an agent: predict the cause before it tells you, refuse fixes you can't explain, and have a human write the root cause in the postmortem. None of this happens by default, because "fix it" is always faster than "explain it". It has to be a deliberate choice, for individuals and for teams.

Own the boundaries; let agents own the interiors. When I wanted another exercise in my piano trainer, my instinct was to build a separate app instead of growing the first one. That's the Unix way coming back. We drifted away from it partly because many small pieces meant many things to remember and maintain. Cheap generation removes most of that cost, and small pieces also keep each part within what an agent can hold in context. But pieces can only be disposable if the interfaces between them aren't. Unix worked because its contract was dumb and stable: lines of text. So I keep interfaces boring, and I decide them myself.

Use the agent to raise the bar. This part is optimistic. Atomic commits, real commit messages, test plans, small reviewable PRs, a quick first assessment of every incoming traceback, a short loop for the simple bugs: we always knew they were good, and deadlines always gave us an excuse to skip them. Agents make them almost free, so skipping them is now a choice. One caveat: these artifacts are claims about the work. An agent will write a confident test plan that was never run, or split commits that don't build on their own. In experienced hands that's easy to catch, and standards go up. In inexperienced hands you get history that looks exemplary and is subtly fictional.

My piano trainer exists because I practice piano. Nobody, me included, thinks an app could do the practicing for me. The app was easy to hand over. The hours at the keyboard weren't, because the hours are the point.

Software engineering is the same. Let the agent build the tool. But someone still has to practice: break things, be surprised, and come out understanding something they didn't before. If AI writes the code, the question isn't whether anyone reads it. It's who's going to learn from its bugs.

40 Lines of Python to Fake a Serial Mouse

Sergey Dobrov — Tue, 10 Mar 2026 15:41:55 +0000

During the COVID lockdowns my son and I started playing The Settlers II in DOSBox.

One of the coolest features of the game is that two players can play on the same computer in split screen, each controlling their own cursor — a surprisingly social multiplayer mode for a 1996 strategy game.

The trick is that the second player uses a serial mouse.

Unfortunately modern operating systems don't really expose the concept of multiple independent mice anymore — they all get merged into a single pointer.

So if I wanted that old-school multiplayer experience back, I needed an adapter.

My first thought was simple: maybe I can fake a serial mouse?

In Unix systems everything is a file. If DOSBox expects a serial device, perhaps I can generate the right byte stream and feed it to it?

Reading through the Linux docs and trying to hexdump the mouse device I realized I need to convert from PS/2 mouse protocol into Microsoft serial mouse protocol. The descriptions of both I quickly found on the Internet: https://roborooter.com/post/serial-mice/.

Quickly noticing some key differences:

Both communicate via groups of three bytes;
The most significant bit of each byte is used for framing in the Microsoft protocol, so the high bits of the coordinates are packed into the first byte;
Both encode movement deltas, but PS/2 uses sign bits in the status byte while the Microsoft serial protocol splits the high bits of the coordinates into the first byte;
As a result PS/2 effectively has one extra bit of precision for each axis.

The first idea was to just write the packets into a pipe and connect DOSBox to it.

Unfortunately, DOSBox expects something that behaves like a real serial device, not just a pipe.

Eventually I landed on socat, which can create a pair of pseudo-terminals:

socat -d -d pty,raw,echo=0 pty,raw,echo=0

This creates two linked devices:

/dev/pts/24
/dev/pts/25

Whatever you write to one appears on the other.

Now DOSBox can connect to one side:

serial1=directserial realport:pts/25 rxdelay:0

And the script writes to the other.

The first version worked — but the mouse felt strange: movements were extremely smooth and continued even after I stopped moving the mouse.

Modern mice have extremely high DPI, which means the adapter was sending a huge number of tiny movements.

DOSBox replayed them with a delay.

The solution was simple: accumulate movement and send it in larger steps.

I deliberately didn’t try to make it neat or reusable — it only needed to run on my laptop:

import struct


def send(conn, x, y):
    (x,) = struct.pack('b', x)
    (y,) = struct.pack('b', y)
    #
    byte1 = 0b01000000
    byte1 += (x & 0b11000000) >> 6
    byte1 += (y & 0b11000000) >> 4
    #
    buff = [byte1]
    buff.append(x & 0b00111111)
    buff.append(y & 0b00111111)
    conn.write(bytes(buff))
    conn.flush()


BUNDLING = 1
SENSITIVITY = 1


with open('/dev/pts/24', 'wb', 0) as conn:
    acc_dx = acc_dy = 0
    with open('/dev/input/mouse1', 'rb', 0) as mouse:
        print("let's get it started!")
        while True:
            b1, dx, dy = mouse.read(3)
            if b1 & 0b00010000:
                dx += -256
            if b1 & 0b00100000:
                dy += -256
            acc_dx += dx
            acc_dy += dy

            dx = dy = 0
            if abs(acc_dx) >= BUNDLING:
                dx = int(acc_dx // SENSITIVITY)
                acc_dx -= dx * SENSITIVITY

            if abs(acc_dy) >= BUNDLING:
                dy = int(acc_dy // SENSITIVITY)
                acc_dy -= dy * SENSITIVITY

            if dx or dy:
                send(conn, dx, -dy)

As you can see the script is very simple:

Main loop reads PS/2 packets from /dev/input/mouse1;
Decodes movement deltas;
Accumulates them over time;
Applies BUNDLING to avoid overwhelming DOSBox with packets;
Applies SENSITIVITY so that our high-DPI mouse feels good in small resolution of the old game;
Every now and then the send routine builds MS Serial Mouse packets back from the accumulated movements and sends it to the pts devices so that socat mirrors it into the other pts which DOSBox will read.

Note that The Microsoft protocol has slightly lower resolution for movement deltas than PS/2, so very large movements would technically need to be split across multiple packets. In practice this isn't an issue because mice report movement in small increments.

The UNIX way

In the end the entire adapter was about 40 lines of Python, no third-party libraries — just the standard library and a bit of Unix plumbing.

Interestingly, modern DOSBox builds now support this feature natively: https://www.dosbox-staging.org/releases/release-notes/0.80.0/?utm_source=chatgpt.com#dual-mouse-gaming, so the little adapter is no longer necessary.

But solving the problem was half the fun — and it’s a nice illustration of how Unix-style abstractions let you insert a tiny translator between two pieces of software from completely different eras.

Even if one of them thinks it's talking to a serial mouse from 1995.

The Best Engineers Can Move Between Abstraction Layers

Sergey Dobrov — Wed, 18 Feb 2026 10:57:14 +0000

One pattern I’ve noticed over the years: the strongest engineers can move between abstraction layers almost effortlessly.

They write high-level code comfortably — but when something behaves strangely, they instinctively descend a few layers, reason about what’s happening underneath, and come back with a fix.

Here’s a simple thought experiment.

Ask someone why Python code using dense numeric arrays is much faster than similar logic written with regular Python objects.

A surface-level answer is:

“Because NumPy is written in C.”

A deeper answer mentions:

contiguous memory
cache locality
pointer indirection
object metadata overhead
how CPUs actually operate on memory

That explanation travels from Python syntax down to memory layout and hardware behavior — and back.

That ability to move across layers isn’t academic. It shows up in very ordinary work.

A Very Ordinary API Problem

Recently I was integrating with an external REST API that was painfully slow.

It returned paginated results and also reported the total number of matching records. The task was straightforward: fetch everything.

The original implementation used broad filters over the entire time range and fetched page by page with large page sizes.

At the HTTP layer, that approach makes sense:

Fewer requests
Larger pages
Simpler control flow
“Minimize round trips”

It feels efficient. But performance was terrible.

Instead of tweaking page size or adding concurrency, I asked a different question:

— Why is the API returning total count?

— That likely means a COUNT(*) somewhere. And pagination with LIMIT … OFFSET … usually means something else:

To serve page N, the database must scan and discard the previous N × page_size rows.

So with broad filters over a large time range, each successive page becomes more expensive than the previous one.

At the REST layer, everything looked clean.

Underneath, it was probably:

REST
→ controller
→ SQL with COUNT(*)
→ LIMIT/OFFSET
→ large scans and discarded rows

So instead of fetching everything broadly, I changed the access pattern.

Fetch day by day:

Smaller slices.
Better index selectivity.
Much smaller offsets.
Less discarded work.

Result: roughly a 10× speedup.

No access to their database.
No vendor escalation.
No architectural rewrite.

Just switching layers mentally, adjusting the shape of the query, and moving back up.

Why This Matters

Most of our daily work lives at high levels of abstraction: frameworks, APIs, cloud services.

And that’s good — that’s where productivity lives.

But performance issues, strange behavior, and cost explosions rarely originate at the same layer where they surface.

The engineers who consistently deliver under pressure are usually the ones who can descend a few layers, reason about what’s actually happening, and then come back with a pragmatic fix.

Not because they love low-level code.

But because they’re not confined to a single abstraction.

And this becomes even more important as more code is generated for us and more infrastructure is abstracted away. When AI writes the boilerplate and platforms hide the machinery, the differentiator isn’t how quickly you can produce code — it’s how well you understand what happens underneath it.

That ability to move across layers becomes rarer.

And that skill compounds.

Rediscovering Unix Pipelines: Two Backup Problems, One mindset

Sergey Dobrov — Mon, 08 Dec 2025 11:31:08 +0000

Modern engineers often reach for JSON parsing, temporary files, or orchestration tools. Unix pipelines still outperform them more often than you'd expect. Two recent backup tasks reminded me how often we over-engineer simple data-movement problems.

Two backup problems, same pattern: both reached for complex solutions involving temporary files, JSON parsing, and extra dependencies. Both could be solved with simple pipelines.

Problem 1: Pruning Old Backups

I needed to keep the latest seven backups in object storage and delete everything older.

First instinct: treat it like an application problem.

mc ls --recursive --json bucket/ \
  | jq -r '. | "\(.lastModified) \(.key)"' \
  | sort \
  | … # extract keys, build array, loop, delete

Parse JSON, build arrays, extract timestamps, loop through objects.

But backups already encode timestamps in filenames. mc find already prints one file per line. sort already orders strings. head already drops lines.

The whole task collapses:

mc find bucket/ --name "backup-*.gz" \
  | sort \
  | head -n -7 \
  | while read -r file; do mc rm "$file"; done

No JSON. No arrays. No parsing. Just text flowing through composable tools.

Problem 2: Creating Backups

A teammate needed to dump PostgreSQL, compress it, and upload to object storage.

His approach (roughly):

First, upload a script to the server:

scp backup.sh db-server:/tmp/

Then run it:

ssh db-server /tmp/backup.sh

The script itself:

#!/bin/bash
pg_dump mydb > /tmp/backup.sql
gzip /tmp/backup.sql
mc cp /tmp/backup.sql.gz s3://bucket/backup-$(date +%Y%m%d).sql.gz
rm /tmp/backup.sql.gz

This requires:

Uploading the script first
Installing mc on the database server
Managing temporary files
Cleanup logic
Disk space for both uncompressed and compressed data

Each of these steps adds friction, state, and failure modes.
But none of them are actually required:

ssh db-server "pg_dump mydb | gzip" \
  | mc pipe s3://bucket/backup-$(date +%Y%m%d).sql.gz

From two commands plus a bash script to one line. From five requirements to zero.

Bonus: Free Parallelism

That backup pipeline runs three processes simultaneously: pg_dump generating data, gzip compressing it, mc uploading it. No threading code. No coordination.

The temporary-file version? Strictly sequential. Each step waits for the previous to finish.

Pipes give you streaming parallelism by default.

Need more? xargs and GNU parallel scale across cores:

# Compress 100 files with 4 workers
find . -name "*.log" | xargs -P 4 -I {} gzip {}

Same pipeline thinking, multiplied across CPUs.

When NOT to Use Pipes

Pipelines aren't always the answer:

Complex state management - multiple passes over data, tracking relationships
Explicit error handling - pipelines can fail silently
Extreme scale - terabytes need Spark/Hadoop
Bash quirkiness - arcane quoting, clunky error handling
Framework requirements - ETL tools gain orchestration but lose composability
Team familiarity - if pipelines are cryptic to your team, write Python

Unix pipes work best for glue code: moving data between systems, transforming formats, filtering streams.

The Pattern to Look For

Whenever you find yourself:

Loading data into arrays
Writing temporary files
Parsing structured data just to transform it
Installing tools on systems just to move data

…there's probably a pipeline waiting to be discovered.

Not because pipelines are "better." Because they're simpler. Simple solutions are easier to debug, modify, and maintain.

Conclusion

Fifty years later, Unix pipelines still win through elimination.

They eliminate temporary state. They eliminate dependencies. They eliminate the complexity of treating data movement as a programming exercise.

Your turn: What's a problem you recently solved with a pipeline instead of code? Or where you wrote code when a pipeline would have worked?

You don't understand GIL

Sergey Dobrov — Thu, 27 Nov 2025 16:14:07 +0000

Some time ago I was chatting with a friend about programming languages, and the conversation drifted — inevitably — to why Python is “bad.”

The first argument was that Python has “no types,” which makes it error-prone.
I pushed back: Python’s modern type system is surprisingly expressive, and meanwhile Java manages to produce endless null-pointer exceptions despite all its ceremony. That point didn’t land well.

So the next argument came out:

“Anyway, Python can’t even use more than one CPU core because of the GIL.”

I didn’t try to debate it.
Instead, I opened a terminal, ran a data-processing script I had lying around, and showed them top.

One Python process was using exactly 300% CPU. They did not believe it.

And that moment captures something important: the GIL is one of the most confidently misunderstood ideas in all of programming.

Why the GIL Seems Simple but Isn’t

What makes this even trickier is that the GIL actually exists to make Python simple.
It lets most of the runtime behave like a friendly, high-level environment where you never have to think about memory management, object lifetimes, or thread safety inside the interpreter.

But concurrency is where that abstraction finally hits its boundary.
The GIL doesn’t behave the same way in every situation — it takes different forms under different workloads.

That’s why so many explanations are technically correct yet still misleading.

So let’s peel it back one layer at a time.

Layer 1: “Threads Are Useless in Python”

A common starting point is the idea that Python threads are “useless” because of the GIL.

If that were true, CPython wouldn’t bother with real OS threads — it could have simulated concurrency with simple user-level green threads.

But CPython uses real pthreads for a reason: threads matter in Python.

Layer 2: “Threads Only Help for I/O”

A slightly more sophisticated version of this is:

“Threads are only useful when something blocks on I/O. Otherwise the GIL stops everything.”

This sounds reasonable — but it’s still not right.

And we already saw that in the very beginning: our Python process was happily using 300% CPU, with no I/O involved at all.

So clearly something else is going on.

Layer 3: “Threads Help for I/O or Native Code — So Problem Solved?”

Once people realize threads aren’t limited to I/O, they usually expand the model:

“Okay, fine — if a thread is blocked on I/O or running C code, another thread can run. That’s the whole story.”

Closer, but still not exactly. Because here’s another catch:

Not all C libraries release the GIL. Some explicitly request it.

And when they do, the interpreter goes right back to single-threaded behavior, even though no Python code is executing.

This is why you can see one native operation scale beautifully across cores, while another operation — also written in C — completely freezes out every other thread in the process.

Layer 4: Why Some C Libraries Must Hold the GIL

So, the “I/O or C computation frees another thread” intuition is still incomplete.
It depends entirely on what the C library is doing under the hood... and whether it needs exclusive access to Python objects or interpreter state.

Every Python object — even something as small as an int or a bytes object — carries a reference count that tracks how many places are using it.
Incrementing and decrementing these counts must happen one at a time.
If two threads updated them independently, you’d get leaked objects, prematurely freed objects, or corrupted memory.

But refcounts are only the beginning.

Any C code that:

creates or destroys Python objects
mutates a Python object (appending to a list, updating a dict, modifying a set)
raises exceptions
calls back into Python code

…relies on parts of the interpreter that assume exclusive access.

And the only way to guarantee that is to hold the GIL.

This is why one C extension can run happily across multiple cores while another — also written in C — blocks every thread in the process.
It depends entirely on whether that extension needs to interact with Python objects or whether it can work on its own data structures without consulting the interpreter.

Layer 5: Why “Just Use Multiprocessing” Is an Oversimplification

When people get frustrated with the GIL, the next instinct is usually: “Okay, forget threads. Just use multiprocessing.”

On paper it sounds perfect — each process has its own GIL, so you get true parallelism, and sometimes that is the right approach.

But as a general rule, it’s still an oversimplification.

Multiprocessing has real costs:

Most data still has to be serialized to move between processes (Shared memory only works for a limited set of data types)
Even with copy-on-write on Unix, large Python objects often end up duplicated anyway — refcount updates alone are enough to break CoW
Starting a process has much higher overhead than starting a thread (a new interpreter instance, new memory space, new OS structures — not just a new stack)
Context switching between processes is heavier for the OS than between threads
Coordinating state is harder when it can’t be freely shared

So yes — multiprocessing sidesteps the GIL for CPU-bound Python bytecode.
But it brings fully separate runtimes, higher startup costs, heavier context switches, and more complicated data sharing.

How to Tell Whether a C Library Releases the GIL

At this point a natural question comes up:

“So how do I know whether a C library actually releases the GIL?”

Unfortunately, you can’t always tell from the outside — two libraries that look identical in Python can have completely different GIL behavior.
But there are a few practical ways to reason about it.

1. If a C extension touches Python objects, it must hold the GIL — but only for those parts
This doesn’t mean it needs the GIL for the entire function.
A well-written C extension typically does this:

Acquire GIL
Inspect or convert Python inputs (refcounts, type checks, copies, etc.)
Release GIL
Run the heavy native computation
Reacquire GIL
Build Python output objects
Return

So:

touching Python objects → requires the GIL
heavy inner computation → often does not

This is why you can see “C code + threads” giving real multi-core speedups despite Python objects being involved at the boundaries.

Some of the standard library’s own C extensions follow this pattern.
For example, zlib, bz2, and hashlib all parse Python arguments and allocate Python objects while holding the GIL, then drop the GIL around the inner compression or hashing loop, and reacquire it only to wrap up the result.

2. Pure native computation usually releases the GIL cleanly
Libraries like:

zlib / bz2 / lzma
hashing
crypto
NumPy (when you do array1 + array2, NumPy releases the GIL around the actual arithmetic loop. But when you do something like array.tolist(), it can't because it's creating Python objects)
many image codecs

operate on raw buffers or on their own internal data structures.
They typically wrap the expensive part with:

Py_BEGIN_ALLOW_THREADS
    /* heavy computation */
Py_END_ALLOW_THREADS

This is how you get things like “Python using 300% CPU” from a single process.

3. Some native libraries can’t release the GIL much — because their core work is Python interaction

Examples:

regex engines working on Python string objects (standard re module doesn't release GIL)
Python-level parsing loops (e.g. json)
libraries that mutate lists or dicts internally (e.g. py-radix)
things that allocate many intermediate Python objects (e.g. csv, json)

These must hold the GIL almost the whole time.

4. Docs might mention it — but inconsistently

Some libraries explicitly say “this releases the GIL,” but many don’t. (e.g. NumPy, SciPy)

If documentation does say it, you can trust it.
If it doesn’t—no conclusion can be drawn.

5. You can measure it
A simple test:

run the operation in many threads
watch CPU usage in top or htop

If you see a single core saturated → it's likely holding the GIL
If you see multiple cores fully used → it's releasing the GIL
If you see partial scaling → it's partial GIL release (very common)

With Big Power Comes Big Responsibility

Releasing the GIL — or running code that doesn’t use it — doesn’t magically make concurrency “safe.” It just gives you more freedom and more ways to shoot yourself in the foot.

If two threads start modifying the same NumPy array, or the same shared buffer, or the same Python object through a C extension, nothing protects you anymore. You can get classic race conditions, torn writes, and inconsistent data just like in any other multithreaded language.

The GIL wasn’t only a limitation — it was also a guardrail.
Once it’s out of the way, you have to be just as careful as you would be in C++ or Java.

Conclusion

The GIL has sharp edges and real limitations — but it also hides a lot of complexity and keeps Python usable without turning every piece of code into a concurrency puzzle.

Once you understand the layers behind it, the whole picture becomes much clearer:

threads aren’t “useless,”
I/O isn’t the whole story,
native code can run in parallel,
native code sometimes can’t,
and “just use multiprocessing” solves one problem while introducing several others.

In practice, Python can make excellent use of multiple cores — it just depends on what kind of work you’re doing and which libraries you’re using.

I’d love to hear your own experiences:

times when multiprocessing was total overkill,
or when a single Python process maxed out all your cores
or situations where threads surprised you (for better or worse)

Leave a comment, share a story, or correct me if I got something wrong — the whole point of this post is to make the conversation around the GIL more honest and less magical.

tl;dr

Your workload is:
├─ Pure Python computation → multiprocessing
├─ I/O bound (network, disk) → threading or asyncio
├─ Calling C libraries
│  ├─ Don't know if GIL-safe → measure with top/htop or check docs
│  ├─ Releases GIL → threading is fine
│  └─ Requests GIL → multiprocessing or asyncio
└─ Many small tasks → consider overhead cost