The last article on this site is from late March. Five months of silence, and I didn’t choose it: the next piece needed a prototype, the prototype needed two weekends I never got, and the queue stopped there.
That queue is worth a look. An idea usually came up at work, inside an architecture discussion or after a review that went badly. To reach the site it had to clear five stages: a working prototype, a GitHub repository with a presentable README, the article, search optimisation, promotion on social. The text sat third. So it was the first thing to go whenever time ran out, because without the two stages before it there was no point in writing it at all.
The obvious cost is time. What took me longer to see is the filter.
A mandatory prototype selects ideas you can build in a weekend. It does not select the ideas that matter. The decisions I actually make, the ones I’d have something to say about, have a shape that doesn’t fit in a repository: a legacy system I can’t recreate, a budget set somewhere else, a regulatory constraint, people who have to agree, a risk that isn’t only mine. For years the format systematically excluded the very material I have the most experience with. I noticed, and kept going, because the format worked.
What I thought I was proving
The prototype was there to show I wasn’t talking into the void. That’s a healthy instinct. Code that runs doesn’t lie, and an article with a demo beside it carries a weight that an article of pure claims doesn’t.
It just proves far less than I assumed. It proves that something works on my machine, on my data, under conditions I picked. AeyeGuard analyses source code with a local LLM and does it well on the repositories I fed it. But I chose those repositories, and I set the terms of the test. A prototype shows that a thing works where its author decided to try it, which is not yet an answer to the question that counts: what happens when someone else sets the terms.
For years I mistook “provable in a weekend” for “important”. They are different axes, and now and then they pull against each other.
The obvious objection
Take the code away and what’s left is opinions, and there are more technical opinions online than anyone needs. It’s a fair objection, and I put it to myself before deciding.
The answer I find convincing is that the proof changes form rather than disappearing. A detailed threat model demonstrates competence as well as a working tool does, provided it carries numbers, precise boundaries, and an explicit account of the conditions under which the design breaks. An article explaining why I discarded three alternatives can be checked by anyone who has faced the same problem: weak reasoning shows immediately, far faster than a bug shows up inside a repository nobody will ever clone.
So here is the rule I’m setting myself. Every piece has to contain at least one claim that can turn out to be wrong: an option discarded with its reasoning, a prediction, a point where the design gives way. Without that, what I’ve written is a tutorial in disguise and belongs somewhere else.
Where the old format still holds
For tutorials the prototype isn’t a tax, it’s the content. If I’m explaining the boost::odeint steppers or an M/M/c/K queue simulation, the running code is the whole value of the piece. That material goes on living, but its natural home is Computational Mindset, which exists for exactly this.
What stays here is the other half: security, architecture, agent systems, and the decisions holding them together. The name of the site changes accordingly. Systems by design names the thing I actually care about, which is that a system has the shape it has because somebody decided it. The part worth writing about is the moment that decision meets a constraint with nothing technical about it, and has to give somewhere.
What comes next
Three kinds of pieces. Decision notes, which don’t describe the cases I work on but the class of problem: the constraints you typically face, the options on the table, why one holds up better than the others in that context. The value sits in the reasoning, and reasoning can be shown in full without telling anybody’s story. Threat models of architectures, starting with AI agent systems, where the trust boundary is still the open problem and nobody has a clean answer yet. And critical readings of entire categories of tools: what they promise, what they deliver, where they stop.
The next article is one of those, on static code analysis. What traditional SAST tools genuinely find and what escapes them by construction, what changes when you put a language model in the loop and what doesn’t change at all, and why the false positive rate is still the constraint that decides whether a tool enters a development process or gets switched off after two weeks.
The archive stays where it is. No article disappears, no link breaks. What changes is only what I add on top of it, and how often I can afford to do it.
