About this site

Where the judgment comes from

Staying pseudonymous does not mean arriving from nowhere. Behind the initials is a trained software engineer with close to ten years of professional work: real production systems, complex codebases, designed, built, debugged and maintained by hand. The first stretch of that career happened entirely before AI assistants existed, and that turned out to be a gift. The judgment this site runs on, what breaks, what scales, what a change actually costs, was built without a model to ask.

The engineering taste that follows from those years is unglamorous: the simplest solution that works, small abstractions, and planning about six months ahead, no further. Of all the code written over the years to make some future extension easier, maybe one in twenty pieces ever got extended. Businesses change direction, projects get finished or shut down, and nobody comes back for the todos. The obsession with detail goes where it pays instead: the last review pass, the exact wording of a constraint, the boring config that decides whether a tool behaves.

The AI interest is older than the products. There were machine learning and AI courses in the engineering degree, and reading on the subject long before it was a normal thing to do. Then ChatGPT shipped, and it looked like the closest thing to magic this field had produced. The workflow here has lived through every phase since: copying snippets between a browser chat and an editor, the first autocomplete-only Copilot, chat arriving inside the IDE, the stretch when nobody could say whether GPT, Gemini or Claude was actually ahead, and now agents working in the terminal.

The goal never changed through any of it: not AI building the product on its own, but one engineer made faster and more precise, with tools configured so carefully that they make as few mistakes as possible. That configuration work, what to hand over, what to keep, how to phrase the guardrails, is most of what gets written about here.

What you will find

Four kinds of articles. Analysis when a lab ships a model, focused on what it means in practice rather than what the press release says. Benchmark write-ups that compare the numbers with hands-on experience. Experiments from the author’s own setups, from context management to agents delegating work to each other in the terminal. And guides on how to actually use these tools day to day.

How it is written

Everything starts from real use. The author spends most working hours inside these tools and writes in the first person from that experience. Opinions appear where they have been earned, and they are marked as opinions.

English is the source of truth. Every article also ships in Spanish, German, French, Italian and Portuguese, translated with care rather than run through a machine and forgotten.

Sources

Every factual claim points to a numbered source: papers, official announcements, changelogs, benchmark repositories. If a claim cannot be sourced or reproduced, it does not get published. And when the numbers disagree with the lived experience, the article says so.

Corrections

Mistakes get fixed in place. When a factual error turns up, the article is corrected and the updated date at the top of the page changes with it, so you can always see that the text moved.

Cosmetic edits, a typo or a clearer sentence, never touch that date. Nothing is quietly rewritten to look right in hindsight: if a claim turns out to be wrong, the correction says what changed.