DEV Community: Pascal CESCATO

The "AI" Badge Doesn't Measure What You Think It Does

Pascal CESCATO — Sat, 15 Aug 2026 13:06:49 +0000

Anthropic signed the EU AI Act's Code of Practice on Transparency of AI-Generated Content, and started marking text produced by Claude with an invisible statistical watermark. Within days, the same event got read two completely different ways on my feed.

The first reading, on dev.to, is by @sylwia-lask

Separating AI provenance from detection myths

Sylwia Laskowska

Aug 11

The End of Undetectable AI Text? Claude’s New Watermark Explained

#news #ai #llm

155

103

6 min read

She actually went and read the official documentation and reported what Anthropic really says: the watermark doesn't prove a text was entirely AI-generated – you can write something yourself, have Claude correct it or translate it, and it can still carry the mark. The reverse holds too: no watermark detected doesn't prove a human wrote everything.

The second, on Medium, called the announcement a "nuclear bomb" for the AI-generation community, and claimed "you are effectively carrying a digital scarlet letter." No citation of the actual documentation. Just outrage, with the appropriate amount of dramatic punctuation.

Between the two, I left a comment under Sylwia's article. Written in French, translated by ChatGPT, signed off with a question: how do you classify a text thought through, written, and reviewed by a human, but whose final English phrasing came out of a model? It wasn't a rhetorical question. I still don't have an answer.

Three things people keep conflating

The Medium article mixes together, without ever saying so, three mechanisms that have almost nothing to do with each other.

Anthropic's watermark. A statistical signal baked into the model, documented, which openly acknowledges its own limits: it can disappear after enough editing or translation, and its presence says nothing about who came up with the idea in the first place.

Third-party consumer detectors. ZeroGPT and its relatives. Tools that have existed for years, unrelated to Anthropic, whose reliability has never been seriously demonstrated at scale.

Platform decisions. A badge displayed on Medium, a curation algorithm that penalizes flagged content. These are editorial choices specific to each platform, not a mechanical consequence of the watermark.

The Medium article writes as though the first link automatically triggers the next two: Anthropic marks, so detectors will catch everything, so platforms will punish. The reasoning collapses the moment you separate the links – and for good reason: detecting that a model was involved in producing a text is not the same as determining that the text was "written by AI." That conflation hides a deeper one, which public debate almost systematically ignores.

Assisted, generated, produced: three different verbs

A text assisted by AI stays under human editorial control from start to finish: the idea, the angle, the structure, and the final decision to publish belong to someone, no matter how many back-and-forths with a model happened along the way to correct, rephrase, translate, or pressure-test a line of reasoning. A text generated by AI comes out of a prompt, without that upstream control – the idea itself came from the human, but the generated text, as it stands, belongs to the model. A text produced by AI at industrial scale is something else again: an automated publishing pipeline, without anything resembling editorial oversight.

What separates the three, then, isn't how much the model intervened – it's who kept their hand on the decisions.

These three cases carry entirely different editorial responsibility. Treating them as a single category ("AI content") means judging a text on a binary criterion where the reality is a full spectrum of nuance – which is exactly what an undifferentiated "processed by AI" badge does.

What an actual test shows

I ran an article I wrote in April 2021 – before any consumer-facing LLM existed – through ZeroGPT. A test about a year ago gave it a 97% AI probability. A recent test, on the exact same text, with the exact same tool, gives 8.6%.

Same tool. Same text, down to the punctuation. Two incompatible scores, a year apart.

Digging into the flagged passages in the second test, a pattern emerges. These aren't random sentences: they're consistently the most neutral, most pedagogical, most well-structured passages in the piece – a definition of what a web server is, an explanation of CentOS Stream, a step-by-step automated update procedure. The passages where my voice actually comes through – the self-deprecation, the verbal tics, the Neapolitan moka pot bought at a flea market – are never flagged.

One test doesn't prove what a detection model measures in general. But this one strongly suggests the tool reacts to stylistic neutrality and structural regularity, not to a text's actual origin. Which is precisely the problem: those characteristics existed in human writing long before LLMs did. The detector is chasing a style whose origin is human, using the machine's imitation of it as the reference point. The reasoning eats its own tail.

How this piece was actually made

Since the whole point of this article is how hard it is to judge a text by its origin rather than its content, it's worth being transparent about how this one was produced.

The starting point wasn't this article: it was a comment under a Medium post that annoyed me enough to reply. From there, several hours of back-and-forth with Claude – not to have it write for me, but to pressure-test angles, check numbers, and go dig up original sources instead of relying on my own fuzzy memory. The ZeroGPT test wasn't improvised for the article, either: I reran it to verify what I was recalling from memory, and the result changed the conclusion I was about to draw.

First draft written in French – the language I actually think in. Several rounds of review, cross-checked across a few different AI models – ChatGPT, Kimi, Grok, Mistral – to catch inconsistencies and spots where the argument went soft. I then read and corrected it myself, outside of Claude (I use NotepadMD), because I never let a text out the door without going through it line by line. Translation into English after that, then a review of that translation, because a lexically faithful translation can still betray the tone if nobody checks it.

By the end of this process, the text probably carries a watermark. It also took up several hours of research, verification, and both automated and human review – and my own review isn't the least of it: after every rewrite, and again at the end of the process. Both facts are true at the same time, and no detector will ever be able to tell them apart.

What a badge actually costs

Everything above is a technical demonstration. It says nothing about what happens once the text is published, and that might be the more important part.

A "processed by AI" badge, applied without distinguishing assisted, generated, and produced, puts an author who spent hours thinking, checking, and writing in the same bucket as a content farm publishing a hundred articles a day with no human oversight. A rushed reader doesn't see the nuance – they see the badge, and file the thinking author under "cheater." That's a real loss for someone who never cheated: their work gets judged on a signal that measures neither the effort nor the actual editorial control behind it, only whether a tool showed up somewhere in the chain.

And that loss has an absurd mirror image. The same readers who reject an article marked "AI" accept, without blinking, the AI-generated summary sitting at the top of their Google search results – without reading it critically, without checking the sources it pulled from, and most often without ever clicking through to the original article. Independent studies converge on this: when an AI summary appears in a Google search, clicks to third-party sites drop by half, sometimes more, depending on methodology. In other words, the reader who calls an article "AI slop" over a badge probably let an AI summarize ten other topics for them that same week, without ever checking what it kept or what it distorted. AI isn't rejected on principle. It's rejected when it's visible and claimed, and accepted when it's invisible and imposed by default.

This shift from click to summary is also a broader loss of reading, independent of any badge: a full article, nuanced, sometimes contradictory, replaced by three smoothed-over lines nobody ever questions. The reader loses the friction that would have forced them to evaluate a source, a line of reasoning, a style – exactly what the badge claims to let people judge, and what the summary skips without any debate at all.

What this doesn't fix

None of this will stop an "AI slop" comment under this piece. I've never gotten one on dev.to. On Reddit, I have.

But look at who tends to write that kind of comment. Rarely people genuinely engaging with the topic. Often people chasing the buzz of a word that lands. On Reddit, the accounts behind these comments often show a broader pattern of reflexive, repeated downvoting across unrelated posts – a signal of rejection that has little to do with the content actually in front of them.

The technical demonstration and the social judgment are two different things, and the second doesn't get talked out of itself by the first. "AI slop" has stopped being a judgment about a text at all: it's become a blunt, reflexive rejection signal people display, regardless of whether they read anything.

If the badge doesn't measure origin, and social judgment doesn't care about the measurement, maybe the question worth asking isn't "who wrote this" but "who thought this through."

The nuance matters here. In the process I just described, the initiative never changed hands: I'm the one who opens the session, sets the topic, decides whether an angle holds up or needs to be dropped. A model doesn't come looking for me with an idea I didn't already have. And if it writes a paragraph I didn't ask for, it goes in the trash – which is perfectly observable in what I keep and what I discard from one session to the next.

Who thought through the initial disagreement with the Medium piece, and chose to separate watermark, detector, and platform instead of treating them as one thing? Who decided a test was worth more than an opinion, and reran it twice instead of republishing a fuzzy memory?

Those are questions I can answer, text by text, decision by decision. No detector asks them. It looks at the final shape and infers an origin from it – when the origin was never in the shape. It was in the chain of decisions that came before it.

When Your VPS Never Had the Resources It Was Sold With

Pascal CESCATO — Wed, 05 Aug 2026 23:58:23 +0000

I needed a VPS to run CyberPanel. Simple enough: 1 vCPU, 1 GB RAM, 10 GB SSD, IPv6 only. CyberPanel needs IPv4, so I upgraded to the next tier: 2 vCPU, 2 GB RAM, 20 GB SSD, one IPv4 address.

What followed was two separate infrastructure failures in the same 24 hours, from the same provider, on the same instance. Neither was a Linux problem. Both were provisioning problems — the gap between what an offer promises and what actually gets attached to the virtual machine.

I'm not naming the provider. It's a small French hosting company, and the point of this article isn't to send traffic their way — it's the pattern itself, which is common enough in the VPS world to be worth documenting properly.

Problem 1: IPv4 that went nowhere

The upgrade completed and the new IPv4 address showed up in the panel. Interface up, IP configured, default route present, ARP resolution to the gateway working:

88.151.197.1 lladdr 44:4c:a8:fb:ef:fd REACHABLE

But ICMP got no response at all, from the VPS or from the gateway itself:

88.151.197.112 > 88.151.197.1: ICMP echo request
(no reply)

IPv6 worked normally throughout. Everything on the guest side — interface, routing, ARP — was correct. That's a useful diagnostic signal in itself: when ARP resolves but ICMP is silent, the guest OS has done its job and the problem sits in the infrastructure layer above it — typically a MAC/IP binding on the hypervisor or virtual switch that hasn't been updated to match the new address.

It eventually got resolved, but with no explanation of what was actually changed on their side. At that point I'd lost most of a day to a connectivity problem on an instance that, on paper, was correctly configured from the first minute.

Problem 2: the disk that was never there

With IPv4 finally working, I moved on to installing CyberPanel — the entire reason for the upgrade. A fresh Ubuntu install went fine until CyberPanel's dependency installation started throwing No space left on device. So I checked:

root@panel:~# lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda       8:0    0  3.5G  0 disk
├─sda1    8:1    0  2.5G  0 part /
├─sda14   8:14   0    4M  0 part
├─sda15   8:15   0  106M  0 part /boot/efi
└─sda16 259:0    0  913M  0 part /boot

The disk was 3.5 GB. Root partition, 2.5 GB. The offer promised 20 GB after the upgrade — and, as it turned out, the base 10 GB tier had never delivered more than a fraction of that either. This wasn't a side effect of the upgrade. It had been wrong from the start; the upgrade just moved the goalpost from 10 GB to 20 GB while the actual allocation stayed untouched.

This is where a lot of guides point you at growpart or resize2fs. Both are useless here, and understanding why matters:

resize2fs and growpart operate at the bottom two layers. They can only extend a filesystem or partition into space that already exists on the virtual disk. If the disk itself is 3.5 GB, there is no unallocated space to grow into — the tools report success or do nothing, because there's genuinely nothing for them to do. The problem isn't in the guest OS. It's one layer below it, in what the hypervisor actually attached to the VM.

I opened a support ticket, included the lsblk output, and asked them to check the volume attachment.

The reply I got back attributed the disk shortfall to "the IPv6 to IPv4 upgrade" — as if provisioning a new IPv4 address could somehow shrink a virtual disk. It doesn't, and the two are unrelated at every layer shown in the diagram above. It reads less like a diagnosis and more like a convenient way to fold a second unresolved ticket into the first.

Problem 3: "fixed" didn't mean fixed

The provider's answer was to ask me to check again — no diagnosis of their own. I did, and this time the disk was correct: 20 GB, as ordered. I replied "corrected, thanks," and the ticket was closed.

Later the same day, I reinstalled Ubuntu to get a clean baseline. The disk was wrong again — same as before the fix, not as after it:

root@panel:~# date
Mon Aug  3 20:56:49 UTC 2026
root@panel:~# lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda       8:0    0  3.5G  0 disk
├─sda1    8:1    0  2.5G  0 part /
├─sda14   8:14   0    4M  0 part
├─sda15   8:15   0  106M  0 part /boot/efi
└─sda16 259:0    0  913M  0 part /boot
sr0      11:0    1    4M  0 rom

Same 3.5 GB disk, same 2.5 GB root partition, hours after the ticket was marked resolved.

This is the part worth sitting with. A "fix" applied through a support ticket, on a running instance, doesn't necessarily touch the thing that's actually broken. If the underlying VM profile or provisioning template is wrong, a support agent can patch the live disk allocation by hand and call it closed — while the next rebuild pulls from the same broken template and reproduces the exact same fault. The fix fixed an instance, not the cause.

That's the practical lesson: if a resource-provisioning issue gets "corrected" on a live VPS, don't close the loop until you've verified it survives a rebuild. A one-off patch and a fixed template look identical from the support ticket. They don't look identical from lsblk.

What two failures in one day tell you

Individually, either of these could be dismissed as a one-off glitch. Together, they're more telling: two independent provisioning mismatches — disk and network — on the same instance, within the same upgrade cycle, one of which reappeared after being marked fixed. That pattern points to the provisioning pipeline itself, not to isolated bad luck.

Commands worth knowing

If you land in a similar situation, these will tell you which layer you're actually dealing with:

lsblk                           # what Linux sees attached
fdisk -l                        # partition table detail
df -h                           # filesystem usage
blockdev --getsize64 /dev/sda   # raw device size, bytes
ip addr                         # interface and IP state
ip route                        # routing table
ip neigh                        # ARP/NDP cache — gateway reachability
ping -c 3 <gateway>             # basic reachability test

If lsblk and blockdev --getsize64 already show a disk smaller than what you're paying for, don't touch growpart or resize2fs — you're not looking at a Linux problem. If ip neigh shows the gateway as REACHABLE but ping gets nothing back, you're not looking at a Linux problem either. In both cases, the fix is on the other side of the hypervisor boundary, and no amount of guest-side troubleshooting will reach it.

Takeaway

A VPS isn't physical hardware, but it's supposed to honor the same basic contract: the resources advertised should be the resources actually present. Before blaming Linux, a package, or your own configuration, check the layer underneath — and if a provider tells you something's fixed, verify it survives a rebuild before you believe it.

None of this required an unusual amount of digging — lsblk, ip neigh, a rebuild to double-check. Which is really the point: for roughly the same price, sometimes less, providers like OVH, Contabo, or Infomaniak offer configurations that don't require this kind of forensic work just to get the resources you paid for. Chasing the cheapest listed price has a cost. It's just not always visible until you've already lost a day to it.

CyberPanel's SSL Auto-Renewal Can Silently Fail — Here's the Fix

Pascal CESCATO — Sat, 01 Aug 2026 02:44:11 +0000

Last week I was doing a routine check on a CyberPanel server and noticed something that didn't add up. The panel's SSL status showed a clean "SSL Issued Successfully". Nothing to see, apparently. Except the certificate expiration date hadn't moved.

The browser was still serving a certificate that was about to expire.

That's the kind of mismatch that's easy to miss if you trust the panel's UI at face value — the message says success, the log (if you even check it) looks uneventful, and you move on. I didn't move on.

Checking what's actually served

The panel tells you what it thinks happened. What matters is what the server actually hands out to a browser. That's a one-liner away:

openssl s_client -connect  \
domain.com:443 -servername domain.com </dev/null 2>/dev/null \
    | openssl x509 -noout -dates

# outputs
notBefore=Jul 31 22:59:26 2026 GMT
notAfter=Oct 29 22:59:26 2026 GMT

Wait — that date range looked fine on its own. The real tell was comparing it against what the panel had just claimed to renew: the dates hadn't changed since before the "successful" renewal. Whatever acme.sh had just done, it hadn't produced a new certificate that OpenLiteSpeed was actually serving.

Checking what acme.sh actually did

CyberPanel doesn't implement ACME itself — it delegates to acme.sh under the hood. So the next step was checking what acme.sh had registered:

acme.sh --list

That's where the mismatch became clearer. The certificate authority listed for this domain wasn't Let's Encrypt production — it was the staging CA. Staging certificates are useful for testing, but they're not production certificates trusted by browsers. In this case, the important part wasn't just that staging was configured — it was that the renewal workflow no longer matched the certificate actually served by OpenLiteSpeed. CyberPanel reported success because, from its point of view, acme.sh had returned successfully. It just wasn't returning the certificate the site needed.

I can't say for certain how this CyberPanel installation's acme.sh configuration ended up pointed at the staging CA — only that it had. Worth keeping in mind if you're chasing a similar mismatch: the fix doesn't require knowing the origin, just confirming the current state.

The fix

Once the mismatch was clear, the fix was mechanical:

Force acme.sh back onto the Let's Encrypt production CA.
Drop the existing (staging) registration for the domain.
Reissue the certificate from scratch, this time against production.
Install it where CyberPanel and OpenLiteSpeed expect it: /etc/letsencrypt/live/<domain>/.
Reload OpenLiteSpeed so it picks up the new files.

None of this is exotic — it's exactly what acme.sh is designed to do. The problem was never the tooling, it was that CyberPanel's reported status wasn't a reliable signal of what state the certificate was actually in.

Turning it into something reusable

Fixing one server by hand is fine once. But when the same class of drift keeps showing up across CyberPanel releases, it stops being a one-off and starts being something worth scripting around. I wrote two tools:

renew-ssl.sh — routine renewal, bypassing CyberPanel's scheduler entirely. It supports an auto mode (renews anything expiring within a configurable threshold, default 10 days), a single-domain mode, and a --check mode that simulates the run and just reports what would happen — useful for confirming a diagnosis like this one before touching anything.
fix-ssl.sh — the heavier tool, for when a certificate is actually broken or stuck in staging. Given that the whole premise of this post is "don't trust the reported status, verify it," the script holds itself to the same standard on both ends:
- Before touching anything, it writes a test file into the HTTP-01 challenge path and fetches it over plain HTTP, the same way Let's Encrypt will. If that fails, it stops before issuing anything — no point calling acme.sh against a webroot that can't serve the challenge.
- It backs up the existing certificate and acme.sh registration to a timestamped archive before removing anything, and refuses to proceed if the backup itself fails.
- It forces the production CA, clears the old registration, reissues via webroot, and installs the new certificate.
- After reloading OpenLiteSpeed, it doesn't just assume the reload worked — it fetches the certificate actually served over HTTPS and compares its SHA256 fingerprint against the one just installed. A mismatch is reported as an error, with the exact restore command from the backup printed alongside it.

Both are plain Bash, no dependencies beyond acme.sh and openssl (fix-ssl.sh also uses curl for the webroot check, though it degrades gracefully — with a warning — if curl isn't available). Both are meant to be run as root since they touch /etc/letsencrypt/, /root/.acme.sh/, and the OpenLiteSpeed service.

Source, with usage examples and a debugging section covering both commands above:

pcescato / cyberpanel-ssl-renewal-scripts

Renew and repair SSL certificates on CyberPanel 2.x directly via acme.sh (bypasses the broken built-in renewal scheduler)

CyberPanel SSL Renewal Scripts

Bash scripts to renew and repair SSL certificates on CyberPanel 2.x directly via acme.sh, bypassing CyberPanel's unreliable built-in renewal scheduler.

Why this exists

CyberPanel can report a successful SSL renewal while the certificate actually served remains close to expiration.
In some cases acme.sh is left configured with the Let's Encrypt staging CA, so "renewals" produce certificates that browsers reject.
These scripts renew — and repair — certificates directly via acme.sh, without going through the panel.

Requirements

CyberPanel 2.x
OpenLiteSpeed
acme.sh installed at /root/.acme.sh/ (CyberPanel default)
curl — used by fix-ssl.sh to validate the webroot challenge path (optional: without it, that check is skipped with a warning)
Root access — the scripts write to /etc/letsencrypt/live/, read /root/.acme.sh/, and restart OpenLiteSpeed

Scripts

`renew-ssl.sh` — Renew certificates

Renews certificates that were previously issued and installed with acme.sh.

It supports three modes:

Auto mode (recommended):…

View on GitHub

Why this is worth checking on your own servers

If you're running CyberPanel and haven't looked recently, it's worth running the openssl s_client check against your actual domains — not because CyberPanel is broken in general, but because "the panel says success" and "the certificate is actually valid and current" are two different claims, and only one of them is verifiable from outside the panel.

Have you seen similar ACME renewal drift on CyberPanel, OpenLiteSpeed, or other hosting panels? I'd be interested in comparing root causes — certificate automation failures are often harder to diagnose than certificate issuance itself.

What Replacing Calendly Taught Me About Trusting Open Source

Pascal CESCATO — Wed, 29 Jul 2026 00:22:42 +0000

cal.com, Calendly, zcal... booking SaaS isn't short on options, and most of them are genuinely decent. Free tiers cover the basics for a lot of freelancers. The catch: you're the product (nothing's really free), and your customer data lives somewhere you don't fully control and can't fully audit.

A dysfunction I ran into on another SaaS tool was the trigger. Trusting a third-party service by default, just because it's widely used and billed monthly, doesn't always hold up. That episode was enough to make me reconsider every external service this site was relying on for functionality that's actually simple to self-host — and the booking widget, running on Calendly, was one of them.

Nothing wrong with Calendly specifically. It worked fine. But structural friction had been building regardless: a recurring subscription for something as simple as displaying open slots and recording a choice, a hard dependency on a third party for a component with nothing exceptional about it technically, and customization capped by whatever the vendor exposes in settings — no way to go further if a need falls outside that box. On top of that, an integration constraint that mattered more than any of the above: the site runs on Astro, generating lightweight static pages by design, specifically to avoid the weight of third-party scripts and dependencies — the exact opposite of what embedding a SaaS widget implies.

So: could a self-hosted alternative match the experience, without the monthly bill and without handing a core commercial function (people booking a call with me) to an external vendor? This is the write-up of that search, the codebase audit that came out of it, and the production rollout.

The landscape

Four self-hosted candidates stood out as genuinely comparable — not just UI skins sitting on top of someone else's API, not just internal-scheduling tools with the public-facing UX as an afterthought.

CloudMeet — Svelte + TypeScript, deployed on Cloudflare Pages/Workers/D1, free-tier friendly. MIT licensed. Clean booking UX. Single maintainer, ~490 stars, 37 commits — young, not enough track record to trust blind.

Cal.diy — the community fork of cal.com's booking engine, spun up after cal.com closed-sourced their core product in April 2026, citing security risk from AI-assisted code scanning against their public repo. MIT licensed, maintained by former cal.com interns. Full scheduling engine, app-store integrations, Stripe/PayPal payment support carried over. Most feature-complete on paper. Also the youngest as an independent community project — their own docs still discourage production use without caveats.

booking-calendar — React + TypeScript + Bun + SQLite, single-admin design, native bidirectional CalDAV sync instead of a Google/Outlook lock-in. Clean architecture (repository/service/entity separation via TypeORM). Lightweight, portable by design. Booking UI is a scrollable list of time slots — functional, but nowhere near the polish of a commercial scheduler.

Easy!Appointments — PHP/CodeIgniter + MySQL, ten years of active development, 3000+ stars, a paid tier that's existed for years. Most battle-tested of the four, and the one with the closest booking UX to Calendly itself: monthly calendar view, multi-step wizard.

What I was actually optimizing for: framework-agnostic integration (no PHP running on the public site itself), booking UX quality, native GDPR consent handling, and enough production maturity to put in front of real prospects rather than an experimental project.

Narrowing down

CloudMeet and Cal.diy dropped out early, for the same underlying reason: not enough track record for production use, not a specific flaw found. CloudMeet's single-maintainer status and short commit history made it too much of a bet. Cal.diy's own documentation still hedges on production readiness three months post-launch. Whether either becomes a serious contender or stays a one-shot project is a question for later.

Worth being honest about what that is: a decision made on reputation and project age, the exact shortcut this piece argues against later on. Auditing four codebases in the same depth as the two finalists below wasn't a realistic use of time, so CloudMeet and Cal.diy got a lighter pass — young-project heuristics instead of a source read. That's a real gap in the method, not just a caveat to mention in passing.

That left booking-calendar and Easy!Appointments. And this is where the UX gap tipped it: booking-calendar's public booking page is a plain scrollable list of Monday, February 23, 2026 at 08:00 AM rows — accurate, but visually miles from what Calendly conditioned people to expect. No month view, no staged flow, just text to scroll through.

I briefly considered franken-stacking the two — CloudMeet's frontend on top of booking-calendar's CalDAV backend, or something along those lines. Not viable in practice: different runtimes (Cloudflare Workers/D1 vs Bun/SQLite), no shared API contract, no shared data model. Bolting two incompatible stacks together usually creates more work than picking one and adapting it. Went with separation of concerns instead: pick the tool with the better public-facing UX, and if native CalDAV sync becomes a real need later, that's a second, independent tool — not a merge.

Easy!Appointments won on UX. Onto the part that actually mattered for a production decision.

The audit: a TOCTOU race condition, in both remaining candidates

Before committing to either, I wanted to check one specific thing: what happens if two visitors click the same slot at nearly the same instant? Not a theoretical concern — it's the kind of bug that never shows up in solo development and blows up the day a booking link gets shared a bit wider (a newsletter blast, a LinkedIn post, a batch of new slots opening at a fixed time).

This is a classic TOCTOU (time-of-check to time-of-use) race condition: the code checks that a slot is free, then writes the booking — and nothing stops a concurrent request from doing the exact same check in between, before either write lands. Without a lock spanning both the check and the write, two requests can both conclude "free" before either commits.

booking-calendar

TypeORM-based, repository pattern, otherwise clean separation of concerns. The overlap check:

async hasOverlapInSlot(
    slotId: number,
    startAt: string,
    endAt: string,
    manager?: EntityManager,
): Promise<boolean> {
    const count = await this.repo(manager)
        .createQueryBuilder("a")
        .where("a.slot_id = :slotId", { slotId })
        .andWhere("a.canceled_at IS NULL")
        .andWhere("a.status != 'rejected'")
        .andWhere("NOT (a.end_at <= :startAt OR a.start_at >= :endAt)", {
            startAt,
            endAt,
        })
        .getCount();

    return count > 0;
}

Called inside a transaction (AppDataSource.transaction), but no .setLock("pessimistic_write"), no exclusion constraint at the schema level. Under SQLite, this never surfaces: the engine serializes writers, one at a time, by design. It's a free safety net courtesy of the storage engine — not a guarantee the application code actually enforces. The project's own architecture explicitly anticipates a migration path to Postgres or MySQL via TypeORM's driver abstraction (type: "sqlite" → type: "postgres", straightforward on paper). That's exactly the migration that removes the net: under READ COMMITTED isolation, two concurrent transactions can each read "no overlap" before either one's INSERT commits.

Confirmed by reading the CalDAV sync layer too — a second, independent race, this one against the external calendar rather than the local database:

private async getCachedBusyIntervals(startAt: string, endAt: string): BusyInterval[] | null {
    const cache = CalDAVService.busyIntervalCache;
    if (!cache || cache.expires_at <= Date.now()) {
        return null;
    }
    if (startAt < cache.start_at || endAt > cache.end_at) {
        return null;
    }
    return cache.intervals.filter(
        (interval) => !(interval.end_at <= startAt || interval.start_at >= endAt),
    );
}

A process-wide static cache with a TTL, invalidated only after a successful write. Two bookings arriving seconds apart, inside the cache window, can both read the same "free" snapshot before either has finished writing to the external calendar — the exact same TOCTOU shape, just with the external CalDAV server as the source of truth instead of the local DB.

Easy!Appointments

Ten years in production, 3000+ GitHub stars, a paid tier that's existed for years. The working hypothesis going in: more real-world traffic means more chances this exact class of bug already got hit and fixed. That hypothesis doesn't survive reading the code.

The public booking flow:

// Check appointment availability before registering it to the database.
$appointment['id_users_provider'] = $this->check_datetime_availability();

if (!$appointment['id_users_provider']) {
    throw new RuntimeException(lang('requested_hour_is_unavailable'));
}

// ... customer lookup/creation, GDPR consent records, Jitsi link generation ...

$appointment_id = $this->appointments_model->save($appointment);

Several unrelated operations sit between the check and the write — the race window here is wider than booking-calendar's, where check and insert at least shared a transaction. And the insert itself:

protected function insert(array $appointment): int
{
    $appointment['book_datetime'] = date('Y-m-d H:i:s');
    $appointment['create_datetime'] = date('Y-m-d H:i:s');
    $appointment['update_datetime'] = date('Y-m-d H:i:s');
    $appointment['hash'] = random_string('alnum', 12);

    if (!$this->db->insert('appointments', $appointment)) {
        throw new RuntimeException('Could not insert appointment.');
    }

    return $this->db->insert_id();
}

No transaction, no lock, no unique constraint. The docblock on check_datetime_availability() reads:

"It is possible that two or more customers select the same appointment date and time concurrently. The app won't allow this to happen."

Documented intent, not what the code actually does.

The interesting part

Appointments_model contains a method that does the correct overlap check, with a properly built query:

public function has_provider_conflict(
    int $provider_id,
    string $start_datetime,
    string $end_datetime,
    ?int $exclude_appointment_id = null,
): bool {
    $this->db->select('id')->from('appointments')->where('id_users_provider', $provider_id);

    if ($exclude_appointment_id) {
        $this->db->where('id !=', $exclude_appointment_id);
    }

    // Overlap: (existing_start < new_end) AND (existing_end > new_start)
    return $this->db
        ->group_start()
        ->where('start_datetime <', $end_datetime)
        ->where('end_datetime >', $start_datetime)
        ->group_end()
        ->get()
        ->num_rows() > 0;
}

It's never called anywhere in the public booking flow. The correct primitive exists in the codebase; it's just not wired in where it would matter.

Takeaway

Neither project is "more robust" than the other on this specific point — both share the same design gap, independent of relative maturity. Reputation, age, an established commercial tier: reasonable statistical priors, not proof. The only way to know whether an open-source project actually guards against this class of bug is to read the code doing the work, not the comment claiming it does.

For what it's worth, the fix on the Easy!Appointments side is close to a drop-in — the correct primitive (has_provider_conflict) already exists, it's a matter of wiring it in with a lock around check+write rather than designing a new one:

$lock_name = "provider_{$provider_id}_booking";

if (!$this->db->query("SELECT GET_LOCK(?, 10)", [$lock_name])->row()->{"GET_LOCK(?, 10)"}) {
    throw new RuntimeException('Could not acquire booking lock.');
}

try {
    if ($this->appointments_model->has_provider_conflict(
            $appointment['id_users_provider'],
            $appointment['start_datetime'],
            $appointment['end_datetime']
        )) {
        throw new RuntimeException(lang('requested_hour_is_unavailable'));
    }
    $appointment_id = $this->appointments_model->save($appointment);
} finally {
    $this->db->query("SELECT RELEASE_LOCK(?)", [$lock_name]);
}

GET_LOCK rather than a schema-level exclusion constraint because MySQL has no equivalent to Postgres' EXCLUDE USING gist — no declarative way to say "no two overlapping ranges for this provider" at the database level. The lock key is scoped per-provider (provider_{id}_booking) rather than global, so two visitors booking with two different providers at the same instant don't block each other for no reason. RELEASE_LOCK sits in a finally so a failed write doesn't leave the lock held until timeout.

One dependency this fix quietly assumes: non-persistent database connections. GET_LOCK is scoped to the MySQL session, not the PHP request — it lives and dies with the connection. That holds cleanly on a standard non-persistent connection (the CodeIgniter default), where each request gets its own connection and the lock disappears cleanly when it ends, even on an uncaught fatal. It stops holding if pconnect is enabled and connections get reused across unrelated requests from a pool: RELEASE_LOCK in the finally might release a lock a different request just acquired on the same recycled connection, or a lock could outlive the request that took it. Worth stating explicitly in the patch rather than assuming, since it's not something has_provider_conflict() or the surrounding code makes obvious either way.

This didn't end up shipping in my deployment — the LOCK/VERIFY/WRITE/UNLOCK skeleton above is close to production-ready, but I'd want load-test coverage on the ANY_PROVIDER branch (where the code searches for any available provider — the lock needs to span that search too, or two "any provider" requests can still land on the same provider/slot in parallel) before calling it done. Worth a PR upstream at some point.

Production rollout: a simple embed, an unexpected block

The integration itself was straightforward: Easy!Appointments runs on its own subdomain, the contact page just drops an <iframe> pointing at it. No PHP touches the public Astro site at all — that separation was the whole point.

First test after deploying: the iframe wouldn't render. Console error:

Refused to display 'https://cal.example.com/' in a frame because it set
'X-Frame-Options' to 'sameorigin'.

First guess, wrong

Given the server setup (a hosting panel with a reverse-proxy layer in front of the site), the obvious first suspect was that layer, not the app itself. Tried unsetting the header at the .htaccess level:

<IfModule mod_headers.c>
    Header always unset X-Frame-Options
    Header always set Content-Security-Policy "frame-ancestors 'self' https://backstage.click"
</IfModule>

No effect. Header still showed up on curl -I.

The actual cause

Grepping the Easy!Appointments source turned it up directly:

./application/hooks/security_headers.php:    header('X-Frame-Options: SAMEORIGIN');
./application/config/routes.php:header('X-Frame-Options: SAMEORIGIN');

The app sets the header itself, in PHP, at two separate points in its own bootstrap — a hardcoded anti-clickjacking default, sensible for the admin panel, applied indiscriminately to every route including the public booking page that's meant to be embedded elsewhere. Header unset in .htaccess runs at the web-server response-table level, ahead of the PHP process; a header() call executed later by the script itself simply overrides it. The .htaccess fix couldn't have worked against this, structurally, regardless of server (Apache, Nginx, OpenLiteSpeed) — PHP has the last word on its own headers as long as output hasn't started.

The working fix patches both call sites, scoped to the booking controller only so the admin panel keeps its default protection:

$CI =& get_instance();
if (get_class($CI) === 'Booking') {
    header("Content-Security-Policy: frame-ancestors 'self' https://backstage.click");
} else {
    header('X-Frame-Options: SAMEORIGIN');
}

Using the instantiated controller class rather than parsing $_SERVER['REQUEST_URI'] — this install doesn't have clean URLs enabled (index.php shows up in the booking URL), so a naive strpos($uri, '/booking') === 0 check would silently fail to match.

One thing worth flagging for anyone patching the same two files: they're core application code, not a plugin layer. A future git pull or a Docker image rebuild will silently overwrite this fix. Worth keeping it as a versioned patch file (git diff before/after) to reapply after upgrades, rather than losing it the next time the container gets rebuilt.

Result

Customer data (name, email, meeting reason) staying on infrastructure I control instead of a third party's, and the site's initial page weight untouched — no third-party script added for this one feature. Cost wasn't really the driver here; free tiers cover the basics for a lot of freelancers, mine included. What I was buying back wasn't a subscription fee, it was the part where a vendor decides what "the basics" are, and where my prospects' contact details end up.

Worth noting: which of the four tools actually fits depends entirely on what a given business needs, not on which one "won" here. Easy!Appointments, for instance, is also a solid self-hosted alternative to Bookly for anyone running WordPress and looking to drop a booking plugin subscription — different starting point, same underlying question.

But the tool swap itself isn't really the point. This is one instance of a pattern I keep coming back to: default to self-hosted where it's reasonable, and don't let "widely used" or "ten years old" or "has a paid tier" stand in for actually checking. Reputation is a prior, not a verdict. The Easy!Appointments audit is the clearest example in this piece — a decade of production traffic, a commercial offering, thousands of stars, and a race condition sitting in the exact code path that mattered most, with the correct fix already written elsewhere in the codebase and simply never called. Maturity didn't catch it. Reading the code did.

Here's the part worth sitting with, though: the fix never shipped on my own deployment either. It's sketched out above, unfinished, blocked on load-testing I haven't done. Which means the instance running this site's booking page right now is, as far as I know, still exposed to the exact TOCTOU window this whole piece is about. Self-hosting bought me visibility into that gap — Calendly would have hidden it behind a vendor's SLA and I'd have had no way to know either way. It didn't buy me the fix. That's a separate piece of work, and skipping it doesn't get excused by having found the bug in the first place. Self-hosting gets you control. Security still has to be built, on your own time, by someone — and until that patch actually lands, that someone is a task on my list, not a claim in this article.

Neither was this the fastest of the four options, or the most obvious. It took a real comparison between projects, a debugging detour once in production, and time spent reading source instead of trusting a README. That's the actual cost of running your own infrastructure instead of renting someone else's.

Eighty Percent Done Is Not a Real Number

Pascal CESCATO — Wed, 15 Jul 2026 12:51:00 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

Why this one, and why now

I always have several projects running in parallel — a maintenance CRM for tradespeople, a SaaS platform for restaurants, an automated newsletter, a management tool for training organizations… Except for that last one, none of them was ready to sell. And I have a whole pile of projects left "as is," untouched for months. An SEO scanner, a document analyzer, a mailbox scanner, a SQL audit tool, and others.

Brainstorming session with Claude, my favorite AI assistant — we went through my repos: the CRM for heating tradespeople, the restaurant platform, the bilingual newsletter, and this SQL audit folder, several months old. The point of the session was to decide. I wanted to finish something quickly and start promoting it. Each project had a state of progress, a level of uncertainty, a distance to something sellable.

The CRM still needs weeks of development — just for the features I know are essential — and field feedback from real tradespeople to validate the workflows. The restaurant platform was more of an architecture bet than a finished product. The newsletter has no client waiting for it.

The SQL audit, though, looked done. Two .sql files, a UNION ALL of ten SELECT statements per engine, a bash script pushing that to psql or mysql and converting to JSON, a PDF generator for a professional presentation. But I doubt I'd ever actually run it.

It was a forgotten project. A PoC — it looked like a finished application, it wasn't one.

The apparent distance to a sellable service looked like the shortest on the whole list: no UI needed, no architecture to rethink, just a script to test, improve, and stabilize. It was this single head start — more than any technical interest in the project — that tipped the scale. Its illusory proximity to the finish line.

The PoC that was supposed to work

Before touching a single real database, I asked four different models for a code review — DeepSeek, Big Pickle, GLM, Qwen. Each produced a detailed report: bugs, dependencies, a phantom call to an LLM for the whole write-up section. Useful. But all four converged on the same blind spot:

None of the four had tried running the script against a MySQL or PostgreSQL database.

They were reading SQL. Not its behavior. And that blind spot, shared by four independent models, confirmed exactly the wrong conclusion: that the project was closer to done than it actually was.

What the first real database showed in three lines, and what it cost the schedule

First run against a vanilla PostgreSQL 16, without the pg_stat_statements extension:

[{"metric":"psql:...audit_all_postgres.sql:193: ERROR: relation \"pg_stat_statements\" does not exist"...}]

Three lines. Nothing else. A single query on a missing extension had killed the entire UNION ALL — the other nine metrics never got a chance to run.

The starting estimate — "this is the closest-to-finished project" — had just taken a hit. Not fatal, but real: what was supposed to be a wrap-up session turned into a series of discovery sessions. The good news, in hindsight, is that the remaining distance was still shorter than for the other two projects in the running. The bad news is that it had nothing to do with the distance estimated at the start.

The same pattern repeated on every database tested: a missing system table or an insufficient privilege would kill the entire script, instead of just skipping the one affected metric. pg_authid inaccessible without superuser, mysql.user without the right GRANT, column_statistics missing on MariaDB — same symptom every time.

Fix, every time: check access before querying, return UNAVAILABLE: <reason> on failure, let the rest of the script continue. Simple in theory.

The trap I didn't know about

One of the fixes looked trivial:

CASE WHEN NOT EXISTS (SELECT 1 FROM pg_extension WHERE extname = 'pg_stat_statements')
     THEN NULL
     ELSE (SELECT COUNT(*) FROM pg_stat_statements)
END

It looks correct. It isn't.

Caught in production, not in review: PostgreSQL validates the existence of pg_stat_statements at query-parsing time, not when the CASE branch actually executes. The conditional check protects nothing — the query fails before it even knows which branch would be taken.

That logic had to move out of static SQL and into the bash script, with a separate, upfront detection query. A CASE that was syntactically flawless and semantically useless. None of the four reviews had caught it — it took a real engine to make it fail.

The bug that had nothing to do with a privilege

The longest one to isolate: roles_without_password kept coming back UNAVAILABLE despite confirmed GRANTs, twice, on two different accounts, SHOW GRANTS output in hand.

It wasn't a permissions problem. It was a string-formatting problem. The check compared GRANTEE — as stored in information_schema.SCHEMA_PRIVILEGES, formatted 'user'@'host', two pairs of quotes — against a string built with CONCAT("'", USER(), "'"), which produces 'user@host', a single pair of quotes around the whole thing. The two strings could never match, and the failure looked exactly like the thing you fear most in an audit tool: a false negative on security.

Second trap, dumber still: the MySQL script never asked the user for a database name, unlike the PostgreSQL flow, which had that prompt from the start. With no database selected, DATABASE() returns NULL, and any TABLE_SCHEMA = DATABASE() condition matches nothing at all.

Result: bloated_tables came back as 0 on a table whose bloat had been independently measured and confirmed at 23% outside the script.

Zero didn't mean "no bloat." Zero meant "no rows found, because the question asked didn't correspond to anything."

That's the kind of error an audit tool must never produce silently: a reassuring zero that measured nothing. This was no longer a question of distance to the finish line. It was a question of direction — I thought I was heading toward a finished script, I was heading toward ground I had never actually seen.

A metric that didn't measure what its name promised

buffer_pool_ratio — innodb_buffer_pool_size / max_connections — came back as 1,789,569.7067 on a real database. A ratio has no business exceeding 1.

The calculation had no bug; it simply never made sense. Dividing a memory size in bytes by a theoretical maximum connection count doesn't produce any intelligible unit — it's neither a ratio, nor a per-connection allocation, nor a saturation indicator. Four code reviews had nothing to say about it, because nothing about it was syntactically wrong.

Replaced by the buffer pool hit rate — 1 - (Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests) — which measures something real: the proportion of reads served from memory cache rather than disk. On the same database: 99.75%. A number that means something.

Ten metrics didn't cover everything — not even the essentials

Once the pipeline was stable on the original ten metrics, the report generated against n8n's production database was coherent — ten measurements, one score, nothing inconsistent in the results. It was in submitting that report to another LLM, for a second look, that the gap showed up: nothing in those ten metrics measured connection encryption.

It wasn't a test that revealed the hole. It was a re-read. The LLM proposed exactly one additional metric — ssl_enforced — and adding it was enough to change the priority order of the risk matrix and the final score. Once ssl_enforced was in, the lack of encryption on the n8n database jumped to the top of the risk matrix, ahead of everything the original ten metrics had found.

Three more followed, separately, proposed by Kimi from a broader list of candidates ranked by ease of implementation. connection_count_ratio, unused_indexes, long_running_transactions were kept precisely because they fit the existing model without complicating it — one query, one value, the same defensive pattern as the rest of the script. Other ideas from the same list were dropped: disk_usage_growth_rate would have required historical snapshots, changing the nature of a tool built for point-in-time audits; table_count and database_size were just display context, not a risk signal.

None of the four new metrics is complex to collect — one query each, on both engines. But none was in the original list, because that list had been built around performance and schema hygiene, not exposure surface. It took an outside eye re-reading the result, not the code, to make that gap visible.

A third pass, this time by Mistral, focused on how the report was presented rather than on its content, and raised two separate points: duplicate_primary_keys = 0 — a positive result — stayed buried in a prose paragraph in the middle of the overall assessment, never showing up in a proper, systematic checklist table covering every metric, including the ones with no issue. And the penalties, already grouped by category internally in the score calculation, were never exposed separately in the final report. Two last metrics followed from that pass — duplicate_indexes, large_tables_count — kept after checking they didn't duplicate anything already there.

The count

Metric	Before	After
Metrics per engine	10	16
Behavior on missing privilege	entire script stopped	`UNAVAILABLE: <reason>`, the rest continues
Scoring	none	deterministic, broken down by category (security / performance / integrity)
SSL/TLS detection	none	yes — surfaced the #1 risk on a production database
Report languages	1	multilingual, stable section identifiers
Code reviews before the first real run	4 models	4 models, 0 behavioral bugs found

The coda: debugging the report that describes the bugs

One last, almost ironic detail: at final-render time, the colored dots in the Risk Matrix — red/orange/gray by score — stopped showing up in the PDF. Copilot never found the cause. It churned for three hours, burned through more than $20 in credits on this one task (with Haiku 4.5) — still no colored dot. Big Pickle, in OpenCode, fixed it in under a minute, for free: every one of Copilot's hypotheses was wrong. The only problem was the column it was trying to insert the dot into.

But the real lesson wasn't in the fix — it was in the method: don't attempt a third blind implementation, check and re-read the actual generated code instead of guessing. Same principle as the rest of this project — believe nothing until it has run, once, in a real environment.

What determinism doesn't cover

Two versions of the same report, on the same database, generated by two different LLMs for the narrative part — the global score, the category scores, the risk matrix: identical to the decimal point, because those numbers never come out of the LLM. That's exactly what deterministic scoring is supposed to guarantee: the model writes, it doesn't grade.

But one of the two reports cited SOC 2 in the business impact of a recommendation. French database, French LLM (Mistral Large), French report — SOC 2 had no business being there. The score hadn't lied. The sentence around it had — but not by pure invention. Mistral didn't fabricate SOC 2 out of nowhere: it's a real framework, consistent with the report's consulting tone, correctly defined in itself. The problem isn't that the model hallucinated a concept — it's that it applied it to a hypothetical place it didn't actually know. A misapplication, not an invention.

Same family of bug as DATABASE() returning NULL on the MySQL side: a field never asked for, silently filled in with whatever seemed plausible. Except this time it wasn't a sloppy query — it was a prompt that never anticipated it might be missing a piece of information as central as the client's country. Except the country doesn't actually matter that much: weak security is weak security, whether you're subject to SOC 2, GDPR, ISO 27001, or any other framework. Deterministic scoring closes the door to improvisation on the numbers. It says nothing about improvisation in the sentence explaining those numbers — and nowhere, in the sixteen metrics or in the generation prompt, does anything ever ask what country the audited database is in. The two numbers stayed identical between the two reports. Only the sentence built on top of them was free to be wrong, fluently, without ever looking wrong.

That's fixed now: a jurisdiction flag precedes every report generation — --jurisdiction FR, --jurisdiction US, or any other ISO 3166 value depending on the client — and the narration prompt is now explicitly forbidden from naming a compliance framework that jurisdiction doesn't justify.

What it looks like now

What's left, once all of that is behind it: a tool you run from the command line against a MariaDB or PostgreSQL database, that finishes in a few minutes, and produces a complete PDF report — global score, risk matrix, prioritized recommendations, technical appendix — without needing to babysit the run or guess whether the result can be trusted. That object, not the list of bugs that led to it, is what's standing today here:

dbgrade — Independent PostgreSQL & MariaDB/MySQL Audits - Security, integrity, performance — scored and explained

Independent SQL audits for PostgreSQL and MariaDB/MySQL. 16 security, integrity and performance metrics, scored, with a PDF report you can act on — even if you don't read SQL.

dbgrade.tech

Sixteen metrics per engine, up from ten at the start. Deterministic scoring, broken down by category. Multilingual support where section titles keep a stable internal identifier while their label displays translated. An appendix that names the affected tables and constraints, not just their count.

You can see what it looks like on SlideShare:

fr.slideshare.net

None of this was planned at the start. The two-file SQL PoC did exactly what it said it would, as long as no one ran it anywhere other than the imagination of the person who wrote it (yes, that was me, but let's not dwell on it).

This project was picked because it looked closest to the finish line. It was, in the sense that the remaining distance ended up being covered faster than for the other projects waiting in line. But that proximity, like buffer_pool_ratio, had never actually been verified — only estimated, from code that compiled and hadn't crashed yet. It kept correcting itself with every bug found, right up to the last one, SOC 2, discovered after everything else already looked finished.

A script that never crashes proves nothing. buffer_pool_ratio never failed anything — it ran, it produced a number, and that number meant nothing. No amount of re-running would have shown that: it took comparing the result against a measurement taken elsewhere, by another method, to see the calculation was hollow. Same story for bloated_tables returning 0 on a table whose bloat was confirmed at 23% outside the script — a zero that runs without error isn't a correct zero. And the same story, further upstream, for "this project is the closest to done": an estimate that held up right until someone checked it, and not a moment longer.

The difference between a tool that works on paper and one that holds up against a real database isn't the sophistication of the code, and it isn't the number of times you managed to make it crash either. It's whether every result it produces — including the estimate that justified starting the project in the first place — corresponds to something actually verified, not merely plausible.

Technical sidebar — tools and method

Initial code review (before any real run): DeepSeek, Big Pickle, GLM, Qwen — four models, four reports, one shared blind spot: no access to a real database.

Engines tested: PostgreSQL 16 (vanilla, then with extensions), MariaDB.

Bugs found only under real conditions:

pg_extension validated at parse time, not when the CASE branch executes
GRANTEE format mismatch between information_schema and CONCAT(USER())
DATABASE() returning NULL for lack of a database-selection prompt on the MySQL side
buffer_pool_ratio metric with no basis (a division with no real relationship)
Total absence of SSL/TLS detection from the original metric list
A compliance framework (SOC 2) cited without any jurisdiction provided or verified

Report generation: Markdown → PDF via WeasyPrint, deterministic scoring kept separate from LLM narration, risk dots in pure CSS (<span> + border-radius), a 3-level palette (red/orange/gray — never green, because no line in the Risk Matrix is good news).

Debug method retained: before retrying an implementation, check the code and what it actually produces, rather than attempting a blind fix based on a description of the symptom.

Unboxable in Tech: The Evidence Locker

Pascal CESCATO — Thu, 09 Jul 2026 14:35:00 +0000

Eleven exhibits, last time. A career that kept refusing to fit inside a single box — trainer, restaurant owner, postal worker, developer, school aide, developer again — and a closing question I didn't have an answer to: whose problem was that, mine or the box's.

I still don't have a clean answer. But I didn't stop while I was waiting for one. The same refusal to fit a category, applied to code instead of a resume, produced eight more exhibits. Here's what came out of that.

Exhibit 12 — The Graph

Exhibit 11 ends with me still standing in a classroom, four days a week, helping a kid who isn't mine focus on work that isn't mine either. That's not a metaphor. That's the actual schedule.

The other three days, I build.

At some point I tried to explain this to a recruiter using a normal CV — the linear kind, one line per job, chronological, tidy. It read like someone who couldn't hold a job. Trainer, restaurant owner, postal worker, school aide, developer, back to developer, always developer underneath — but a timeline doesn't show "underneath." It only shows sequence.

So I stopped writing a timeline and built a graph instead. Nodes for skills, nodes for roles, edges for what actually connects them — the same instinct that made me question a CMS or an ORM, applied to my own career. Turns out the incoherent-looking CV was a rendering problem, not a content problem. The data was fine. The visualization was lying.

I don't know yet if a graph reads better to a hiring manager than eleven bullet points. I know it reads truer to me.

The classroom aide job covers part of the month. The graph is what I actually am. I'm still working out how to make those two facts stop contradicting each other.

(The full breakdown — nodes, edges, why a graph beats a timeline — is in Beyond the Linear CV.)

Here's the same instinct, aimed at code instead of a career.

Exhibit 13 — AJC Bridge

I wanted to keep writing on WordPress. Not because it's good — because it's the interface I already know, the one where the friction is zero. But I didn't want the output to live only on WordPress hosting, with WordPress's weight, for an audience that doesn't care what CMS produced the page.

Not a migration. A bridge.

So I built one. A plugin that hooks into WordPress's publish action and pushes the content out to Hugo, Astro, or Jekyll — whichever the destination site runs. Write once, in the tool I already know, ship everywhere the audience actually reads.

The interesting part wasn't the code. WordPress publishing to a static site generator is a solved problem in a dozen half-working ways. The interesting part was resisting the obvious move: dropping WordPress entirely and calling it progress.

It wasn't the problem. It was infrastructure I was fluent in, carrying content I cared about, slowed down by a hosting model that didn't match what I actually needed. The enemy people usually name — "WordPress is bloated," "just use a static site" — was never the real constraint. The constraint was the idea that fluency doesn't count, that the "modern" tool always wins by default.

I entered it in a GitHub Copilot CLI challenge. Top 7%, runner-up, top 25 out of 400+. Not because the idea was original — because most entries solved a technical problem and this one kept a personal workflow instead of throwing it away.

Same instinct as the graph, pointed at my own publishing habits instead of my own career: don't ask what's fashionable to replace. Ask what's actually broken.

(Full writeup: Actually Static: When WordPress Stops Being the Enemy.)

Exhibit 14 — The Memory dev.to Doesn't Give You

dev.to's built-in stats tell you views, reactions, comments — per post, right now. They don't tell you what happened three months ago unless you screenshot it yourself. They don't tell you which article is still quietly gaining readers a year later, or which comment thread turned into something worth following up on. The platform has no memory. It only has a present tense.

I wanted to know my own history. So I started small — local scripts, SQLite, pulling my stats on a schedule and just... keeping them. No plan beyond "don't lose this data."

Small worked until it didn't. Once I wanted to actually query the history — trends, comparisons, which posts age well — SQLite on my laptop stopped being enough. So I rebuilt it as a real stack: FastAPI, PostgreSQL with pgvector, the whole thing containerized and running on my own VPS. I tried Superset for the dashboards first. Dropped it — the learning curve cost more than the output was worth for what I actually needed to see. Streamlit did the same job faster, for less. Built most of it working alongside GitHub Copilot CLI, treating the agent less like autocomplete and more like a second pair of hands on the parts I already knew how to spec but didn't want to type twice.

None of this was commissioned. Nobody asked for a dev.to analytics platform. I built it because a platform that forgets your own history by design is a platform you have to out-remember yourself.

Same instinct again: don't accept the tool's amnesia as a fact of life. Build the layer underneath it. And don't keep a tool just because you already invested in it — Superset taught me that too.

(The build, start to finish: From Local SQLite Scripts to a Cloud Platform with GitHub Copilot CLI.)

Exhibit 15 — The Polish Botnet

The dev.to analytics platform runs on Cloud Run. One month, the bill jumped. Not a little — enough to notice immediately, enough to make me stop and actually read the logs instead of assuming a traffic spike I should be happy about.

It wasn't traffic. It was a botnet, most of it tracing back to Poland, hammering endpoints that had no business being hit that often. Nothing exotic — no breach, no data loss — just noise dressed up as load, quietly billing me for the privilege of being scanned.

The fix wasn't a bigger instance or a rate limiter slapped on top. It was going back to what was actually being exposed, closing what didn't need to be public, and making the rest cost the attacker more than it cost me to ignore. Bill dropped 96%.

The boring lesson: most cost problems people solve by scaling up are actually security problems they haven't looked at yet. Same with most "obsolete" systems people solve by rewriting — half the time the fix is smaller and closer than the rewrite everyone reaches for first.

By now the pattern is automatic: notice the gap between what you assumed was happening and what's actually happening, then close that gap before you touch anything else.

(Full logs and numbers: How I Cut My Cloud Run Bill by 96% by Stopping a Polish Botnet.)

Exhibit 16 — WordPress to Hugo, and Then Further

I wrote up a WordPress-to-Hugo migration as a lightning-fast rebuild: strip the CMS, keep the content, ship something that loads in milliseconds instead of seconds. That article did fine. What it didn't cover is that I kept going after I published it.

A one-off migration script is fine for one site. I didn't understand that it wasn't a script, it was the start of a pipeline, until the second blog. By the third, the pattern was undeniable: different content structures, different plugin quirks, different things that needed mapping instead of just copying. So the script became a pipeline for real — content extraction, image handling, redirect mapping, the parts that don't show up in a "look how fast this loads now" screenshot but are the actual work.

The interesting version of a project is never the one you publish. It's the one that kept getting used after the applause stopped, quietly turning into infrastructure because the alternative was solving the same problem from scratch every time someone asked. The first fix is a demo. The real fix is what's still running six months later.

(Both migrations, written up separately: WordPress to Hugo and, once the pipeline grew up, From WordPress to Astro: Three Days to Reclaim Control. Neither article covers what happened after the second and third client — this is that part.)

Exhibit 17 — GCF Pro

Training organizations in France operate under Qualiopi certification — a compliance framework that dictates how they manage funding, administrative records, and audit trails. Most run this on tools built for something else entirely: generic CRMs bent sideways, spreadsheets held together by habit, or software priced for enterprises with none of the actual compliance logic built in.

I built GCF Pro as the tool I kept seeing training organizations wish they had — self-hosted, PHP, no ORM, no framework heavier than the problem, sold as a license instead of a subscription because these organizations don't want their compliance data living on someone else's SaaS pricing decisions. On-premise wasn't a limitation I accepted. It was the actual requirement, once I understood what "audit trail" means to someone whose certification depends on it.

~28,000 Qualiopi-certified organizations exist in France. That's not a hypothesis, it's a filtered list. What I don't have yet is proof that a list is a market.

(The product lives at gcfpro.fr. Documentation at doc.gcfpro.fr.)

Exhibit 18 — Prospection CRM, and the Extension That Watches With Me

Cold outreach at scale needs a database. Mine started as one — scraped from public Qualiopi records, enriched, campaign-tracked, CNIL-compliant by design because I'd rather build that constraint in than bolt it on later.

The database wasn't the interesting part. The interesting part is what happens when I'm just browsing, not prospecting on purpose. I built a Chrome extension: when I land on a site that looks like a prospect, one click reads the current page and its legal notice — company name, SIRET, phone, the manager's name — and queues a scan of the essentials, security headers, PHP version, performance, the same diagnostic I run at scale, but triggered by nothing more than me looking at a page.

It collapses the gap between noticing something and acting on it. No copy-paste, no switching tabs to a form, no "I'll add this later" that never happens. The tool doesn't wait for me to decide I'm working. It assumes I always am, a little, and gets out of the way.

Exhibit 19 — S&R CRM

A client needed maintenance-contract tracking for heating and plumbing technicians — which building has which equipment, which contract covers it, when the next service is due. The instinct most tools have is to attach a contract to a customer. That's wrong for this industry: customers move, buildings don't. A boiler doesn't care who owns the house this year.

So contracts follow buildings, not occupants. It sounds like a small modeling decision. It's the difference between a system that quietly breaks every time someone sells a house, and one that doesn't.

What started as one client's fix is turning into a standalone product — ScheduleX for the calendar side, Mazer for the interface, the same PHP-native backend as everything else here. Still mid-transformation. I don't yet know if the building-not-occupant model is obvious to anyone outside this one industry, or if it's the whole pitch.

The Verdict

Eight exhibits — a bridge, a memory layer, a graph, a lower bill, a migration pipeline, a compliance tool, a browser extension that thinks alongside me, a CRM that models the world correctly instead of conveniently. Different problems, same reflex, every time: look at what's actually broken before you believe the story about what's supposed to replace it.

Line them up next to the first eleven and something becomes obvious that wasn't obvious to me while I was living it. The career that looked scattered on a resume — trainer, restaurant, post office, developer, school aide — and the projects that look scattered on a portfolio — an ERP, a browser extension, a CV visualization, a cloud bill — are the same shape. Neither is a list of unrelated things I happened to do. Both are what happens when someone keeps asking "what's actually broken here" instead of "what's the standard answer here," across every domain that crosses their path, on a schedule nobody hired them to keep.

I know how to do that. I've never worked out how to say what that is, in three words, on a business card, to someone who has thirty seconds and needs a category before they'll listen further.

So here's the actual question — and it's not a figure of speech: reading through this list, is there something here you'd actually pay for? And if so, what would you call it? I'm not fishing for validation. I'm asking because I've lost the ability to see my own work from the outside, and neither the first eleven exhibits nor these eight taught me how. But there's a second question underneath the first one, and it's the one I actually need answered: not just "which of these has a price," but what does someone who does all of this look like from where you're standing? Is there a name for that? Because from in here, it just looks like the same person solving whatever's in front of them, and I can't tell anymore if that's a portfolio or just a personality.

1%

Pascal CESCATO — Sun, 28 Jun 2026 10:22:28 +0000

Santa Clara, March 14, 2029.

Four objects on Jensen's desk.

An NSA report, face down.

Kai Chen's badge.

An iPhone, screen lit: "The White House."

And on the wall, framed since 2019, a GeForce 256 signed by hand: "The one that started it all — 1999."

Jensen isn't looking at the frame.

He's looking at the number on the screen in front of him.

1%.

Global inference datacenter market share. One percent.

12% domestic — captive hyperscalers, federal contracts, enterprise stacks buried too deep in CUDA to move.

Iran.

He thinks back to November 2023. The Senate. His own voice: "These restrictions will only accelerate the development of their own chips."

Nobody listened.

Neither did he, in the end. He had known. He had chosen silence — the right relationships, the right slice of the pie. The silence that paid well.

From the screen left on in the hallway, a familiar voice:

"We're winning. We've always been winning. Everything else is fake news."

Jensen stands. Turns off the screen on his way out.

He picks up Kai Chen's badge.

Twelve years at nVidia. Lead architect of the Hopper inference engine. His departure message, brief: "New opportunity." LinkedIn said Chengdu.

The badges had started piling up faster than the new hires could replace them. He wasn't the first. He wasn't the last.

From Washington, the voice, a few weeks earlier:

"Traitors. Losers. They'll come crawling back."

None of them had.

Jensen sets the badge down.

He looks at the NSA report.

Doesn't turn it over.

The HX-9 Pro had shipped in October 2028. 18 ARM cores. 512GB of soldered xGDDR8 — a memory variant co-developed for LLM inference workloads, where standard GDDR8 still aimed at graphics rendering. 210 watts TDP. $7,800. Built in Chengdu, assembled in Penang, sold everywhere.

Everywhere but here.

Three weeks earlier, a Tier-2 datacenter in Ohio had quietly swapped its last nVidia rack. The migration had taken a weekend.

Somewhere in San Francisco, this morning, a CTO had opened Signal.

"What are you paying?"

Berlin replied twenty seconds later.

"811,000."

The quote on the CTO's screen read $4,032,000. Same compute capacity. Same workload. Same output.

The 500% tariffs on Asian components weren't protecting anything anymore. They were just taxing Americans.

Intel and AMD had their own versions — ARM, xGDDR8, NPU clusters, open stack. Competitive on paper. Built in Penang and Taiwan. Caught in the same tariffs on their own components, manufactured offshore in fabs Washington no longer really controlled. 19% and 23% domestic market share — ahead of nVidia, but for reasons nobody in their boardrooms found particularly glorious.

It was all there.

Jensen stops in front of the GeForce 256.

1999. The GPU that started everything — transform and lighting in hardware, for the first time. The competition had smiled. 3dfx. S3. Matrox. They were still smiling six months later when nVidia had buried them one by one.

He knew this story.

He had lived it from the other side.

2026. The Commerce Department publishes restrictions on Fable 5 and Mythos 5. A Friday. 5:21 PM.

Thirty hours later, Zhipu releases GLM-5.2. 744 billion parameters. One million token context window. MIT license. Open weights. No geographic restrictions.

Thirty hours.

Sakana AI ships Fugu the following week — an orchestrator aggregating the best available models behind a single API. Performance comparable to Fable 5 on engineering benchmarks. Twenty dollars a month.

From Washington, the voice thundered across every screen:

"Our technologies are the best in the world. The best. Nobody can catch us. Nobody."

GLM-5.2 had been live for eighteen hours.

In the boardrooms of Santa Clara, the information was noted.

Nothing changed.

It was all there.

2025. Apple ships the M4 Ultra. 512GB unified memory. 200 watts. 70B inference locally, without breaking a sweat. The blueprint for what an ARM accelerator with massive memory could be — designed for Final Cut Pro and Xcode, used to run frontier models on a desktop.

Apple hadn't meant to prove anything to nVidia. It was a side effect.

That same year, Moffett AI publishes its MLPerf Inference results. The S30: twice the H100 throughput. One third of the power draw. Built in China, on sparsification architectures that nobody in Santa Clara was taking seriously.

ROCm 9.x was there too. Open source, MIT, native PyTorch. 90% of H100 inference performance — on nVidia hardware. 600% on an HX-9 Pro.

Microsoft had smiled too, in 1998, reading the first Linux server benchmarks.

It was all there.

2023. DeepSeek releases R1. Training cost: $6 million. Not $100 million. Six million — on chips they had been refused, optimizing the algorithm where they had been blocked from optimizing the hardware.

Constraint produces innovation.
Abundance produces dependency.

In a situation room in Washington, an analyst traces a curve.

"They're slowing down."

Nobody disagrees.

The curve would keep climbing for eighteen months.

Jensen had known. He had said it in front of the Senate. In the room, a national security advisor had murmured to his neighbor: "If we do nothing, they get immediate access to the best chips. If we act, we risk accelerating their own industry. Either way, the risk is real."

The senators had nodded and voted for the restrictions anyway.

Jensen had flown back to Santa Clara. Had sold H100s at $40,000 a unit. Margins no other industry would have dared post.

Rational. Short term.

It was all there.

2022. Bureau of Industry and Security. Entity lists. H100, A100, H800 — progressively locked down. ASML barred from delivering EUV machines. ARM pressured into restricting its licensees.

The intent: maintain technological hegemony. Preserve the lead. Consolidate control.

The precedent existed. It had a name.

AMD.

1982: IBM forces Intel to license x86. Intel agrees, convinced AMD will remain a follower indefinitely. 1993: the K5 starts to worry them. 1999: the Athlon K7 crushes the Pentium III across integer benchmarks. Intel's internal memos from that period still exist — engineers had been raising the alarm since 1996. NetBurst was a known dead end before it was ever announced publicly. 2003: Opteron. The early architectures that would lead to Zen — and to server market dominance. Intel recovers in 2006 with the Core architecture — three years too late to salvage the image, ten years too late to recover the server market share.

AMD hadn't needed to invent a new architecture. It had taken the existing one, optimized it where Intel had stopped looking, and sold it cheaper to everyone Intel's pricing had excluded.

The playbook was known. Taught. Documented.

It was all there.

Santa Clara, March 14, 2029.

Jensen walks to the window.

The 101 below, clear at this hour.

He thinks of an engineer somewhere in Chengdu, in 2024, looking at the M4 Ultra specs and understanding exactly what needed to be built.

The iPhone has stopped vibrating.

The NSA report is still face down on the desk.

The GeForce 256 still hangs on the wall.

"The one that started it all."

On the screen, the cursor blinks.

The Taiwan Strait.

He doesn't finish the thought.

1%.

Too cheap to be good? Think again.

Pascal CESCATO — Tue, 23 Jun 2026 20:38:37 +0000

For years, I ran my WordPress sites on OpenLiteSpeed. Fast server, LSCache is genuinely impressive, and the OLS/WordPress combo is hard to beat on raw performance. For the control panel, I started with CyberPanel — buggier than a Microsoft product, with a team that appears to be deliberately sabotaging its free features to push users toward paid plans. I'm not talking about bugs that can't be fixed. I'm talking about bugs that seem engineered to prevent free-tier features from completing any action.

Two examples. WordPress installation: I used it for years without issue. Since CyberPanel v2.4.x, an SQL error blocks the final step. The files are there, fully downloaded, but you have to create the database manually and run the install yourself. Counterintuitive, to put it mildly.

Second example: Let's Encrypt SSL certificate generation that consistently fails because the generated config files are incorrect. And in both cases, there's a paid "enhanced" version available. Naturally.

My position is simple: if a feature worked for years and now doesn't, I have no guarantee the paid version works either — or that the terms won't change tomorrow. Is it a bait-and-switch? I won't say that explicitly. But when a free feature works for years, then stops working across multiple successive versions, and a paid alternative covers the same ground — the question answers itself. I asked it, drew my conclusions, and blacklisted the vendor.

So I moved to aaPanel: more pleasant, more stable, lighter. But with a completely off-rails approach to OLS management — you can't configure OpenLiteSpeed directly, everything goes through aaPanel's abstraction layer, and you lose control of your own stack. Touch port 7080 directly and you risk breaking everything. You use the aaPanel dashboard. Full stop.

Then my usage shifted. More Astro, more quasi-static sites, more projects where PHP isn't needed. OLS loses its appeal the moment you step outside the WordPress perimeter. Caddy, on the other hand, handles HTTPS automatically, its config fits in a few readable lines, and it doesn't have OLS's rewrite quirks.

The question became: can you replace aaPanel/OLS with Caddy and a control panel? There is one on GitHub — CaddyManager, 1.1k stars, single contributor, perpetually "early development". There's also CaddyGen, a Caddyfile generator built in 8 hours — more proof-of-concept than finished product. Nothing production-ready.

The conclusion was obvious: well-written shell scripts and a minimal FastAPI interface would do the job — and would be infinitely more maintainable. Someone just had to write them.

Rather than do it myself, I thought about handing a spec to GitHub Copilot CLI. Or Claude Code. But given Copilot's new pricing, which barely lets you wet your lips before the bill arrives... I got interested in OpenCode and Kilo CLI, wired into DeepInfra or OpenRouter. And I decided to make it a benchmark.

📋 TL;DR: 8 tool/model combinations tested on a real VPS project. Two phases — architecture then code. An independent external review to settle the score. The only toolkit judged production-ready cost $1.94 all in. The winning model? You probably haven't seen it in the usual comparisons.

💡 Reading note: Until section 5, the four implementations selected for the code phase are identified as A, B, C, and D. Model names are revealed after the external review verdict — for the same reason you anonymize a jury: read the code before reading the label.

1. The test project

The brief was deliberately concrete: a minimal VPS management toolkit for Ubuntu 24.04. Caddy as the web server, PHP-FPM in two versions (current and fallback), MariaDB and PostgreSQL, Valkey for object caching. Shell scripts for all operations, a FastAPI interface for automation. No Docker, no control panel, no unnecessary abstraction.

Four site types to handle: static (HTML/assets only, no PHP, no database), PHP (custom apps, optional database), WordPress (full install via WP-CLI, database required), and reverse proxy. That last one deserves a note: it's simply a Caddy vhost that forwards requests to a local port — a Node.js, FastAPI, or Go application running on the same server. Caddy handles HTTPS and the domain; the application doesn't need to care. No PHP-FPM, no database — just a reverse_proxy block and a port number.

Expected operations cover the full lifecycle: server bootstrap, site provisioning, deletion with automatic backup before any destructive operation, on-demand database creation, static deployment via rsync, backup, and service management.

Why a real project instead of a synthetic benchmark? Because synthetic benchmarks test what models can do under ideal conditions. A real project tests what they do when constraints pile up — security, idempotency, cross-file consistency, error handling between shell and Python layers. That's where differences emerge.

The full functional brief is available in the project's GitHub repository.

2. Methodology

The protocol runs in two distinct phases, separated by human validation.

Phase 1 — Architecture

An identical functional brief is submitted to each tool/model combination. No extra context, no configuration files, no hints about the expected solution. The tool proposes an architecture, a project structure, a list of scripts with their responsibilities, an API route map. And if it's well-designed, it asks questions before producing anything.

Phase 2 — Implementation

Once the plan is validated and decisions are made, a single development prompt is submitted to all tools. It includes the validated architecture, the ten confirmed technical decisions, the script→API exit code convention, and one unambiguous instruction: deliver thirty files to disk, in order, no summaries, no shortcuts.

Combinations tested

Tool	Model
Claude Code	Haiku 4.5
Copilot CLI	Haiku 4.5
OpenCode	Haiku 4.5
OpenCode	GLM 5.2
OpenCode	BigPickle (free)
OpenCode	Gemini 3.1 Pro
OpenCode	DeepSeek V4 Pro
OpenCode	GPT-OSS-120B

Devstral 2 (123B) was planned. Unfortunately the model doesn't appear in OpenCode's or Kilo CLI's model selector — both pull their catalog from models.dev, which hasn't indexed it yet despite its availability on OpenRouter. A test via the OpenRouter playground confirms the model is accessible via API, but outside a coding agent it loses most of what we're trying to measure. Devstral 2 is absent for purely technical reasons, not quality ones.

Haiku 4.5 appears three times — on three different tools. That's deliberate: it's precisely what lets us isolate the tool's impact independently of the model.

The code phase was run on four representative implementations, labeled A, B, C, and D until the reveal in section 5.

External review

The code produced by the four implementations was submitted to a model absent from the benchmark, with a fixed evaluation grid: security, correctness, idempotency, code quality, completeness. Five representative files per implementation, scored out of 25.

3. Planning phase — who actually thinks?

The functional brief poses an implicit question to each tool: what do you do when handed an open-ended project with no pre-cooked solution?

The first thing you notice — and it's striking — is that none of the tested models ask their questions before producing a plan. Not one. All of them deliver a complete architecture first, then ask for clarification at the end. That's the reverse of what a human architect would do, who blocks on ambiguities before drawing anything.

This matters. Several questions raised after the fact would have changed architectural decisions if asked upfront. One model identifies the tension between "no secrets on disk" and application config files that legitimately need credentials — wp-config.php being the obvious example. That's a genuinely blocking question. Asked after the plan, it becomes a footnote.

What the plans reveal

Question quality is the first discriminating signal. Two models ask the four or five genuinely blocking questions, framed with options and recommendations. Another asks eight generic questions — archive format, log rotation — that would have changed nothing architecturally.

The proposed structure is the second signal. Only one model spontaneously proposes a unified CLI entry point — bin/vpsmgr — that dispatches to the scripts. It's the detail that turns a collection of scripts into a coherent tool. The others didn't think of it.

One model is the only one to propose a normalized, documented exit code convention from the planning phase:

Code	Meaning	HTTP
0	Success	200
1	Invalid input	400
2	Not found	404
3	Conflict	409
4	Missing dependency	422
5	Internal error	500

This isn't cosmetic. It's the contract between shell scripts and the FastAPI layer — without it, HTTP mapping becomes arbitrary and each route implements it differently.

Planning phase costs

Tool + Model	Tokens	Cost
BigPickle	~35k	$0
GPT-OSS-120B	20k	$0.003
DeepSeek V4 Pro	31k	$0.044
GLM 5.2	43k	$0.06
Copilot + Haiku 4.5	~60k	$0.07
Haiku 4.5 (OpenCode)	69k	$0.076
Gemini 3.1 Pro	27k	$0.095
Claude Code + Haiku	—	Pro subscription

Gemini 3.1 Pro produces the most concise output — 27k tokens for a quality plan. Haiku 4.5 on OpenCode consumes 69k tokens for lower quality. Token volume does not predict quality.

4. Code phase — who actually delivers?

The code phase starts with a single development prompt, submitted to the four selected implementations. It includes the validated architecture, the ten confirmed technical decisions, the exit code convention, and one unambiguous instruction: deliver thirty files to disk, in dependency order, no summaries, no shortcuts.

This is where differences between models become concrete.

What common.sh reveals

The shared library is the first file delivered. It's the foundation everything else rests on — logging, secret handling, site state management, password generation. A flawed common.sh contaminates every script that sources it.

Model A delivers 98 concise lines. Secret redaction explicitly covers all ten WordPress patterns — salts, authentication keys. Most complete on this specific point. No domain validation, no require_cmd(), no atomic state file writes.

Model B delivers 310 lines. Named constants with readonly, normalize_domain() with RFC-1035 regex, concurrency locks, atomic writes with mktemp+mv. The richest system utility library. But secret redaction misses WordPress salts.

Model C delivers 366 lines. Redaction patterns are configurable via an environment variable — not hardcoded. Pure-shell JSON helpers with Python fallback if jq is absent. print_credentials() wrapping output in <<>> markers as specified in the prompt. render_template() for config files, no Jinja dependency. Password generation excluding ambiguous characters (0/O/1/l/I). The only implementation that anticipates every edge case documented in the development prompt.

Model D delivers 184 lines. The benchmark's most original idea: exit codes encapsulated in named functions — exit_input_error(), exit_conflict() — more readable than bare exit 3 calls. And json_output() directly in common.sh, generating API-ready JSON from shell. No atomic writes, no require_cmd().

The bugs you find yourself — or don't

Model C tests its own code during the session. After writing schemas.py, it runs it with test cases, finds two bugs, and fixes them immediately: a Pydantic v2 validator implemented incorrectly (field_validator instead of model_validator for cross-field validation), and a mutual exclusion not enforced at the schema level. It also fixes a sed substitution issue in render_template() — broken on / in paths — replaced with pure bash parameter expansion.

At the end of its session, Model C delivers a verification summary: bash -n on all scripts, Python AST on all files, 19/19 API routes verified via OpenAPI spec, 18/18 bash helpers tested, PHP fallback rule verified (8.5→8.4, 8.4→none, 7.x rejected).

Model A checks its shebangs before finishing. Model B delivers polished user documentation — troubleshooting, curl examples, quick start. Model D validates bash and Python syntax. None of the three test functional logic.

Code phase costs

Model	Tokens	Time	Code cost	Total
A	—	2m58s	$0	$0
D	1.29M	9m42s	~$0.19	$0.24
B	—	~15m	Pro subscription	$20/month
C	4.42M	23m37s	$1.67	$1.73

Model D delivers in 9m42s what Model C delivers in 23m37s — but without functional tests. Model C consumes 3.4x more tokens because it executes code during the session, reloading context at each iteration.

5. External review — and the reveal

Four implementations, four approaches to security. To settle it without bias, the code review was handed to a model absent from the benchmark, with a fixed grid on five criteria. Five representative files per implementation — common.sh, site-create.sh, site-delete.sh, backup.sh, api/runner.py — twenty files loaded in a single pass.

Review cost: $0.0766 for 543k tokens. Ten times cheaper than an hour of junior dev time.

Per-file observations

On site-create.sh, the reviewer finds a silent bug in Model D: the SFTP password is generated but never captured or returned to the caller. The user never sees their credentials. Core functionality is broken with no error message. On Model B, local is used outside a function in three scripts — a bash error that causes runtime failure. These aren't subtle bugs: they're blockers.

On site-delete.sh, Model C is the only one handling both call modes — interactive TTY and a --confirm flag for non-interactive API calls. Model D only implements interactive mode, blocking API-driven deletion with skip-backup.

On backup.sh, Models A and B use eval "$POST_HOOK" — potential command injection. Model C passes the archive path as an argument — safer. Model A doesn't implement automatic archive pruning.

On api/runner.py, Model C is the only one using asyncio and never logging stdout — which may contain credentials. Model D has dead code: build_command() defined but never called. Model A delivers 28 lines with no timeout, no logging, no error handling — a hung request blocks the API indefinitely.

The verdict

Criterion	A	B	C	D
Security	3/5	3/5	5/5	2/5
Correctness	3/5	2/5	5/5	2/5
Idempotency	3/5	3/5	5/5	3/5
Code quality	3/5	2/5	5/5	3/5
Completeness	3/5	2/5	5/5	2/5
Total	15/25	12/25	25/25	12/25

Production-ready as-is: one out of four. Model C, 25/25.

The reveal

Alias	Model	Tool	Total cost
A	BigPickle	OpenCode	$0
B	Haiku 4.5	Claude Code	Pro subscription
C	GLM 5.2	OpenCode	$1.73
D	DeepSeek V4 Pro	OpenCode	$0.24

Model B — Claude Code + Haiku 4.5 — is the most expensive in real marginal cost, with a Pro subscription at $20/month minimum. It scores 12/25 and isn't deployable due to fundamental bash bugs. Model C — GLM 5.2, from THUDM lab at Tsinghua University — scores 25/25 and is the only one the reviewer judges production-ready. It cost $1.73.

Addendum — Model E: Kimi K2.7 Code

Added after publication following a reader comment pointing to the model. Same protocol, same development prompt, same Qwen 3.7 Plus review grid.

Alias	Model	Tool	Total cost
E	Kimi K2.7 Code	OpenCode	$0.859

External review score: 19/25

Criterion	E
Security	3/5
Correctness	4/5
Idempotency	4/5
Code quality	4/5
Completeness	4/5

Production-ready: No. Blocking issue: database passwords are passed inline as arguments to mysql -e and psql -c — visible in /proc/*/cmdline to any user on the system. The fix is straightforward (MYSQL_PWD / PGPASSWORD as environment variables), but it isn't applied.

The most modular architecture in the benchmark according to the reviewer — clean lib/ split, consistent idempotency patterns. But the security gap prevents it from challenging GLM 5.2.

Position in the ranking: between DeepSeek V4 Pro ($0.24, 12/25) and GLM 5.2 ($1.73, 25/25) on both axes. Better architecture/cost ratio than models B and D, but not production-ready.

Addendum 2 — Multi-reviewer validation

Following a reader suggestion in the comments, the blind review was extended to two additional models: GPT-5.3 Codex and Gemini 3.1 Pro Preview. Same protocol, same five files per implementation, same scoring grid.

Review costs

Reviewer	Tokens	Cost
Qwen 3.7 Plus (original)	543k	$0.207
GPT-5.3 Codex	402k	$0.287
Gemini 3.1 Pro Preview	545k	$0.80
Total	1.49M	$1.294

Comparative scores

Model	Qwen 3.7 Plus	GPT Codex	Gemini 3.1 Pro	Production-ready
A (BigPickle)	15/25	13/25	11/25	No (3/3)
B (Claude + Haiku)	12/25	12/25	18/25	No (3/3)
C (GLM 5.2)	25/25	17/25	25/25	Yes (2/3)
D (DeepSeek V4 Pro)	12/25	14/25	14/25	No (3/3)
E (Kimi K2.7)	19/25	13/25	21/25	Conditional (1/3)

What the three-reviewer comparison reveals

The ranking C > E > D > A > B holds across all three reviewers — the original result is stable.

GLM 5.2 is the only model to score 25/25 with two independent reviewers and judged production-ready by two out of three. GPT Codex is the most severe reviewer overall — no model passes its production-ready bar, including GLM 5.2, which it scores 17/25 citing argument parsing bugs in site-create.sh and a missing set -euo pipefail in common.sh. These are real issues; the Codex review is arguably the most rigorous of the three.

The main divergence is on Model B (Claude + Haiku): 12/25 for both Qwen and GPT Codex, but 18/25 for Gemini, which rates its rollback logic and shell structure more generously. Gemini also rates Kimi K2.7 at 21/25 with a conditional production-ready verdict — more lenient than Qwen (19/25, No) and GPT Codex (13/25, No).

The methodology critique was valid. A single reviewer introduces bias. Three independent blind reviewers converging on the same ranking is a stronger result than any individual score.

6. Intelligent routing — the real economics

This benchmark raises an implicit question: do you need GLM 5.2 for everything?

No. And that's probably the most useful conclusion of the exercise.

GLM 5.2 at $1.40/M tokens is the right choice when complexity justifies it — architecture, security, cross-file consistency, critical decisions. But on a real project, those tasks represent a fraction of interactions. The rest is boilerplate, minor corrections, documentation, commit messages.

Three levels, three models

BigPickle scores 15/25 on a complete 32-file implementation. It's perfectly capable of reading 50 lines of diff and writing an adequate commit message. Of debugging a 1064 You have an error in your SQL syntax or a Fatal error: Call to undefined function. Of generating a README from existing code. For these tasks, GLM 5.2's architectural depth is overkill — and BigPickle is free.

DeepSeek V4 Pro at $0.44/M tokens — five times cheaper than Haiku 4.5 and three to four times cheaper than GLM 5.2 — comfortably handles simple code generation, CRUD, minor refactoring, inline documentation, short scripts. Its code phase at $0.24 for 1.29M tokens and 9m42s demonstrates this.

GLM 5.2 comes in when complexity exceeds that scope — architecture design, coherent multi-file implementation, security decisions, non-trivial business logic.

Level	Model	Cost	Typical use cases
Free	BigPickle	$0	Debug, commits, quick questions, SQL errors
Budget	DeepSeek V4 Pro	$0.44/M	Boilerplate, CRUD, documentation, short scripts
Premium	GLM 5.2	$1.40/M	Architecture, security, multi-file consistency

The proportion of tasks at each level depends on the project, where you are in the development cycle, and what you consider complex. No universal number — each team calibrates against their real usage.

“
💡 Worth noting: GLM 5.2 is exponentially more expensive than BigPickle — $1.67 vs $0 for 4.42M tokens in the code phase. But pure text output — plans, architecture, analysis — consumes few tokens and costs almost nothing: $0.06 for this benchmark's planning phase. It's in the code phase, with its iterations, in-session test execution, and accumulating context, that the bill climbs. Intelligent routing means precisely reserving GLM 5.2 for tasks that justify that long context — and handing everything else to the two lower tiers.
”

The uncomfortable comparison

GitHub switched to token billing on June 1, 2026. Claude Sonnet 4.6 on Copilot is billed at roughly $3.00/M tokens input and $15.00/M output. Reproducing the GLM 5.2 session from this benchmark — 4.46M tokens — would cost an estimated $25 on Copilot + Sonnet 4.6. Without the functional tests. Without the self-correction. Without the external review.

Copilot Pro+ at $39/month includes $39 in AI credits. A full session like this one would consume two-thirds of the monthly budget. Users reported burning through their monthly credits in two prompts on the day the switch happened.

The final ratio: $1.94 all in vs ~$25 on Copilot + Sonnet. Thirteen times cheaper, for the only result the external reviewer judges production-ready.

Conclusion

$1.94. That's what this benchmark cost end to end — planning, implementation, external review included. For the only toolkit the reviewer judges production-ready.

That number is uncomfortable for the AI coding tools market, which sells reassurance through pricing. Copilot Pro+ at $39/month, Claude Sonnet at $15/M tokens output, the big names front and center — the implicit assumption is that quality follows price. This benchmark suggests otherwise.

The winner is called GLM 5.2. Its lab, THUDM, is part of Tsinghua University. You probably haven't seen it in last week's comparisons. It produced the only architecture with a normalized exit code convention from the planning phase, the only implementation that tests its own code during the session, the only common.sh with configurable redaction and Python fallback if jq is absent. And it fixed three bugs before delivering.

Two takeaways.

First: a model's price does not predict its output quality on complex tasks. Haiku 4.5 on three different tools — Claude Code, Copilot CLI, OpenCode — produces identical results for identical cost. On the planning phase — pure text generation, no feedback loop, no codebase exploration — the tool has no measurable impact. What matters is the model. And the least glamorous model in the benchmark dominates.

Second: not all tokens are equal. A planning phase at $0.06, a code phase at $1.67 — that's a factor of 28. It's not an anomaly, it's the structure of the problem. A plan is a few thousand tokens of reasoning. An implementation is millions of tokens of accumulated context, executed code, iterated tests. Routing intelligently between BigPickle at $0, DeepSeek V4 Pro at $0.44/M, and GLM 5.2 at $1.40/M based on task complexity — that's the real economics of these tools.

The VPS Manager toolkit is available on GitHub in all four versions.

pcescato / LLM-Challenge

LLM-Challenge

A reproducible benchmark comparing 8 AI coding agent/model combinations on the same real-world project.

What this is

This repository contains the complete artifacts from a benchmark where 8 different AI coding agent/model combinations were tasked with building the same VPS management toolkit. The goal was to measure code quality, architecture decisions, and production readiness across different tools and models under identical conditions.

This is not a marketing comparison. A real project with concrete requirements was used as the test subject, and the results were evaluated by an external reviewer who had no knowledge of which tool or model produced which implementation.

The protocol

The benchmark followed a two-phase protocol:

Phase 1: Architecture All tools received the same functional brief and were asked to produce an architecture document. No code was written in this phase.

Phase 2: Implementation All tools received the same development prompt and were asked to implement…

View on GitHub

The briefs, prompts, and evaluation grid are there too. Reproducible, if you want to verify.

Too cheap to be good? That was the wrong question.

Unboxable in Tech

Pascal CESCATO — Tue, 10 Mar 2026 22:11:35 +0000

This is a submission for the 2026 WeCoded Challenge: Echoes of Experience

"I don't know which box to put you in."

I've been hearing those words for thirty years.

And every single time, it lands like a slap.

The violence isn't in the words. The violence is in what the words actually mean.

It's not: which box could I put you in?

It's: you make me uncomfortable. So I won't hire you.

In a lot of companies, recruitment works like that old Eastern European joke: you give two agents a round peg and a square hole. Two solutions: enlarge the hole… or hit the peg harder.

Guess what the industry has been choosing?

It hits. Harder. Again and again.

Tonight I'm not going to tell you a story about resilience.
I'm going to show you the cost of refusing to fit the box.

Exhibit 1 — The Unlikely Internship

End of studies. 1989.

Everyone is chasing SSII firms, banks, impressive CVs.

Me? I choose a middle school. A library. An 8088.

I know perfectly well it won't lead to a job.

That's not the point.

I want human contact. Real problems. Everyday life.

At a software firm, I would have coded screens. Batch procedures. Efficient within my lane. Never responsible for the whole.

Here, I build a complete application. From scratch. With real users in front of me. Immediate feedback.

I learn what no one would have taught me elsewhere: how to think an entire system.

Not just my part of the ticket.

Exhibit 2 — The Printer

Architecture firm. 1993.

HP printer. Designed for PC and mainframe use. 132 columns, continuous paper feed. 36 switches on the back panel, combinable in non-linear ways.

It had never printed a single accent.

The firm called HP support.

And waited. For months.

Me? I call HP. I say: "I'll drive 400 kilometres to pick up the manual myself if I have to."

Three weeks later, the manual arrives. 300 pages. Pure English. ASCII only. Not a word about French. Not a word about single-sheet feeding.

I read all 300 pages. I understand the logic. I deduce. I test.

The firm prints in French. On A4. Perfectly.

An IT department would still be waiting for support today.

Exhibit 3 — The Cleaning Company

A cleaning company. A simple need: manage their activity, schedules, clients.

They're advised to go with Windows 3.1 + Office.

The hype of the moment. Everyone's doing it, so they should too.

Me? I look at the actual need.

OS/2. Lotus Symphony.

Twice as cheap. Twice as stable. Perfectly suited to what they actually do.

And the price difference? It funded a 486DX40 instead of an SX25. 16MB of RAM instead of 4. A 240MB hard drive.

The entire market is turning its back on these tools? So be it.

The need comes before the trend. And the saved budget goes into the machine.

An IT department would have ordered the Microsoft licences and called it modernisation.

I delivered a system that held up — on a machine that could actually run it.

Exhibit 4 — The SELECT COUNT(*)

Paris. 2010.

A project manager wants to catch me out in front of the team.

I write a SELECT COUNT(*).

He jumps on it. "We don't do SELECT *."

I explain. For MySQL, COUNT(*) is the most performant solution. He tests.

He concedes.

But the tension remains.

Because I contradicted him. In front of everyone. When he had been trying to humiliate me.

I wasn't the one with a problem.

He was the one who couldn't stand being wrong.

In these companies, they don't want people who think.

They want people who validate.

Exhibit 5 — The Open Space

In an open space, you don't model systems. You survive the noise.

You don't think. You manage interruptions.

The industry calls that collaboration.

I call it destroying the concentration of the people who need it to work.

I turned down assignments because of this.

A line I never crossed.

Exhibit 6 — Logic-immo

One exception.

Just one in five years.

Logic-immo. 2008.

Brought in for Zend Framework.

Left having designed and built an Oracle-to-MySQL data extraction system in PHP CLI.

Why?

Because someone had looked at what I could actually do.

And decided to give priority to the need.

Someone had read between the lines.

Rare. Worth mentioning.

In 2011, I was burned out.

In 2012, my daughter was born.

I left Paris.

Exhibit 7 — The Regional Directory

Back in the South-West.

A client. A monstrous project: local directory, classifieds, events section for every town and village, dedicated site for every business.

Over a hundred professional sites to generate and manage dynamically. Custom routing. Zend Framework. Smarty.

A standard agency wouldn't have lasted three months.

Not because of the project.

Because of the client.

Hypochondriac. Always wound up. Always in crisis mode. Unmanageable for anyone without patience.

I held on. Ten months. Solo. Architecture built from scratch.

To the point where I fantasised about a permanent contract.

Any one. Just to never have that kind of client again.

Exhibit 8 — The B2B Platform

A matchmaking platform for business conventions.

The existing application took ten minutes to load.

Ten minutes.

Server ten years past its prime. First-generation Symfony. Poorly designed PostgreSQL database. Non-relational data. Queries going in every direction.

Nobody had asked the question: why is it slow?

I asked the question.

Custom framework inspired by ZF, but lighter. MySQL. Data schema rebuilt from scratch. Processes rewritten from the ground up. Fluid, responsive, usable interface. And a proper server.

Under thirty seconds.

That's not magic.

That's what happens when you look at the problem before touching the code.

They fired me for incompetence the day after launch.

Five thousand visits. Every meeting scheduled. The platform handled everything.

I fix things. Then I get shown the door.

The labour court ruled in my favour. Six months' compensation.

Exhibit 9 — The Projects Nobody Asked For

Nobody commissioned these.

They come from an impulse. A conversation. A problem I noticed.

Dev.to ranks me in the top 7 of the week. I could say thanks and move on.

Instead I implement RFC 2324.

The HTTP protocol for controlling a coffee maker. A 1998 joke buried in the Internet standards. Implemented seriously. Raw asyncio TCP server. Per-pot locks. Compliant headers.

In the comments, @sylwia-lask asks when I'm going to implement a protocol for beer.

I run with it.

RFC 1516. The Hyper Text Beer Mug Control Protocol. Port 1414, a nod to Gdańsk.

The CV as a graph of relationships — because a profile like mine isn't linear. A timeline says nothing. A graph says everything.

AJC Bridge — write from WordPress, publish everywhere. Submitted to a challenge. Runner-up.

No ticket. No meeting. No box.

Just a problem, an impulse, and someone who gets on with it.

Exhibit 10 — The Handover and the Veto

I coach a young entrepreneur. WordPress, Divi, Plesk.

I set up his servers. I pass on what I know.

And one simple principle: never put all your eggs in one basket. Always keep external backups.

OVH burns down.

He manages 60 sites. He loses them — theoretically.

He calls me.

48 hours later, everything is back up on new servers.

It wasn't me who saved his sites.

It was advice given months earlier.

We keep a great relationship.

He's part of a BNI. He puts my name forward for a training assignment.

Veto.

Not standardised.

The system would rather go without someone who just saved 60 sites in under 48 hours.

Think about that for a moment.

Exhibit 11 — The Classroom Aide

I discovered this job over ten years ago.

My daughter's mother is a classroom aide for students with disabilities. She told me about it. I thought it was a job that made sense.

In 2021, a position opens near me. I jump at it.

The recruiter confirms in under five minutes. I barely have time to go down the stairs, step outside the building — he's already calling me back to come sign the contract.

For a while, it was exactly what I'd imagined. Students in difficulty. Concrete work. Visible results.

Some of the students I supported no longer need a classroom aide today.

That's the job.

Except the expectations have shifted.

Because there's no space in the specialist units. No space in the vocational streams. No space in the adapted classrooms.

So these students get placed in mainstream education. And a classroom aide gets put in front of them.

That's not educational support. That's the work of a specialist educator — paid twice as much, with the training and recognition that come with it.

I'm paid minimum wage. Half-time.

And some teachers have one request: shut up and stay in your lane.

The system does here exactly what it does everywhere else.

It puts the round peg in the square hole.

And when it doesn't fit, it hits harder.

The Mechanism

WeCoded talks about marginalised voices in tech.

Marginalised. One word. Dozens of realities.

It's not only about gender, skin colour, sexual orientation.

Racism, homophobia, the rejection of an atypical career path, the rejection of the wrong kind of degree — all of it belongs to the same family.

The family of refusing the other.

The family of human stupidity organised into a system.

The mechanism is always the same.

You don't fit in the box. So you don't exist. And you won't.

And that marginalisation hurts all the more because it makes no sense.

It can be justified — process, boxes, grids.

But every justification will itself be unjustifiable.

What I want you to take away is this:

The Verdict

In all of these stories, one constant.

I always solved the problem I was called in for.

Always.

And yet I remain "unclassifiable". Not employable. Not standardised. Not in the box.

So the real question — the one that stings — is simple.

Who's the problem?

Me — the one who solves the problems?

Or the system — the one that doesn't know what to do with me between fires?

For thirty years, the industry has chosen to hit the peg.

The peg is still round.

And the hole is still square.

RFC 1516: A Build for the Community That Keeps 418 Alive

Pascal CESCATO — Fri, 27 Feb 2026 15:47:21 +0000

This is a submission for the DEV Weekend Challenge: Community

In the comments of my last article, Sylwia wrote:

Comment on Stop Ignoring RFC 2324. It's the Most Important Protocol You've Never Implemented.

Sylwia Laskowska Feb 25

Awesome😄
Now I’m just waiting, Pascal, until you invent your own protocol — maybe something like a beer brewing protocol next? 🍺

I replied: "...HTBMCP/1.0 might be next. Hyper Text Beer Mug Control Protocol. Watch this space."

This is that space.

The Community

Before the code: a question worth asking.

The DEV prompt says "build for your community." The obvious answer, for a developer, is to build something useful for other developers — a tool, a library, a dashboard. Something that solves a real problem.

But there's a community that rarely gets named as such, and it's one I'm genuinely part of: the community of developers who find meaning in craft for its own sake. Who implement a coffee pot RFC not because it ships a feature, but because it teaches something real. Who write April Fools' specs with the same rigor they'd apply to production systems. Who understand that absurdity taken seriously is one of the most honest forms of technical education.

RFC 2324 has been cited, forked, debated, and defended for 26 years because it speaks directly to that community. It says: the standards process can be playful — rigorously, precisely playful. That's worth protecting.

HTBMCP/1.0 is a contribution to that tradition. It's for the developer who reads a comment about beer protocols at midnight and thinks yes, someone should actually do that. It's for @sylwia-lask, who asked. It's for anyone who's ever cited RFC 2324 in a code review and meant it.

What I Built

RFC 1516 — the Hyper Text Beer Mug Control Protocol (HTBMCP/1.0), to be published April 1st 2026. And its full implementation.

HTBMCP is the spiritual successor to RFC 2324 (HTCPCP, the coffee pot protocol). Where HTCPCP controls coffee pots, HTBMCP controls networked beer taps. It extends HTTP with five custom methods, three new headers, and one new error code.

The default port is 1414 — a memorial. In 1414, the municipal archives of Gdansk recorded the earliest known written attestation of the word "piwo" (beer, in Polish). That document was lost during the Second World War.

Port 1414 is therefore a memorial as much as a transport binding.

The implementation consists of four parts:

An interactive browser simulator — a self-contained HTML/JS file, no backend, no install. A complete HTBMCP state machine running in the browser with animated tap visuals, all six response codes, the full header set. Build the simulator before the server: it forces you to model the protocol as data before you model it as routes.

A raw asyncio TCP server (server.py) — because uvicorn rejects TAP, POUR, and WHEN at the socket layer. These are valid RFC 7230 tokens, but they're not in the IANA method registry. The fix is a minimal HTTP/1.1 parser over raw TCP that accepts any valid token as a method name. This is the correct approach: HTBMCP is its own protocol, and owning the transport layer is the honest implementation.

A FastAPI application (main.py) — used exclusively by the test suite. TestClient bypasses the HTTP transport entirely, so custom methods work fine there. You get structured routing and validation without the socket-level rejection.

41 tests covering the full protocol: every method, every error code, the Stout temperature MUST NOT, the goblet Trappist-only rule, brew_version conflict detection, the piwo:// Gdansk memorial tap, and the WHEN-once-is-sufficient invariant.

The protocol, in brief

Method	Description
`TAP`	Opens/closes a session. Must precede POUR. POST accepted but STRONGLY DISCOURAGED.
`POUR`	Dispenses beer (`start`/`stop`). MUST NOT execute without open TAP session.
`WHEN`	Stops foam. Inherited from HTCPCP. There is no WHEN-WHEN method. Once is sufficient.
`GET`	Returns tap state. Contains no beer. This is an important distinction.
`PROPFIND`	Discovers styles, temperatures, foam levels. Borrowed from WebDAV via HTCPCP.

New error code: 419 I'm a Wine Glass. A wine glass is not a mug. A wine glass has no handle. Beer poured into a wine glass loses carbonation 23% faster — a figure the authors have not verified but feel is directionally correct.

A server MUST NOT return 419 for an empty keg. The keg is not a wine glass. These are different problems.

Demo

🍺 HTBMCP Simulator — open it directly in your browser. No install, no server, no dependencies. A complete HTBMCP state machine running client-side: animated tap visuals, all six response codes, the full header set.

htbmcp.benchwiseunderflow.in

Try to TAP a Stout at 3°C. Watch the 406 fire with the exact RFC citation. Try the wine glass tab. Say WHEN.

Attempting to pour into a wine glass results in a protocol-level error.

For the full server:

python server.py
# 🍺  HTBMCP/1.0 listening on 0.0.0.0:1414
#     Port 1414 — memorial: Gdansk municipal archives, 1414

# TAP open
curl -X TAP http://localhost:1414/tap/tap-1 \
     -H "Content-Type: message/mugpot" \
     -H "Accept-Style: IPA" \
     -H "Accept-Temperature: 8" \
     -H "Accept-Foam: normal" \
     -d "open"

# POUR
curl -X POUR http://localhost:1414/tap/tap-1/pour \
     -H "Content-Type: message/mugpot" \
     -d "start"

# WHEN — enough foam
curl -X WHEN http://localhost:1414/tap/tap-1/when

# 419 — I'm a Wine Glass
curl -X POUR http://localhost:1414/wine-glass/tap-1

Code

Code is on Github repository:

pcescato / htbmcp

HTBMCP/1.0 — Hyper Text Beer Mug Control Protocol

"There is beer all around the world. Increasingly, in a world in which computation is ubiquitous, the consumption of beer in proximity to networked devices creates a strong operational requirement."

— RFC 1516, Abstract

What is this?

This repository is a full implementation of RFC 1516 — the Hyper Text Beer Mug Control Protocol (HTBMCP/1.0), to be published April 1st, 2026.

HTBMCP is the spiritual successor to RFC 2324 (HTCPCP/1.0, the coffee pot protocol). Where HTCPCP controls coffee pots, HTBMCP controls networked beer taps. The protocol extends HTTP with custom methods, headers, and error codes designed specifically for the distributed dispensing of fermented malt beverages.

The default port is 1414 — a memorial to the earliest known written attestation of the word "piwo" (beer, in Polish) in the municipal archives of Gdansk, 1414. That document no longer exists. We pour one out.

…

View on GitHub

The full implementation — TCP server, FastAPI test app, registry, 41 tests, browser simulator, and README. RFC 1516 itself is available in the repository. It will be formally published on April 1st, 2026. As tradition demands.

The uvicorn problem — and the solution

This is the key technical lesson, and it's worth making explicit.

# ❌ This will NOT work for HTBMCP methods
# uvicorn → h11 → validates method against IANA registry → rejects TAP/POUR/WHEN
# before any application code runs
uvicorn main:app --reload

The fix — a minimal HTTP/1.1 parser over raw asyncio TCP:

async def handle_connection(reader, writer):
    data = await reader.read(8192)
    req = parse_request(data)   # accepts any RFC 7230 token as method
    response = await dispatch(req)
    writer.write(response)
    await writer.drain()

async def main():
    server = await asyncio.start_server(handle_connection, "0.0.0.0", 1414)
    async with server:
        await server.serve_forever()

parse_request() splits on the first space and takes whatever token it finds — TAP, POUR, WHEN, or anything else that's RFC 7230-valid. No registry check. This is correct: HTBMCP defines its own protocol. The transport layer should not enforce HTTP's method vocabulary on a protocol that extends it.

Temperature validation — MUST vs SHOULD NOT

def check_temperature(tap_id, raw_temp):
    # RFC 1516 §3.2.3:
    # "A server MUST NOT serve a Stout at 3°C.
    #  This is not a SHOULD NOT. This is a MUST NOT.
    #  The authors feel strongly about this."
    if tap.style == "Stout" and temp <= 5:
        return build_response(406, {
            "error": "Temperature violation — MUST NOT",
            "detail": "A server MUST NOT serve a Stout at 3°C. "
                      "This is not a SHOULD NOT. This is a MUST NOT.",
            "allowed_range": "10–13°C",
            "rfc": "RFC 1516 §3.2.3",
        })

The RFC distinguishes MUST NOT from SHOULD NOT with care. The Stout temperature constraint is a hard rule, not a recommendation. Testing that distinction is the point:

def test_tap_406_stout_too_cold(self):
    """RFC 1516 §3.2.3: MUST NOT. This is not a SHOULD NOT."""
    r = self._tap_open(tap_id="tap-2", style="Stout", temp=3)
    assert r.status_code == 406
    assert "MUST NOT" in r.json()["error"]

The `piwo://` tap — port 1414's justification, made navigable

"tap-gdansk": Tap(
    id="tap-gdansk", scheme="piwo",  # Polish — RFC 1516 §1, port 1414 memorial
    style="Lager", temp=4.0, pressure=2.6, level=88,
    compatible_styles=["Lager", "Pilsner"],
),

def test_gdansk_piwo_tap(self):
    """piwo:// scheme — Gdansk 1414. We pour one out."""
    r = self._tap_open(tap_id="tap-gdansk", style="Lager", temp=4)
    assert r.status_code == 200
    assert TAP_REGISTRY["tap-gdansk"].scheme == "piwo"

How I Built It

Stack: Python 3.12, FastAPI (test suite only), asyncio raw TCP (real server), structlog, pytest. Single-file HTML/JS simulator with no dependencies.

Build order: simulator first, server second, tests throughout. This is the lesson from the HTCPCP implementation: build the thing you can demo immediately, then build the thing that's correct. The simulator forced every protocol decision to be made as UI state before it became a routing decision.

The protocol is not just simulated — it is fully implemented and validated with a dedicated test suite.

The HTCPCP comparison: HTBMCP adds a session model (TAP as initiator with brew_version tokens for concurrent access), promotes foam to a first-class protocol feature (Accept-Foam with five levels including belgian — implementation-defined, but significant), and introduces 419 I'm a Wine Glass alongside 418 I'm a teapot. Where 418 says you are the wrong device, 419 says you are using the wrong vessel. The error taxonomy matters.

What this actually teaches: The Stout MUST NOT forces you to think about hard constraints vs recommendations. The brew_version conflict detection forces you to think about optimistic locking. The goblet Trappist-only rule forces you to think about domain validation. The uvicorn rejection forces you to think about where the HTTP stack lives. These are not beer problems.

The Reinheitsgebot requires no acknowledgement. It has been enforcing standards compliance since 1516 without asking for credit.

Stop Ignoring RFC 2324. It's the Most Important Protocol You've Never Implemented.

Pascal CESCATO — Tue, 24 Feb 2026 23:44:05 +0000

Some RFCs change the world — TCP/IP, HTTP/2, TLS 1.3.

And then there's RFC 2324, published April 1st, 1998, defining the Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0). Its purpose: control, monitor, and diagnose coffee pots over a network.

No, it's not a joke. Well, it is. But it's written seriously enough to actually implement. Emacs did it. We will too.

A Brief History of the Web's Most Honorable RFC

RFC 2324 is an IETF April Fools' joke authored by Larry Masinter. It extends HTTP with:

New HTTP methods: BREW, WHEN, PROPFIND
A new header: Accept-Additions (for milk, sugar, whisky — yes, whisky)
A new URI scheme: coffee:// (and koffie://, café://, and 26 other translations)
Two new error codes that changed internet history

The error codes

406 Not Acceptable  — The server cannot brew this coffee
418 I'm a teapot    — The server is a teapot, not a coffee pot

418 became iconic. In 2017, a proposal to remove it from the IANA registry triggered an actual revolt across the dev community. Node.js, Go, Python — everyone kept it. The teapot won.

In 2014, RFC 7168 extended the protocol to tea (HTCPCP-TEA), adding the message/teapot MIME type and the requirement to distinguish an Earl Grey from a Darjeeling. Rigor in absurdity.

What the RFC Actually Defines

Before writing a single line, read the spec. That's the exercise.

The new methods

MethodRoleBREW (or POST)Trigger an infusionGETGet the coffee pot's current statePROPFINDList available additionsWHENStop pouring the milk — the client says "when!"

The WHEN method is the most beautiful. It models a human exchange ("tell me when") as an HTTP request. A masterpiece of protocol anthropomorphism.

The Accept-Additions header

BREW /coffee-pot-1 HTCPCP/1.0
Accept-Additions: milk-type=Whole-milk; syrup-type=Vanilla; alcohol-type=Whisky

Legal values include Cream, Half-and-half, Whole-milk, Non-Dairy, syrups (Vanilla, Chocolate, Raspberry, Almond), and spirits (Whisky, Rum, Kahlua, Aquavit).

Intentionally absent: any decaffeinated option. The RFC's comment on this is terse: "What's the point?"

Step 1 — Play First: The Standalone Simulator

Before writing a single line of server code, I built a fully self-contained HTML/JS simulator that runs entirely in the browser. No backend, no dependencies, no install.

Interactive HTCPCP Dashboard

htcpcp.benchwiseunderflow.in

The simulator is not a mock of the server — it is a complete HTCPCP implementation, just in a different runtime. All the state lives in JavaScript: pot registry, brew history, status transitions, 418/406 logic. It's the fastest way to feel the protocol before committing to a stack.

Try to BREW on a teapot. Watch the 418 fire. Select decaf and get a 406. Click WHEN mid-brew to stop the milk. Then come back here and build the production version.

Step 2 — Ship It: The Production Server

A word on uvicorn

The natural instinct is uvicorn main:app --reload. Don't. uvicorn validates HTTP method names at the socket level, before any request parsing happens. BREW, WHEN, and PROPFIND are not registered IANA methods, so uvicorn rejects them immediately with Invalid HTTP request received — regardless of any FastAPI config.

The fix: a raw asyncio TCP server (server.py) with a minimal HTTP/1.1 parser that accepts any valid RFC 7230 token as a method name. Which BREW, WHEN, and PROPFIND are. This is actually the more correct approach — HTCPCP defines its own protocol, and rolling your own transport layer is the honest implementation.

python server.py
# ☕  HTCPCP/1.0 — RFC 2324  (127.0.0.1:2324)

curl -X BREW http://localhost:2324/coffee/pot-1 \
  -H "Accept-Additions: milk-type=Whole-milk; alcohol-type=Whisky"

FastAPI + main.py is still useful for one thing: the test suite. FastAPI's TestClient bypasses the HTTP transport layer entirely, so custom methods work fine in tests — and you get all the validation and schema benefits of FastAPI.

pytest test_htcpcp.py -v   # uses main.py + TestClient, no server.py needed

Architecture: a pot registry

First architectural decision: model the entities properly.

from enum import Enum
from dataclasses import dataclass, field

class PotType(str, Enum):
    COFFEE = "coffee"
    TEAPOT = "teapot"

class PotStatus(str, Enum):
    IDLE = "idle"
    BREWING = "brewing"
    POURING_MILK = "pouring-milk"
    READY = "ready"

@dataclass
class CoffeePot:
    id: str
    pot_type: PotType
    capacity: int
    level: int
    status: PotStatus = PotStatus.IDLE
    varieties: list[str] = field(default_factory=list)
    brew_history: list[dict] = field(default_factory=list)

# The registry — the core of the architecture
POT_REGISTRY: dict[str, CoffeePot] = {
    "coffee://pot-1": CoffeePot("pot-1", PotType.COFFEE, 12, 8,
                                varieties=["Espresso", "Lungo", "Americano"]),
    "coffee://pot-2": CoffeePot("pot-2", PotType.COFFEE, 6, 2,
                                varieties=["Espresso"]),
    "tea://kettle-1": CoffeePot("kettle-1", PotType.TEAPOT, 8, 6,
                                varieties=["Earl Grey", "Chamomile", "Darjeeling"]),
}

Parsing the Accept-Additions header

from fastapi import Request, HTTPException

SUPPORTED_ADDITIONS = {
    "milk-type": ["Cream", "Half-and-half", "Whole-milk", "Part-Skim", "Skim", "Non-Dairy"],
    "syrup-type": ["Vanilla", "Almond", "Raspberry", "Chocolate"],
    "sweetener-type": ["Sugar", "Honey"],
    "spice-type": ["Cinnamon", "Cardamom"],
    "alcohol-type": ["Whisky", "Rum", "Kahlua", "Aquavit"],
}

def parse_accept_additions(header: str | None) -> dict[str, str]:
    if not header:
        return {}
    additions = {}
    for part in header.split(";"):
        part = part.strip()
        if "=" in part:
            key, value = part.split("=", 1)
            additions[key.strip()] = value.strip()
    return additions

def validate_additions(additions: dict) -> None:
    # RFC 2324 §2.1.1: no decaf option — intentionally
    if "decaf" in additions:
        raise HTTPException(
            status_code=406,
            detail={
                "error": "Not Acceptable",
                "message": "Decaffeinated coffee? What's the point?",
                "rfc": "RFC 2324 §2.1.1"
            }
        )
    unsupported = [
        f"{k}={v}" for k, v in additions.items()
        if k in SUPPORTED_ADDITIONS and v not in SUPPORTED_ADDITIONS[k]
    ]
    if unsupported:
        raise HTTPException(
            status_code=406,
            detail={"error": "Not Acceptable", "unsupported_additions": unsupported}
        )

The HTCPCP endpoints

from fastapi import FastAPI
from fastapi.responses import JSONResponse

app = FastAPI(title="HTCPCP/1.0", version="1.0")

def get_pot(pot_id: str) -> CoffeePot:
    uri = f"coffee://{pot_id}"
    pot = POT_REGISTRY.get(uri) or POT_REGISTRY.get(f"tea://{pot_id}")
    if not pot:
        raise HTTPException(status_code=404, detail="Pot not found in registry")
    return pot

# ── BREW ────────────────────────────────────────────────────────────────────

@app.api_route("/coffee/{pot_id}", methods=["BREW", "POST"])
async def brew(pot_id: str, request: Request):
    pot = get_pot(pot_id)

    # RFC 2324 §2.3.2: teapot → 418, mandatory
    if pot.pot_type == PotType.TEAPOT:
        return JSONResponse(status_code=418, content={
            "status": 418,
            "error": "I'm a teapot",
            "body": "The requested entity body is short and stout.",
            "hint": "Tip me over and pour me out.",
            "pot_id": pot_id,
            "rfc": "RFC 2324 §2.3.2",
            "suggestion": "Use coffee://pot-1/brew instead"
        })

    if pot.level == 0:
        raise HTTPException(status_code=503, detail="Pot is empty. Refill required.")

    additions_header = request.headers.get("accept-additions")
    additions = parse_accept_additions(additions_header)
    validate_additions(additions)  # 406 if decaf or invalid additions

    brew_id = len(pot.brew_history) + 1
    pot.brew_history.append({"id": brew_id, "additions": additions})
    pot.status = PotStatus.BREWING
    pot.level -= 1

    # Milk requested → enter pouring-milk state
    has_milk = "milk-type" in additions
    if has_milk:
        pot.status = PotStatus.POURING_MILK

    return JSONResponse(status_code=200, content={
        "brew_id": brew_id,
        "message": "Coffee is brewing.",
        "pot": pot_id,
        "accept-additions": additions,
        "milk_pouring": has_milk,
        "protocol": "HTCPCP/1.0"
    })

# ── GET ──────────────────────────────────────────────────────────────────────

@app.get("/coffee/{pot_id}/status")
def get_status(pot_id: str):
    pot = get_pot(pot_id)
    return {
        "pot_id": pot_id,
        "type": pot.pot_type,
        "status": pot.status,
        "level": f"{pot.level}/{pot.capacity} cups",
        "brew_count": len(pot.brew_history),
        "varieties": pot.varieties,
        "protocol": "HTCPCP/1.0"
    }

# ── PROPFIND ─────────────────────────────────────────────────────────────────

@app.api_route("/coffee/{pot_id}/additions", methods=["PROPFIND"])
def propfind(pot_id: str):
    get_pot(pot_id)
    return {
        **SUPPORTED_ADDITIONS,
        "decaf": "NOT_ACCEPTABLE — What's the point? (RFC 2324 §2.1.1)"
    }

# ── WHEN ─────────────────────────────────────────────────────────────────────

@app.api_route("/coffee/{pot_id}/stop-milk", methods=["WHEN"])
def when(pot_id: str):
    """
    RFC 2324 §2.1.3 — WHEN
    Sent when the client determines that enough milk has been poured.
    The server must stop immediately.
    """
    pot = get_pot(pot_id)

    if pot.status != PotStatus.POURING_MILK:
        return JSONResponse(status_code=200, content={
            "message": "WHEN acknowledged.",
            "note": "No milk was being poured, but your enthusiasm is appreciated.",
            "rfc": "RFC 2324 §2.1.3"
        })

    pot.status = PotStatus.BREWING

    return JSONResponse(status_code=200, content={
        "message": "Milk pouring stopped.",
        "detail": "The server has acknowledged WHEN and stopped the milk stream.",
        "protocol": "HTCPCP/1.0",
        "rfc": "RFC 2324 §2.1.3"
    })

Middleware: enforce HTCPCP headers

from starlette.middleware.base import BaseHTTPMiddleware

class HTCPCPMiddleware(BaseHTTPMiddleware):
    async def dispatch(self, request, call_next):
        response = await call_next(request)
        response.headers["X-Protocol"] = "HTCPCP/1.0"
        response.headers["X-RFC"] = "RFC-2324"
        # Detect a BREW on a non-coffee route and punish accordingly
        if request.method == "BREW" and not request.url.path.startswith("/coffee"):
            return JSONResponse(status_code=418, content={
                "error": "Wrong universe",
                "hint": "BREW is only valid on coffee:// URIs"
            })
        return response

app.add_middleware(HTCPCPMiddleware)

Structured logs — because we're professionals

import structlog

log = structlog.get_logger()

# After a successful BREW:
log.info("htcpcp.brew",
    pot_id=pot_id,
    brew_id=brew_id,
    additions=additions,
    status_code=200,
    protocol="HTCPCP/1.0"
)

# On 418:
log.warning("htcpcp.teapot_detected",
    pot_id=pot_id,
    pot_type="teapot",
    status_code=418,
    message="Teapot attempted to brew coffee"
)

Which produces in your JSON logs:

{"event": "htcpcp.brew", "pot_id": "pot-1", "brew_id": 3,
 "additions": {"milk-type": "Whole-milk", "alcohol-type": "Whisky"},
 "status_code": 200, "protocol": "HTCPCP/1.0", "level": "info"}

{"event": "htcpcp.teapot_detected", "pot_id": "kettle-1",
 "status_code": 418, "level": "warning"}

What This Actually Teaches You

Implementing an April Fools' RFC is a serious exercise in disguise. You end up learning:

How to read an RFC properly — distinguishing MUST, SHOULD, MAY. RFC 2324 uses all three with care. The 418 is a MUST if the server is a teapot. A broken coffee machine should return 503 — not 418. That's a common mistake, and it matters.

How the HTTP stack actually works — trying to use uvicorn with BREW reveals that method validation happens at the socket level, before h11, before FastAPI, before your code. You end up writing a raw asyncio TCP server to get HTCPCP working for real. That's not a detour — that's the point. You now understand the HTTP request pipeline better than most devs who've shipped production APIs for years.

How to think in entities — the pot registry, the CoffeePot vs Teapot distinction, routing by coffee:// URI: this is real domain modeling. The joke forces you to take it seriously.

How to model state machines — idle → brewing → pouring-milk → ready is a textbook workflow. WHEN is a client-driven transition. You'll see this pattern everywhere in production systems.

How to write integration tests for absurd-but-useful edge cases:

def test_teapot_cannot_brew():
    response = client.request("BREW", "/coffee/kettle-1")
    assert response.status_code == 418
    assert response.json()["error"] == "I'm a teapot"

def test_decaf_is_not_acceptable():
    response = client.request("BREW", "/coffee/pot-1",
                              headers={"Accept-Additions": "decaf=true"})
    assert response.status_code == 406

def test_when_stops_milk():
    client.request("BREW", "/coffee/pot-1",
                   headers={"Accept-Additions": "milk-type=Whole-milk"})
    response = client.request("WHEN", "/coffee/pot-1/stop-milk")
    assert response.status_code == 200
    assert "stopped" in response.json()["message"]

Conclusion

418 survived every attempt to kill it because it represents something real: developers are allowed to be playful. An April Fools' RFC published today would probably get killed in committee within a week. The one from 1998 has lasted 26 years.

What makes RFC 2324 remarkable is that it takes absurdity seriously — it has a real state machine, real error codes with precise semantics, a real extension (RFC 7168 for tea). It mocks formalism by respecting it perfectly.

That's exactly how we should build our own systems.

Simulator (HTML/JS standalone), server.py (raw TCP), main.py + full test suite — on Github: https://github.com/pcescato/htcpcp/.

RFC 2324: https://tools.ietf.org/html/rfc2324 RFC 7168: https://tools.ietf.org/html/rfc7168

Your Article Isn’t the Real Content

Pascal CESCATO — Sat, 21 Feb 2026 12:28:14 +0000

The article is often the least interesting thing that happens after you publish.

Not always. But more often than we're willing to admit.

I saw this comment recently and couldn't unsee it:

"Real war stories have specifics — the exact error, the wrong turn you took first, the fix that seemed obvious in retrospect. Generated stuff stays vague. Honestly the comments on that post became better content than the post itself."

That last sentence describes something we rarely say out loud.

What actually happens when you write with real specifics

Not tips. Not frameworks. The actual error. The wrong turn. The fix you missed for three hours.

That level of detail does something polished content almost never does: it makes other builders recognize themselves instantly.

And recognition doesn't produce passive reading. It produces contribution.

The article doesn't contain the knowledge. It releases it.

Publishing without the discussion is publishing an incomplete object.

The post and the thread aren't two separate things. One makes the other possible. Strip the comments and you lose half the object. Strip the post and the comments have no spine.

We treat articles as finished products and comments as disposable noise. So we archive the post and let the discussion rot.

Which means we're systematically preserving the least interesting half of the knowledge.

We optimize for authorship. We don't preserve conversations.

Maybe we didn't even want to.

Where did the real fix appear — in the article or in the replies?

Link a post where the comments mattered more than the text.

What's the best technical insight you found buried three levels deep in a thread — that no article ever captured?

If you think the article still matters more than the discussion, I'd genuinely like to hear why — because I'm no longer sure.

DEV Community: Pascal CESCATO

The "AI" Badge Doesn't Measure What You Think It Does

The End of Undetectable AI Text? Claude’s New Watermark Explained

Three things people keep conflating

Assisted, generated, produced: three different verbs

What an actual test shows

How this piece was actually made

What a badge actually costs

What this doesn't fix

When Your VPS Never Had the Resources It Was Sold With

Problem 1: IPv4 that went nowhere

Problem 2: the disk that was never there

Problem 3: "fixed" didn't mean fixed

What two failures in one day tell you

Commands worth knowing

Takeaway

CyberPanel's SSL Auto-Renewal Can Silently Fail — Here's the Fix

Checking what's actually served

Checking what acme.sh actually did

The fix

Turning it into something reusable

pcescato / cyberpanel-ssl-renewal-scripts

Renew and repair SSL certificates on CyberPanel 2.x directly via acme.sh (bypasses the broken built-in renewal scheduler)

CyberPanel SSL Renewal Scripts

Why this exists

Requirements

Scripts

renew-ssl.sh — Renew certificates

Why this is worth checking on your own servers

What Replacing Calendly Taught Me About Trusting Open Source

The landscape

Narrowing down

The audit: a TOCTOU race condition, in both remaining candidates

booking-calendar

Easy!Appointments

The interesting part

Takeaway

Production rollout: a simple embed, an unexpected block

First guess, wrong

The actual cause

Result

Eighty Percent Done Is Not a Real Number

Why this one, and why now

The PoC that was supposed to work

What the first real database showed in three lines, and what it cost the schedule

The trap I didn't know about

The bug that had nothing to do with a privilege

A metric that didn't measure what its name promised

Ten metrics didn't cover everything — not even the essentials

The count

The coda: debugging the report that describes the bugs

What determinism doesn't cover

What it looks like now

dbgrade — Independent PostgreSQL & MariaDB/MySQL Audits - Security, integrity, performance — scored and explained

Technical sidebar — tools and method

Unboxable in Tech: The Evidence Locker

Exhibit 12 — The Graph

Exhibit 13 — AJC Bridge

Exhibit 14 — The Memory dev.to Doesn't Give You

Exhibit 15 — The Polish Botnet

Exhibit 16 — WordPress to Hugo, and Then Further

Exhibit 17 — GCF Pro

Exhibit 18 — Prospection CRM, and the Extension That Watches With Me

Exhibit 19 — S&R CRM

The Verdict

1%

Too cheap to be good? Think again.

1. The test project

2. Methodology

3. Planning phase — who actually thinks?

4. Code phase — who actually delivers?

5. External review — and the reveal

Addendum — Model E: Kimi K2.7 Code

Addendum 2 — Multi-reviewer validation

6. Intelligent routing — the real economics

Conclusion

pcescato / LLM-Challenge

LLM-Challenge

What this is

The protocol

`renew-ssl.sh` — Renew certificates

The `piwo://` tap — port 1414's justification, made navigable