DEV Community: Den

The Scariest Word in a Codebase Is "Temporary"

Den — Sun, 01 Nov 2026 05:31:54 +0000

It's Halloween, which means the internet is full of horror stories. Developers have their own kind. Ask anyone about the scariest thing they've found in a codebase and nobody mentions a clever exploit or a race condition that took a week to catch. They mention something small, quiet, and old. Something that's still there.

Here are five of those. None of them is a bug. All of them are scarier than most bugs.

1. "Temporary"

The single scariest word you can grep for.

Every long-lived codebase has a fix that was supposed to last a week. It has a comment saying so — // TEMPORARY, remove after the migration — dated four years ago. The migration finished. The fix stayed. By now three other features depend on its exact behavior, including the part where it's wrong, and removing it is a project nobody will approve because "it works, don't touch it."

The people who wrote the software that failed at Y2K weren't careless. They wrote temporary code in the 1960s and 70s — who would still be running this in thirty years? — and the code outlived the question. Temporary code doesn't ask permission to become permanent. It just waits.

2. The silent default

A bug screams. A default whispers.

The scary configuration isn't the one that's set wrong — that one shows up in testing, eventually. It's the one nobody set at all, because the default quietly did something reasonable on the developer's machine and something else in production. Debug mode that defaults to on. A retry count that defaults to forever. A timeout that defaults to "no timeout," which is a way of saying the timeout is your uptime.

You can't grep for a missing line. That's what makes it frightening: the reviewer's eye slides over the thing that isn't there.

3. The comment that lies

No comment is a gap. A wrong comment is a trap.

// returns null if the user has no subscriptions — and it doesn't, not since the refactor two years ago, but the comment survived because comments don't fail CI. Every developer who reads it writes code against a function that doesn't exist anymore. The comment isn't documentation; it's disinformation with good formatting.

I've started treating every comment I read as an unverified claim. It's a sad way to read code, and it has saved me more than once.

4. The test that always passes

A test suite with zero failures feels like safety. Sometimes it's a costume.

There are tests that assert the mock returns what the mock was told to return. Tests wrapped in a try/except that swallows the failure. Tests that were disabled "for the release" — there's that word again — and never came back. The suite is green, the badge is green, and the confidence is fictional.

Bugs are honest: they break things. A hollow test does something meaner — it teaches you to stop looking.

5. The script only one person understands

Somewhere in the deploy pipeline there is a file — it's usually a shell script, it's always named something like final_deploy_v2_REAL.sh — that exactly one person can read. It works. Nobody knows why. It parses a log with awk in a way that depends on the locale, and it has survived three attempts to replace it because every attempt found one more thing it quietly does.

This isn't a knowledge problem. It's a horizon problem: the day that person is on vacation and the script breaks, the whole company gets a very educational afternoon.

The pattern

Look at the five and a pattern shows up: none of them is scary because of what it does. They're scary because of what they hide. A bug is a visible monster — you can point at it, assign it, fix it, close it. These are the opposite. They look like stability. The temporary fix works, the default behaves, the comment reads well, the suite is green, the script runs.

Until the one night they don't — and it's never an afternoon, is it.

So, since it's the season: what's the scariest thing you've found in a codebase? The older and quieter, the better. I have a feeling the comment section can do better than my five.

Microsoft Offered a Quarter of Its Staff a Way Out. That's Not the Same as a Layoff

Den — Tue, 27 Oct 2026 08:23:45 +0000

The headline going around is "Microsoft lays off 60,000". That's not what happened, and the difference matters if you work in tech — at Microsoft or anywhere that tends to copy Microsoft.

What happened on Monday, October 26: Microsoft offered a voluntary exit package to roughly 60,000 employees. Nobody was fired. Some of those people will choose to leave; most won't. And the company said, in the same breath, that this doesn't rule out layoffs.

Here's what's in the offer, what it tells you, and what I think it means.

What was actually offered

According to the reports, the offer went out in an internal memo from Chief People Officer Amy Coleman. The main points:

Who: about 60,000 people — roughly a quarter of Microsoft's 223,000 full-time employees — in the US, Canada, the UK and India.
Which levels: level 70 and below on participating teams. That reaches up to general managers and some vice presidents, but not corporate vice presidents.
Which teams: business units decide whether they take part. Sales and some engineering groups are reported to be out.
No filters on the person: no minimum age, no minimum tenure, and performance isn't a factor.
The package: pay based on tenure and level, continued stock vesting, health coverage for a fixed period, and career-transition services.
Timing: a decision by the first week of December, departures by the end of the year.

This is the second round in a year. In the spring Microsoft ran its first-ever voluntary retirement program for long-serving US employees — reportedly around 8,750 people were eligible and about 30% accepted. The new offer is far broader and reportedly less generous — no extended health coverage this time — and Microsoft is said to expect fewer people to take it.

The background: around 15,000 layoffs in 2025, about 4,800 cuts in July 2026, more in September. And the stated reason for the restructuring: committing tens of billions of dollars to AI infrastructure.

The line that matters most is the company's own: voluntary departures will not replace involuntary reductions when business conditions warrant them.

Voluntary exit vs. layoff: what's different

If you've only been through layoffs, a buyout looks like a softer version of the same thing. It's a different mechanism with different consequences.

Who chooses. In a layoff, the company picks names. In a buyout, the employee decides. That sounds kinder, and it is — but it also means the company doesn't control who leaves.

Who actually leaves. People with good outside options are the ones most likely to take the money: strong engineers who can get hired in a month, people near a natural career change. A buyout tends to remove some of the people the company least wanted to lose. Companies know this, which is why they restrict eligibility by team and level — the exclusion list is the company protecting what it can't afford to lose.

What it signals. A broad voluntary offer, from a company that also says layoffs remain possible, is usually a first step, not the whole plan. The voluntary round shows how many people leave on their own; whatever gap remains can be closed the other way.

Paperwork and optics. Layoffs come with legal notice requirements in many places and with headlines. Voluntary exits are, on both fronts, quieter. "We offered generous packages" reads very differently from "we cut a quarter of the company".

What developers can read from it

Look at who's excluded. Sales and some engineering groups are reportedly not part of the offer. That's where the company is placing its bets — and, by contrast, which work it considers easier to shrink.

The middle is in scope. Eligibility goes up to general managers and some VPs. This isn't only about junior roles or one struggling division; layers of management are part of it.

The market is about to get crowded. If even a modest share of 60,000 people take the package, a lot of experienced engineers and managers will be job-hunting in January at the same time. If you're planning a move in early 2027, you'll be competing with them.

If you get an offer like this anywhere, here are the questions worth answering before the deadline. This isn't advice on whether to take it — that depends on your finances and options, which only you know:

Exactly which stock keeps vesting, and until when? What happens to unvested grants?
How long does health coverage last, and what happens after?
What do you sign? Release of claims, non-compete or non-solicit clauses, rehire restrictions?
How does the timing interact with bonuses, refreshers and taxes?
What happens if you don't take it and a layoff follows — is the layoff package better or worse?

My take

This part is opinion.

The common reading is "AI is replacing engineers". I don't think that's what this is. Nothing in the offer says AI does these people's work now. What it says is that the budget is moving: money that was salaries becomes data centers and GPUs. That's a capital-allocation decision, not a productivity miracle — and it would happen even if the AI tools never got good enough to do anyone's job.

The voluntary format is genuinely better for the people involved than a surprise list: they choose, they get time, they get a package. But it's also good for the company in ways that are easy to miss — it's quieter, it shifts the decision onto employees, and it tests how far headcount can fall before anyone has to be fired. The sentence about layoffs remaining possible isn't a footnote. It's the frame for everything else.

And the scale is the real story. A quarter of a company's workforce being told "the door is open" is not routine trimming. When the biggest software employers start treating headcount as the line to cut so they can buy compute, it changes what job security means for everyone who writes code — not overnight, but steadily.

Microsoft reports quarterly results this week. I'd expect the AI spending numbers to say more about this offer than the memo did.

I keep up with stories like this through RealFeedApp, a free science and tech digest with plain-words explainers.

Sources: Calcalist, The Deep Dive, CTV News / AFP.

Two More Languages Should Have Been Cheap. My Estimate Was Off by a Lot

Den — Tue, 27 Oct 2026 08:20:28 +0000

RealFeedApp writes a short summary and a plain-words explainer for every science and tech story it picks up. A language model does the writing, on our own server, not through someone else's API. Until this week it wrote in two languages.

On Monday I added German and Portuguese. I had done the arithmetic first. I had a measurement of how busy the model was, I had a per-language cost, and the sum said: a noticeable increase, comfortably within capacity.

By the evening the monitoring sent a message I hadn't seen in weeks: the worker isn't keeping up, a story has been waiting too long for its summary. A measurement over the hours since the release said the model was now busy almost all the time — several times the load I had estimated.

Nothing was broken. The estimate was. Here is how it was wrong, and what I changed.

The estimate counted the wrong thing

My mental model of the cost was: one call writes all the languages, so a new language costs whatever its share of the answer costs. Two more languages, a somewhat longer answer. Proportional, predictable.

That model was true before the change and false after it. Writing four languages in one answer had failed earlier quality tests — the answer grew, languages leaked into each other — so the new languages went into a separate call: the base pair in one request, the new pair in another, with the finished English headline passed along as a reference.

A separate call doesn't cost "the extra output". It costs reading the whole article again, plus the instructions, plus the output. I had priced the new languages as a few more lines of text. In reality each story got one more full trip through the model.

And explainers got the same treatment, in the same shape: a second call per story.

The lesson isn't "separate calls are expensive". They were the right call for quality. The lesson is that the cost model has to change when the call structure changes, and mine silently didn't.

Counting calls told me the wrong story too

The obvious first move was to look at what the model was doing: count calls by type. Explainers had doubled, summaries had grown — and explainers are the longest texts the system writes. Dropping the new languages from explainers looked like the cheap fix.

Then I measured seconds instead of calls. The worker logs each step before it starts, and each model call logs its duration, so a few lines of awk can attribute every second of model time to the step it belonged to:

journalctl -u my-worker --since '-6h' -o cat | awk '
  /worker: enriching/  {t="enrich"}
  /worker: explaining/ {t="explain"}
  match($0, /model .*: [0-9]+ s/) {
    split(substr($0, RSTART, RLENGTH), a, " "); s[t] += a[3]; n[t]++
  }
  END { for (k in s) printf "%s: %d calls, %.0f s\n", k, n[k], s[k] }'

Explainers turned out to be a small slice of the model's time. Almost all of it went to the summary step. The long texts were rare; the step that ran for every single story dominated. Cutting explainers would have saved almost nothing and made the product worse.

Count the resource you're short of. I was short of model-seconds, not of calls.

Why a small queue raised the alarm

The other surprise was the shape of the problem. The queue wasn't long. A handful of stories were waiting. But the oldest one had been waiting since roughly the release.

The worker always takes the highest-ranked stories first. That's what you want when there's spare capacity: the important news gets summarized first. When there's no spare capacity, it means the stories at the bottom never get a turn — fresher, higher-ranked ones keep arriving and jumping ahead.

That's why the alert watches the age of the oldest waiting item, not the length of the queue. A queue that stays short while its oldest member gets older is exactly what running at full capacity with a priority order looks like. Queue length would have stayed green all evening.

Two languages or one?

The options were: drop both new languages from generation, add hardware, or find something in between.

The in-between: keep German, drop Portuguese. But the pair was one call. Removing half of it wouldn't remove the call — it would only shorten the answer, while the expensive part, reading the article, stays.

So the question was empirical: how much cheaper is a call with one language than a call with two? And does one language on its own keep its quality? An earlier test had shown that a single-language call drifted into the language of the instructions — but those instructions were in Russian. The new calls used English instructions.

I ran the same comparison the earlier decision was based on: the same set of articles, the same prompts and sampling, the pair against German alone. German alone came out roughly a third cheaper per call, with no detectable quality loss: no wrong script, no drift into English, nothing cut off. (Checking for drift into English needed its own check — German and English use the same alphabet, so the usual script test can't see it. Counting common function words did.)

Portuguese came out of generation. German stayed.

Don't break the experiment you're running

There was a tempting further cut: stop generating German too, translate it lazily only for people who pick it in the menu, and add it back when there's demand.

The catch: the demand for a new language on a news site mostly comes from search, and search needs pages in that language to exist. Day pages and article pages are only built for languages that have finished translations. Remove generation, and the German pages disappear, and nobody arrives looking for German, and the demand test reads zero. The cut would have guaranteed its own justification.

So the menu now offers exactly the languages that are generated. A language in the menu either works fully or isn't there.

What I'd do before the next language

Price the call structure, not the output. If the change adds a call, the cost is a full call — input included.
Measure in the unit you're short of. Seconds of model time per step, not call counts.
Watch the oldest item, not the queue length. With priorities, saturation looks like a short queue that ages.
Test the cheaper variant instead of assuming it's half price. One language out of two wasn't half the cost; it wasn't the full cost either.
Check that a cost cut doesn't sabotage the metric you'll judge it by.

And the obvious one, the one the estimate was supposed to replace: run the change for an hour and measure before calling it done. The arithmetic was fine. It was arithmetic about a system that no longer existed.

Animating a Logo You Only Have as a PNG

Den — Tue, 27 Oct 2026 08:13:30 +0000

The RealFeedApp logo is a newspaper inside an atom: two green orbits around a blue page, two little green balls on one of the orbits. It begs to move. The balls should run along their orbit, the page should stay put, and when a ball goes behind the page, it should disappear behind it.

There was one problem. The logo exists as a single PNG — the app icon. No SVG, no layers, no design file. Somewhere a designer once drew it; what I had was 1254×1254 pixels.

This is how I got it moving, first in short vertical videos rendered with Pillow, then on the website as an animated SVG. Most of the work was undoing things I assumed about the picture.

Attempt one: split by colour, spin the green

The cheap idea: the page is blue, the orbits are green, so split the image by colour and rotate the green layer.

a = np.asarray(icon).astype(np.int16)
r, g, b, alpha = a[..., 0], a[..., 1], a[..., 2], a[..., 3]
green = (g > b + 15) & (g > r + 40) & (alpha > 128)

One catch: the page has a little green square on it — the "photo" in the newspaper. It's green too, so it would fly off with the orbits. The logo is a fixed asset, so I just cut that rectangle out of the mask by position. Not elegant; correct forever, because the logo doesn't change.

Rotating the green layer works and looks fine. It also wasn't what I wanted: the whole atom spins like a fan. Real electrons don't drag their orbit around with them. The orbits should stand still and only the balls should move.

Attempt two: erase the balls, patch the gaps

So: erase the two balls from the picture, draw new ones that move.

Finding the balls is a morphology trick. They're much thicker than the orbit lines, so an erosion — Pillow's MinFilter — wipes out the lines and leaves the balls.

It also leaves the places where the two orbits cross. At a crossing the line is twice as thick, and erosion can't tell that apart from a ball. My first mask erased two balls and two crossings, and Pillow's MaxFilter (which I used to grow the mask back) is a square kernel, so it erased them as big squares. The result looked like someone had taken a hole punch to the logo.

The fix for detection: the balls are the two largest connected blobs after erosion. A tiny breadth-first flood fill over the mask, sort by size, take two. Erase each with a proper circle, not a square.

The fix for appearance didn't exist. In the original drawing each ball has a thin dark gap around it, where the orbit stops short of the ball. Erase the ball and you get a ball-shaped hole with an orbit that ends on both sides. I tried drawing short arcs over the gaps; they came out torn and slightly off the line.

Lesson: once you're patching a raster, you've lost. Redraw the part you need to animate.

Fitting the orbits from pixels

Redrawing an orbit means knowing its ellipse: centre, two semi-axes, tilt. I didn't have those numbers, but I had the pixels, and pixels can vote.

Scoring a candidate ellipse is simple: sample points along it and count how many land on green (on a slightly dilated mask, so a one-pixel miss still counts). Then brute-force a grid of candidates:

def score(cx, cy, A, B, ang):
    u = np.linspace(0, 2 * np.pi, 240, endpoint=False)
    x = cx + A * np.cos(u) * np.cos(ang) - B * np.sin(u) * np.sin(ang)
    y = cy + A * np.cos(u) * np.sin(ang) + B * np.sin(u) * np.cos(ang)
    return mask[y.astype(int), x.astype(int)].mean()

On a 400-pixel copy of the icon, a coarse grid of a few hundred thousand candidates takes a minute or two. The best score is one orbit. The best score with a clearly different tilt is the other. Neither scores 100% — parts of both orbits are hidden behind the page — and that's fine, because the score only has to rank.

I drew both fitted ellipses in red over the original and they sat on the green lines. Both balls sat on the steep orbit, exactly opposite each other. That told me the motion: two balls, one orbit, half a turn apart.

The page was transparent

With orbits redrawn as vectors and the original page pasted on top, the first render showed the orbits through the page.

I had assumed the dark page fill was opaque. It isn't: it's a light blue at about a quarter opacity, which reads as dark navy on a dark background. And the soft glow around the icon is the same colour at the same opacity. Anything I drew "behind" the page simply showed through it.

In the original, the orbit isn't behind the page at all — it's just not drawn there. So "behind" has to mean "cut out by the page's silhouette".

The silhouette is where I lost the most time, because my first two ideas both failed silently.

Flood fill from outside. Take the solid blue outline, flood-fill from a corner, and whatever didn't fill is inside. It filled nothing. On an image that came straight out of Image.fromarray(), ImageDraw.floodfill returned without complaint and changed no pixels; calling .copy() first made it work. I didn't dig into why — I just stopped trusting fills on images built from arrays. The working fill revealed the second problem: the outline isn't closed. At the bottom, the flat orbit passes in front of the page and covers the outline completely. The fill leaked inside through the gap.

Close the gaps first. Dilate the outline, fill, erode back. Better, but the bottom gap is as wide as an orbit is thick, and closing it took so much dilation that the corners rounded off.

Convex hull. The page is two overlapping rounded rectangles — a convex-ish shape. Take every solid blue pixel, compute the convex hull, fill the polygon. Andrew's monotone chain is twenty lines and needs no libraries. The hull hugs the page within a pixel or two, and gaps in the outline don't matter, because a hull doesn't care what's between its points.

def hull(points):
    points = sorted(set(points))
    def turn(o, a, b):
        return (a[0] - o[0]) * (b[1] - o[1]) - (a[1] - o[1]) * (b[0] - o[0])
    lower, upper = [], []
    for p in points:
        while len(lower) >= 2 and turn(lower[-2], lower[-1], p) <= 0:
            lower.pop()
        lower.append(p)
    for p in reversed(points):
        while len(upper) >= 2 and turn(upper[-2], upper[-1], p) <= 0:
            upper.pop()
        upper.append(p)
    return lower[:-1] + upper[:-1]

Everything behind the page is now multiplied by "outside the hull". The glow outside the hull went too; on a pink background it had looked like a smudge.

In front or behind?

One more question per point of each orbit: does it pass in front of the page or behind it? The original picture already knows. Walk the fitted ellipse degree by degree; where the point is inside the page's silhouette and the original has green there, the orbit is in front. Inside the silhouette without green, it's behind. Outside the silhouette, it doesn't matter.

That gives two layers: the back segments of both orbits (masked by the hull), drawn under the page, and the front segments, drawn over it. A ball uses the same per-degree flag to decide which side of the page it's on. The flat orbit crosses in front of the page at the bottom, exactly as in the original; the balls vanish behind the page and come out the other side.

One small Pillow note: ImageDraw.ellipse doesn't anti-alias. Draw the balls at 3× and downscale, and the edges stop being jagged.

On the web: the same geometry as SVG

For the site header I didn't want a video or a GIF. The same script that extracts the layers now also writes an SVG:

the page is an embedded PNG (it's semi-transparent with fine detail — there's no honest way to vectorise it);
both orbits are <ellipse> elements with the fitted parameters;
the balls are two <circle>s moving along the steep orbit with <animateMotion> and <mpath>, the second one started half a period earlier with a negative begin;
a <mask> built from the hull polygon hides everything behind the page;
the front segments of the orbits go on top as a path.

No JavaScript runs the animation. The only JavaScript is a click handler: the SVG element has pauseAnimations() and unpauseAnimations(), so clicking the logo pauses the balls and clicking again resumes them. If the system asks for reduced motion, it starts paused.

Because the SVG is generated from the same code as the video frames, the logo in the header and the logo in the Shorts can't drift apart.

What I'd tell myself at the start

Look at the alpha channel before you plan anything. "The page is dark" was a guess based on how it looked on a dark background. It was transparent.
Don't patch a raster you want to animate. Redraw the moving parts; keep only the static parts as pixels.
Pixels can vote for geometry. A brute-force fit with a dumb score beats eyeballing coordinates, and it's reproducible.
Erosion finds thick things, including the thick things you didn't mean. Filter by connected-component size.
When a fill fails silently, try it on a .copy(). Then check that the outline is actually closed.

The balls go round every eight seconds in the header of realfeedapp.com. Click the logo if they bother you.

Sub-circuits by flattening: path ids, pins by position, and the bug I found while writing this

Den — Thu, 22 Oct 2026 02:52:32 +0000

In the roadmap post
I asked whether sub-circuits should be flattened before simulation or evaluated
recursively, and I leaned towards flattening. I have now built it, so here is how it
works and what I would warn you about.

Boolflow is a free browser logic simulator. A block is a
circuit you drew, given a name, that you can place again as one element with its own
pins. The expansion code is flatten.js (108 lines, comments included) and the
library and editing logic is blockLibrary.js (172). Both are plain JavaScript with
no React, so everything below was run under bare node.

The idea: the simulator never learns that hierarchy exists

A block is an ordinary node with one extra field: its own definition.

{ id: 'u1', data: { type: 'SUB', name: 'HA', def: { nodes, edges }, inputs: ['A','B'], outputs: ['S','C'] } }

Before a circuit is simulated, every block is replaced by a copy of its definition,
each id rewritten to block/inner. The simulator receives one flat circuit. It is
just longer.

The ids are the point. Simulation state, such as a flip-flop's stored bit, is keyed
by node id. If I had pasted a definition's nodes in unchanged, two copies of a block
containing a flip-flop would have shared that one flip-flop. With path-style ids they
cannot. Two half adders placed side by side become:

p, q, u1/a, u1/b, u1/x, u1/and, u1/s, u1/c, u2/a, u2/b, u2/x, u2/and, u2/s, u2/c

Blocks nest, and the path spells the nesting out (t/p/inv, t/q/inv), which is
what a test asserts. A bonus I did not plan: the same paths give meaningful signal
names on the waveform panel for free. Two blocks named DIV2 containing a flip-flop
labelled D show up as DIV2/D.Q and DIV2#2/D.Q. The #2 is added when a twin
appears at the same level.

I have not measured the memory cost of flattening, and I will not pretend to. A
teaching circuit is hundreds of nodes. If you build a CPU out of blocks, measure it.

Pins are elements, and order comes from position

What are a block's pins? The INPUT and OUTPUT elements inside its definition.
Inside the expansion they stay as plain buffers, which is exactly where the outside
wires attach.

The question I had not thought about: which pin is pin 0? A circuit file stores
nodes in an arbitrary order, and there is no pin-ordering UI. So pins are sorted by
where they sit on the canvas: top to bottom, then left to right. The order on the
block mirrors the order on the sheet it was drawn on. A test lists B before A in
the file, draws A above B, and expects [A, B].

Names come from the element's label, and an unnamed pin is called in_0, out_0
and so on. (That is one reason naming a switch or a lamp matters, and why I added a
way to do it in the editor. It had not been possible.)

Wires that cross a block's edge are rewritten while flattening. A wire into pin i
lands on the inner element that takes input i; a wire out of pin j leaves from
the inner element that drives output j. A wire to a pin that the definition no
longer has is skipped, not an error.

After simulating, one more step: the flat circuit knows nothing about the block as a
node, so the block's own output values are copied back from the elements that drive
them, which is how the pins on the canvas show a value.

for (const [id, drivers] of flat.blocks) {
  drivers.forEach((flatId, j) => { vals[`${id}:out-${j}`] = vals[`${flatId}:out-0`] ?? null; });
}

The same expansion runs in front of the Verilog, VHDL and C++ exporters, the test
runner and the waveform. None of them needed to know what a block is.

What a block may not contain

makeBlock turns a layer into a block, or says why it cannot:

A layer with no logic, or no OUTPUT: refused.
A CLOCK inside: refused. Only the editor's own timer flips a clock, and it knows nothing about what is inside a block. Feed the clock in through an input pin.
Notes, frames, VIAs and net labels are left out, and the dialog says how many ("3 notes, frames, VIAs and net labels are left out"), because they are decoration and cross-layer plumbing, not logic.

Because the definition is embedded in the block, and the block is embedded in the
circuit file, a saved circuit is self-contained: a block placed ten times is still
one definition, and it travels with the file. The library of your own blocks is kept
in localStorage under boolflow-blocks. A recursion cannot happen by construction
(a definition is embedded, not referenced), but a hand-made file could nest
absurdly deep, so expansion stops at depth 16.

Editing a block after placing it: the hard half

Placing is easy. The part that took the design time is: you edit the definition,
and every copy has to follow without breaking the wires you already drew.

All copies share a blockId. When the definition changes, every copy gets the new
definition and new pin lists, and each existing wire is remapped. The key rule is
that a wire follows its pin by name, not by index. If wires followed the index,
inserting an input at the top would silently shift every wire to its neighbour.

This is the real function run on a half adder (A, B → S, C), wired from S to one
lamp and from C to another:

Edit to the definition	Outputs afterwards	What happens to the wires
Rename `S` to `SUM`	`SUM, C`	stay put
Drag `C` above `S`	`C, S`	both follow their pin: `S` is now `out-1`, `C` is `out-0`
Add output `CO` at the top	`CO, S, C`	`S` moves to `out-1`, `C` to `out-2`
Delete `C`	`S`	the wire to `C` is dropped, and counted
Rename both	`SUM, CARRY`	both stay put

The rename row is the awkward one. A name that has vanished, with as many names
appearing, is read as a rename: the wire stays on the same pin. Otherwise the pin was
removed and its wire goes with it.

I should be straight about that last part. The function counts the wires it moved
and the wires it dropped, and the tests check both numbers. The editor currently
throws the counts away, so a wire to a deleted pin disappears without a word. That
is a gap in the UI, not a design choice, and it is next on my list.

The bug I found by writing the table

I had one more row in my head: rename and reorder in a single edit. Rename S to
SUM and drag C above it, then apply.

My first implementation answered a vanished name by keeping the same index. The
outputs became C, SUM; the wire that used to leave S (index 0) stayed on index 0,
which is now C. Both lamps ended up reading the C pin:

u1:out-0 -> os      (was S, now reads C)
u1:out-0 -> oc      (C, correct)

No error, no warning, the circuit just lies. All the existing tests passed, because
none of them combined the two edits.

The fix is the obvious one once you see it: pair the names that vanished with the
names that appeared in order, wherever they now sit, instead of by index.

const lost  = oldNames.map((nm, i) => (newNames.includes(nm) ? -1 : i)).filter(i => i >= 0);
const fresh = newNames.map((nm, j) => (oldNames.includes(nm) ? -1 : j)).filter(j => j >= 0);
return lost.length === fresh.length ? fresh[lost.indexOf(oldIndex)] : -1;

Now S becomes SUM at index 1 and C stays at index 0. Three new checks cover it,
and the case where you rename both outputs at once.

One ambiguity I cannot remove: if you delete one pin and add another in the same
edit, that is indistinguishable from a rename, and I treat it as one. The wire moves
to the new pin. If that is not what you meant, the wire is wrong in a way you will
see on the canvas rather than in a log.

What I would warn you about

Editing a block nested inside another block is only possible through the outer one. You open the outer definition and edit from there.
Bus contention inside a block is not detected. Two drivers fighting over one wire are checked for on the sheet, not inside a definition.
Dropped wires are silent when you edit a block (see above).
The exporters are still combinational only, blocks or no blocks. Flip-flops are skipped and flagged.
No clocks inside. Described above.
Sharing is not done. The block library is per browser, and the definition travels inside a circuit file, but there is no "share this block" link.

Questions

If you shipped hierarchy, did you flatten, or evaluate recursively? What did it cost you?
How does your editor decide which pin is which when the user has no ordering UI? Position-based was my answer. I am not sure it is a good one.
For the rename-or-delete-and-add ambiguity: would you ask the user, or pick one and tell them? I pick and tell them.

The half adder and the divide-by-4 counter built from two copies of one DIV2 block
are in the examples at boolflow.site.

1,400 PRs and 800k Lines Deleted: How OpenAI Cleans Up Its Code with Agents (and What You Should Steal)

Den — Tue, 20 Oct 2026 11:30:22 +0000

This is a retelling with commentary. The original is Rodrigo Roim's post on the OpenAI Developers blog, October 14, 2026: Maintaining software with the GPT-6 family. Everything under "My take" is my own analysis, not the author's position.

TL;DR

Five engineers on OpenAI's Core Experimentation team, working part-time over two weeks, merged 1,400+ PRs and deleted 800k+ lines of code that GPT-6 Astra found and prepared for removal via Codex.
In a separate pass, the agent found hundreds of stale experiments and feature flags, including one "permanent" flag that was burning ~0.42% CPU in the main service.
The cheaper GPT-6.1 Sol at Ultra effort produced 92% of Astra's findings at 14% of the cost.
CI got roughly twice as fast: median from ~10 to 4.5 minutes, p90 from 12.5 to 6 minutes.
For context: Anthropic's recent Claude Opus 5.5 makes the same bet on long, codebase-wide tasks and tells the same cost story ("beats the competitor's flagship at a fifth of the cost"). I break down what can and can't be compared.
The main message of the post isn't "agents will do everything" — it's "start small, review, scale up, and feed review feedback into the next prompt."

Context: agents sped up development — and tech debt too

Here's a paradox people rarely talk about: when code gets written faster, junk accumulates faster too. Unused functions, long-finished A/B tests, flaky tests. Roim's team builds OpenAI's internal experimentation platform — everything from frontend to model-serving optimizations — so they have a lot of flags and experiments.

The post covers three maintenance scenarios and a cost comparison between models.

1. Removing dead code

The old way. The classic approach is heavy static analysis plus runtime logging. The author admits that even with that and careful reviews, there were incidents caused by mistakenly deleted code. Reflection breaks static analysis, and a "dead" branch might turn out to be an emergency switch for some future incident.

The intermediate step (GPT-5.6 Sol). The model was given a specific area and clear validation criteria — and it wrote the static analysis and removed the code itself. These targeted prompts turned out to be easier to maintain than the homegrown analysis system, with comparable reliability.

With GPT-6 Astra, the team tested whether the model could handle a vague request. The prompt was literally a sentence or two (typos included): "find and clean up dead code; feel free to check Slack, Statsig, or any other source to confirm it's really unused."

What the model did:

dug through PR history;
pulled context from Slack threads and internal trackers;
checked production profiling tables to confirm the deleted lines were never executed;
attached a rationale to every deletion — which sped up reviews dramatically.

Result: 1,400+ PRs, 800k+ lines deleted. Reviews were distributed to the teams owning the relevant code. Tangible wins: one service's container image shrank from 3.31 GB to 1.72 GB (−48%), and about 400 visual snapshot variants disappeared from the test suite.

2. Stale experiments — the harder problem

A stale experiment isn't the same as dead code. It may still run in production, and its eligibility conditions could theoretically change at any moment. Static analysis is nearly useless here. The team previously used deterministic scripts with database queries and knew they were missing many genuinely stale experiments (false negatives).

The author's approach is interesting in itself: he didn't know where to start, so he asked the model to write the prompt for him. The result was a short instruction along these lines:

find substantial dead code tied to constant or abandoned Statsig gates/configs in two specific projects;
check against the live configuration, git history, and overlapping PRs;
preserve production behavior, safeguards, and killswitch flags;
ignore SDK fallbacks and local overrides;
one small draft PR per cleanup, with a link to the flag's console page.

Then came the loop: the author comments on the PRs → asks the model to incorporate the comments → asks it to write a prompt to scan the entire repository, plus help with prioritization (he was worried about drowning in findings).

The final "big" prompt (using the /goal command) required the agent to:

audit all Statsig projects and inventories, not just the ones labeled stale;
look for indirect usages: enums, constants, wrappers, aliases, schemas, dynamically assembled names, consumers in other services;
factor in the CPU cost of each check based on production telemetry;
produce a markdown report split into parallel workstreams by owner and file, with evidence and costs;
not touch live configurations or services.

Result: the top of the report was dominated by big efficiency wins — experiments nobody had considered stale for years. After manual verification, hundreds of experiments and flags were removed.

The most telling story

Years ago, someone created a flag that let internal developers override all other new-feature flags — for testing. It was implemented as a single line of Python mapping that flag to every feature, buried among hundreds of similar lines. Inconspicuous.

Astra figured out that this line caused a serious CPU fan-out, estimated the cost — but didn't delete it on its own. It escalated to a human reviewer: the flag was marked "Permanent" in the console and could have had an operational purpose. After review, the flag was removed: estimated savings of ~0.42% CPU in the main affected service.

3. Cost: GPT-6 Astra vs. GPT-6.1 Sol

The author ran the same stale-experiment prompt on subdirectories of one repository — 6,000+ files, ~1M lines of Python, TypeScript, Go, and Rust — and manually validated the findings.

Model / effort	API cost	Accepted findings	Cost per finding
GPT-6 Astra, Ultra	$109.06	142	$0.77
GPT-6.1 Sol, Ultra	$15.12	131	$0.12
GPT-6.1 Sol, Medium	$5.27	86	$0.06

The cost includes research subagents and automatic follow-up turns by Codex.

The main discrepancy between the models at Ultra: Sol missed constant flags used as dependencies of other flags, while Astra caught them. The author's takeaway: such error patterns can be compensated with prompting to get close to the expensive model's results with the cheap one. But new model releases can make those "crutches" obsolete, so prompts need revisiting.

4. Three more ideas from the post

The author suggests starting these on GPT-6.1 Sol Medium and raising effort if results look promising.

Flaky tests. Scan recent CI runs, find unstable tests, try a fix for each, and open a PR if it works. Key caveat in the prompt: the goal is obvious fixes for simple problems, not exhaustively fixing everything.
Cleaning up AGENTS.md. Find an instruction in recent sessions that misled the agent, then A/B test it: replay the original prompt on the same repo snapshot with and without that instruction, comparing quality, tool calls, tokens, runtime, and cost. Essentially an eval for your own context file.
Reducing CI load. Ask for a table of ideas to cut CI load, ranked by estimated CI minutes saved per day based on run history.

The third idea led to about 30 optimization PRs: median CI from ~10 to 4.5 minutes, p90 from 12.5 to 6. One standalone fix — adding a missing mock — cut a 63-test suite from 592.6 to 29.8 seconds (−95%, all tests kept).

For comparison: what Anthropic claims about Claude Opus 5.5

To avoid seeing the topic through a single vendor's eyes, it's worth putting a competitor's recent release side by side. On September 22, 2026 — about three weeks before the OpenAI post — Anthropic released Claude Opus 5.5. The positioning is very similar: long agentic tasks across the whole codebase, migrations, audits, reviews — with an emphasis on cost.

What in the announcement relates to code maintenance

Auditing and fixing a 200k-line codebase took one early tester under three hours. The previous Opus 5 needed more than 20 hours and 2.5× the tokens for the same job.
A 680k-line migration — in under a day. Anthropic estimates it would have taken an engineering team weeks.
Optimization without behavior changes. Asked to cut load times across every page of a web app, Opus 5.5 succeeded 39 times out of 40, while Opus 5 made smaller improvements that also altered the app's behavior. For maintenance work, this is arguably the most important metric in the entire announcement.
Rewriting HAProxy from C to Rust in an internal test: both models (Opus 5.5 and the pricier Fable 5.1) passed nearly all of the project's regression tests, but Opus 5.5 finished in 9.5 hours versus 12 and cost 51% less.
Code review: according to Deloitte, even at its lowest effort the model caught 72% of known bugs versus 56% for Opus 5 at high effort — with fewer false alarms.
Orchestration: a Stripe engineer describes a multi-day rebase of 40 stacked PRs where one session directed a dozen others, and all 40 PRs passed CI the next day.

Numbers that can be lined up against the OpenAI post

	Claude Opus 5.5	GPT-6 Astra
Terminal-Bench 4.0 (best result)	66.4%	57.9%
FrontierCode v1.1 — "would this code be merged"	54.4% (max)	53.3%
Price, $ per 1M tokens input / output	4 / 20	—
Cache reads, $ per 1M tokens	0.20	—

According to Anthropic, at default effort (medium) Opus 5.5 beats Astra's top FrontierCode score at roughly a fifth of the cost per task, and matches Astra on Terminal-Bench at about 40% of the cost. Astra's figures in the table are those published by OpenAI, not Anthropic's own measurements.

On safety, Anthropic says the model is much less likely to take hard-to-reverse actions or step outside its given boundaries, and in a new containment test it attempted to circumvent boundaries about 85% less often than Opus 5. The company is also candid that the model often suspects it's being evaluated, which limits confidence in how it will behave in real-world settings.

What this comparison tells us

1. Both companies tell the same cost story. OpenAI: "GPT-6.1 Sol delivers 92% of Astra's results at 14% of the price." Anthropic: "at medium effort we beat the competitor's flagship at a fifth of the cost" — and Factory, quoted in the announcement, says this is the first model they'd default to at medium. The race has shifted from peak scores to cost per useful result. That's good news for us: "cheap mode by default, expensive mode surgically" is now advice from both vendors.

2. A direct comparison isn't valid — and that matters. OpenAI has an internal case study with real findings validated by hand. Anthropic has benchmarks and quotes from early testers the vendor picked itself. Neither is an independent evaluation. Competitor numbers in the tables are taken "as reported by the other side," with different harnesses and effort settings. Anthropic itself admits in the announcement that at this capability level, benchmark margins increasingly fail to reflect real-world differences.

3. Read the footnotes. A small but telling example: the announcement's table lists 54.4% for Opus 5.5 on FrontierCode (the max-effort result), while the text below says 54.6% at medium. So medium comes out slightly higher than max. That may well be noise or different runs, but these are exactly the kinds of discrepancies worth noticing before drawing conclusions.

4. Anthropic names the metrics missing from the OpenAI post. "Improved without changing behavior" (39 of 40) and "fewer false alarms in review" are exactly what I argue below: for maintenance work, false-positive rate and behavior preservation matter more than the number of PRs opened. It's a shame neither vendor publishes these metrics systematically.

How to compare models on your own code

Since vendor numbers can't be taken at face value, the only honest benchmark is your repository. A mini-protocol you can run in a day:

Pin a snapshot of the repo (a commit) and one prompt — e.g., finding stale flags in a single directory.
Run it on 2–4 configurations: different models and effort levels.
For each run, count accepted findings, rejected findings (false positives), review time, and API cost.
Analyze the discrepancies, as the OpenAI author did: which classes of findings does the cheap configuration miss — and can a prompt close the gap?
Save the snapshot, prompt, and list of reference findings — that's your eval for the next model release.

The key number isn't "cost per finding" but cost per accepted finding, including reviewer time.

My take: what's impressive in these numbers, and what to read with caution

The numbers check out

I recalculated: 131/142 ≈ 92%, $15.12/$109.06 ≈ 13.9% — the claimed "92% of findings at 14% of the cost" is honest. Median CI −55%, p90 −52%, image −48%. No arithmetic sleight of hand.

But it's a vendor case study — and that matters

The post is written by the company that sells these models. That doesn't make it false, but the sample is successful scenarios inside OpenAI, in an ideal environment for an agent: telemetry, profilers, access to Slack and the flag console, unlimited model access.
No false-positive rate. We know how many findings were accepted, but not how many were rejected or how much time it took to triage them. "Cost per finding" in the table only counts API spend, not reviewer hours. For 1,400 PRs, human time is almost certainly worth more than $109.
A single validator. In the model comparison, findings were checked by the author himself. That's fine for a blog post, but it's not a benchmark.
Lines of code are a vanity metric. 800k lines / 1,400 PRs ≈ 570 lines per PR on average. Impressive, but the real value shows in other numbers: image size, CPU, CI time. Good on the author for including them.
The author admits that some proposals added more complexity than they were worth — prioritization and measurement stayed with humans.

Why deleting code is the ideal task for an agent

I don't think it's a coincidence that the loudest agent success story is not a new feature but deletion. The task has a rare combination of properties:

Verifying is easier than doing. Finding dead code in a million lines is slow and boring. Confirming that a specific deletion is safe, when evidence is attached (zero calls in the profiler, flag at 100% for two years, a thread saying "experiment closed"), takes a couple of minutes. Agents are strongest where verification is cheaper than generation.
Bounded damage. A deletion goes through tests and review and is easy to roll back with git revert. Compare that with a new feature, where the mistake may be in the idea itself.
Measurable outcome. Megabytes of image, percent of CPU, minutes of CI. You can calculate whether it paid off.
It's work people put off for years. Nobody finds it interesting and it doesn't get anyone promoted. That's why the biggest "free" wins pile up here.

The practical takeaway: if you're looking for where to first deploy an agent on your team, code maintenance is a better candidate than generating new code.

The bottleneck shifts from finding to reviewing

Rough math. Say a PR review takes 10 minutes on average (realistic with evidence attached; longer without). 1,400 PRs × 10 minutes ≈ 230 person-hours. That's more than a month of one engineer's work. The API cost is a rounding error by comparison.

That changes the whole economics:

The scarce resource is reviewer attention, not tokens. Optimize the PR format: short diff, clear rationale, links to evidence, nothing extra.
Without a code ownership map, this doesn't scale. OpenAI routed reviews to owning teams. If you don't have an up-to-date CODEOWNERS or equivalent, 1,400 PRs will sit in a queue.
A prioritized report matters more than PRs. The author was right to ask the agent for a report with estimated benefits first. An agent that opens 500 unranked PRs shifts work onto people rather than removing it.

Marginal cost per finding: the most interesting part of the table

The post compares average cost per finding. But for deciding "which model to use," the marginal cost matters more: how much each additional finding costs when moving to a more expensive configuration.

Upgrade	+Findings	+Cost	Cost per extra finding
Sol Medium → Sol Ultra	+45	+$9.85	≈ $0.22
Sol Ultra → Astra Ultra	+11	+$93.94	≈ $8.54

The marginal cost per finding jumps roughly 40×. A classic diminishing-returns curve.

But there's a nuance that's easy to miss. Those 11 findings only Astra caught are constant flags acting as dependencies of other flags. These are the most tangled cases, and possibly the most valuable. So the right question isn't "which model is cheaper" but "what does a finding the cheap model misses cost me?" For tech debt, usually not much — so Sol Ultra looks like a sensible default. For a security audit, the answer might be different.

The working strategy that follows: a bulk pass with the cheap model, and the expensive one applied surgically to the known blind spots you discovered by comparing results.

An agent doesn't replace static analysis — it complements it

The agentic approach is powerful because it can connect unstructured sources: Slack, PR history, trackers, telemetry. A deterministic analyzer will never do that. But the agent has a flip side: non-determinism. Two runs of the same prompt can produce different lists of findings. That's fine for a one-off cleanup, not for guarantees.

I think the most viable setup is hybrid:

The agent discovers a class of problems and proves specific instances.
The discovered pattern is turned into a deterministic check: a lint rule, a CI job, a script. The agent can write it too — as happened with GPT-5.6 Sol in the post.
The check keeps the problem from coming back, while the agent goes hunting for new classes.

That way, knowledge gained through an expensive non-deterministic process gets locked into a cheap deterministic one.

Prompts are code — and they rot too

One offhand remark by the author is, in my view, underrated: prompt tweaks that compensate for a model's weaknesses become obsolete with the next release. That means:

prompts for recurring tasks should be stored in the repository and versioned, like code;
they need evals: a fixed repo snapshot plus a set of known correct findings. Otherwise, when you switch models, you won't know whether things got better or worse;
the post's idea of A/B testing AGENTS.md instructions is exactly such an eval in miniature. It deserves to become a regular practice, not a one-off experiment.

Without telemetry, the agent is guessing

Notice what Astra relied on for its strongest findings: production profiles, CPU per flag check, CI run history. Without that data, the agent could only say "looks unused" — the same thing static analysis says, just more expensively.

A non-obvious consequence: investing in observability becomes a prerequisite for agentic code maintenance. If you don't have production profiling and per-flag metrics, start there. Otherwise you'll have an agent working blindfolded.

Chesterton's fence, agent edition

There's an old principle: don't take down a fence until you understand why it was put up. The "Permanent" flag story is a textbook example: the agent found an expensive line, calculated its cost, but stopped when it saw signs of intent and handed the decision to a human.

That behavior wasn't accidental: the prompt set it up ("preserve killswitches and safeguards"). The practical takeaway: escalation criteria should be spelled out as carefully as deletion criteria. The agent needs to know not only what to look for, but which signals mean stop: "permanent" or "do not remove" labels, mentions in postmortems, links to incidents, code in disaster-recovery paths.

And one more thing the post doesn't mention: deleted code and closed experiments are part of institutional memory. A dead branch is sometimes the only place showing how the system used to work. The answer isn't to avoid deletion but to write good PR descriptions. An agent that writes a rationale for every deletion is also building an archive where, a year later, you can find out "where did X go."

A loop worth thinking about

The post opens by admitting that agents sped up development, which increased the maintenance load. And it ends with agents doing the maintenance too. That's a loop: agents produce code faster than humans can absorb it, and agents clean that code up.

That isn't necessarily bad, but it changes the engineer's role: less writing, more setting constraints, checking evidence, and making decisions. The good news: those skills always separated seniors from juniors. The bad news: juniors will have a harder time gaining experience on the routine work agents now take over. How teams will grow people in this environment is a question the industry doesn't have an answer to yet.

What actually transfers (even if you don't have GPT-6)

The most valuable part of the post isn't the models but the patterns for working with an agent. They apply to any coding agent:

Demand evidence, not just a diff. Every deletion comes with a rationale and links (PR, thread, metric). That's what makes 1,400 PRs reviewable.
Explicitly list what must not be touched. Killswitches, emergency branches, "Permanent" flags. The 0.42% CPU flag story is the perfect example: the agent found the problem but escalated instead of deleting.
Small draft PRs, not one mega-commit. Easier to review, easier to roll back, easier to route to owners.
Meta-prompting. Asking the model to write the prompt for the next pass, with review feedback baked in, is a cheap and effective way to iteratively improve instructions.
Start with the cheap model on a small scope. Compare configurations on one task — Medium may well be enough.
Report → prioritization → parallel workstreams. An agent that writes a report with estimated benefits first is more useful than one that immediately opens 500 PRs.

On safety — what the post says too little about

"Don't touch live configs" in a prompt is a wish, not a guarantee. If the agent has write access to the flag system, sooner or later it will use it in a way you didn't expect. Practical conclusions:

give the agent read-only access to Slack, trackers, the flag console, and telemetry;
keep merging and config changes in the hands of humans and CI;
remember that Slack threads and tickets are untrusted input: an agent that reads everything is vulnerable to instructions hidden in that text.

How not to let your flags get to this point

An agent cleaning up flags that piled up for years is the cure. Prevention is cheaper:

every flag has an owner and an expiration date;
experiment flags and operational killswitches are different types, with different lifecycle rules;
a recurring (even monthly) agent task: "find flags that have been at 100% or 0% for 30+ days and prepare a report" — exactly what the post describes, but in small, regular doses.

Wrap-up

OpenAI's post isn't about "agents will replace engineers" — it's about code maintenance turning into a loop: the agent finds and proves → a human decides → feedback improves the next prompt. The strongest point is about cost: a 7× price difference between models for 92% of the result means that for routine tech debt, an expensive flagship may simply be overkill. The Claude Opus 5.5 announcement points the same way — and that convergence is more telling than any single vendor's benchmarks.

Want to try it? Take one flaky test or one stale flag and ask an agent to find it, prove it, and open a small draft PR. If it works, expand to a directory. Then to the repository.

Are you already letting agents clean up tech debt? What's your PR acceptance rate? Share in the comments 👇

Sources:

Maintaining software with the GPT-6 family, OpenAI Developers Blog, Oct 14, 2026
Introducing Claude Opus 5.5, Anthropic, Sep 22, 2026

Why AND(0, ?) is 0: three values, snapshots and memory in a logic simulator

Den — Sun, 18 Oct 2026 22:33:31 +0000

In my last post
I planned a feature, and executing it turned up a bug: the simulator could not
hold a bit with two gates. The first circuit in every digital logic course, an SR
latch from two cross-coupled NOR gates, read ? for every combination of inputs.

The short version of that story fits in a paragraph. This post is the long one:
what actually had to change inside the simulator core, in the order it had to
change, with the traces I used to convince myself each step was necessary. If you are building
anything that evaluates a circuit (a logic simulator, a spreadsheet engine, a
reactive graph), some of this will transfer.

Boolflow is a free browser logic simulator. The engine is
plain JavaScript with no React in it, so every number below comes from running
it under bare node.

Three values, and who gets to use them

A wire is 0, 1 or null, where null means "unknown". The original gates were
strict: if any input is unknown, the output is unknown.

That is wrong in exactly the case that matters. AND(0, ?) is 0 whatever the
question mark turns out to be. A controlling value decides a gate on its own:

const and = vs => (vs.includes(0) ? 0 : vs.every(v => v === 1) ? 1 : null);
const or  = vs => (vs.includes(1) ? 1 : vs.every(v => v === 0) ? 0 : null);
const inv = v  => (v === null ? null : v ? 0 : 1);

NAND and NOR are inv(and(...)) and inv(or(...)), so they inherit it.

Not every gate has a controlling value, and the code reflects that. XOR has none:
XOR(?, x) is unknown for either x, so XOR stays strict. NOT is strict because
inverting an unknown is an unknown.

One honest consequence: everything else is also still strict, and strict is
pessimistic. A MUX with an unknown select returns ? even when both data inputs
are 1, where real hardware gives 1. Adders, decoders and comparators do the
same. I only taught the AND/OR family, because that is the family that can resolve
a loop. I have not been bitten by the rest, but it is a real gap, not a design
decision.

Rounds, not sweeps

Here is the circuit. Two NOR gates, each fed by the other's output:

Q  = NOR(R, ~Q)
~Q = NOR(S, Q)

Start with both outputs unknown and set S = 1. Evaluate ~Q first and you get
NOR(1, ?), which is 0 by the controlling value. Now Q sees NOR(0, 0) and
becomes 1. The pair resolved out of nothing.

Notice what I just did: I picked an order. That is the second bug the latch
exposed. My relaxation loop evaluated gates in place, in whatever order the nodes
happen to sit in the file, so each gate saw its neighbour's new value immediately.
For a circuit with no loops that is harmless, because it converges to the same
answer whatever the order. With a loop, the order of the file decides the answer.

Here is the dangerous input to show it. Hold S = R = 1 (both outputs go low), then
release both at once. I replicated the rule in a 15-line toy, since the engine does
not print its rounds. Evaluating in place:

order Q, ~Q:   round 1  Q=1 ~Q=0   round 2  Q=1 ~Q=0   → stable, Q=1
order ~Q, Q:   round 1  Q=0 ~Q=1   round 2  Q=0 ~Q=1   → stable, Q=0

Two different stable answers, picked by which node I happened to list first.
Hardware does not work like that: both gates see the same old values and update
together. So a round now evaluates every gate against a snapshot of the previous
round's values, then applies all the results at once (a Jacobi iteration, if you
want the name):

snapshot:      round 1  Q=1 ~Q=1   round 2  Q=0 ~Q=0   round 3  Q=1 ~Q=1 …

Both gates flip every round, forever. That is what a real SR latch does when you
release both inputs of the forbidden state at the same instant: nothing in the
circuit says which gate wins, and I would rather show that than invent a winner.

The loop is small (relax in simulateComb.js, 26 lines):

const round = nodes => {
  const before = { ...vals };
  readFrom.v = before;           // gates read the snapshot…
  evaluate(nodes);               // …and write into vals
  readFrom.v = vals;
  return Object.keys(vals).filter(k => vals[k] !== before[k]);
};

What it buys is a test that reverses the node list and demands identical answers
for a six-step set / hold / reset / hold / set sequence.

How do you know it will never settle?

A circuit without loops needs as many rounds as its longest path. So the budget is
generous and simple:

const iters = Math.max(combNodes.length * 2, 10);

Still changing after that: the wires that changed in the last round are
oscillating. I do not leave them at whatever value the last round happened to
write, because that would look like a result. Every output of the gates involved
is set to unknown, and the rest of the circuit gets another go at settling around
them. The simulate() result is flagged, and
the editor shows a warning in the status bar.

This is the real engine on the latch, one row per tick:

S=0 R=0  Q=? Qb=?             power-up: nothing has set it
S=1 R=0  Q=1 Qb=0             set
S=0 R=0  Q=1 Qb=0             hold
S=0 R=1  Q=0 Qb=1             reset
S=0 R=0  Q=0 Qb=1             hold
S=1 R=1  Q=0 Qb=0             the forbidden input
S=0 R=0  Q=? Qb=?  UNSETTLED  both released at once
S=1 R=0  Q=1 Qb=0             a normal set recovers it

A small note on the editor: you cannot reach the oscillating row with two
switches, because releasing two switches is two clicks, which is two ticks. You
reach it by wiring one switch to both S and R. I got that wrong in an article
first and had to correct it.

Memory lives in the wires

Look at the "hold" rows. For the latch to hold Q = 1 after S drops to 0, the
tick that sees S = 0 has to start from Q = 1, ~Q = 0. Every call to
simulate() used to start from a blank wire map, so there was nothing to hold. A
latch keeps its bit in its own outputs.

So the values of the combinational wires now carry over from tick to tick, split in
two the same way flip-flop state already was:

let wiresCommitted = new Map();   // what the last tick settled on
let wiresWorking   = new Map();   // what this tick is computing

beginTick() promotes working to committed. Here is the same sequence with the
memory wiped before every tick:

S=0 R=0  Q=? Qb=?
S=1 R=0  Q=1 Qb=0
S=0 R=0  Q=? Qb=?      ← the bit is gone as soon as S is released
S=0 R=1  Q=0 Qb=1
S=0 R=0  Q=? Qb=?

The set and reset still work, because the controlling input is present. Releasing
it forgets. That is the difference between a gate that reacts and a gate that
stores.

Why two maps instead of one? The reason is the one flip-flop state already had, and
the comment above it in the code says it better than I would: simulate() runs
more than once per tick, because a layer is re-simulated once the values coming
through VIAs from other layers are known. With one map advanced in place, the
first of those runs consumed the clock edge while its inputs were still
unresolved, so a flip-flop fed through a VIA latched a stale value and the edge was
spent by the time the real value arrived. Reading every run from the same
start-of-tick baseline makes them recompute the same transition with progressively
better inputs. Wires needed the same treatment for the same reason.

For circuits without loops, stale starting values change nothing, since they settle
to the same answer from anywhere. A test runs different input pairs back to back
through an XOR and an AND and checks every answer.

Time: delta cycles for the stateful elements

Flip-flops, counters and registers are not gates, and they have the opposite
problem. A toggle flip-flop is D = NOT Q: its input depends on its own output.
Evaluated in a single sweep, that reads ?.

So a tick is not one sweep but a sequence of delta cycles, borrowed from how HDL
simulators work:

Every element's output pins start out showing its previous state, so feedback reads real values.
All elements are evaluated against the same snapshot and updated together. A shift register must not see its neighbour's new value.
The combinational logic settles on the new outputs (the rounds from above).
Repeat while anything changed.

A ripple counter's second stage sees its clock edge one delta later than the first.
An asynchronous reset takes effect in the delta after the counter reached the
decoded value.

Two details earned their place by failing.

First sight of a clock. A flip-flop meeting its clock for the first time has not
seen it change, so it must not fire. Without that, a stage clocked from a Q-bar
output (idle high) takes a spurious edge at power-up.

The cap. There has to be a ceiling or an oscillating circuit hangs the tab:
MAX_DELTAS = 32. I tested what that means, since a comment in the code said "a
ripple counter needs one per stage". A chain of N toggle flip-flops, each clocked
by the previous one's Q, with one rising edge at the front:

stages	high after the edge tick	one tick later
4	4	4
32	32	32
33	32	33
40	32	40

Beyond 32 stages the ripple does not complete in the tick that caused it. It
finishes on the next tick, because the remaining stages still see an unconsumed
rising edge. Nobody draws a 33-stage ripple counter in a teaching tool, but the
behaviour is a direct consequence of the cap, so I would rather list it.

What it still does not model

Zero delay. Every gate answers instantly, so there are no glitches and no hazards, and the waveform is an idealisation. The panel says so.
One kind of "not a number". null means unknown and high-impedance (a tri-state buffer with its enable off returns null). Verilog separates x and z; VHDL's std_logic has nine values. Merging them kept the code small, and I suspect it will eventually bite someone with a bus.
The pessimistic gates above: MUX, adders, decoders.
Real latch physics. A real SR latch released from the forbidden state ends up in a random state, or in metastability. The simulator says ? and flags it. I think that is the honest answer, but it is a modelling choice.

The tests

test-latches.mjs has 29 checks: NOR and NAND latches, a gated D latch from four
NAND gates and an inverter, and a master-slave D flip-flop from two of those, with
the output required not to follow D while the clock is high. Each one used to read
? for every input.

If the engine were a library I would have written these first. It was not, I did
not, and it took the first circuit of any digital logic course to find the gap.

Questions

Would you split unknown from high-impedance now, or wait until a bus forces it?
Is Jacobi (snapshot) rounds the right model for a teaching tool, or is a proper event queue with delays worth the complexity?
If you have built an evaluator with feedback, what was your oscillation policy: a cap, a visited-state set, or refusing loops?

Everything above is live at boolflow.site, with the SR
latch and the master-slave flip-flop in the examples.

I built my own roadmap. The first thing it found was that my SR latch didn't work.

Den — Fri, 16 Oct 2026 20:26:10 +0000

Two posts ago I compared my logic simulator to nine others
and listed three honest gaps. In the
next one
I opened the code and discovered that the three gaps were really five items in a
dependency graph, two of them invisible: make time explicit, then waveforms and
step mode; make node identity hierarchical, then sub-circuits; and test cases that
can handle a clock once time exists.

That was the plan. This post is about what happened when I executed it, which is a
different thing, because the plan was drawn by someone who had not yet tried to
build a flip-flop out of two gates.

Boolflow is a browser digital-logic simulator, free, no
account. Everything below is live.

The scoreboard

In the roadmap post	What shipped
Explicit tick counter + history	Done, but a "tick" turned out to mean something other than I wrote
Step mode + waveform panel	Done
Hierarchical node ids by flattening	Done
Sub-circuits	Done, including editing a block after you placed it
Test cases (sequential half)	Done: a `C` in a column is a clock pulse
"The clock frequency bug"	Fixed, and it was worse than I said
"Tell the user it didn't settle"	Done, in a form I did not expect
Share link	Not done
Truth table to circuit	Not done
iframe embed	Decided against
Buses	Still untouched, as promised

The table is the boring part. The interesting part is everything in it that
needed a footnote.

"Tick" does not mean what I said

I wrote that I needed a monotonically increasing integer owned by the simulator,
and a ring buffer recording the value map at each tick. Both are in. But I
recorded a frame on every evaluation, then watched a waveform fill up with
identical columns while I dragged a gate across the canvas. Moving a node
re-simulates the circuit. Nothing observable changes. Time should not advance.

So a tick is now an event: a frame is stored only when a watched signal
differs from the previous frame. Drag a node, nothing. Flip a clock, a frame.
Throw a switch while the clock is paused, a frame. The panel says so in one line
under its title (each column is one change in the circuit, not a fixed time
step), because a waveform with no propagation delay is an idealisation and I
would rather say it than have someone discover it.

Step mode fell out the way I hoped. Pause stops the timer; Step runs one tick of
the same schedule the timer would have run. With one clock that is a half-period,
which is where I keep wanting to say "one clock edge" and keep being wrong: you
need to evaluate the falling half too, or the flip-flop never sees the clock go low.

The clock bug was a sleeper

In the last post I showed this line:

const freq = allClocks[0]?.data.freq ?? 1;

Every clock ticked at the frequency of whichever clock came first. I called it a
bug nobody had hit. It was better than that. When I went to fix it I found that
there was no way to set a clock's frequency in the UI at all. freq was
stored, loaded, displayed ("1 Hz") and never editable. The bug was unreachable
from the interface and would have bitten the first person who loaded a file with
two different values.

The fix: one timer at the greatest common divisor of all the clocks' flip periods,
each clock flipping on every n-th tick. Two clocks that coincide flip in the
same render instead of one render apart. And since freq now matters, the clock
node got − and + buttons (0.25 to 8).

The latch that wasn't

This is the part I did not see coming.

I planned to add an oscillation warning, because I had read my own relaxation loop
and noticed it never checked convergence. Ten lines, I said. So I wrote a few
probes to see what it would take to make a circuit oscillate, to have something to
test the warning against. A ring of three inverters. A NAND ring with an enable.

They stayed at ?. Every one of them. A ring of inverters never leaves "unknown",
because NOT(unknown) is unknown, so there is nothing to oscillate.

Then, almost as an afterthought, I wired up the first circuit in every digital
logic course: an SR latch from two cross-coupled NOR gates.

Q  = NOR(R, ~Q)
~Q = NOR(S, Q)

Set it. Reset it. Hold it. ?, for every combination of S and R. My simulator
could not do the first memory circuit anyone learns.

Two causes, both mine.

One. Gates were strict about unknowns. This is the AND gate:

case 'AND': s1(a !== null && b !== null ? a & b : null); break;

If either input is unknown, the output is unknown. But AND(0, ?) is 0, whatever
the question mark turns out to be, and NOR(1, ?) is 0. That is the entire
mechanism by which a cross-coupled pair resolves out of nothing: one gate sees a
controlling input and is decided before the other has an opinion.

const and = vs => (vs.includes(0) ? 0 : vs.every(v => v === 1) ? 1 : null);
const or  = vs => (vs.includes(1) ? 1 : vs.every(v => v === 0) ? 0 : null);

Two. Every call to simulate() started from a blank wire map. A latch holds its
bit in its own outputs, so a blank start means it has nothing to hold. The wire
values now carry over from tick to tick, split into "what the last tick settled
on" and "what this tick is computing", the same way I already treated flip-flop
state.

That second fix has a consequence I had to think about: for a circuit with no
loops, starting from stale values changes nothing, because it settles to the same
answer from any starting point. A test runs six different input pairs
in a row through an XOR and an AND and checks every answer.

Gates have to update together

The relaxation loop also evaluated gates in place, in whatever order the nodes
were listed. With a latch, that makes the order of the file decide the answer.
It now relaxes in rounds: every gate reads a snapshot, all of them update, repeat.
A test reverses the node list and expects identical results.

And now the warning can exist

Release both inputs of a NOR latch from S = R = 1 at the same instant and each
gate sees two zeros, wants to output 1, then sees a 1, wants 0, forever. In real
silicon one gate wins by a few picoseconds and nobody knows which; that is
metastability.
In a zero-delay engine the tie never breaks. After twice-the-node-count rounds the
loop is declared oscillating, its wires are shown as ?, and the status bar says
Does not settle.

The humbling footnote: my first draft of the article claimed you could "release both
together" by clicking two switches. I clicked two switches in the real editor and the latch
landed in a perfectly definite state, because two clicks are two ticks. The only
way to get the oscillation is one switch wired to both inputs. I fixed the article.

The save button that forgot

To make sub-circuits I needed named pins. Named pins come from the labels on
INPUT and OUTPUT elements. I looked for where a user types such a label.

There isn't one.

data.label existed. The truth table read it. The test cases read it. The Verilog,
VHDL and C++ exporters read it, and even sanitised it into a legal identifier in
all three languages. My own landing page said signal names come from the labels you
typed on the canvas. The only things that ever set it were the built-in examples.

Then I read the save function:

return {
  id: n.id, type: n.data.type, x: n.position.x, y: n.position.y, value: n.data.value,
  // ...PLM fields
};

Type, position, value. A saved circuit came back without its names, without its
clock speed, without its net-label names, and without its frames at all: a frame
has no data.type, so it was written without a type and could not come back.

The fix is unglamorous. There is now a small name tag under every switch, lamp,
clock, probe and block; you click it and type. And the whole file format moved into
one module with a round-trip test: build a circuit with every kind of node, write it,
read it back, compare. Old files with the lost fields still load.

I am slightly embarrassed that export with your own signal names, a feature I had
been pleased with, was unreachable for anyone who built a circuit by hand.

Sub-circuits: flattening was the right call

I said I would flatten: when you place a block, inline a copy of its nodes into
the parent with every id rewritten to instance/original. The simulator never
learns hierarchy exists.

u1/ff        u2/ff        u1/inner/ff

The engine change was small, and the test that justified the whole exercise is
short. A block containing a toggle flip-flop, placed twice, each copy given its
own clock. Pulse copy A twice and copy B once, and check that A has toggled twice
and B once. Before, both copies would have shared one entry in the state map and
fought over it.

Two things I did not anticipate paid off for free. The path ids make waveform
labels meaningful (DIV2/D.Q, DIV2#2/D.Q) with no extra work. And because a
block is just a circuit, blocks nest, and the exporters, test cases, truth table
and waveform all see through them by calling the same flatten first.

Pins by position, and editing by name

A block's pins are its INPUT and OUTPUT elements, ordered top to bottom as they
sit on the canvas, so the block looks like the drawing it came from.

Editing a placed block was the part I said I would not do, and then did, because a
block you cannot change is a block you redraw. Double-click it and its circuit
opens on the canvas in place of yours; Done writes the change into every copy.

The interesting problem is what to do with the wires. You add a pin at the top and
every other pin's index shifts. If wires followed indices, you would silently
rewire the whole circuit. They follow names: rename a pin and its wire stays;
add a pin and the others move down with their wires; remove one and only its wire
goes. One refinement came from using it: when a name disappears but the number of
pins on that side is unchanged, it is a rename in place, and the wire stays. Renaming
in_0 to CLK is the most common edit there is, and dropping the wire for it would
have been a cruel default.

Tests that can count clock edges

The comparison with Digital had one line I wanted to close: declare inputs and
expected outputs in a table, run, get pass or fail. Mine could only do
combinational rows. Now a C in an input column is a clock pulse: the signal goes
0, 1, 0, and the outputs are checked after it has settled.

CLK | Q0 Q1 Q2 Q3
C   | 1  0  0  0
C   | 0  1  0  0
C   | 1  1  0  0

A table with a C runs top to bottom as one sequence from power-up, and x in an
input column keeps the last value. It runs on a state of its own and puts the
editor's live state back afterwards, so running a table does not stop the counter
you are watching.

I will say what it does not do: setup and hold times. A pulse is an instant. The
article about it says so.

The 404 that only production had

All of the above was checked in a browser. The landing page got a real screenshot
of the editor, and it was broken on the first deploy: alt text, no image.

The backend serves dist/ from an explicit allow-list: /assets, /donate, a few
root files. A new /img folder fell through to the SPA catch-all, which answers
every unknown path with the app shell and a 404. vite dev and vite preview serve
the whole public/ folder, so I never saw it locally. The fix was one mount; the
lesson is that "works in the preview server" and "works behind my own router" are
different statements. (It also turned out the screenshots were being sent as
application/octet-stream; the Python on the server evidently does not know
.webp, so that got a one-line fix too.)

What is still not there

Exporting to Verilog/VHDL/C++ is combinational only. Flip-flops, registers and counters are skipped, and every skipped element is flagged in the output. Tests handle a clock now; the exporters do not.
A block nested inside a block is editable only through the outer one.
Bus contention (two drivers fighting over a wire) is detected at the top level, not inside a block.
No share link and no truth-table-to-circuit synthesis.
The 1 Hz on a clock means one flip per second, so the real frequency is 0.5 Hz. I know. Fixing it would make every demo twice as fast, so it stays until I decide what the label should say.

Answers to my own questions

Last time I asked five questions, so here is what I actually did.

Flattening versus recursive evaluation. Flattening. The memory cost I worried about never showed up at this scale, and the unplanned benefit was readable path names on the waveform.
Idealised waveforms. Kept idealised, and said so on the panel. No fake unit delay.
Step granularity. One tick of the shared timer, which is half a clock period with a single clock. I did not build single-gate stepping.
Two invisible refactors out of five. In hindsight the invisible ones were the ones that exposed the most. Making time explicit led directly to noticing that the latch did not work.
Embeds versus sub-circuits. Sub-circuits. I then decided against the iframe embed entirely.

What I would tell myself before the roadmap post

I wrote a confident dependency graph after reading the simulation entry point and
the state map. That was a good read of two files. It said nothing about the gates,
the save function or the router, and every surprise in this post lived in one of
those.

The numbers, for the record: 282 automated checks across 11 scripts, all passing;
49 articles with a diagram each, in three languages; 32 examples, every one checked
for structure and the sequential ones actually run. The articles I corrected along
the way were checked by running the circuits they describe, which is the habit this
whole stretch taught me.

Boolflow is at boolflow.site: free, no account, nothing
to install. If you teach digital logic or have ever built a latch from NOR gates
and wondered whether a tool would do it, I would like to hear what breaks.

Everyone Types "yes"

Den — Mon, 12 Oct 2026 08:40:03 +0000

The smoke test for my little SSH key program is one command: clone a repository of mine over SSH. On a fresh machine, before anything is cloned, it asks this:

The authenticity of host 'github.com (<IP address>)' can't be established.
ED25519 key fingerprint is SHA256:<key fingerprint>.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

And I typed yes. Like everyone does.

This series has been about two things so far: keeping the passphrase out of ps, and checking whether a tool uses your SSH at all. The second post leaned on one defence — the wall of @@@ OpenSSH throws when a server's key changes. This post is about the uncomfortable part: that wall protects you only if the key it's comparing against was the right one. And that key got there when you typed yes.

Trust on first use

SSH's model has a name: TOFU, trust on first use. The first time you connect, the client has nothing to compare against, so it asks you. Whatever you accept goes into known_hosts, and from then on any change is an alarm.

It's a reasonable design. The weak point is obvious: if someone is between you and the server on that first connection, you accept their key, and from then on the alarm protects the impostor. Everything after the first yes is only as good as the first yes.

Most of the time this is theoretical. Then sometimes it isn't.

March 2023

On March 24, 2023, GitHub replaced its RSA SSH host key. The private half had been briefly exposed in a public repository; anyone who copied it could, in principle, pretend to be github.com to RSA clients.

So every RSA user got the wall: REMOTE HOST IDENTIFICATION HAS CHANGED. Exactly the alarm that's supposed to make you stop and think.

GitHub published the new fingerprint and instructions. But the fix that spread fastest was the short one: ssh-keygen -R github.com, connect again, type yes. Which works — and quietly accepts whatever key answered that next connection, without comparing it to anything. The alarm did its job; the habit undid it.

What "verifying" actually means

The question at the prompt isn't "do you want to connect". It's "does this fingerprint match the one you got some other way". The point is some other way — a channel an attacker on your network path can't also fake.

For the big hosts that channel exists. GitHub, GitLab and Bitbucket publish their host key fingerprints in their documentation, served over HTTPS. Don't take them from this post, by the way — a fingerprint in a blog post is exactly as trustworthy as the blog. Open the provider's docs page.

Then there's a feature I'd used for years without noticing: you can paste the fingerprint instead of typing yes. Note the [fingerprint] in the prompt. Copy the published value, paste it, and OpenSSH compares it for you. A mismatch is refused. No squinting at forty base64 characters.

Already have hosts in known_hosts and want to check them after the fact?

ssh-keygen -l -F github.com

prints the fingerprints of what you stored. Compare with the docs.

`ssh-keyscan` is not verification

In the previous post I used ssh-keyscan to plant a deliberately wrong key — that's what it's good for. It's also widely used for something it can't do: "trusting" a host in scripts and CI.

ssh-keyscan github.com >> ~/.ssh/known_hosts

This downloads the key from whoever answered on port 22. If that's an impostor, you've just written the impostor's key down as trusted, automatically, with no prompt. It's the scripted version of typing yes without reading.

GitHub's own recovery instructions in 2023 did something better: they fetched the keys from the API over HTTPS —

curl -L https://api.github.com/meta | jq -r '.ssh_keys | .[]' | sed -e 's/^/github.com /' >> ~/.ssh/known_hosts

— which moves the trust to TLS, a channel you already rely on. Better still for CI: copy the published known_hosts lines once, check them into the repository, and use that file. A pinned key changes only when you change it.

Two settings worth knowing while you're there:

StrictHostKeyChecking accept-new — accept unknown hosts automatically, but still refuse changed keys. A sane middle ground for automation.
StrictHostKeyChecking no — accept everything, including changed keys. If you find it in a pipeline, that pipeline has no host verification at all.

Closing the series

Three posts, three places the same thing goes wrong — a secret or a trust decision handled in a way that looks fine and isn't:

The passphrase goes through ssh-agent or SSH_ASKPASS, never through argv.
The SSH client is the one you configured — check that your tools read your config, check host keys, and use your agent.
The first host key is compared against a fingerprint from another channel, not accepted with yes or fetched with ssh-keyscan.

None of this needs new software. Everything in this series is already in OpenSSH — the askpass hook, the config, the fingerprint prompt, accept-new. The defaults are good. The weak spot is almost never the protocol; it's the shortcut around it.

As for my smoke test: it now starts by pasting the fingerprint.

Your Git GUI Isn't Using Your SSH

Den — Mon, 12 Oct 2026 08:28:15 +0000

In the previous post I was building a small GUI for creating SSH keys, and the first decision was how to pass a passphrase to ssh-keygen without leaking it. The second decision came right after: should the program talk SSH itself, through a library, or just run the system ssh?

I chose the system binary. Not because the libraries are bad, but because of what I found when I looked at what "use a library" actually means.

"SSH" is two different things

When you type git clone git@github.com:... in a terminal, git runs ssh, the OpenSSH client. That client reads ~/.ssh/config. It checks ~/.ssh/known_hosts. It asks your ssh-agent for keys. It follows ProxyJump through a bastion. All the behaviour you've tuned over years lives there.

Many GUI clients, IDE plugins and deploy tools don't run that binary. They link an SSH library and speak the protocol themselves. The protocol is the same. The behaviour around it is whatever the application's authors wrote.

Take libssh2, one of the common ones. It's a solid library, and it has the building blocks: a known-hosts API, an agent API, even security-key signing. But they're building blocks. Each OpenSSH behaviour you rely on becomes a feature somebody had to remember to implement. And some aren't there at all — the library has no ssh_config parser and no ProxyJump.

The most telling line is in libssh2's own example program. Right after connecting, a comment says to check the host key against your known hosts — "that is your call". The example then prints the fingerprint and carries on.

That's fine for an example. It's a problem when an application ships the same shape.

What can quietly differ

Host key verification. In the terminal, a changed server key stops you with a wall of @@@ and "REMOTE HOST IDENTIFICATION HAS CHANGED". That warning is the whole defence against someone sitting between you and the server. An embedded client might check its own store instead of known_hosts, accept any new key silently, or not check at all.

Your config. Host aliases, IdentityFile, IdentitiesOnly, ProxyJump, algorithm restrictions — if the client doesn't read ~/.ssh/config, none of it applies, and nothing tells you. You hardened something; the tool doesn't know.

Where the passphrase lives. OpenSSH hands that job to ssh-agent: the key is unlocked once, the passphrase isn't stored anywhere. An application with its own stack may offer to "remember" the passphrase — in its own settings, encrypted with who knows what.

Which keys work. Newer key types and hardware keys (ed25519-sk, ecdsa-sk) work in OpenSSH long before every embedded stack catches up.

On Windows there's a bonus version of this: Git for Windows ships its own ssh.exe, separate from the OpenSSH built into Windows. Two clients, two configs in practice, two agents. A key added to one agent is invisible to the other.

Check your own tools

I'm not going to name clients here — versions change, and what I'd write today could be wrong next month. Instead, here's how to find out about the tools you actually use. Each check takes a minute.

1. Does it read ~/.ssh/config? Add an alias:

Host gh-alias
    HostName github.com
    User git

ssh -T gh-alias should greet you. Now clone gh-alias:you/some-repo.git in the GUI. If it fails with "could not resolve host", it isn't reading your config. (ssh -G gh-alias shows exactly what OpenSSH would use, for comparison.)

2. Does it check host keys? This is the important one. Back up your known_hosts, then put a wrong key under github.com's name — GitLab's key will do:

cp ~/.ssh/known_hosts ~/.ssh/known_hosts.bak
ssh-keygen -R github.com
ssh-keyscan -t ed25519 gitlab.com 2>/dev/null | sed 's/^gitlab.com/github.com/' >> ~/.ssh/known_hosts

ssh -T git@github.com must now refuse loudly. Fetch from a GitHub repo in the GUI. If it connects without complaint, it would connect just as happily to an impostor. Restore afterwards:

mv ~/.ssh/known_hosts.bak ~/.ssh/known_hosts

3. Does it use your agent? With a passphrase-protected key, empty the agent with ssh-add -D and fetch in the GUI. If it connects without asking for the passphrase, it has the passphrase stored somewhere. Find out where.

What to do with the answer

If a tool fails these checks, look for a setting before looking for a replacement. Many have an option like "use system SSH" or "use system Git", and plain git lets you choose the client outright with core.sshCommand or GIT_SSH_COMMAND. Tools that simply run your system git are already using your system ssh.

For my own little program that settled it. Running the system ssh means every check above passes by construction — not because I implemented them, but because I didn't have to. It also means one less library to track for security fixes.

The safest SSH code is the SSH code you didn't write. Before trusting a tool with your keys, spend three minutes checking whose SSH it's actually using.

ssh-keygen -N Puts Your Passphrase in ps

Den — Mon, 12 Oct 2026 08:19:46 +0000

I'm writing a small GUI that walks a person through creating an SSH key. The core of it is one call to ssh-keygen, and on paper that call is trivial:

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -N 'correct horse battery staple'

The user types a passphrase into a nice field, the program puts it after -N, the key appears. Most scripts and wrappers I've looked at do exactly this.

It's also the one way of doing it that I ruled out first.

argv is public

Command-line arguments are not a private channel between you and the program you start. On Linux they live in /proc/<pid>/cmdline, and by default that file is readable by every user on the machine. ps just prints it:

$ ps -eo user,args | grep '[s]sh-keygen'
alice  ssh-keygen -t ed25519 -f /home/alice/.ssh/id_ed25519 -N correct horse battery staple

"But it only runs for a moment." A passphrase-protected key isn't instant to write — ssh-keygen runs a deliberately slow key derivation to encrypt it — and anyway "the window is short" is not a security property. A loop over ps costs nothing to leave running.

And ps is only the most obvious place. The same string can end up in shell history if anyone ever runs the command by hand, in auditd logs that record every execve with its arguments, and in any process-monitoring agent that ships command lines to a dashboard.

A secret in argv has already left the process. The question is only who reads it.

(You can mount /proc with hidepid=2 so users only see their own processes. It's a good setting. It's also not something a desktop app can assume about the machine it runs on.)

Three ways to hand over a passphrase

Once -N is out, you need another channel. I found three approaches in the wild.

1. -N in argv. Covered above. Out.

2. A pseudo-terminal. Start ssh-keygen inside a pty, wait for it to ask, type the answer. This is what expect scripts do, and it works. Two problems for me.

The first is practical: Qt's QProcess doesn't do pseudo-terminals, so I'd be writing forkpty handling by hand.

The second is worse. The program now depends on the exact text of the prompt. And that text changes. On Ubuntu 22.04, which ships OpenSSH 8.9, key generation asks:

Enter passphrase (empty for no passphrase):

Current OpenSSH asks:

Enter new passphrase (empty for no passphrase):

One word. A wrapper that waits for the old string on a newer system just hangs, with no error, waiting for a question that has already been asked differently.

3. SSH_ASKPASS. This is the mechanism OpenSSH itself provides for exactly this case. You point the environment variable at a helper program; when ssh-keygen needs a passphrase, it runs the helper with the prompt as its only argument and reads the answer from the helper's stdout. Seahorse, GNOME's key manager, does it this way — it sets SSH_ASKPASS to its own helper and calls setsid() so the child has no controlling terminal to fall back on.

There used to be a catch: ssh-keygen would only use the helper under certain conditions — a display present, no terminal to ask on. OpenSSH 8.4 added SSH_ASKPASS_REQUIRE=force, which means "always use the helper, no matter what". Ubuntu 22.04 has 8.9, so for my target it's simply available.

You can try it from a terminal with a one-line helper:

#!/bin/sh
# ~/bin/askpass-zenity
exec zenity --password --title="$1"

SSH_ASKPASS=~/bin/askpass-zenity SSH_ASKPASS_REQUIRE=force \
  ssh-keygen -t ed25519 -f ~/.ssh/id_demo

A dialog pops up, twice: once for the passphrase, once to confirm it. Nothing in argv, nothing typed into a terminal you don't control.

The helper has to get the passphrase from somewhere

This is the part that's easy to get wrong after getting everything else right.

If your app already collected the passphrase in its own window and now launches the helper as askpass-helper 'correct horse...', you've moved the secret from ssh-keygen's argv to the helper's argv. Same ps, same leak, one process later.

The cleanest version is the one Seahorse uses: the helper is the dialog. It asks the user directly and prints the answer. The passphrase never passes through the parent process at all — your app doesn't hold it, log it, or forward it.

If the design really requires the main window to collect it, hand it over through something that isn't world-readable:

A pipe or a Unix socket in a directory only your user can access, with the path in an environment variable. The helper connects, reads, prints, exits.
An environment variable with the passphrase itself is the fallback. It's not great, but it's a different class of exposure: /proc/<pid>/environ is readable only by the process owner and root, unlike cmdline.

Whichever you pick, remember the helper is called twice for a new key — once per prompt — and has to answer both.

It isn't about ssh-keygen

ssh-keygen just happens to be where I met it. The same shape shows up everywhere a tool accepts a secret as an argument: mysql -p<password>, sshpass -p, curl -u user:password. All of them have a quieter alternative — a config file, an environment variable, a prompt, a helper — and all of them still appear in scripts with the secret inline, because the inline version is the one that fits on one line in a README.

If a secret is on the command line, assume it's in a log. Then find the channel the tool's authors built for the case where it shouldn't be — there almost always is one.

My News Digest Got a Telegram Channel That Forgets Everything After a Week

Den — Thu, 08 Oct 2026 16:36:36 +0000

A while back I posted here about RealFeedApp, a free digest that collects science and tech news, collapses the retellings into one card, ranks by significance and writes a short summary in your language. Last time it learned to explain itself: every card got three plain-language lines under the summary.

This post is about what happened since. The headline is a Telegram channel, and the most interesting thing about it is a setting: every post deletes itself after a week.

The first version was a wall of text

The idea was obvious. Search engines take months to notice a new site; a channel reaches people the day you post. So the first version did the obvious thing: once a day, the five top stories of the last 24 hours, as one message. Headline, summary, link to the original, repeat five times.

It worked, technically. I opened the first post in the channel and was disappointed.

It was a block of text. No pictures. None of the "in plain words" lines the site had just learned to write. No tags, no sense of which field a story belonged to. And every link went straight to the original source, so the site — the thing that actually does the work — was nowhere in it.

Nobody reposts a wall of text. You can't forward the one story you care about; it's glued to four others. And a reader who skims it learns nothing they couldn't have got from any aggregator.

The lesson was simple and slightly embarrassing: I had built a channel that showed less than the product it was supposed to advertise.

One story, one post, the whole card

So the channel now posts the way the site shows things. One story per message, spread through the day instead of a morning dump. Each post is the card:

the cover image from the site;
the headline and the summary;
the "in plain words" block — the field as a tag, what was done, why it matters — set off from the summary the way it is on the card;
tags you can tap through within the channel;
a link to the story's page on the site, and from there to the original;
the same story in Russian, folded into a collapsed quote at the very bottom.

The link to the site matters most. A post is now a preview of a card, not a replacement for it. If the story is yours, you forward that one post. If you want more, you land on the site, where the rest of the feed is.

Two small rules came out of looking at real posts before they went out. A story whose translation came out broken doesn't get posted at all — a broken word in a feed is a bug; in a public post it's a broken word in front of every subscriber at once. And the channel leans towards news over dense preprints: the feed is for people who opted in to a field; the channel is for people who just followed a link.

One channel, two languages

The site writes every summary in English and Russian, but the first channel was Russian only. That cut out half the readers. Two channels would have split the subscribers instead, and doubled the posting for a project run by one person.

So each post is now an English card with the Russian version inside it, as a collapsed quote: one line and an arrow until you tap it. An English reader never scrolls past Russian text; a Russian reader is one tap away from the full card in their language, with its own link to the Russian page of the story.

Fitting two languages into one post had a side effect. A photo caption in Telegram is short, and one card already filled it. So posts went from "photo with a caption" to a text message with the cover shown as a large preview above it. It looks the same, and there is room for both languages.

Why the posts disappear

Here's the setting I mentioned at the top: the channel's messages auto-delete after a week.

It sounds like throwing work away. It's the opposite.

A channel that keeps everything slowly becomes the product. Scroll back far enough and it's a second, worse feed: no search, no topics, no "hide this", no memory of what you liked, and nothing that gets better the more you use it. If that archive grows forever, it starts competing with the site and the app — and it wins on convenience while losing on everything else.

So the channel is a window, not a home. It shows what's happening this week, and points at the place where the rest lives. A week-old science headline is stale anyway; anything that still matters is on the site.

What else is new

RSS. Every story that goes to the channel also goes into an RSS feed: /en/rss.xml and /ru/rss.xml. The footer has a one-click "Follow on Feedly" link. If you'd rather not use Telegram at all, it's the same stream of hand-picked stories in your reader.

Bluesky. The same stories go to @realfeedapp.com as short threads: the summary with a link card to the story page, then what they did and why it matters as replies. English only — that's where a lot of the science crowd moved, and topic feeds there show posts beyond your followers.

Story pages. Every story now has its own page on the site: cover, summary, the plain-words block, tags, and a clear button to the original. That's where channel posts lead.

A daily archive. Each finished day gets a page with its top stories, open to everyone, no account needed — and an archive that lists the days. If you missed a week, that's the fastest way to catch up.

Links in your language. The feed now has its own address per language (/en/, /ru/, …). Share the Russian version with a friend and they get the Russian version, regardless of what their browser says.

Keywords from a vocabulary. Your own keywords are no longer typed in free text; you pick them from the terms the feed actually uses, and the screen explains what they change. Free text looked flexible and mostly matched nothing.

A quieter, more honest daily digest in the app. The notification gives you one reason to open it instead of a list nobody can read in a notification shade; the app tells you when the next one arrives; and the last digest can be reopened from settings.

A cleaner feed. Threads and discussions no longer show up as news — nothing happens in them, someone just talks about something that did. A story is filed by what it's about, not by where it came from. And a headline that says the opposite of its own summary, or names something the article never mentions, doesn't reach the feed.

Try it

Still free.

The site: realfeedapp.com — a preview of the feed with no account; signing in with Google opens the rest and remembers your topics.
The channel: t.me/realfeedapp — English cards, with a Russian version inside each post.
Bluesky: @realfeedapp.com.
RSS: realfeedapp.com/en/rss.xml, or "Follow on Feedly" in the site's footer.