DEV Community: Pascal CESCATO

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.

Who Are We Still Writing Technical Articles For?

Pascal CESCATO — Tue, 17 Feb 2026 12:34:14 +0000

I recently read an article by @miracool asking the question: do people still genuinely care about technical articles? My answer is nuanced: yes, but not everyone.

Beyond that question, there is another, more fundamental one: who do we choose to write for today?

A Long-Term Trajectory

I've been writing technical articles since 2010-2011. Some still exist in the Wayback Machine archives — like this one, dated December 2011, about a MySQL limitation that barely makes sense to address today. My blog has been running since 2016. Since August 2025, I've also been writing in English.

I've never published at an industrial pace. I wrote when I had something to clarify, document, or share.

Over this period, one observation stands out: some articles disappear within a few months, while others continue to be read years later. Not massively. But steadily. By readers who arrive through a specific search, who actually read, and who sometimes write back.

It's almost always the same types of texts that survive: those that document an approach, a technical decision, a real problem encountered over time. Highly specific tutorials, on the other hand, meet an immediate need and then logically fade away.

This isn't a theory. It's an observation built over time.

How We Consume Technical Knowledge Today

Fifteen or twenty years ago, you bought a technical book and used it for years. I bought the PHP5 Bible in the mid-2000s. I relied on it for nearly three years. But back then, you couldn't find nearly as many up-to-date resources online as quickly as you can now.

Today, access to technical knowledge is immediate. Resources are digital, abundant, constantly updated. Tools have simplified many deployments. Answers are available within seconds.

This isn't better or worse. It's a different way of learning and working. I consume differently myself.

But this evolution has a direct consequence: the lifespan of technical content has shortened. And that naturally changes the way we write.

Technical Articles Haven't Disappeared — They've Evolved

We need to distinguish between two types of technical articles.

There's daily news: announcements, releases, updates. A new version of PostgreSQL. New MySQL features. A new project from an Apache incubator. These articles are widely read. They meet a need for technical current events. It's information.

And there's the in-depth magazine: detailed articles, experience reports, carefully constructed reflections. The National Geographic of tech. These articles reach a smaller but loyal audience. Readers who are genuinely interested.

This distinction between technical news and substantive reflection isn't new. There have always been texts with no clear thinking behind them. Lists like "Top 5 WordPress Themes for 2026" or "10 Best Plugins for 2025" that enumerate tools with their pros and cons but offer no real analysis have always existed. Humans are perfectly capable of producing empty content. Artificial intelligence didn't create this problem — it simply amplified the volume.

What remains rare are articles that go deeper. That not only show strengths and weaknesses but explain use cases, contexts, the reasoning behind choices. Those require structured thinking. As Boileau once said: what is well conceived is clearly stated.

To illustrate this concretely, I submitted the same prompt to Gemini and ChatGPT: "write a 1500-word article on 'who do we choose to write a technical article for?'". Both produced correct, well-structured texts. ChatGPT even found some interesting angles — the translator-reader, the machine as an unexpected recipient. But both shared the same fundamental limitation: zero lived experience, zero concrete data, zero personal trajectory. Texts that are true for everyone, and therefore belong to no one.

That's not a flaw in the tool. It's the direct consequence of a prompt with no real thinking behind it.

AI produces articles, but left undirected, it doesn't produce substantive ones. You can ask it to write a tutorial on any technical subject and get a text that looks correct on the surface but is empty of genuine reflection.

For my part, I use AI to structure my articles, to rephrase, to validate hypotheses. But I don't give it a generic prompt like "write a 1500-word article on who we choose to write a technical article for." The thinking that feeds the text comes from my research, my experience, my history.

And the drafts the AI produces — all of them, not just the first — are then reread, corrected, and reworked to match my own voice. This article itself is the result of a conversation with Claude and ChatGPT. But once that conversation was over, I reread it. I rewrote entire sections. I amended others. The work is greatly simplified by AI, but it isn't directly generated writing. It's augmented writing. The difference is essential.

Both types of articles still exist. But they don't address the same audience or the same timeframe.

What has changed is that the sheer mass of available information has paradoxically made in-depth articles more substantive, not less relevant. Since the basic tutorial is everywhere, what remains to be written is the reasoning behind it.

Why I No Longer Write Tutorials

For a long time, I wrote very detailed tutorials. Complete guides, designed to walk a reader from start to finish.

Today, I don't write them anymore.

Not because tutorials have become useless. They remain essential, particularly for beginners or specific use cases. But they are now produced faster and often better by others: official documentation, communities, interactive tools, technical assistants.

A very precise tutorial also becomes obsolete faster. Versions change, methods evolve, abstractions multiply. In many cases, a quick search is enough to solve the problem.

So it's not the tutorial that's disappearing. It's simply that I've stopped making it the core of my writing.

What Writing Still Allows

Technical writing retains a specific quality.

It allows for measured reflection. Rereading. Precise citation. Continuity over time. A text can be found again, annotated, reused, reread years later.

A video informs. An instant response helps solve a problem. But a structured text allows you to follow a line of reasoning and return to it.

This isn't about the superiority of formats. It's about function. Writing remains particularly well-suited for documenting a technical experience over time.

What Holds Its Value

Over time, I've shifted my center of gravity.

I'm less focused on explaining exactly how to do something. Others do that very well and very quickly. I try instead to document an approach, a technical choice, a feedback report, a thought process, what worked and what didn't.

This type of text doesn't meet an immediate need. It speaks to those who want to understand a line of reasoning, not just execute a procedure.

It probably reaches fewer people. But it lasts longer.

A Different Audience

This audience exists. I know because some articles continue to be read long after publication. They show up in stats. They're found through specific searches. Sometimes they prompt a message months or years later.

I've had articles that were read far more widely. Between 2017 and 2019, an article about Twenty Seventeen, the WordPress theme, generated 20 to 25,000 reads and over a hundred comments. I also see what viral articles on dev.to look like: thousands of likes, hundreds of comments.

That's not what I'm talking about.

Writing in English hasn't given me a massive audience. Between August 2025 and today, 25 articles have generated around 14,000 views. Modest numbers.

But it's a different audience. Switching to English wasn't a strategy. It came naturally. My technical experience is international. And this English-speaking audience — partly made up of people who write themselves, and above all readers interested in this kind of reflection — aligns more closely with who I am.

I'm not addressing a majority. I'm addressing people who build, who think, who look for experience reports rather than immediate answers.

Why Write Publicly?

If this audience is limited, why keep publishing? Why not simply keep private notes?

Because public writing changes the nature of reflection. It forces you to clarify. To structure. To stand behind what you write. And sometimes, it creates a deferred conversation with people you will never meet directly.

Publishing an in-depth technical article is contributing to a shared space for reflection. However modest. However quiet.

An Assumed Choice

Writing substantive technical articles today isn't the fastest way to gain visibility. It's not the most efficient for producing content at volume either.

But it's the approach that best matches the way I work and think.

I write to document approaches and technical trajectories. For a handful of interested readers. For continuity over time.

There's nothing heroic about this choice. It's simply consistent with how my practice has evolved.

Side note: this article is written in WordPress and published directly to dev.to via the API — I covered how that works in a previous article.

Continuing

Technical articles haven't disappeared. Neither has their audience. It's simply different: less massive, more attentive.

Writing today for that audience is a choice.

The question, for me, isn't whether people still care about technical articles. They do. Or at least, some do.

My question is more ethical: do we still want to write for those who truly care?

Actually Static: When WordPress Stops Being the Enemy

Pascal CESCATO — Sun, 08 Feb 2026 13:28:48 +0000

This is a submission for the GitHub Copilot CLI Challenge

This post is for developers who like writing in WordPress but want the speed and safety of static sites — and the freedom to publish anywhere from a single editorial hub.

📋 Table of Contents

Summary

What I Built
- The Search for an Alternative
- Existing Tools: Effective but Heavy
- Tech Stack
Demo
- The Real-World Gauntlet
- Where Copilot CLI Accelerated Development
- Why Local Image Optimization Matters
- Architecture
- How It Works
- Production Update: Multi-Destination Publishing
- Technical Highlights
My Experience with GitHub Copilot CLI
- Specification First, Code Second
- The Work Pattern
- The Prompt Gallery: Steering the CLI
- What This Actually Means
- The Real Value
- The Development Rhythm
- Real Example: AVIF Generation Fix
- The Audit Trail Advantage
- Code Review: Validating Production Readiness
- WordPress.org Submission: The Road to Approval
- Addendum: Automating the Future with GitHub Actions
Conclusion
Final Thought

What I Built

I spent years wrestling with WordPress performance and security issues.

Optimizing caching layers, hardening installations, fighting plugin bloat — all to keep public-facing sites running acceptably.

Then I discovered static site generators. Hugo. Astro. Fast, secure, elegant.

But months of tweaking themes, debugging build pipelines, and fighting with deployment workflows taught me something: I'd just traded one set of problems for another.

Today, I use both. Not as competitors, but as partners.

Here's the paradox I kept running into: WordPress is probably the best writing environment ever built. The interface is mature, the editor works, and you can focus on what matters — writing.

Static site generators are probably the best deployment target ever built. Fast, secure, cheap to host, and scalable by default.

So why do we keep choosing between them?

In a comment on one of my previous posts, @juliecodestack captured this tension perfectly:

"I spent quite a lot of time tweaking Hugo sites instead of writing, and I'm afraid I'll do the same thing if I transfer to Astro."

That's the real problem. Not WordPress. Not Hugo. The friction between writing and deploying.

The problem with keeping WordPress public-facing isn't the editor — it's everything else.

Exposing a complete WordPress site to the public means decent hosting, heavy dependency on plugins — at minimum for security and SEO — and serious maintenance.

And by default, performance is variable, to say the least.

The Search for an Alternative

This observation gradually led me to look for a different solution.

For some time now, I've been moving my content publishing to static sites.

But what I really wanted was simpler: keep WordPress as a writing environment while completely removing its public presence.

At a time when static sites can be deployed in seconds on almost any infrastructure, keeping WordPress as a frontend doesn't always make much sense anymore — as long as you have a robust deployment solution.

Write normally. Publish automatically.

No manual export, no scripts to run, no friction.

Existing Tools: Effective but Heavy

Having dozens of articles on my WordPress blogs, I developed a suite of Python tools capable of exporting a complete site to Hugo or Astro.

Functional, reliable, but based on a global export logic: complete site generation, transformation, then deployment.

An effective process, but heavy.

And especially unnatural in a daily writing workflow.

This search for a more fluid editorial workflow gave birth to the project.

The solution: A WordPress plugin implementing per-post, multi-target publishing strategies — GitHub (static), dev.to (API), or both — with atomic commits, structured Markdown conversion, and deployment automation.

It converts posts to Markdown with generator-compatible front matter, optimizes images (WebP/AVIF), commits atomically to GitHub, and can trigger static deployments via GitHub Actions.

Five publishing strategies:

WordPress Only – Pure WordPress site, plugin inactive
WordPress + dev.to – Public WordPress site, optional dev.to syndication per post
GitHub Only – Headless WordPress → static generator → GitHub Pages
Dev.to Only – Headless WordPress → direct dev.to publishing
Dual (GitHub + dev.to) – Static site as canonical + dev.to as controlled syndication

Tech Stack

WordPress Core:

WordPress 6.9+ (PHP 8.1+)
Action Scheduler (async background processing)
Native WordPress APIs (WordPress.org compliant)

Image Processing:

Intervention Image (AVIF + WebP optimization)
Local processing before upload (reduces GitHub Actions cost)

Publishing Destinations:

GitHub API (Trees API for atomic commits)
dev.to API (Forem REST API for direct publishing)

Static Site Generators (via GitHub):

Hugo (YAML/TOML front matter)
Jekyll (different conventions)
Astro (content collections)
Eleventy (custom structures)

Deployment:

GitHub Actions (automated Hugo builds)
GitHub Pages (free static hosting)

Architecture:

Universal adapter pattern (SSG-agnostic)
Async queue system (Action Scheduler)
Atomic commits (all-or-nothing sync)
Strategy-based routing (5 publishing modes)
Post-level sync control (per-post checkboxes)
Headless mode with 301 redirects

Development Timeline

Core plugin development: 48 hours of active coding across 8 sessions
WordPress.org compliance: 3 hours (code review + fixes)
Documentation & testing: 3 hours
Total: ~54 hours over 9 days (Feb 6-14, 2026)

The 23 checkpoints represent iterative development—each a working,
tested increment. Copilot CLI contributed ~70% of implementation time.

Key Features:
✅ Fully asynchronous sync (no admin blocking)
✅ Atomic commits (Markdown + all images in one commit)
✅ Native WordPress APIs only (WordPress.org compliant)
✅ Multi-format image optimization (AVIF → WebP → Original)
✅ Zero shell commands (100% GitHub API)
✅ HTTPS + Personal Access Token authentication
✅ WP-CLI commands for bulk operations

Demo

The workflow is now operational.

Quick Test (3 minutes)

Visit: githubcopilotchallenge.tsw.ovh/wp-admin

Login: tester / Password: Github~Challenge/2k26

Create a post, click Publish → Watch GitHub commit + Hugo deploy

Result: WordPress → Hugo in ~30 seconds.

Demo version: The live demo runs on commit da4e82f (frozen at challenge deadline, Feb 15, 2026). The main branch continues active development—Astro support added post-challenge.

Result is visible on the demo website - as you can see below:

Why I Finally Stopped Fighting My Publishing Workflow | AJC Bridge

For years, I maintained two separate worlds. World One: WordPress. Comfortable writing interface, familiar editor, everything just works. But slow page loads, constant security updates, plugin conflicts, and that nagging feeling that I’m running a Boeing 747 to deliver a postcard. World Two: Static sites. Blazing fast, secure by default, costs pennies to host. But writing in Markdown files, committing to Git, running build commands, debugging deployment pipelines. I spent more time being a DevOps engineer than a writer.

pcescato.github.io

You can also see commited files in the website repository, where you can also find the workflow in .github/workflows.

Articles are written in WordPress, as before.

When publishing or updating, a dedicated plugin automatically triggers synchronization to a GitHub repository.

Each piece of content is converted to Markdown with Hugo-specific front matter, along with optimized images (WebP and AVIF).

Everything is sent in a single commit via the GitHub API.

A GitHub Actions workflow then takes over: static site generation, then deployment to GitHub Pages.

Concretely, publishing in WordPress is now enough to put a complete static version of the site online, without manual export or additional intervention.

The Real-World Gauntlet

This wasn't a smooth 48-hour sprint. The project survived several reality checks:

Hugo Theme Version Hell: The theme I wanted required Hugo 0.146.0 minimum. My local install was 0.139.0. GitHub Actions defaulted to 0.128.0. Each environment needed explicit version pinning, and debugging failures meant decoding cryptic TOML errors across three different build contexts.

GitHub Pages URL Stuttering: The deployed site initially rendered with broken internal links because Hugo's baseURL configuration didn't match GitHub Pages' expectations. Pages built locally worked fine. CI builds deployed with relative paths pointing to void. Solution: hardcode the production URL in the workflow, accept that local previews would have slightly broken navigation.

Image Pipeline Memory Limits: Processing 10+ images per post with AVIF encoding pushed PHP's memory limits on shared hosting. First attempt: fatal errors. Second attempt: disable AVIF, keep WebP. Final solution: increase memory_limit to 512M and batch-process images sequentially instead of in parallel.

Action Scheduler Race Conditions: Early versions created duplicate commits when saving a post multiple times quickly. WordPress's save_post hook fires on autosaves, manual saves, and quick edits. Needed: debouncing logic, transient locks, and post meta flags to prevent redundant syncs.

PHP 8.1 Strictness: A single explode() call on a null value was enough to freeze the entire sync pipeline. We had to implement a try-catch-finally pattern to guarantee that even on crash, the sync lock is released and the UI updated. No more hung admin screens.

Git Line Ending Hell (LF vs CRLF): GitHub Actions Linux runners rejected files modified on Windows because of line ending mismatches. Solution: enforce LF via .gitattributes globally. One config file, zero cross-platform headaches.

The Partial Save Trap: WordPress tabbed interfaces only submit visible fields. When updating the Front Matter template, the GitHub PAT field wasn't sent, resulting in accidental deletion. Fix: array_merge() logic to preserve existing values during partial updates.

None of this was in the initial specifications. All of it was mandatory to ship.

Where Copilot CLI Accelerated Development

Copilot CLI's impact was most visible on structured, repetitive work—precisely where manual development is most tedious.

Measured Example: WordPress.org Compliance Refactoring

When WordPress.org review flagged 6 compliance issues, the fixes required:

Global plugin renaming (30+ files)
Intervention Image API migration (v2 → v3)
Asset restructuring (inline scripts → proper enqueuing)
README updates (external services documentation)

Time with Copilot CLI: 3 hours 8 minutes (measured)

Estimated manual time: 7-10 hours (based on scope)

Acceleration: ~3× faster

This wasn't the only acceleration—it was the only one with precise timestamps.

Other Notable Accelerations (estimated based on comparable WordPress development):

GitHub Trees API integration: ~90 minutes with CLI vs estimated 4-6 hours manual (API docs, trial/error, debugging)
Admin UI components: ~1 hour with CLI vs estimated 3-4 hours manual (WordPress Codex research, boilerplate)
Image optimization pipeline: ~2 hours with CLI vs estimated 5-6 hours manual (library selection, testing, error handling)

The pattern: Copilot CLI consistently provided 3-4× acceleration on structured tasks where the goal was clear and the implementation was well-documented.

What didn't accelerate: Architecture decisions, integration debugging, WordPress.org submission process, edge case discovery.

The real value wasn't just speed—it was eliminating context switching. No searching documentation, no hunting for syntax examples, no copy-pasting boilerplate from other projects.

Why Local Image Optimization Matters

The plugin processes images on the WordPress server before uploading to GitHub. This is crucial:

Without local optimization:

Upload 5MB original JPEGs to GitHub
GitHub Actions must download, process (ImageMagick/Sharp), then deploy
Build time: 2-3 minutes per post
GitHub Actions runner minutes consumed: high
Failed builds leave orphaned large files in Git history

With local optimization (current approach):

WordPress generates AVIF (50-150KB) + WebP (100-300KB) + original
Upload ~500KB total per post to GitHub
GitHub Actions just copies files, no processing
Build time: 15-30 seconds
Clean Git history, minimal runner usage

The trade-off: PHP memory limits and processing time on the WordPress side. But WordPress is idle 99% of the time. GitHub Actions runners cost money per minute.

Processing locally shifts the bottleneck to where it's free.

Architecture

What's Currently Handled:

✅ Posts and Pages: Both sync automatically with proper Hugo front matter
✅ Deletions: Trashing a post/page in WordPress triggers file deletion in GitHub
✅ Updates: Editing content re-syncs, overwriting existing files
✅ Categories and Tags: Converted to Hugo taxonomies in front matter
✅ Featured Images: Optimized and linked in front matter (featured_image field)
✅ Custom Fields: Basic fields map to front matter (extensible via adapter)

Current Limitations (MVP scope):

⚠️ Draft Handling: Drafts stay in WordPress, never sync (intentional)
⚠️ Revisions: Only published versions sync, revision history stays local
⚠️ Complex Blocks: Gutenberg blocks convert to HTML, then basic Markdown (no advanced block preservation)
⚠️ Shortcodes: Rendered to HTML before conversion (loses original shortcode)
⚠️ ACF/Meta Boxes: Only standard custom fields supported (ACF requires custom adapter extension)
⚠️ Author Pages: Not yet implemented (single-author blogs work fine)

Deliberate Trade-offs:

WordPress remains the source of truth. The plugin doesn't sync bidirectionally. If you edit Markdown directly in GitHub, those changes won't flow back to WordPress. This is intentional — simplicity over complexity.

Theme Changes and SSG Migration:

Thanks to the universal front matter template system, changing Hugo themes or even migrating to a different SSG is now straightforward:

Update the front matter template in plugin settings (no code changes)
Bulk re-sync all posts via WP-CLI (wp jamstack sync --all)
Optional cleanup of old file structure in Git (if directory paths changed)

The adapter pattern is already in place. Adding support for Jekyll, Eleventy, or Astro means implementing a new adapter class — the core sync engine remains untouched.

What's not yet automated: migrating between SSGs with fundamentally different content structures (e.g., Hugo's content/posts/ vs Astro's src/content/blog/). This would require a bulk file move operation in Git, which is currently manual.

But changing front matter conventions within the same SSG? That's now a settings change, not a refactoring project.

The repository contains:

WordPress plugin (WordPress.org compliant)
GitHub API integration (atomic commits)
Asynchronous sync management (Action Scheduler)
Hugo-compatible Markdown generation
GitHub Actions workflow for deployment

How It Works

The process in detail:

1. Writing: Standard WordPress interface, no change in the writing experience

2. Automatic Commit: The GitHub repository receives Markdown, optimized images, and front matter

You can see the .github/workflows folder, where you can find the hugo.yml file (1), the content folder (2), the static/images one (3), and last deployment status (4).

3. Hugo Structure: content/posts/ structure automatically generated with correct naming

4. Deployed Site: Static version online via GitHub Pages, optimal performance

The whole thing forms a simple publishing chain: write in WordPress, publish, and let the rest execute.

Resources

Source Code: AJC Bridge
Releases: GitHub Releases
Documentation: DeepWiki (AI-generated)

Production Update: Multi-Destination Publishing

While building this plugin, I realized something obvious in hindsight: the dev.to API has existed for years.

I'd been so focused on static site generators that I missed the simpler path: publish directly to dev.to via API.

So I added it.

Five Publishing Strategies

The plugin now supports five distinct workflows, each solving different use cases:

1. WordPress Only

WordPress (public site)

Plugin configured but sync disabled. For teams evaluating the plugin or running pure WordPress sites.

2. WordPress + dev.to Syndication

WordPress (public, canonical) → dev.to (syndication)

WordPress remains your public site. Optionally syndicate posts to dev.to with canonical_url pointing back to WordPress. Perfect for established WordPress sites with existing audiences who want dev.to reach.

Per-post control: Checkbox in post sidebar: "☐ Publish to dev.to"

3. GitHub Only (Headless WordPress)

WordPress (headless) → Hugo/Jekyll → GitHub Pages

Traditional JAMstack workflow. WordPress is admin-only, frontend redirects to your static site. All published posts sync automatically.

4. Dev.to Only (Headless WordPress)

WordPress (headless) → dev.to

Zero infrastructure. WordPress writes, dev.to publishes, WordPress frontend redirects. For developers who want WordPress's editor but dev.to's community without managing static sites.

This is the mode I use. All my articles are published exclusively on dev.to.

5. Dual Publishing (GitHub + dev.to)

WordPress (headless) → GitHub (canonical) + dev.to (syndication)

Best of both worlds. Hugo site = canonical source (your domain, your control). Dev.to = syndication (massive audience, zero SEO penalty via canonical_url). WordPress frontend redirects to Hugo.

Per-post control: GitHub always syncs. Checkbox controls dev.to: "☐ Publish to dev.to"

Five publishing strategies covering WordPress-only, headless, and hybrid workflows

API key configuration

Per-post checkbox in sidebar: decide which posts syndicate to dev.to

Why This Matters

For established WordPress sites: Keep your public WordPress site (audience, SEO, landing pages) but syndicate blog posts to dev.to for community reach.

For JAMstack purists: Go fully headless with Hugo, optionally syndicate to dev.to.

For dev.to community members: Use WordPress as your writing environment, publish exclusively to dev.to.

For migrations: Start with WordPress Only, test strategies incrementally, migrate when ready. Zero lock-in.

Technical Implementation

The architecture supports all five modes through strategy-based routing:

switch ( $strategy ) {
    case 'wordpress_only':
        return; // No sync

    case 'wordpress_devto':
        if ( post_meta '_wpjamstack_publish_devto' === '1' ) {
            sync_to_devto( $post, canonical_url: get_permalink() );
        }
        break;

    case 'github_only':
        sync_to_github( $post );
        break;

    case 'devto_only':
        sync_to_devto( $post, canonical_url: null );
        break;

    case 'dual_github_devto':
        sync_to_github( $post );
        if ( post_meta '_wpjamstack_publish_devto' === '1' ) {
            sync_to_devto( $post, canonical_url: $hugo_url );
        }
        break;
}

Headless mode automatically redirects WordPress frontend (301) to the canonical destination (Hugo or dev.to) in headless strategies. WordPress admin remains fully functional.

Per-post control in WordPress + dev.to and Dual modes: a checkbox in the post sidebar lets authors decide which posts syndicate externally.

Canonical URL handling:

WordPress + dev.to: canonical_url → WordPress permalink
Dual (GitHub + dev.to): canonical_url → Hugo site URL
Dev.to Only: No canonical (dev.to is primary)

Real-World Usage

This article was published using dev.to's rich editor before I implemented the adapter.

Future articles will be published via the plugin: I write in WordPress, click Publish, and the plugin handles the rest via dev.to's API.

The dev.to API isn't new. The Forem platform has supported it for years.

What's new is the integration: WordPress as the writing environment, dev.to as the publishing platform, zero manual steps.

That's the difference between a demo and production: the tool becomes part of the workflow, not just a talking point.

What's Next

The plugin ships with Hugo and dev.to adapters, but the architecture supports more:

Additional platforms ready:

Jekyll (GitHub Pages native SSG)
Hashnode (GraphQL API)
Ghost (Admin API)

AI-native architecture: Compatible with emerging frameworks like WordPress/agent-skills for future voice-controlled publishing.

WordPress.org submission: Submitted February 6, 2026. Pending review for public distribution to the WordPress plugin directory.

The adapter pattern means adding new destinations is straightforward. The hard part — WordPress integration, async processing, error handling — is done.

Technical Highlights

1. Universal Front Matter Engine

Instead of hardcoding the plugin for a single Hugo theme, we built a raw template system. Users define their own YAML (or TOML) with custom delimiters and placeholders like {{id}}, {{title}}, or {{image_avif}}.

This means the same plugin can adapt to any SSG convention:

Hugo with YAML front matter
Jekyll with different taxonomy names
Eleventy with custom data structures

You control the output format. The plugin just fills in the blanks.

2. Asset Management by WordPress ID

To guarantee unbreakable links, optimized images (WebP and AVIF) are stored in folders named by WordPress ID: static/images/1460/.

Rename your post slug for SEO ten times? Your images never break. The ID is immutable. The file paths are permanent.

3. Native WordPress Integration

The plugin integrates as a first-class citizen with its own sidebar menu and tabbed navigation.

Role-based security: Authors only see their own sync history. Critical settings (GitHub PAT) remain admin-only.

Responsible cleanup: A "Clean Uninstall" option removes all plugin traces (options and post meta) on uninstall, leaving zero database pollution.

4. Atomic Commits via GitHub Trees API:
Instead of multiple sequential commits (one per image, one for Markdown), the plugin uses GitHub's Git Data API to create a single commit containing all files:

// Collect all files (Markdown + images)
$all_files = [
    'content/posts/2026-02-07-this-is-a-post.md' => $markdown_content,
    'static/images/1447/featured.webp' => $webp_binary,
    'static/images/1447/featured.avif' => $avif_binary,
    'static/images/1447/wordpress-to-hugo-1024x587.webp' => $webp_binary,
    'static/images/1447/wordpress-to-hugo-1024x587.avif' => $avif_binary,
];

// Single atomic commit
$git_api->create_atomic_commit($all_files, "Publish: This is a Post");

This approach is transactional: either everything commits or nothing does. No partial states, cleaner history.

5. Beyond Hugo: Multi-SSG Architecture
While this demo targets Hugo, the adapter pattern isn't locked to a single SSG. The same codebase can support:

Hugo (YAML/TOML front matter, content/posts/)
Jekyll (different taxonomy conventions, _posts/)
Eleventy (custom data structures, src/content/)
Astro (content collections, src/content/blog/)

Adding a new SSG means writing one adapter class — the sync engine, image optimization, and GitHub integration remain untouched.
This architectural choice transforms the plugin from "Hugo-only" to a platform for any static site workflow. The 43 million WordPress sites aren't just potential Hugo users — they're potential static site adopters, period.

6. WordPress-Native Compliance:
To meet WordPress.org requirements, the plugin uses exclusively native WordPress APIs:

wp_remote_post() instead of curl
WP_Filesystem instead of file_put_contents()
$wpdb prepared statements
No exec(), shell_exec(), or Git CLI

This makes it suitable for publication in the official WordPress plugin repository.

My Experience with GitHub Copilot CLI

When I started this project, I wasn't looking for a tool to code for me.

I was looking for a way to accelerate the execution of a project whose architecture was already clear.

Having already used GitHub Copilot CLI, Gemini CLI, and various LLMs on other projects, I knew these tools could produce code quickly.

But I also knew that without a precise framework, they mainly produce... code.

Not necessarily a coherent system.

Note: This isn't the autocomplete in the editor, but a command-line tool capable of generating complete files from structured prompts.

Specification First, Code Second

The first step wasn't to code. The first step was to write specifications. Define the scope. Break down the project into functional blocks.

Identify non-negotiable constraints: WordPress native only, no shell execution, reliable async processing, atomic GitHub commits, WordPress.org compliance to publish the plugin in the official repository and benefit the community.

Here are my first interactions with Copilot CLI:

GitHub Copilot Session - WordPress Plugin

You

You are generating a production-grade WordPress plugin.

Use specifications.md and the ADR addendum as the single source of truth.

We are implementing ONLY the bootstrap foundation of the plugin.

Do NOT implement sync logic, adapters, queue logic, or GitHub logic yet.

STEP 1 — Generate plugin file structure

Generate the exact plugin file tree defined in section 7.1 of specifications.md.

Do not add extra files.
Do not invent features.
Respect strict architecture decisions.

STEP 2 — Create main plugin bootstrap file

Create:

wp-jamstack-sync.php

The file must:

include proper WordPress plugin headers
prevent direct access via ABSPATH check
define constants:
- WPJAMSTACK_VERSION
- WPJAMSTACK_PATH
- WPJAMSTACK_URL
load required core files (empty placeholders allowed)
register activation hook
register deactivation hook

STEP 3 — Activation hook

On activation:

verify WordPress >= 6.9
verify PHP >= 8.1
if not compatible:
- deactivate plugin safely
- show admin error
- do not use raw die()
- use WordPress-safe handling

STEP 4 — Development .env loader (DEV ONLY)

Add a lightweight .env loader.

Rules:

Only load .env if: WP_ENVIRONMENT_TYPE === 'development'
Do nothing in production
Fail silently if file missing
No external libraries
Parse simple KEY=VALUE pairs
Populate values into: $_ENV and getenv()

Never require .env in production.

STEP 5 — Output

Return:

plugin file tree
full content of wp-jamstack-sync.php
nothing else

Agent

I'll read the specifications and create the plugin bootstrap foundation.

7 messages not shown

Agent

Now I'll create the plugin bootstrap foundation with the exact structure from section 7.1:

3 messages not shown

Agent

Perfect! Here's the complete output:

1. Plugin File Tree

wp-jamstack-sync/
├── wp-jamstack-sync.php       # Main plugin bootstrap file
├── /core                      # Empty (placeholder for future classes)
├── /adapters                  # Empty (placeholder for future adapters)
├── /admin                     # Empty (placeholder for future admin UI)
├── /cli                       # Empty (placeholder for future WP-CLI)
├── /includes                  # Empty (placeholder for future helpers)
└── /assets                    # Empty (placeholder for future assets)
    ├── /css
    └── /js

2. Full Content: `wp-jamstack-sync.php`

<?php
/**
 * Plugin Name: WP Jamstack Sync
 * Plugin URI: https://github.com/pascalcescato/wp-jamstack-sync
 * Description: Automated WordPress to Hugo publishing system with async GitHub API integration.
 * Version: 1.0.0
 * Requires at least: 6.9
 * Requires PHP: 8.1
 * Author: Pascal CESCATO
 * Author URI: https://github.com/pascalcescato
 * License: GPL v2 or later
 * License URI: https://www.gnu.org/licenses/gpl-2.0.html
 * Text Domain: wp-jamstack-sync
 * Domain Path: /languages
 */

if ( ! defined( 'ABSPATH' ) ) {
    die( 'Direct access not permitted.' );
}

// Plugin constants
define( 'WPJAMSTACK_VERSION', '1.0.0' );
define( 'WPJAMSTACK_PATH', plugin_dir_path( __FILE__ ) );
define( 'WPJAMSTACK_URL', plugin_dir_url( __FILE__ ) );

// Development .env loader (only in development environment)
if ( function_exists( 'wp_get_environment_type' ) && 'development' === wp_get_environment_type() ) {
    wpjamstack_load_env();
}

/**
 * Load environment variables from .env file (development only)
 *
 * @return void
 */
function wpjamstack_load_env() {
    $env_file = WPJAMSTACK_PATH . '.env';

    if ( ! file_exists( $env_file ) ) {
        return;
    }

    $lines = @file( $env_file, FILE_IGNORE_NEW_LINES | FILE_SKIP_EMPTY_LINES );

    if ( false === $lines ) {
        return;
    }

    foreach ( $lines as $line ) {
        // Skip comments
        if ( strpos( trim( $line ), '#' ) === 0 ) {
            continue;
        }

        // Parse KEY=VALUE pairs
        if ( strpos( $line, '=' ) !== false ) {
            list( $key, $value ) = explode( '=', $line, 2 );
            $key   = trim( $key );
            $value = trim( $value );

            // Remove quotes if present
            $value = trim( $value, '"' );
            $value = trim( $value, "'" );

            // Set in $_ENV and putenv
            $_ENV[ $key ] = $value;
            putenv( "$key=$value" );
        }
    }
}

/**
 * Activation hook - verify system requirements
 *
 * @return void
 */
function wpjamstack_activate() {
    global $wp_version;

    $errors = array();

    // Check WordPress version
    if ( version_compare( $wp_version, '6.9', '<' ) ) {
        $errors[] = sprintf(
            /* translators: %s: Required WordPress version */
            __( 'WP Jamstack Sync requires WordPress %s or higher.', 'wp-jamstack-sync' ),
            '6.9'
        );
    }

    // Check PHP version
    if ( version_compare( PHP_VERSION, '8.1', '<' ) ) {
        $errors[] = sprintf(
            /* translators: %s: Required PHP version */
            __( 'WP Jamstack Sync requires PHP %s or higher.', 'wp-jamstack-sync' ),
            '8.1'
        );
    }

    // If errors exist, deactivate and show message
    if ( ! empty( $errors ) ) {
        // Deactivate the plugin
        deactivate_plugins( plugin_basename( __FILE__ ) );

        // Show error message
        wp_die(
            '<h1>' . esc_html__( 'Plugin Activation Failed', 'wp-jamstack-sync' ) . '</h1>' .
            '<p>' . implode( '</p><p>', array_map( 'esc_html', $errors ) ) . '</p>' .
            '<p><a href="' . esc_url( admin_url( 'plugins.php' ) ) . '">' .
            esc_html__( 'Return to Plugins', 'wp-jamstack-sync' ) . '</a></p>',
            esc_html__( 'Plugin Activation Error', 'wp-jamstack-sync' ),
            array( 'back_link' => true )
        );
    }

    // Activation successful - future tasks go here
    // (e.g., create tables, set default options, schedule cron)
}

/**
 * Deactivation hook - cleanup tasks
 *
 * @return void
 */
function wpjamstack_deactivate() {
    // Future cleanup tasks go here
    // (e.g., clear scheduled tasks, flush caches)
}

// Register activation/deactivation hooks
register_activation_hook( __FILE__, 'wpjamstack_activate' );
register_deactivation_hook( __FILE__, 'wpjamstack_deactivate' );

// Load core files (placeholders for now)
// require_once WPJAMSTACK_PATH . 'core/class-plugin.php';
// require_once WPJAMSTACK_PATH . 'core/class-sync-runner.php';
// require_once WPJAMSTACK_PATH . 'core/class-queue.php';
// require_once WPJAMSTACK_PATH . 'core/class-logger.php';
// require_once WPJAMSTACK_PATH . 'core/class-github-api.php';

// Initialize plugin
// if ( class_exists( 'WPJamstack\Core\Plugin' ) ) {
//  WPJamstack\Core\Plugin::get_instance();
// }

✅ Bootstrap foundation complete

- File structure matches section 7.1 specifications

- Main plugin file created with WordPress-compliant headers

- Version checks (WP 6.9+, PHP 8.1+) enforce requirements on activation

- Safe deactivation with proper error handling (no raw die())

- Development .env loader active only when WP_ENVIRONMENT_TYPE === 'development'

- Core file loaders commented out (ready for future implementation)

Then organize development into successive stages.

Development unfolded in structured phases: bootstrap, core architecture, async queue system, media pipeline, atomic GitHub commits, deletion lifecycle, bulk operations, and admin-side hardening.

Copilot CLI was used as an execution partner — implementing each layer under explicit constraints (WordPress native APIs only, async safety, atomic operations, repository compliance). The focus was not just faster coding, but building a production-ready system.

This approach is very similar to what a technical project manager or lead engineer would do before entrusting implementation to a team. The difference here is that the “team” consisted of a tool capable of producing code extremely quickly — but only if instructions were precise and constraints well defined.

So I didn’t write code in the traditional sense. I wrote functional and technical specifications, prompts, refined instructions, corrected trajectories, and validated outputs against the intended architecture.

Each step consisted of describing what needed to be built, verifying what was produced, and adjusting accordingly.

Sometimes Copilot proposed a relevant structure on the first try. Sometimes it required reworking, clarification, or tighter constraints.

The Work Pattern

Very quickly, a work pattern emerged: specification → generation → verification → correction → iteration.

In this process, Copilot behaves less like a magic generator than like a fast executor.

It can structure an entire class in seconds, propose a coherent implementation, or refactor a complete block.

But it can also forget an essential hook, overwrite an existing method, or produce functional code that doesn't comply with initial constraints.

Real Examples of Issues:

Method replaced by an incomplete stub
Hook not registered, causing silent failures
File generated but not actually written to disk
Fatal error on activation, typical of strict WordPress environments

Each incident required going back to fundamentals: verify, understand, correct, reformulate.

The Prompt Gallery: Steering the CLI

To move from concept to production-grade code, I steered Copilot CLI through complex engineering hurdles. These aren't just snippets; they are the instructions that shaped the architecture.

1. The Atomic Shift (Core Logic)

Context: Moving from simple file uploads to the GitHub Trees API to ensure images and Markdown commit simultaneously.
Refactor the Git_API class to use the Trees API. I need a single atomic commit containing the Markdown file and all processed images. Use the SHA of the base branch to create the tree.

2. The Stateful Sync (Lifecycle Management)

Context: Preventing duplicates on Dev.to by persisting remote IDs.
Update the Sync_Runner to check for '_atomic_jamstack_devto_id'. If it exists, use a PUT request to update the existing article; otherwise, POST a new one and save the returned ID.

3. The Security Audit (Hardening)

Context: Passing the official WordPress 'Plugin Check' tool.
Scan admin/class-settings.php. Identify all missing nonces and un-sanitized $_POST variables. Apply wp_verify_nonce and sanitize_text_field according to WP.org standards.

What This Actually Means

This is probably the most interesting aspect of the experience.

Using Copilot effectively doesn't mean writing one prompt and waiting for a result.

It's much more like continuous piloting, where the quality of instructions directly conditions the quality of what's produced.

In this context, the tool becomes particularly effective for accelerating everything that's structured: class creation, file organization, repetitive function implementation, refactoring, documentation.

As soon as the objective is clearly defined, execution can become very fast.

But the responsibility for architecture, technical choices, and overall coherence remains entirely human.

The Real Value

In the end, the experience is less like "AI-assisted development" than a form of assisted technical direction.

Code is produced quickly, but it must be thought out, supervised, and validated continuously.

This project was built in less than two days. Not because the tool replaces design work, but because once that work is done, execution can be considerably accelerated.

This is probably where GitHub Copilot CLI becomes most interesting: it's not a substitute for development, but an accelerator for an already thought-out and structured project.

The Development Rhythm

Each feature followed a consistent workflow that kept development focused and auditable:

1. Planning: Describe the goal in natural language
Example: Add atomic commit support using GitHub Trees API

2. Proposal: Copilot suggests implementation approach
Copilot outlines: file changes, API calls, error handling

3. Review: Validate architecture before generation
Check: Does this align with WordPress standards? Any edge cases?

4. Generation: Multi-file code updates with consistent patterns
Copilot writes across 5-10 files simultaneously

5. Testing: Manual verification and integration testing
Test: WordPress admin, GitHub API, Hugo deployment

6. Checkpoint: Document working increment for audit trail
Create: checkpoint file with context and decisions

This rhythm repeated 23 times throughout development. Each checkpoint represents a tested, working state—not just code, but verified functionality.

The checkpoints weren't documentation overhead. They were the development cadence.

Real Example: AVIF Generation Fix

Here's what an actual development session looked like:

Detailed problem description → Copilot proposes complete solution with code, validation, and error handling

The prompt describes:

What to fix: AVIF generation failures
How to fix it: Use explicit AvifEncoder, add file validation
How to verify: Check encoder usage, test file creation

Copilot responds with a 281-line implementation plan covering:

Code changes across 2 methods
Import statements updates
Error logging improvements
Verification commands

After applying changes: verification confirms correct implementation, Before/After shows API migration

Time: ~15 minutes from problem to verified solution

Manual estimate: 1-2 hours (research v3 API docs, update all calls, test each format)

Acceleration: ~4-6× faster

This pattern—detailed prompt, comprehensive response, systematic verification—repeated throughout development. The 23 checkpoints represent 23 iterations of this cycle.

The Audit Trail Advantage

Beyond just writing code, GitHub Copilot CLI acts as a technical scribe.

My session history evolved through 23 distinct checkpoints, documenting every architectural pivot from the initial foundation to the final security hardening:

001-wordpress-plugin-foundation
002-media-processing-with-avif-support
003-deletion-and-bulk-sync
004-atomic-commits-and-monitoring
...
019-fix-plugin-check-errors
020-add-nonce-security
021-uninstall-api-compliance
022-fix-nonce-sanitization-warnings
023-fix-token-double-encryption.md

You can browse the complete checkpoint history here: https://github.com/pcescato/ajc-bridge/tree/main/docs, including the initial specifications.

Each checkpoint includes context files like wordpress-api-compliance-guide.md, token-preservation-fix.md, or settings-merge-test-plan.md.

This isn't just a side effect — it's a massive win for maintainability.

It transforms the "black box" of AI generation into a transparent, step-by-step engineering log. Six months from now, when I need to understand why a particular decision was made, I won't be guessing. The checkpoint history tells the story.

What worked well:
✅ Rapid scaffolding of classes following WordPress standards
✅ Boilerplate code generation (hooks, filters, nonces)
✅ Refactoring large blocks (sequential commits → atomic commits)
✅ Documentation generation from inline comments

What required constant supervision:
⚠️ Architecture decisions (adapter pattern, async queues)
⚠️ WordPress.org compliance verification
⚠️ Error handling and edge cases
⚠️ Integration testing across components

Code Review: Validating Production Readiness

Once the plugin was functional and submitted to WordPress.org (February 6), I wanted to validate its code quality independently—without waiting for the review team's feedback.

The question: Is this truly production-ready, or did fast development introduce critical bugs?

The Review Process

I used GitHub Copilot CLI to conduct a comprehensive security and compliance audit.

The prompt: Review this WordPress plugin for critical blockers. Focus on security vulnerabilities, WordPress.org compliance, and data integrity issues.

Review completed in 10 minutes with an 800-line report covering:

Security (authentication, sanitization, secrets handling)
Compliance (coding standards, uninstall cleanup, version consistency)
Correctness (race conditions, SQL queries, data loss risks)

Findings: 3 Critical Blockers

Grade: C+ (production-ready with critical fixes needed)

The review validated the architecture ("excellent design, clean separation") but identified 3 blockers that would likely trigger WordPress.org rejection:

1. Secret Logging (Security - CRITICAL)

Issue: GitHub token previews logged to debug files.
Risk: Partial token exposure in database logs and files.
Fix: Removed all secret previews (30 minutes).

2. Version Mismatch (Compliance - CRITICAL)

Issue: Plugin header showed 1.1.0, readme.txt showed 1.2.0.
WordPress.org automated checks reject version inconsistencies.
Fix: Updated plugin header and constant to 1.2.0 (5 minutes).

3. Incomplete Uninstall (Compliance - CRITICAL)

Issue: Plugin created 13 post meta keys but only cleaned up 5 in uninstall.php.
Why this matters: WordPress.org reviewers manually check uninstall cleanup. Incomplete removal is a rejection reason.
Fix: Added 7 missing meta keys + 1 option cleanup (15 minutes).

Fixing the Blockers: 20 Minutes

I created a surgical prompt for Copilot CLI:

Fix ONLY the 3 critical blockers. 
Do NOT refactor anything else.

Changes made:

✅ Removed secret logging (verified with grep)
✅ Synced all versions to 1.2.0
✅ Completed uninstall cleanup (11 meta keys total)

WordPress.org Submission: The Road to Approval

Moving code from a local environment to the official WordPress.org repository is the ultimate moment of truth. For this project, I implemented a two-tier quality assurance strategy that transformed potential rejection into a near-immediate technical validation.

Process Timeline

February 6: Initial plugin submission.
February 12: Internal review via Copilot CLI. Identified and fixed 3 critical logic and security bugs in 20 minutes.
February 14 (00:00): Received official WordPress.org review. Identified 6 specific compliance and ecosystem issues.
February 14 (03:08): Within 3 hours, all 6 issues were addressed and version 1.2.0 re-submitted.

Current Status: ✅ Pending Final Manual Approval (Typical queue wait: 7–14 days).

The Refactoring Challenge: 3 Hours Instead of 10

The 6 compliance issues required substantial code changes:

What needed to be done:

Global renaming: 30+ files, hundreds of references
API migration: intervention/image v2 → v3
Assets restructuration: Extract 6 inline scripts, implement wp_enqueue
Documentation: External services section with API details

Manual estimate (senior developer): 7-10 hours
Actual time with Copilot CLI: 3 hours 8 minutes

The difference? Copilot CLI excels at systematic refactoring:

Global renaming: One prompt replaced hundreds of references across 30+ files without missing edge cases
API migration: Copilot read the intervention/image v3 changelog and refactored all image processing calls automatically
Pattern extraction: Identified all inline <script>/<style> tags and generated proper enqueue functions with correct hooks

This wasn't about generating new code—it was about surgical precision
at scale. The kind of work that's technically straightforward but
humanly tedious and error-prone.

The result: A compliant, tested plugin ready for re-submission in
the time it would have taken to just complete the renaming manually.

The Power of Dual Review (AI + Human)

This workflow demonstrates that even "production-ready" code benefits from an external perspective. The two audits served very different, yet complementary, purposes:

1. Internal Audit (Copilot CLI): Security & Logic

Copilot acted as a tactical second pair of eyes, catching issues that fast-paced development often misses:

Security Vulnerabilities: Identified partial exposure of sensitive secrets.
Operational Integrity: Ensured rigorous cleanup during activation/uninstallation.
Version Hygiene: Fixed inconsistent constants that would have triggered automated rejection.
Result: Transitioned the code from "fragile" to a robust, enterprise-grade architecture.

2. WordPress.org Review: Compliance & Ecosystem

Since writing this, the plugin passed WordPress.org official review. The review (a mix of automated algorithms and human oversight) focused on how the plugin lives within the WordPress ecosystem:

Intellectual Property: Renamed "Atomic Jamstack Connector" to "AJC Bridge" to eliminate trademark confusion.
Technical Standards: Replaced inline <script> and <style> tags with the proper wp_enqueue system.
Transparency: Documented external service usage (GitHub & Dev.to APIs) in the readme.txt to comply with Guideline 6.
Dependency Hygiene: Forced an upgrade of the intervention/image library (v2.7 → v3.11) to patch known vulnerabilities.

Takeaway: Production Readiness over Theoretical Perfection

The plugin moved from "Blocked" to "Repository Ready" in record time.

Surgical Fixes: We didn't perform a radical rewrite. Instead, we used AI to target specific files flagged in the reviews, applying and testing patches immediately.
The Value of Audit Trails: The detailed history of architectural decisions made during development allowed the AI to understand the "why" behind the code, proposing fixes that maintained the plugin's logic.
Engineering Pragmatism: We prioritized critical blockers for the submission while deferring minor optimizations (like edge-case race conditions) to the v1.3 roadmap.

The Lesson: AI doesn't replace official validation; it prepares you for it. By using Copilot to eliminate logical bugs early, you clear the path to focus on the platform's specific quirks — the trademark checks, the enqueue rules, the dependency audits that only humans (or their algorithms) flag.

Next Step: Official launch on the WordPress.org repository under the slug ajc-bridge.

Addendum: Automating the Future with GitHub Actions

To wrap up this intensive session, I implemented a professional CI/CD pipeline to ensure that every future release of AJC Bridge is as clean and reliable as this one.

The "Release-on-Demand" Machine

In just a few minutes, I used Copilot CLI to generate a GitHub Actions workflow that automates the entire packaging process:

Trigger: The workflow springs into action the moment a new version tag (e.g., v1.2.0) is pushed, or via manual trigger.
Clean Packaging: It automatically builds a production-ready ZIP file, strictly excluding development overhead like .git, .github configurations, composer.json, and local documentation.
Standardized Deployment: The ZIP is structured specifically for WordPress.org standards (internal folder named ajc-bridge), ensuring a seamless installation for users.
Automated Releases: The workflow creates an official GitHub Release and attaches the optimized plugin archive as a primary asset.

Why this Matters

By automating the release process, I’ve eliminated the risk of human error—like forgetting to remove a sensitive config file or misnaming a folder.

This completes the transition from a solo dev project to a professionally maintained bridge. Whether it’s a minor patch or a major feature update (like the upcoming v1.3), I can now ship a compliant, high-quality version to the community in seconds with a single Git command.

Conclusion

GitHub Copilot CLI didn't replace development.

It didn't eliminate the need to think, architect, or decide.

But used as an execution partner rather than an automatic generator, it made it possible to quickly transform a clear idea into a functional system.

That's perhaps where these tools really make sense: they don't change the way we build, but they reduce the distance between what we imagine and what we put into production.

In this specific case, they made it possible to solve a real tension: write comfortably in WordPress while publishing to a high-performance static site.

No friction. No compromises.

Just a workflow that works.

Looking ahead: v1.3 will add smart Table of Contents generation—
automatically detecting long-form content and generating dev.to /
SSG-compatible ToC with configurable thresholds (>600 words, 2+ H2) to ensure it only triggers when useful.

Final Thought

WordPress isn't the enemy; it's the most powerful editorial engine we have. By decoupling it from the frontend, we don't just fix performance—we future-proof the web.

Ready to see it in action? Try the live demo here or explore the code on GitHub.

From Local SQLite Scripts to a Cloud Platform with GitHub Copilot CLI

Pascal CESCATO — Sun, 01 Feb 2026 11:04:17 +0000

This is a submission for the GitHub Copilot CLI Challenge

From SQLite CLI to Cloud Platform: How I Became an AI Architect

What I Built

TL;DR: I transformed a local SQLite-based CLI tool into a production-grade analytics platform in 30 hours of actual work, without writing a single line of code by hand.

The Starting Point

Every developer has one: a useful local script that becomes your "technical memory." Mine was a DEV.to analytics tracker—a Python CLI tool backed by SQLite—that helped me understand my content performance beyond basic stats. It tracked follower attribution using 7-day windows with 6-hour tolerance, calculated quality scores with weighted formulas, and performed sentiment analysis on comments using VADER. You can read about it in my When DEV.to Stats Aren't Enough: Building My Own Memory article.

This work is not a port of a third-party project. It is an evolution of a codebase I originally created and maintain, and the repository is publicly available on GitHub:

pcescato / devto_stats

DEV.to Metrics Tracker 📊

Automatic collection and historical analysis of your DEV.to metrics

"Without historical data, you only see snapshots. With historical data, you see trends."

🎯 Goals

Automatically collect all your DEV.to metrics
Store historical snapshots for long-term analysis
Deep-dive into engagement (comments, followers, etc.)
Never lose data again — the core idea behind the project

📦 Files

devto-metrics-tracker/
├── devto_tracker.py          # Main collection script
├── comment_analyzer.py       # Deep comment analysis
├── setup_automation.sh       # Automatic cron setup
├── advanced_analytics.py     # Advanced metrics analysis
├── anrety.py                 # Article analysis tool
├── checkcoverage.py          # Coverage verification
├── checkincremental.py       # Incremental data checks
├── cleanup_articles.py       # Cleanup of removed articles
├── cli_to_svg.py             # CLI-to-SVG converter
├── dashboard.py              # Metrics dashboard
├── diagnose.py               # Metrics diagnostics
├── fix.py                    # Error correction script
├── list_articles.py          # List collected articles
├── nlp_analyzer.py           # NLP analysis on comments
├── quality_analytics.py      # Article quality analysis
├── quick_check.py

…

View on GitHub

But it lived in isolation on my machine.

The Vision

I wanted to transform this personal tool into a secure, scalable web platform accessible from anywhere. My non-negotiable constraints:

PostgreSQL 18 (not 16, not 17—I wanted latest JSONB features and pgvector compatibility for tomorrow)
SQLAlchemy Core (NOT ORM—I refused to hide my procedural SQL logic behind ORM magic)
Authentik (self-hosted IAM with granular groups, not just a basic OAuth proxy)
Caddy outside Docker (bare metal reverse proxy for performance)
Apache Superset (initially... more on that pivot later)

The Final Stack

After strategically pivoting away from Superset (1GB RAM was too heavy for my 4GB VPS), the production stack became:

Component	Technology	Purpose
Backend	FastAPI (async)	High-performance REST API
Database	PostgreSQL 18	Partitioned tables, JSONB, arrays, pgvector-ready
Cache	Valkey 8.0	Redis-compatible in-memory store
Frontend	Streamlit	Interactive data visualization (replaced Superset)
Security	Authentik + Caddy	Self-hosted IAM with proxy auth
Infrastructure	Docker Compose	Containerized deployment

Key Features

1. The "Sismograph"

Unlike traditional analytics showing cumulative totals, my Sismograph visualizes real-time activity pulses. It calculates deltas between data snapshots to reveal when traffic actually spikes, not just how many views you have total.

2. Author DNA

Automatic thematic classification of content:

"Expertise Tech" (SQL, PostgreSQL, Docker)
"Human & Career" (feedback, learning, growth)
"Culture & Agile" (management, performance)

The system analyzes titles and tags, counting keyword matches to determine dominant themes.

3. Real-Time Activity Monitor (The "Wake-up" Call)

While the Sismograph shows pulses, I needed a way to spot "sleeping" articles that suddenly regain traction months later.

For instance, my article "From Pocket to Wallabag", published 4 months ago, suddenly saw a spike of 10 views in a single morning. This view, implemented via a targeted prompt to GitHub Copilot CLI, aggregates current activity across the entire library. It transforms the platform from a simple archive into an active monitoring tool, saving me from manual, article-by-article checks.

4. Strategic Pivot: Performance Over Weight

Initially, I aimed for Apache Superset for the visualization layer. However, the reality of the field—a 4GB VPS—quickly imposed its limits: Superset alone consumed 1GB of RAM, leaving too little room for the rest of the stack.

Thanks to AI, I was able to perform an immediate architectural pivot:

Zero emotional attachment: Since the code wasn't "hand-written" over several days, I had no hesitation in discarding Superset in favor of Streamlit (512MB) to regain system fluidity.
Reduced cost of change: What would normally have taken days of manual reconfiguration and dashboard rebuilding was resolved in just a few hours of prompt-driven steering.
Future-Proofing while Lean: I used this reclaimed agility to integrate Vector(1536) columns via pgvector into my PostgreSQL 18 schema. Even though I am not using embeddings yet, the structure is ready for tomorrow without having cost a single effort of complex migration today.

AI doesn't just generate code; it makes architecture malleable. It allowed me to meet strict hardware constraints without sacrificing my long-term technical vision.

Demo

🔗 Live Platform:

API Documentation: analytics.weeklydigest.me/docs
Dashboard: streamlit.weeklydigest.me (requires Authentik authentication: login: judge, password: Github~Challenge/2k26)
Source Code: (GitHub Repository)

pcescato / devto_githubcopilotcli_challenge

AI-assisted migration of DEV.to analytics from CLI to production web platform using GitHub Copilot CLI

DEV.to Analytics Platform

AI-assisted migration of DEV.to analytics from CLI to production web platform using GitHub Copilot CLI

📖 Overview

A comprehensive analytics platform for tracking and analyzing DEV.to content performance, migrating from a SQLite-based CLI tool to a production-ready web application with PostgreSQL 18 and modern web technologies.

Challenge Entry: GitHub Copilot CLI Challenge

🏗️ Tech Stack

Backend: FastAPI (Python 3.10+)
Database: PostgreSQL 18
ORM: SQLAlchemy Core (NOT ORM models)
Advanced Features: pgvector for embeddings, JSONB, partitioning
Analytics: Apache Superset
API Integration: DEV.to Forem API

📊 Current Status

Phase 2 Complete: PostgreSQL 18 Schema Migration ✅

✅ Complete technical documentation (2,218 lines)
✅ 18 SQLAlchemy Core table definitions
✅ Business logic preservation (quality scores, attribution, sentiment)
✅ PostgreSQL 18 features (JSONB, ARRAY, Vector, partitioning)
✅ Migration guide and validation scripts

Next Phase: FastAPI REST API development

🚀 Quick Start

Prerequisites

…

View on GitHub

Architecture Overview

The platform implements a proxy-based forward authentication model:

User Request
↓
Caddy Reverse Proxy (bare metal)
↓
Authentik Verification (SSO, groups: Admin/Judge)
↓
Protected Service (Streamlit/API)

Security Benefits:
✅ Applications remain "auth-agnostic" (zero authentication code in app)
✅ Centralized identity management with granular RBAC
✅ Single Sign-On across all subdomains

Resource Optimization Story

Initial deployment included Apache Superset (1GB RAM), which proved too heavy. I made a strategic architectural pivot:

❌ Removed: Apache Superset (1GB)
✅ Added: Authentik IAM (600MB) + Custom Streamlit dashboard (512MB)
💡 Result: 10% memory footprint reduction + better security + custom UX

Because the code was AI-generated, pivoting took hours, not days. No sunk cost fallacy—just constraint optimization.

My Experience with GitHub Copilot CLI

No, I Didn't Code for 10 Days Straight

I worked mostly in the evenings (2–3 hours per session), plus one Saturday afternoon and evening, and one Sunday morning — roughly 30 hours total to migrate from a SQLite-based CLI to a production-grade cloud platform with SSO.

My Secret Workflow: Three-Stage Delegation

I didn't talk directly to Copilot CLI. I used a cascade of intelligence:

Claude/Gemini (The Architect): Brainstorming and constraint definition. I discussed requirements ("PostgreSQL 18 mandatory", "Core not ORM", "API not CLI"). It structured my fuzzy ideas into precise technical prompts.
GitHub Copilot CLI (The Implementer): I fed the optimized prompts + source files (@devto_tracker.py, @content_collector.py...). It generated 57-page technical documentation, PostgreSQL schema, FastAPI endpoints, Docker configs.
Me (The Guardian): I validated business logic preservation and enforced technical constraints.

Working with Copilot as a layered system

I didn’t “chat” with GitHub Copilot CLI. I treated it as an execution layer inside a broader workflow.

Before Copilot ever saw the code, I clarified non-negotiable constraints using a general-purpose model (Claude, sometimes Gemini or ChatGPT): PostgreSQL 18 (not 16 or 17), SQLAlchemy Core instead of an ORM, Authentik and Caddy outside Docker, Streamlit replacing Superset once memory pressure became an issue. These decisions were made upfront and never negotiated later.

Only once the intent was explicit did I involve Copilot CLI. I pointed it at the real codebase and asked it to extract documentation, schemas, and implementation details. In one pass, it produced a 57-page technical document describing architecture, data flows, algorithms, and business rules — without me writing a single line of code.

The final step was purely human: enforcing invariants. Whenever Copilot proposed a local optimization that conflicted with system-level intent — such as dropping reaction-level history in favor of aggregates — the answer was simply no. Aggregation was allowed only on top of preserved raw data, never instead of it.

What mattered here wasn’t prompt cleverness. It was clarity of constraints. Once those were explicit, Copilot became extremely effective — not as a decision-maker, but as an execution engine.

The quality of the outcome didn’t come from better prompts, but from better invariants.

That structure worked well — until one architectural decision made it clear where responsibility really sits.

The Moment I Had to Remind AI Who's Boss

There was one moment where the limits of delegation became very clear.

At one point, Copilot suggested simplifying the database schema by collapsing the detailed reaction breakdown (likes, unicorns, reading lists) into a single total_reactions integer column. From a purely technical standpoint, the suggestion made sense: fewer columns, simpler queries.

But that optimization would have broken something fundamental. Without this granularity, my weighted follower attribution algorithm collapses. These extra fields weren’t accidental complexity — they were deliberate architectural choices, preserved to ensure the system remains analytical, not just descriptive.

I didn’t “argue” with the AI or try to outsmart it. I simply restated the constraint: the schema was not up for simplification. This wasn’t a performance issue, it was an architectural one. Copilot adjusted immediately and moved on.

The lesson wasn’t that the AI was wrong. It was that local optimization without systemic intent is just guesswork. AI optimizes syntax; humans guard semantics.

Zero Lines Written, 100% Generated, 100% Controlled

Technical Documentation: 57 pages in one pass (2 hours vs 2-3 days)
SQL Schema: 26KB, 18 tables, partitioning, JSONB, arrays, pgvector-ready
FastAPI Endpoints: 14 routes, async, SQLAlchemy Core
Authentik Integration: Complete Docker Compose setup
Tests: pytest suite with 82% coverage

I wrote zero lines of Python code. I wrote prompts, I validated architectures, I corrected trajectories.

The Non-Negotiable Invariants

When I said "PostgreSQL 18," it was non-negotiable. Not for whimsy, but because I wanted:

Improved JSONB performance
Future pgvector compatibility

When I demanded "SQLAlchemy Core," it was to preserve exact existing SQL patterns. I also enforced the preservation of my 'proximity search' logic — a complex SQL pattern that finds the closest snapshot within a 6-hour tolerance window. While not yet fully exploited in the Streamlit dashboard, keeping this precision infrastructure allows for high-accuracy time-series analysis later on.

AI generates the "how." You must imperative keep the "why" and the "what."

Impact Metrics

Task	Traditional Estimate	Actual (AI-assisted)	Time Saved
Technical Documentation	2-3 days	2 hours	~90%
SQLite → PostgreSQL Migration	3-4 days	4 hours	~85%
FastAPI Development	5-7 days	6 hours	~80%
IAM Configuration (Authentik)	2 days	3 hours	~75%
Total	12-16 days	~30 hours	~80%

But the real gain isn't time—it's optionality. When I realized Superset consumed too much RAM, I pivoted to Streamlit in hours, not days. Because I hadn't "written" the code, I had no emotional attachment to what had to be discarded.

Beyond Code: The Infrastructure Blueprints

One of the most revealing moments of this challenge wasn’t about writing better prompts or cleaner Python. It was realizing that code alone was not the artifact worth sharing.

Using GitHub Copilot CLI, I deliberately piloted the AI to export and document the production chassis itself—not just the application logic, but the architectural constraints that make the system actually run on a 4GB VPS.

What I Exported

Instead of pushing isolated source files, I created an anonymized Deployment Blueprint in /deploy/production/, capturing the real operating context:

docker-compose.yml — Service orchestration with explicit memory ceilings (FastAPI, Streamlit, Valkey)
Caddyfile — Reverse proxy configuration encoding the SSO flow (Caddy → Authentik → applications)
deploy_analytics.sh — A zero-downtime deployment script with validation steps
.env.example — A complete environment template, with every secret replaced by {{CHANGE_ME}}

This wasn’t about reproducibility for its own sake—it was about making constraints visible.

Defensive Documentation

I also required Copilot to generate what I call defensive documentation: a README that clearly defines boundaries, not just capabilities.

What this directory is NOT

Not a backup — This is an architectural snapshot, not a recovery plan

Not plug-and-play — Domains, networks, and volumes must be adapted per environment

Not containing secrets — All sensitive values have been intentionally scrubbed

This distinction matters. AI didn’t “decide” what was safe to publish, deployable, or acceptable.

It followed instructions.

That, to me, is the real lesson: a modern architect doesn’t delegate responsibility to AI—they use it to enforce clarity, reproducibility, and accountability across the entire system.

Conclusion: From Developer to Prompt Architect

Being an AI architect isn’t about delegating thinking — it’s about orchestrating it.

What this experience taught me is that I’m no longer just a developer who writes code. I’ve become an architect who writes constraints, curates business logic, and decides where complexity is acceptable — and where it isn’t.

GitHub Copilot CLI isn't my coding assistant. It's an execution engine — and I'm not a "prompt engineer." I'm an architect who writes constraints, not code.

It implements what I specify, quickly and relentlessly, but it doesn’t own the intent. When architectural decisions mattered — like preserving reaction-level granularity in my data model — the responsibility stayed firmly with me.

The real shift isn’t that AI writes code for us. It’s that it forces us to be explicit about our decisions. The clearer the intent, the less the AI needs to “think” — and the more effective it becomes.

As this system scales from thousands to tens of thousands of records, I’m less worried about the code I wrote and more confident in the constraints I defined. Those constraints can evolve. Prompts can be rewritten. Architecture can be re-expressed without dragging years of accidental technical debt behind it.

The future of development isn’t AI replacing developers. It’s developers moving upstream — from implementation to strategic architecture — with AI handling the translation.

GitHub Copilot CLI Challenge — January 2026. 40 commits, 0 lines written by hand, 30 hours of actual work, 7,078+ records migrated, production-grade security deployed.

Symfony AI: When a School Bus Painted as a Rocket Pretends to Go to Orbit

Pascal CESCATO — Tue, 27 Jan 2026 14:58:05 +0000

_Technical satire

You'd almost want to believe it. One fine morning, Symfony announces its "AI" module, and the whole ecosystem shivers as if the framework had just discovered quantum gravity. But very quickly, scratching beneath the polish, you realize you're not witnessing a technological revolution... but a makeover operation.

A school bus repainted white, decorated with three NASA stickers, and presented as a space shuttle.

Welcome to "Symfony AI," or the subtle art of pretending to be modern.

1. AI Integration Cosplay Style: Fake Chic on Real Emptiness

The AI component offers a ChatModelInterface perfectly DI-friendly, perfectly Symfony. But behind it, what's really there? A nicely wrapped HTTP request, and an object instantiation to make you believe magic is happening.

No serious streaming, no parallelism, no fine-grained token management at high cadence. Just a layer of architectural polish that transforms a simple API call into a sacred ritual.

It's technical cosplay: you dress up as an astronaut, but you stay in the backyard.

Streaming: When the 1980s Tires Explode

In the real world of AI, an LLM takes time to respond — sometimes 10, 20, 30 seconds. So we use streaming (Server-Sent Events) to display words one by one, giving the illusion of fluidity.

In Python (FastAPI):

Native, asynchronous streaming
One worker can handle 100+ simultaneous connections without breaking a sweat
While OpenAI generates the response, the worker is free to process other requests
Non-blocking architecture: everything is fluid

In Symfony (classic PHP-FPM):

Making proper streaming work is already a pain
Each streaming connection monopolizes one complete PHP worker
If 50 users are streaming a response simultaneously, your 50 PHP workers are all frozen, patiently waiting for OpenAI to deign to send back a token
Meanwhile? Your site doesn't respond anymore. Other visitors wait. Monitoring goes haywire.
This is textbook worker starvation: all your workers are alive but useless, blocking on I/O while your queue fills up and users time out.

The school bus doesn't just have NASA stickers. It also has 1980s tires that explode as soon as you exceed 30 mph.

That's when you understand that synchronous PHP architecture was never designed for this. You can apply as much polish as you want, the foundation remains unsuitable.

2. Doctrine: A Ferrari with a Lawnmower Engine

Modern RAG relies on vector operations: cosine distances, ANN indexes, millions of points in memory. Doctrine, on the other hand, relies on PHP object hydration designed in 2009 for SQL relations.

But let's be honest: even for standard plowing — your everyday SELECT * FROM user WHERE active = 1 — Doctrine consumes like an ogre.

The Hidden Cost of "Simple CRUD"

Forced hydration:

It manufactures complete PHP objects with all the machinery (EventManager, UnitOfWork, lazy-loading proxies) just to display three fields in a JSON.

Memory footprint:

50,000 rows? The PHP process takes 400MB and the garbage collector screams. This isn't data management, it's helium inflation.

Subtle N+1:

Even senior devs forget a fetch="EAGER" and suddenly your page makes 47 SQL queries to list users. Doctrine doesn't protect you from yourself, it amplifies your mistakes.

DQL Overhead:

The DQL parser + SQL generator + result set mapping to transform SQL into objects... it's molecular gastronomy to make a sandwich. You wanted SELECT id, name FROM user? Doctrine offers you a ballet of 800 lines of internal code.

The Real Metaphor

You can announce the same power on paper — "millions of entries management, elegant abstraction" — but Doctrine isn't even a robust farm tractor.

It's a garden micro-tractor, with 25 HP, meant to plow flowerpots (your 200-line admin CRUD), that we're trying to pass off as intensive farming equipment.

And here, in AI, we're asking this micro-tractor to plow 50 hectares of 1536D vectors continuously.

Result?

It melts its clutch (PHP segfault)
It blows its tires (disk swap activated, server on its knees)
The driver (the DBA) has to call for help at 3 AM

The metaphor "Ferrari with tractor engine" was already too flattering.

It's a Ferrari with a Honda lawnmower engine.

You can't race the 24 Hours of Le Mans with a block that was designed to mow the lawn.

A Concrete Example That Kills

Let's take a basic RAG chatbot: 50,000 documents, OpenAI embeddings (1536 dimensions), semantic search.

With Qdrant (or Pinecone, or Weaviate):

Latency: 20-50ms
RAM: ~2GB for 50k vectors
Scale: linear up to several million vectors

With Symfony AI + Doctrine:

Doctrine tries to hydrate thousands of PHP objects to calculate cosine distances
MySQL (or PostgreSQL) does a full table scan on an embedding column stored as JSON or BLOB
Latency: 3-8 seconds for a simple query
RAM: the PHP process explodes to 512MB, then 1GB, then timeout
The DBA receives an alert at 3 AM and resigns by email

And the worst part? Even if the dev adds a vector index (pgvector on PostgreSQL, for example), Doctrine doesn't know how to generate the specific search operator like pgvector's <->.

They have two options:

Write raw SQL with NativeQuery → the ORM is useless, we just added 3 layers of abstraction to... write SQL by hand
Use Doctrine's QueryBuilder → which will generate a slow and inefficient query, completely ignoring the vector index

The abstraction isn't just slow. It's useless. Worse: it's dangerous, because it gives the illusion that you're doing things properly while sabotaging performance.

It's a Ferrari with a lawnmower engine: it looks impressive on the brochure, but try exceeding 20 mph.

3. Economic Incoherence: Doing AI with Yesterday's Problem's Tool

Using Symfony to do AI is like using COBOL to make a website in 2025.

Technically possible? Yes, absolutely.

Has someone already done it? Probably, in some basement of the Finance Ministry.

Is it a good idea? No. Never. Under no circumstances.

The Real Economic Question

Facing a RAG project, an average company has two options:

Efficient option:

Two Python devs → FastAPI + Qdrant → robust prototype in two weeks → scales to 10M vectors with 2 servers → controlled cost, performance delivered.

Symfony option:

We try to fit embeddings into Doctrine → six months of refactoring → a budget equivalent to a country house → performance that makes a 200-line Python script smile → scales to 100k documents maximum before everything collapses.

It's not a question of Symfony devs' competence. It's a question of tool unsuitable for the problem.

Symfony AI is a solution for those who want to do AI without ever approaching AI. For those who prefer to pay six months of consulting rather than three weeks of Python training.

4. The Rubber Belt Against the Metal Chain

The rubber belt (Symfony AI) is exactly what we put in place of the metal chain (an AI-native architecture).

Why did the automotive industry replace chains with belts?

Cost: a belt costs less to produce — like avoiding training a Python team or hiring an ML engineer.
Silence: it makes less noise — no organizational friction, no questioning of the historical stack.
Lightweight: it lightens — we don't change anything about hosting, we stay on a shared server that does what it can.
Planned obsolescence: a belt is replaced regularly — exactly like these Symfony AI refactorings that come back every X months.

The problem? A belt breaks cleanly. No sign, no warning. It gives out. Brutally.

And when the Symfony AI belt breaks:

embeddings explode the RAM of an OVH shared server
Doctrine latency makes the chatbot timeout in production
a "simple" RAG must handle 100k documents and MySQL triggers a 12-second full table scan
the application becomes unavailable
emergency committee improvised around a PowerPoint

... it's engine failure: valves in pistons, project to rewrite, budget to double.

The metal chain (Python + vector DB + AI-designed architecture), it makes noise at first, it's expensive to install, but it lasts 300,000 km. It's made to withstand.

With Symfony AI, we replaced a durable solution with a disposable one, to save 15% at startup and lose 85% later.

This is exactly the French IT department economy: preferring a controlled and predictable expense (changing the belt every 60,000 km) to an initial investment that guarantees survival (the chain).

5. Conclusion: Modernity Tailored to Reassure, Not to Advance

Symfony AI isn't dangerous, nor useless. It's simply cosmetic: an elegant way to tell teams "don't you dare change your stack."

It's makeup on an unsuitable architecture. A yellow school bus, solid but slow, to which we stick "AI ready," "Vector search inside" and two metallic stickers.

From afar, it shines. Up close, you still see traces of the old "Municipal Service" logo.

The illusion doesn't go into orbit, even with NASA stickers.

It's AI for those who are afraid of AI. A stagecoach disguised as a spaceship. Ceremonial modernity.

And in a world evolving at the speed of AI, it's funnier than it is serious.

Being Right Too Early: What NGINX in 2010 Taught Me About Tech Adoption

Pascal CESCATO — Mon, 26 Jan 2026 07:02:49 +0000

How shipping NGINX in production before it was 'safe' became my playbook for Caddy, Astro—and for refusing performance theater in tech.

People tell me I have something against current standards. What they don't see is that this isn't a recent position. I'm not writing hot takes based on six months of experience. I've been documenting production deployments and technical experiments for over 15 years. That perspective lets you see cycles that others mistake for novelty.

June 2010. I published a comprehensive guide on installing NGINX + PHP-FPM on Debian. By then, I'd already been running NGINX in production for 2-3 years. The response from potential clients was consistent: "Interesting, but we'll stick with Apache."

Fifteen years later, NGINX powers 35% of all websites.

This is what happens when technical readiness arrives before market readiness. And this is what the archive proves: I wasn't wrong. I was early.

ACT 1: THE SETUP (2010)

My Context in 2010

I was a freelance "firefighter." The kind of developer companies called when their internal teams had already failed. I'd been installing Linux web servers since 1997, when most shops were still paying for Windows NT. By 2010, I had a clear track record:

Lead developer on Skyrock's Palm WebOS app
Multi-site WordPress platform managing 100+ sites
Logic-Immo migration: Oracle → MySQL, Apache → NGINX
Various corporate projects (Pierre et Vacances, EuroRSCG, etc.)

I wasn't writing that NGINX tutorial to evangelize. I was documenting what already worked in production.

The Article (2010)

The original article made a simple argument:

The Problem:
"PHP frameworks enable faster development but degrade performance. Even with opcode caching (APC, eAccelerator, XCache), optimization isn't enough for high-traffic sites."

Traditional Solutions:

More powerful servers (expensive)
Database servers on separate hardware (expensive)
Load balancing multiple servers (expensive)
Code review and optimization (time-consuming, diminishing returns)

Alternative Solution:
Switch from Apache to NGINX.

The Pitch:
"10x the capacity, same hardware."

Not theory. Production data from sites I'd already migrated.

The Market Response

Client: "Our Apache setup is drowning under traffic."
Me: "Switch to NGINX. I've run it for 3 years. Here's the data."
Client: "Too risky. Let's add more servers."

[6 months later]

Client: "It still crashes. Can you fix it?"

I wasn't frustrated by the rejections. I understood them. Risk-averse decisions are rational in corporate environments. The market optimizes for predictability, not performance. Understanding this doesn't make the wrong solution right, but it explains why the right solution doesn't sell.

ACT 2: THE WORLD OF 2010

Pattern Recognition (1989-2010)

This wasn't my first time being right too early.

1989: Building on dBASE III+ and Clipper while classmates learned COBOL for IBM mainframes. My curriculum was COBOL, CICS, JCL, MERISE—mainframe thinking. The PC was still a "toy" in academic circles. One got me the diploma. The other got me clients.
1997: Running Linux web servers while others paid for Windows NT
2007: NGINX in production while others scaled Apache vertically

Same pattern, different decade. See what works, adopt it, document it, watch the market ignore it for 5-10 years.

By 2010, I knew exactly how this would play out. I just didn't expect it to take 15 years this time.

The Technical Landscape

What was standard in 2010:

Apache 2.2: 60%+ market share, the "safe" choice
PHP 5.2/5.3: with mod_php or FastCGI
XCache/eAccelerator: for opcode caching
Compiling your own web server: normal practice for anyone serious
The C10K problem: known but considered a "high-traffic edge case"

What I was already running:

NGINX 0.8.x (version 1.0 wouldn't arrive until 2011)
PHP-FPM (experimental, "not production-ready" according to most)
Varnish Cache in front when needed
Percona Server instead of vanilla MySQL

My CV from 2011 listed: "Web Servers: Apache, NGINX, Varnish Cache + APACHE & mod_pagespeed"

I put Apache first because that's what clients wanted to see. NGINX was already my default for new deployments.

Who Was Using NGINX in 2010

Rambler (Russian search engine—where NGINX originated)
WordPress.com (beginning migration)
A handful of startups
Freelancers like me who'd bothered to test alternatives

Who Wasn't

95% of French web agencies
Enterprise IT departments
Anyone who needed to justify their choices to non-technical management

The Pitch I Made

Technical merit:

Event-driven architecture vs Apache's process-per-connection
Better memory usage under load
Simpler configuration (once you learned it)
Native reverse proxy capabilities

Real-world data:

Sites I'd migrated: 70-80% reduction in memory usage
Same traffic, 1/3 the servers needed
Response times: 30-50% improvement under load

The Objections I Heard

"Nobody else is using it"
Translation: "If it fails, I can't blame the industry standard"

"Our team doesn't know NGINX"
Translation: "Training costs money"

"What about support?"
Translation: "Open source = scary, even when it works better"

"Apache has mod_rewrite, how does NGINX handle .htaccess?"
Translation: "We want the new thing to work exactly like the old thing"

The Decision Pattern

My proposal: NGINX + PHP-FPM, 3-4 servers, streamlined architecture

Competitor's proposal: Apache + mod_php, 8-10 servers, familiar stack

Winner: Competitor

Six months later:

"The site still crashes. Can you come fix it?"

What Was "Revolutionary" in 2010

# 2010 NGINX configuration
# Today this is copy-paste from any tutorial
# Then it was "too exotic"

upstream php_backend {
    server 127.0.0.1:9000;
}

server {
    listen 80;
    server_name example.com;

    location ~ \.php$ {
        fastcgi_pass php_backend;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }
}

Compare to 2010 Apache + mod_php setup:

Multiple config files scattered across the system
.htaccess parsing on every request
Module loading complexity
Significant resource overhead

Why Technical Merit Wasn't Enough

"Technical superiority loses to operational inertia. Every time. The market doesn't buy the best solution. It buys the solution it can justify."

The market isn't broken. It's optimized for a different outcome: minimizing decision-maker risk, not maximizing technical performance.

ACT 3: THE SLOW ADOPTION CURVE (2010-2020)

2010-2012: The Pioneer Years

Me and a few others: NGINX in production
WordPress.com announces migration (2011)
NGINX version 1.0 released (April 2011)
GitHub switches
Market share: still <10%

My projects in this period:

Skyrock app on Palm WebOS (lead developer, 2010-2011)
Multi-site WordPress platform (100+ sites, NGINX-based)
Logic-Immo migration: Oracle → MySQL
Every new client deployment: NGINX by default

2013-2015: The Early Adopters

Startups choose NGINX (no legacy, no politics)
Performance benchmarks start appearing publicly
NGINX Inc. founded, offers commercial support (2013)
"Now it's a real company" = legitimacy for corporate buyers
Market share crosses 20%

The calls I started getting:

"Remember in 2010 when you suggested NGINX? We're ready to talk about that now."

2016-2018: The Tipping Point

Docker/containers boom: NGINX default in base images
Cloud providers bundle NGINX by default
"NGINX vs Apache" articles everywhere (5 years late)
Market share approaches 30%
CTOs start asking their teams: "Why are we still on Apache?"

2019-2020: The New Normal

NGINX in every tutorial
"Apache" in articles about legacy migration
Junior devs who've never configured Apache
Market share: 35%+

The Cycle Completed

2010: "Too risky, nobody uses it"
2012: "Interesting, but we need more time"
2014: "We're evaluating it"
2016: "We should probably migrate"
2018: "Migration planned for next year"
2020: "Obviously NGINX, what else would we use?"

What Changed Technically

Almost nothing. NGINX 1.0 (2011) worked essentially the same as NGINX 0.8 (2010). The features I used in 2008 are the features people deployed in 2018.

What Changed Commercially

Everything.

Social proof (WordPress, GitHub, etc.)
Commercial support available
NGINX Inc. marketing budget
Industry consensus achieved

The Lesson

"Technical readiness and market readiness are different things. I had the first in 2008. The market achieved the second in 2016. That's an 8-year gap where being right was commercially useless."

The Client Who Called Back

Scenario (2010-2015):

2010: I pitched NGINX migration, showed data, explained architecture
Their response: "Too risky, we'll scale Apache instead"
2011-2014: They added servers, applied patches, paid for band-aids
2015: Site crashes regularly, team exhausted, costs spiraling
Emergency call: "Can you come do that NGINX migration now? We'll pay premium rates."

My answer: "No."

Not because of ego.

Because nothing had changed.

Why I Don't Work With Clients Who Rejected Me

The surface reasons they rejected me (2010):

"NGINX is too risky"
"Team doesn't know it"
"Need commercial support"

The real reason:

I wasn't politically correct
I challenged their existing choices
I didn't validate their comfort zone

In 2015, they're still the same organization.

Same people. Same hierarchy. Same culture. Same politics.

The crisis forced them to call me. But it didn't change who they are.

What Would Happen If I Accepted

Week 1-2:

I diagnose the problem (same as 2010)
Propose solution (same as 2010)
They agree (finally)

Week 3-4:

I start migration
Their lead dev (who chose Apache in 2010): "Why are we changing the log format?"
Their project manager: "Can't we keep the old structure?"
Their CTO: "Is this really necessary?"

Week 5-8:

Every. Single. Decision. = Meeting
"Why not use mod_rewrite compatibility?"
"The team isn't comfortable with this approach"
"Can we do a POC first with 20% traffic?"
"We need to document every change for compliance"

Week 9+:

Migration drags on
Budget explodes (because of their delays)
They blame me for cost overruns
Tension with their team (who resent the outsider)
Politics escalate

End result:

Site works (because I'm competent)
Bill paid late after multiple reminders
Reputation: "Skilled but difficult to work with"
Reference: None (or worse, negative)

The Core Problem

They didn't reject NGINX in 2010. They rejected me.

Not my skills. Not my track record. My approach.

I don't do:

Politics over technical merit
Endless meetings to validate obvious decisions
Compromises that make solutions worse
Tolerating incompetence to protect egos

In 2010, this made me "too risky."

In 2015, this makes me "difficult to work with."

Same person. Different words. Same rejection.

The Pattern

If they rejected me for political reasons, accepting their emergency call means:

Technical decisions still filtered through committee approval
Every architectural choice becomes a negotiation
I'm responsible for outcomes but not empowered for decisions
The project succeeds technically but fails politically
I get paid but build no sustainable relationship

My time has value. I choose where to invest it.

My Boundary

"You had your chance to make a smart decision. You chose to optimize for political safety. That's a legitimate choice. But I work in environments where technical merit drives decisions. Our constraints are incompatible."

This isn't revenge. It's recognizing that some problems can't be solved within certain constraints.

I can't fix technical dysfunction while operating inside political dysfunction. The emergency doesn't change the constraint. It just makes it more expensive.

What I Tell Them

"I appreciate the call. But we weren't a good fit in 2010, and we won't be a good fit now. The crisis you're facing is a symptom of the decisions you made then. You need someone who can work within your constraints. That's not me. Good luck."

No anger. No lecture. Just clarity.

What Actually Happens

Client calls someone else who accepts the emergency project.

That consultant:

Works within their political constraints
Delivers a working-but-fragile solution
Takes longer due to committee approvals
Gets paid well and receives glowing references

Because they played the game correctly.

Technical outcome:

Site works (for now)
Architecture compromised by committee decisions
Same crisis likely in 3 years
Cycle repeats

I'm not in that cycle anymore. That's a choice.

ACT 4: WHY EARLY ADOPTION FAILS

The Core Insight

"Being right too early is functionally identical to being wrong. The market doesn't reward correctness. It rewards timing."

The Risk Asymmetry (Corporate Perspective)

When you're the decision maker:

Scenario A: Choose Apache (2010)

Infrastructure: 10 servers to handle load
Hosting costs: High (more servers, more management)
Management: Complex (more moving parts)
Site crashes anyway
Response: "We need even more servers"
Your career: Safe (industry standard choice)

Scenario B: Choose NGINX (2010)

Infrastructure: 3 servers handle same load
Hosting costs: 1/3 of Apache approach
Management: Simpler, more efficient
Site works perfectly
Response: "But what if it breaks?"
Your career: At risk (exotic choice)

Scenario C: Choose NGINX and it fails (2010)

Same cost as B
Response: "Who authorized this experiment?"
Your career: Over

The Math

From a decision-maker's perspective:

Apache fails: Shared responsibility (industry standard failed, not you)
NGINX works: You took unnecessary risk (why gamble?)
NGINX fails: Personal responsibility (you authorized unproven tech)

Rational choice in corporate environment: Apache

Optimal choice technically: NGINX

This isn't stupidity. It's different optimization criteria. The market optimizes for decision-maker safety. I optimize for technical efficiency. Both are rational within their constraints.

The Knowledge Gap

What clients said:
"Our team knows Apache. Training on NGINX would take weeks."

What they meant:
"Change is expensive and uncertain. Status quo is cheap and certain."

Reality:

NGINX config: simpler than Apache once learned
Training time: 2-3 days for competent sysadmin
ROI: immediate (better performance, lower costs)

But "immediate ROI" loses to "zero learning curve."

The Support Theater

Conversation I had multiple times:

Client: "What if NGINX breaks at 3am?"

Me: "Same thing as if Apache breaks. You fix it."

Client: "But Apache has commercial support."

Me: "Which you've never used. When did you last call support?"

Client: "That's not the point. We could call support."

The point wasn't actual support. The point was ass-covering.

If Apache fails: "We had support, they're working on it."

If NGINX fails: "Why did we choose unsupported software?"

The Consultant's Paradox

The scenario:

Client has problem
I propose correct solution (NGINX)
Competitor proposes safe solution (more Apache)
Competitor wins contract
Problem persists
Client calls me back (emergency rates)
I implement original solution
Problem solved

The outcome:

I was right
Competitor got initial contract
I got emergency contract (higher rates, worse conditions)
Client paid 3x total cost
Nobody learned anything

Why This Pattern Persists

Incentive misalignment:

Consultant incentive: solve problem correctly
Internal team incentive: make defensible choice
Manager incentive: avoid personal risk
Company incentive: minimize cost

Only one of these aligns with "choose NGINX in 2010."

When Correctness Isn't Enough

You can be right about:

Technical merit
Performance data
Cost analysis
Long-term trajectory

And still not win contracts.

Because the market doesn't buy solutions. It buys comfort, predictability, and defensibility.

This isn't a flaw in the market. It's a feature. Understanding this changes the game from "convince them I'm right" to "document for those who are ready."

What I Learned

Strategies that don't work with markets optimized for safety:

Lead with "this is better" (triggers defensiveness)
Show data proving current approach wrong (embarrasses decision-makers)
Propose unfamiliar solutions without crisis (no urgency)

What works for markets optimized for safety:

Wait for crisis (creates urgency)
Frame new solution as "industry best practice" (provides social proof)
Provide easy rollback plan (reduces perceived risk)
Let them "discover" the idea (creates ownership)

In other words: Wait for the market to be ready.

But I Don't

Why? Because:

Waiting wastes time that could be spent documenting
Sites crash while everyone waits for consensus
Someone has to create the first map
The archive helps those who come after

"I wrote that 2010 NGINX tutorial knowing most readers wouldn't use it for 5 years. But when they were ready, it was there. That's value that compounds."

I'm not playing the market's game. I'm playing a longer game: building knowledge infrastructure for those who optimize for technical merit over political safety. It's a smaller market, but it's my market.

ACT 5: THE CYCLE CONTINUES (2026)

Today's NGINX

Market status (2026):

35%+ market share
Default in Docker/Kubernetes
Every junior dev's first web server
"Obviously the right choice"

What changed:
Nothing technical. Same core architecture as 2010.

What changed:
Everything commercial. Consensus achieved.

The New Generation

I work with developers who:

Never configured Apache
Don't remember the C10K problem
Think NGINX was always the standard
Have no idea it was controversial

To them, my 2010 article is historical documentation. Like reading about migrating from IIS 5.

Meanwhile, I've Moved On

My current stack (2026):

Caddy (automatic HTTPS, simpler config)
OpenLiteSpeed (LiteSpeed performance, open source)

The response:

"NGINX works fine. Why change?"

My answer:

"That's what people said about Apache in 2010."

The Pattern Repeats Exactly

Category	Then (2010)	Now (2026)
Web Server	Apache = standard	NGINX = standard
"Alternative"	NGINX = exotic	Caddy = exotic
CMS/Platform	WordPress = standard	WordPress still = standard
"Alternative"	Static blogs = niche	Astro/Hugo = niche
Objection	"Need commercial support"	"Need commercial support"
Objection	"Team doesn't know it"	"Team doesn't know it"
Objection	"Too risky"	"Too risky"

The cycle is fractal. It repeats at every layer of the stack.

Other Technologies I'm "Too Early" On in 2026

Static Site Generators (WordPress → Hugo → Astro)

This is the perfect modern parallel to the Apache → NGINX story.

The progression:

Platform	Market Position	Technical Reality	Why It Matters
WordPress	The Standard (comfort)	Dynamic CMS for static content. Database + 50 plugins to display text. Slow, fragile, constant security patches.	It's the Apache of CMS. Everyone knows it, so it feels safe.
Hugo	The Transition (exploration)	Pure speed. Go binary, millisecond builds. But rigid templating, steep learning curve.	It's the "NGINX moment" for content—fast but unfamiliar.
Astro	The Pragmatic Choice (efficiency)	Static by default, interactive when needed. Zero JS unless required. Combines speed + developer experience.	Security by design (no DB = no hacks), hosting costs near zero, performance optimal.

The pattern is identical to 2010:

Moving from WordPress to Astro is the same decision as moving from Apache to NGINX: remove unnecessary layers, keep only what serves the end user.

WordPress: "But everyone uses it, and there are plugins for everything!"
Hugo: "Interesting, but our team doesn't know Go templates"
Astro: "Why change? WordPress works fine"

Reality (business website, 50k monthly visitors):

WordPress: 2-4 vCPU, 4-8GB RAM, MySQL database, PHP-FPM pool, opcode cache, object cache, CDN required for acceptable performance. Load time: 1.5-3s.
Astro: Static files on CDN edge nodes. Zero compute, zero database, zero runtime. Load time: 200-400ms. Scales to millions of requests without infrastructure changes.

Market response: "WordPress works fine. Why change?"

Same inertia. Different technology. Same 5-10 year adoption curve ahead.

Anti-Agile (my most-read article: more than 2k views, "Performance Theater")

Response: "But we've always done Scrum"
Reality: Ritual replacing productivity

Vector Databases with SQL (MyScaleDB)

Response: "Specialized DBs are better"
Reality: Most teams don't need specialized, they need familiar

The pattern is identical.

The Meta-Pattern

Innovation emerges
  ↓
Early adopter tests it
  ↓
Writes documentation
  ↓
Market rejects it: too risky
  ↓
Problems persist
  ↓
Crisis forces change
  ↓
Innovation becomes standard
  ↓
Early adopter already testing next thing
  ↓
[Cycle repeats]

The Question

"Should I stop being early? Should I wait for the market to catch up?"

My Answer

No.

Because:

Someone has to go first. If everyone waits, nothing moves.
Technical correctness matters, even when it's commercially irrelevant.
Documentation compounds. That 2010 article helped thousands migrate in 2015-2020.
Integrity. I'd rather be right too early than wrong on time.

The Trade-Off

Being right too early has opportunity costs.

I could have:

Nodded along with Apache recommendations in 2010
Accepted the emergency callback in 2015
Built my career on reassuring corporate indecision
Optimized for income over integrity

Instead, I chose:

Technical integrity over political comfort
Documentation over repeat contracts
Freedom to say "No" over financial security
Building for those who come after over maximizing current revenue

This is a trade-off, not a defeat.

I'm not a victim of the market. I'm someone who understood the rules and chose to play a different game. That game has different rewards: the ability to sleep at night, the freedom to document truth, and a clean archive that helps people a decade later.

The market optimizes for conformity. I optimize for correctness. Both strategies have costs. I've made my choice consciously.

The Archive Doesn't Lie

In 2026, when someone searches "NGINX migration 2010," they find my article.

Not as nostalgia. As a roadmap.

Someone migrating from Apache today can follow the exact steps I documented in 2010. The configuration still works. The architecture still makes sense. The reasoning is still valid.

That's the value of being right early: you leave a map for those who come after.

I'm not waiting for vindication. I'm building documentation for the next generation of people who see patterns before the market does. That's a different game with different rewards.

Final Thought

"In 2010, I was documenting NGINX when the market wasn't ready. In 2026, I'm documenting Caddy and Astro for those who will be ready in 2030. In 2040, someone will write this exact article about whatever comes next."

The technology changes. The pattern doesn't.

I've been writing for 15 years. That archive shows three complete cycles:

1997-2010: Linux servers → mainstream
2007-2020: NGINX → mainstream
2020-2035: Static-first architecture → (pending mainstream)

The value isn't in being right on time. It's in documenting the path before the crowd arrives.

When you search "NGINX 2010," you find my guide. When you search "WordPress to Astro" you'll find my current work. In 2035, both will be obvious. But the people who needed the map in 2010 and 2026 had it waiting.

That's the game I'm playing. Not convincing the market. Building infrastructure for those who are ready.

The archive doesn't lie. The pattern holds. And the next generation won't have to rediscover what we already documented.

Postscript (January 2026):

As I finalize this article, Cloudflare announces the acquisition of Astro.

The pattern I documented over 15 years just played out again in real-time:

Astro was "too risky" in 2024
Cloudflare validates it in 2026
It will be "obviously correct" by 2030

I didn't predict this acquisition. I predicted the pattern.

And the pattern is never wrong. Just early.

Grumpy postscript (for 2035 readers):

If you're reading this in 2035 and it all sounds "obviously correct", remember someone got called an idiot for writing it in 2010.

The archive hasn't issued an apology. Neither do I.

If You Liked This

My archive shows patterns across tech stacks and organizational dysfunction. If this resonated, you might find value in:

Building Reliable Legal AI — How I turned frustration with "semantic" search tools that miss Supreme Court cases into a graph-based legal search engine. Same pattern: the market sells AI magic, reality needs structured data.

Actually Agile: Against Performance Theater in Software Development — Why most Agile rituals are stage props for managers, not tools for developers. The same inertia that resisted NGINX created cargo-cult Scrum.

Efficient Laziness at Scale: The Agile Team I Never Needed — How I use "laziness" as a design constraint for systems, not as an excuse. Building tools that make the right thing the easy thing.

From WordPress to Astro: Three Days to Reclaim Performance — Applying the NGINX playbook to CMS migration. Same objections ("WordPress works fine"), same 10x performance gain.

Closing

What's your "NGINX moment"? What are you right about too early?

Read the original (2010): Installer NGINX, PHP5-FPM, Xcache et MySQL sur une Debian Lenny / Squeeze

Current stack (2026): Caddy + OpenLiteSpeed. See you in 2035.

When DEV.to Stats Aren't Enough: Building My Own Memory

Pascal CESCATO — Sun, 18 Jan 2026 20:27:16 +0000

One Tuesday morning at 9:14 AM, my six-month-old article got 37 views in 20 minutes. DEV.to's dashboard just said "+37 views". No context. No cause. No pattern.

I wanted to know why. Was it a comment from someone influential? A share somewhere? A title change from weeks ago finally paying off? The platform couldn't tell me. So I decided to steal my own data.

Not to optimize. Not to perform. But to understand how my articles actually live over time.

The Starting Point

I started with devto-analytics-pro by @gnomeman4201 — a solid foundation for collecting basic metrics. But I wanted more: a temporal vision, a memory that could tell the story of an article over time.

First step: store everything in a database. Not once, but every 4 to 6 hours. Automatically.

Why this frequency? Because with daily snapshots, you miss the fine variations. You miss what happens between noon and 6 PM. You smooth everything out. But with this frequency, suddenly, you see the breathing. You see when an article wakes up, when it falls asleep, when something revives it.

What I Discovered by Looking at My Data

The first thing the data taught me is that I didn't know my own articles as well as I thought.

For example, I discovered that a simple like from an active DEV community member can change everything. Not a spectacular reaction, just a like. But enough for DEV.to to feature the article. And there, the views climb. Not violently, but distinctly. Without regular data tracking, this phenomenon would have completely escaped me.

I also saw that a title change can triple visibility. Same content, same tags, same structure. Just a reformulated title. And suddenly, the exposure curve takes off again. It's not a "shock" — it's a lesson. A lesson you can only learn by watching temporal evolution, not by consulting a cumulative total.

Another discovery: some articles I thought were "dead" continue to bring readers six months after publication. Not many, but regularly. Two views per day, three comments per week. A discreet but real life. Without history, I would never have known they were still breathing.

And then there are the strange rhythms. My latest article on Cloud Run: 15 views at once on January 11 at 11 AM. Then nothing for 24 hours. Then 10 views on the 13th at 7 AM. Then silence. Then 12 views on the 15th at 11 AM. Then 10 more views on the 17th at 7 AM. Like jerky breathing. Without this collection every 4 hours, I would have only seen a total: "139 views in a week". With it, I see an article that lives in spurts, waking up at specific moments, then going back to sleep.

What the Tool Revealed About Me

By looking at my own data, I understood things my intuition didn't tell me.

The tool automatically classified my articles into four categories: "Tech Expertise", "Human & Career", "Culture & Agile", and "Free Exploration". I didn't choose these categories — the content analysis made them emerge.

And there, surprise:

Free Exploration    ████████ 7.3% engagement
Culture & Agile     ███ 2.5% engagement  
Tech Expertise      ██ 2.6% engagement

My "Free Exploration" articles — the freest, most personal ones — generate almost three times more engagement than technical pieces. These texts only reach 211 people on average, but these 211 people react, comment, discuss.

Respiration, for example: 460 views, 8.7% engagement. An article about burnout, writing, breathing. Nothing technical. Just a personal reflection. And it's the one that creates the most conversation.

My "Culture & Agile" articles bring more visibility: 819 views on average, but only 2.5% engagement. Actually Agile: Against Performance Theater: 2154 views, 4% engagement. It reaches many people, but engagement is shallower.

A revealing detail: "Actually Agile" generated 29 comments over 33 days. "Respiration" generated 10 comments over 3 days. The first created a conversation that stretched over time. The second created a concentrated explosion, then silence. Two types of engagement, two different rhythms.

So I wrote three more "Free Exploration" pieces the following month. Not because I was chasing engagement, but because I finally understood what kind of writing created real conversations.

Reading Times (Or: Who Really Reads?)

The tool also collects a metric that DEV.to provides but that nobody really looks at: cumulative reading time.

And there, we encounter surprising things.

My "Cloud Run Bill" article: on January 17, 25 views, 480 seconds of reading. That's 19 seconds average per view. The article is 5 minutes of reading. Conclusion: most people didn't read it. They scrolled, saw the title, maybe looked at the first paragraph, then left.

But on January 16: 15 views, 729 seconds of reading. That's 48 seconds average. Still not 5 minutes, but significantly more. These 15 people actually read part of the article.

And on January 15: 22 views, 30 seconds of reading. 1.4 seconds per view. These people didn't even open the article. They just saw the title in their feed.

What this metric reveals is that "views" means nothing. Some views are real readings. Others are lightning-fast passes. Others are click errors.

If I only look at total views (139), I think: "Not bad for a week."
If I look at reading times, I think: "In reality, maybe 30 to 40 people actually read the article."

And that completely changes the perspective.

What Tags Reveal (And What They Hide)

The tool also analyzes performance by tag. And there again, surprises arrive.

The "performance" tag: 5 articles, 3028 total views, 606 views on average. It's my most visible tag.

The "devjournal" tag: 1 single article, 460 views, but 8.7% engagement. It's "Respiration". A unique article, unclassifiable, unlike anything else I've written.

The "scrum" tag: 1 article, 2154 views, 4% engagement. It's "Actually Agile". The most viewed, but not the most engaging.

What these numbers say is that my most personal articles reach fewer people but create more conversation. My most "professional" articles reach more people but engage less deeply.

And that's exactly the kind of lesson you can only draw by crossing multiple dimensions: views, engagement, tags, temporality. A single metric tells nothing. It's the relationship between metrics that makes sense emerge.

Loyal Readers (Or: Who Really Comes Back?)

The tool also analyzes comments. Not just their number, but who comments, on how many articles, with what regularity, over what duration.

And there, we discover something that DEV.to stats don't show: who your real readers are. Not those who pass once and disappear, but those who come back.

In my case:

One reader commented on 9 different articles, over a period of 86 days. 38 comments total, 261 characters average. This isn't someone who says "Nice post!" and leaves. This is someone who really reads, thinks, discusses.
Three other readers commented on 3 articles each, over periods of 27, 33, and 58 days. They come back. Not systematically, but regularly.

What these numbers reveal is that I have a small core of loyal readers. Not thousands of followers, not tens of thousands of views. But a dozen people who really read what I write, who come back, who engage in conversation.

And that, for me, is worth a thousand times more than 10,000 views from people who skim and move on.

When Do Comments Arrive?

Another discovery: comment timing.

When I publish an article, 39.8% of comments arrive in the first 24 hours. Then there's a secondary peak between 24 and 72 hours (27.8%). Then it slows down: 10.4% between 3 and 7 days, 6.9% between 1 and 4 weeks.

But — and this is where it gets interesting — 15% of comments arrive more than a month after publication.

That means my articles continue to create conversations long after they come out. Not massively, but constantly. A comment here, another there, three weeks later, two months later. People who stumble upon an old text, read it, have something to say.

Without this temporal analysis of comments, I would never have known that my articles had this long, discreet life.

(Note in passing: the tool also detects spam. "Lost your crypto? Don't panic!" on an article about CVs. Sometimes, data also tells the absurdities of the web.)

Real Analytics Isn't About Counting. It's About Storytelling.

When you collect data regularly, you no longer see totals. You see trajectories. Rhythms. Moments when something happens.

Let's take a concrete example. My article "How I Cut My Cloud Run Bill by 96%". If I only look at DEV.to stats, I see: "139 views in 7 days". That's all.

But if I look at my timeline collected every 4 hours:

January 10, 7 PM: 14 views (article published 1 hour before)
January 11, 11 AM: +15 views at once (peak)
January 11, 3 PM: +1 view
January 11-12: +1 to +5 views every 4 hours (slow growth)
January 13, 7 AM: +10 views (second peak)
January 13-14: complete stagnation (0 views for 24h)
January 15, 7 AM: +10 views (awakening)
January 15, 11 AM: +12 views (peak)
January 15-16: back to calm (+1 to +2 views)
January 17: +10 views in morning, +10 views at 11 AM, +5 views at 3 PM (last surge)
January 18: complete silence

You see the difference?

Raw data says: "139 views".

The timeline tells: "This article lived in waves. A first peak at publication, then slow growth, then three brutal awakenings on the 13th, 15th, and 17th of January, always in the morning. Then, silence. The article fell asleep."

And now, I can ask real questions: why these morning peaks? Did someone share the article in a morning newsletter? Does DEV.to have a recommendation logic that works in waves?

Without this fine memory, I would only see a number. With it, I see a story.

What I Did With These Discoveries

Nothing spectacular. I didn't change my way of writing. I didn't set up a content strategy. I didn't start writing for the numbers.

But I understood what resonates. I understood that my most personal texts create more conversations, even if they reach fewer people. I understood that certain technical subjects continue to be useful long after their publication. I understood that changing a title can revive an article, but it's not a recipe — it's a possibility.

And above all, I understood that my articles live in time. Not when I publish them. But in their trajectory.

The Uncomfortable Truths

Building this tool also forced me to face things I didn't want to see.

Some articles I was proud of are genuinely dead. Not sleeping. Dead. Zero views for weeks. No comments. No reactions. Just silence. I kept thinking "maybe they need time to find their audience". The data said: no, they're just not interesting to anyone.

I also discovered that some of my "high view" articles were inflated by my own bugs. One article showed 2500 hours of reading time over a week. Impressive, right? Except when you do the math: that's 104 days of continuous reading compressed into 7 days. Impossible. Turned out to be a SQL query error — I was doing a SUM on a field that already contained cumulative totals. The real reading time was closer to 57 hours. Still good, but not magical. And embarrassing: I was impressed by my own coding mistake.

And the hardest truth: most people don't read. They skim. They see the title in their feed, click, scroll for 3 seconds, leave. The "view" counts as engagement for DEV.to's algorithm, but it's not a real read. It's just... noise.

Without this tool, I could have lived in comfortable illusions. With it, I had to face reality: writing into the void is real, inflated metrics are real (even when you inflate them yourself by accident), and most "engagement" is shallow.

But strangely, that made me feel better. Because now I know which articles genuinely connect with people. And those few real connections matter more than any vanity metric.

Why Other Authors Might Want This

You don't need it if you write from time to time, without seeking to understand how your texts are received. DEV.to stats are more than enough.

But if you want to know:

Why certain articles "take off" and others don't
If a title change really had an effect
How your texts live over time
If your old articles continue to bring readers
What topics really trigger conversations

Then you need a memory. A tool that observes, not a tool that counts.

Why DEV.to Can't Do This (And Why That's Normal)

DEV.to is a platform, not an analytics tool. Its role is to give you a quick overview: how many views, how many reactions, how many comments. That's already a lot.

But a platform can't indefinitely store the detailed history of every author. It would be an enormous burden, for marginal use. Most authors don't need to know exactly what time an article took off on March 14th.

I do.

Not to "perform". Not to optimize. But because I want to understand what's happening. Because I am — and remain — an observer. Someone who likes to watch how things evolve over time, how an article lives, how a conversation develops.

That's why I built this tool. For me first. To understand my own texts, my own trajectories.

My Stance: Observer, Not Strategist

I don't optimize. I don't chase metrics. I don't compare myself to others.

I observe. I watch how my words live over time. I see what creates real conversations versus what just accumulates views.

This tool is an observation instrument. Not a strategy tool. Not a growth hack. Just a way to see what happens when you write honestly and let time reveal the patterns.

Conclusion: What Numbers Don't Say

DEV.to shows the data. This tool shows the story.

The data says: "This article has 139 views."
The story says: "This article lived in waves. A first peak at publication, then three brutal awakenings on January 13, 15, and 17, always in the morning, then silence."

The data says: "Your 'Agile' articles have 819 views on average."
The story says: "Your 'Agile' articles reach wide but engage little (2.5%). Your 'Free Exploration' articles reach 211 people but engage three times more (7.3%)."

The data says: "Respiration has 460 views."
The story says: "Respiration has 8.7% engagement — your best ratio — because it's the text where you opened up the most."

And sometimes, the story is much more interesting than the total views.

If you too want to see the secret life of your words, steal your data and listen. The rest is just noise.

Technical Annex: How It Works

The tool runs on my machine automatically every 4 hours via cron, calling devto_tracker.py --collect.

At each collection:

Query DEV.to's API for all articles and metrics
Store a complete snapshot in SQLite: views, reactions, comments, reading time
Detect changes: modified titles, added tags, deleted articles
Record events: "Staff Pick" detected, view spikes >3x average
Collect and analyze comments (length, timing, author)

SQLite is the heart of the system. Not MongoDB, not PostgreSQL — just SQLite. For 20-30 articles with snapshots every 4 hours, it's more than enough. A single file, easily backupable, easily queryable.

Analysis scripts:

dashboard.py — Overview: most viewed articles, engagement rate, performance by tag, author DNA

comment_analyzer.py --full-report — Comment analysis: who comments, when, on how many articles, with what depth

traffic_analytics.py --article ID — Precise timeline: views per day, reading time, reactions

seismograph.py — Correlation detection: title change → view spike, influential comment → exposure boost

Each script queries the same database with a different question. Simple Python. No complicated frameworks. Just scripts that read SQLite and display results in the terminal.

Installation (3 Steps)

The code is on GitHub: github.com/pcescato/devto_stats

# 1. Clone
git clone https://github.com/pcescato/devto_stats.git
cd devto_stats

# 2. Install dependencies
pip install requests python-dotenv

# 3. Configure API key
cp .env.example .env
# Edit .env, add your DEV.to API key
# (get it at https://dev.to/settings/extensions)

First collection:

# Initialize database
python3 devto_tracker.py --init

# Collect first data
python3 devto_tracker.py --collect

Automate (recommended):

chmod +x setup_automation.sh
./setup_automation.sh

This script will create a cron wrapper and offer different collection frequencies (2x/day, 4x/day, 6x/day).

After a few days: trends emerge.
After a few weeks: complete timelines.
After a few months: a real memory of your texts.

It's not a fancy dashboard. It's not a Web interface with animated graphics. It's a command-line tool for those who want to understand, not impress.

🚀 What Happened Next: From Prototype to Production

Update (February 2026): Two weeks after building this SQLite prototype, I took on a new challenge: migrate the entire system to production-grade cloud infrastructure using GitHub Copilot CLI as an execution engine.

The approach: Treat AI as an "execution engine" — I defined architectural constraints and business logic, Copilot handled implementation.

The result: A live platform deployed in 30 hours of actual work:
✅ PostgreSQL 18 with monthly partitioning (7,000+ records)
✅ Authentik SSO with role-based access control
✅ Real-time sync workers with advisory locking
✅ Production-grade security (forward auth proxy)

The Sismograph you read about above? It's now live and tracking article "pulses" in real-time.

👉 Read the full migration story: From Local SQLite Scripts to a Cloud Platform with GitHub Copilot CLI

Try the live demo:
🌐 Dashboard: https://streamlit.weeklydigest.me
🔐 Credentials: judge / Github~Challenge/2k26

Why Streamlit + Cloud Run is a Billing Trap (and How I Fixed It)

Pascal CESCATO — Sat, 10 Jan 2026 18:22:16 +0000

The Initial Shock: When Your Demo Becomes a Target.

On January 4th, 2026, I deployed my "Knowledge Graph CV" app on Cloud Run. Just a small demo for the New Year, New You Portfolio Challenge on Dev.to, which I describe in the article Beyond the Linear CV. Nothing too complicated. A CV transformed into an interactive graph via Gemini AI, some Plotly visualizations, all wrapped in a nice Streamlit interface.

I thought: "Estimated budget: €5-8/month. Should be fine." I set the limit at €10 - to have a small safety margin.

Less than 72 hours later, I received a Google Cloud notification. My usage was already at €5.20.

In the Google console: Projected cost: €28/month.

The next day: €35.

The day after: €42.

Something was attacking my app in real time.

The Painful Statistics

Cloud Run logs analysis (first 6 days):

Origin	Requests	Type	Behavior
🇵🇱 Poland	975/day	WebSocket	30s connections each
🇺🇸 USA (Comcast IPv6)	478/day	WebSocket	60s timeout
🇻🇳 Vietnam	476/day	WebSocket	Keeps reconnecting
Total bots	1929/day	101 (WebSocket)	16.7h CPU/day

Real cost: €0.40/day = €12/month for CPU alone.

Add RAM (368Mi), I/O, network... and you easily reach €25-30/month.

For a side project. That shouldn't exceed €10.

I had two options:

shut down the app
understand what was happening

I didn't want to close my app. I needed to understand. And fast.

The Culprit: Streamlit and Its Immortal WebSockets

Streamlit is great for building interactive dashboards. The catch? Everything relies on a persistent WebSocket connection.

Here's what happens when a bot arrives:

1. Bot hits my URL
2. Streamlit opens a WebSocket (Status 101)
3. Python starts, loads libs (pandas, plotly, gemini...)
4. The bot... never closes the connection
5. Cloud Run bills until timeout (30-60s)
6. The bot... immediately reopens a new connection

Result: one bot = 30s of CPU billed. 50 bots/hour = 25 minutes of CPU. 1200 bots/day = 10 hours of CPU.

At €0.024/CPU-hour, that's €9/month just for the bots.

And that's when I understood the problem:

If your Python code sees the request, it's already too late. You've already paid.

The False Leads (Or How I Wasted 3 Days)

Attempt 1: Filter in Python

import streamlit as st
import os

def block_bots():
    ip = st.context.headers.get("X-Forwarded-For", "").split(",")[0]
    if ip.startswith("185.136.92"):
        os._exit(0)  # Brutal process kill

Result: ❌ Complete failure.

Why? Because the bot hits /_stcore/stream (Streamlit's WebSocket endpoint). Python only executes after the WebSocket is established.

The 30 seconds are already billed.

Attempt 2: Password Protection

Idea: put a password page before the app.

if not st.session_state.authenticated:
    password = st.text_input("Password:", type="password")
    if password == os.getenv("DEMO_PASSWORD"):
        st.session_state.authenticated = True

Result: ❌ Partial failure.

The bot stays blocked on the password page... but the WebSocket stays open for 30s.

Cost: still €9/month.

Attempt 3: Reduce Timeout to 15s

gcloud run deploy --timeout=15s

Result: ⚠️ Works but...

The bot pays 15s instead of 30s (50% savings), BUT the app becomes unusable for real users. CV analyses take 15-20s.

Not acceptable.

Attempt 4: Consult 3 Different AIs

I asked for help from:

ChatGPT (rate limiting, environment variables, IP filtering)
Gemini (monitoring, memory optimizations)
Claude (architecture, debugging)

Result: Each gave me valuable leads, but none found THE solution.

Why? Because we were in an off-the-beaten-path case. AIs suggest standard solutions. Here, I needed to improvise.

The Breakthrough: "Block BEFORE Python"

Then, reading my logs for the umpteenth time, I noticed something:

{
  "remote_ip": "169.254.169.126",        // Cloud Run internal IP
  "X-Forwarded-For": "185.136.92.136",  // Bot's real IP
  "status": 101,
  "latency": "30.003234081s",
  "uri": "/_stcore/stream"               // Direct WebSocket!
}

The bot doesn't even go through the homepage. It hits the WebSocket directly.

Conclusion:

An application firewall is too late. You need a bodyguard IN FRONT of Streamlit.

A reverse proxy.

Why Caddy (And Not NGINX)

I already use Caddy for other projects (reverse proxy in front of PostgreSQL in Docker). I know its lightness, its simplicity.

NGINX? Too heavy for a Cloud Run container:

Image ~50 MB (vs ~15 MB for Caddy)
Verbose configuration
Additional modules needed
RAM: ~15-20 MB (vs ~5-10 MB Caddy)

In a 368Mi container, every byte counts.

Caddy is a sniper. NGINX is a tank.

I needed a sniper.

The Final Architecture: The "Thermal Shield"

BEFORE (€42/month):

AFTER (€1.59/month):

Architecture breakdown:

The Code: 3 Files, ~60 Lines

1. Caddyfile (~35 lines)

{
    admin off
    auto_https off
    servers {
        trusted_proxies static 169.254.0.0/16
    }
}

:8080 {
    # Grouped matcher for all banned IPs
    @denylist {
        header X-Forwarded-For *185.136.92.*
        header X-Forwarded-For *115.98.235.*
        header X-Forwarded-For *119.111.248.*
        header X-Forwarded-For *115.96.83.*
        header X-Forwarded-For *2601:600:cb80:*
        header X-Forwarded-For *57.151.128.*
        header X-Forwarded-For *2402:3a80:*
    }

    # Respond 403 to any of these matches
    handle @denylist {
        respond "Access Denied" 403
    }

    # Everything else goes to Streamlit
    handle {
        reverse_proxy localhost:8501 {
            header_up X-Real-IP {http.request.header.X-Forwarded-For}
            header_up X-Forwarded-For {http.request.header.X-Forwarded-For}
        }
    }

    log {
        output stdout
        format console
    }
}

Key config points:

trusted_proxies static 169.254.0.0/16: Tells Caddy to trust Cloud Run's internal proxy (which always has an IP in 169.254.x.x). Without this, Caddy doesn't read X-Forwarded-For correctly.
@denylist: Grouped matcher - if any of the patterns match, we block.
header X-Forwarded-For *185.136.92.*: Simple wildcard - blocks all IPs starting with 185.136.92 (the entire /24 range).

Principle: Caddy reads the X-Forwarded-For header (where Cloud Run puts the real IP), compares it to the blacklist, and blocks BEFORE Python starts.

2. Dockerfile (20 lines)

FROM python:3.11-slim
WORKDIR /app

# Install Caddy (single binary, 15MB)
ADD https://caddyserver.com/api/download?os=linux&arch=amd64 /usr/bin/caddy
RUN chmod +x /usr/bin/caddy

# Install Python dependencies
COPY --from=ghcr.io/astral-sh/uv:latest /uv /bin/uv
COPY pyproject.toml .
COPY . .
RUN uv pip install --system -e .

# Config & startup
COPY Caddyfile start.sh ./
RUN chmod +x start.sh

EXPOSE 8080
CMD ["./start.sh"]

3. start.sh (5 lines)

#!/bin/bash
# Launch Streamlit in background (internal only)
streamlit run app.py --server.port=8501 --server.address=127.0.0.1 &

# Launch Caddy in foreground (public-facing)
caddy run --config /app/Caddyfile

That's it.

Two processes in one container. Caddy in front, Streamlit behind.

The Numbers: Crushing Victory

Results after 1 hour of production (heavy load):

Type	Requests	Action	CPU	Cost/month
Bots	904	403 (blocked)	2.17s	€0.01
Humans	22	101 (passed)	328.68s	€1.58
TOTAL	926	Mixed	330.85s	€1.59 ✅

Cost evolution (projected):

D+1: Deployment (€1)
D+2: Bots discover the app (€5 → €28 projected)
D+3-4: Escalation (€42 at peak)
D+5: Caddy v1 partial (€25)
D+6: Caddy v2 finalized (€1.59) ✅

Reduction: -96.2% (€42 → €1.59)

What This War Taught Me

1. The Real Cloud Cost Isn't AI

Gemini API? €0.05/day.

Bots camping on WebSockets? A fortune.

2. WebSockets Are the Achilles' Heel of Serverless

A classic HTTP connection: <1s billed.

A lingering WebSocket: 30s billed.

Multiply by 1000 bots, and you understand the problem.

3. IPv6 Makes Blacklists Obsolete

A bot in IPv4: 185.136.92.136

The same bot in IPv6: 2601:600:cb80:fba0:48a9:f979:23ca:193b

Good luck blacklisting all variations.

4. A Reverse Proxy = Best Economic Defense

Cloud Armor (Google WAF)? $7/month.

HTTPS Load Balancer? €18/month.

Caddy in the container? €0.

5. AIs Help, But Don't Find Everything

ChatGPT, Gemini, Claude all helped me explore. But the final solution? Me, at 2 AM, reading logs.

6. You Learn More in Prod Than in Tutorials

No Udemy course would have taught me:

How to read Cloud Run logs
Why X-Forwarded-For vs remote_ip
How Streamlit handles WebSockets
Why a reverse proxy saves at least €25/month

Production > Tutorials. Always.

The Bottom Line

I thought I was building an AI project for a Dev.to challenge.

I ended up at war with an international botnet.

Result:

✅ Functional and public app
✅ Controlled costs (€1.59/month projected)
✅ 900+ bots blocked/day
✅ A story to tell

And most importantly: I learned more in 6 days of debugging than in 6 months of tutorials.

If you're launching a serverless app exposed to the public, put a reverse proxy in front. Not for security (though...), but for your wallet.

Running Streamlit on Cloud Run? Check your billing NOW. Drop your monthly cost in comments - let's compare notes 👇

Resources & Code

Complete source code: GitHub - knowledge-graph-cv
Detailed technical article: Beyond the Linear CV

Beyond the Linear CV

Pascal CESCATO — Sun, 04 Jan 2026 10:46:55 +0000

This is a submission for the New Year, New You Portfolio Challenge Presented by Google AI

About Me

My professional path isn't linear. It's atypical, composed of pivots, skill acquisitions across different contexts, and transitions that traditional CVs struggle to represent.

For years, the challenge wasn't "how to write a CV" but rather: how to make a non-linear journey readable?

The classic portfolio format—chronological, linear, static—works well for continuous trajectories. It breaks down for everything else. This project emerged from that personal need: what if we stopped trying to flatten our careers into a timeline, and instead represented them as they truly are—a network of interconnected skills, projects, and experiences?

As we enter 2026, "New Year, New You" doesn't have to mean reinventing yourself. Sometimes it means representing yourself more accurately.

Portfolio

What You'll See

The app loads with my CV as a demo so you can explore immediately:

Network Graph: 30+ interconnected nodes showing skills, projects, and expertise domains

Flow Diagram: Visual journey from skills → projects → specialized areas

Skills Matrix: Heatmap showing which projects use which technologies

Zero friction: No upload required to see it in action. Click "Upload Your Own CV" when you want to try yours.

Visualizing Career Evolution

To test the system's ability to capture career trajectories, I ran my own CV from 2021 vs 2025:

2021 Graph (37 nodes, 74 edges):

Corporate-focused: Skyrock, Logic-Immo, Photobox
Legacy tech: Flash/Zend_Amf, Palm webOS, ORACLE
Broader scope: Lead Dev, Project Manager, Full-Stack Engineer

2025 Graph (30 nodes, 74 edges, +23% density):

Independent: Freelance + personal projects
Modern stack: Astro, LLM/RAG, Docker, PostgreSQL
Focused expertise: Migration Engineering + AI Automation

What changed?

-8 technologies (legacy tech retired)
+2 concepts (AI Automation, Migration Engineering)
+23% density (deeper specialization vs wider breadth)

The graph doesn't just show skills—it tells the story of a career pivot from corporate generalist to independent specialist.

This is exactly what traditional CVs fail to capture.

Career Evolution: 2021 → 2025

Metric	2021	2025	Change
Nodes	37	30	-19% ↓
Edges	~74	74	=
Density	2.0	2.2	+23% ↑
Stack	Legacy + Modern	Modern only	🔄
Focus	Corporate generalist	Independent specialist	🎯

Key transitions:

Out: Flash, ORACLE, Palm webOS, 5 corporate clients
In: Astro, LLM/RAG, Docker, AI Automation, Migration Engineering
Evolved: PHP 4→7, WordPress (legacy→modern), MySQL

The graph doesn't just track skills—it reveals strategic pivots.

Real-World Testing

I tested the tool with three different profiles:

Senior Specialist (30 nodes, 2.47 density)

Deep expertise in AI/Migration
Modern stack (Astro, LLM, Docker)
High interconnection within niche

Mid-Level Generalist (33 nodes, 2.42 density)

Broad CMS expertise (WordPress, Magento, PrestaShop)
Traditional e-commerce stack
Skills distributed across varied projects

Junior Polyvalent (35 nodes, 2.57 density)

Modern full-stack (MERN, Angular, Symfony)
Creative skills (design, video)
The matrix revealed interesting gaps: claimed Symfony expertise with no projects demonstrating it

Key insight: The tool adapts to different career stages and reveals actionable patterns—like skills declared but not proven in projects.

How I Built It

The Problem: Structure, Not Extraction

This isn't keyword extraction. It's about asking AI to reason about context and produce a structured representation: nodes, relationships, and a graph-oriented vision.

Most CV parsers extract surface-level keywords. This project asks: "What are the semantic connections between my Python skills, my migration projects, and my AI automation expertise?"

Tech Stack

AI Layer:

Gemini Flash Preview 3.0 for CV analysis
Google AI Studio for prompt engineering & iteration
Custom system prompt with 6 levels of extraction rules

Visualization Layer:

Streamlit for the web interface (rapid prototyping)
vis.js (via streamlit-agraph) for network graphs
Plotly for Sankey flow diagrams & heatmaps

Deployment:

Google Cloud Run for containerized deployment (challenge requirement)
Docker for containerization
GitHub integration for CI/CD

Why streamlit-agraph for Network Visualization?

The Network Graph view uses streamlit-agraph (a vis.js wrapper). During development, I evaluated several alternatives for displaying interactive network graphs in Streamlit. Here's the decision matrix that led to this choice:

Library	Responsive	Interactive	Force-Directed Layout	Dev Time	Verdict
streamlit-agraph	⚠️ Fixed canvas	✅ Full (click, zoom, pan)	✅ Automatic	~2 hours	✅ Selected
Plotly Graph Objects	✅ 100% responsive	⚠️ Limited interactions	❌ Manual positioning	~6 hours	❌ Too much effort
Pyvis	⚠️ HTML file generation	✅ Full	✅ Automatic	~4 hours	❌ Complex integration
NetworkX + Matplotlib	✅ Fully responsive	❌ Static image	✅ Automatic	~3 hours	❌ No interactivity
D3.js Custom	✅ 100% responsive	✅ Full control	✅ Custom	~8+ hours	❌ Time prohibitive

Decision rationale:

For this project, interactivity was the priority. The ability to click nodes, activate focus mode, and explore connections dynamically was more valuable than perfect responsive behavior in iframes.

streamlit-agraph delivered:

✅ Zero-configuration force-directed layout (nodes position themselves)
✅ Full interaction support (click handlers, zoom, pan)
✅ Production-ready in ~2 hours of development
✅ Professional visual quality out of the box

Trade-off accepted:

⚠️ Fixed canvas size (1400×900px) doesn't fill 100% of iframe width
✅ Mitigation: Canvas size chosen to work well on 1440px+ screens (laptops/desktops)

Alternative approaches considered (Plotly, D3.js) would have provided better responsive behavior but at the cost of 3-4× development time and reduced interactivity.

So streamlit-agraph hit the sweet spot between functionality, visual quality, and development speed.

Responsive Strategy

While the canvas is fixed at 1400×900px, users can collapse the sidebar (<< button) to gain ~250px of vertical space. This makes the app work perfectly even on 1366-1680px screens.

Sidebar open: Full controls + graph (optimal on 1920px+)
Sidebar closed: Full-screen graph (optimal on 1366px+)

User-controlled responsiveness proved more practical than attempting CSS magic with fixed-size canvas elements.

Development Process

1. Prompt Engineering in Google AI Studio

Before writing any application code, I spent time in AI Studio crafting the extraction prompt. This phase was critical:

LEVEL 1: Core entities (Person, Skills, Projects)
LEVEL 2: Relationships (USES, CREATED, MASTERS)
LEVEL 3: Technical relationships (PHP ENABLES WordPress)
LEVEL 4: Concepts & expertise domains
LEVEL 5: Temporal & contextual relationships
LEVEL 6: Bidirectional concept-project links ← Key innovation

Why this matters: A CV isn't just nodes, it's the connections that matter. "Python" isn't just a skill—it ENABLES AI Automation, which is IMPLEMENTED_IN multiple projects, which DEMONSTRATES Migration Engineering expertise.

The prompt evolved through 20+ iterations in AI Studio before integration.

2. Multi-View Dashboard

Initial version had only the network graph. User feedback revealed a problem: different audiences need different views.

Developers want to explore connections (Network Graph)
Recruiters need quick visual narratives (Flow Diagram)
Managers want fast skill scanning (Skills Matrix)

The breakthrough was realizing this isn't three separate features—it's three perspectives on the same data.

3. Iterative UX Refinement

Based on real user testing:

V7.0: Multi-view dashboard
V7.1-V7.6: Spacing optimization (nodes were overlapping)
V8.0-V8.2: English interface + demo auto-loading

The demo CV auto-load was inspired by the challenge theme: show, don't tell. Let visitors see the result instantly instead of asking them to upload first.

4. Deployment on Google Cloud Run

As required by the challenge, the app is deployed on Google Cloud Run. The deployment is straightforward:

Containerized: Streamlit app packaged in Docker
Serverless: Auto-scaling, pay-per-use
Public URL: Accessible without authentication
CI/CD: Connected to GitHub for automatic deployments

Cloud Run was chosen for its simplicity and alignment with the Google AI ecosystem.

Google AI Tools Used

Google AI Studio was essential for:

Rapid prompt iteration without deploying code
JSON validation to ensure consistent output structure
Token optimization to stay within rate limits

Gemini Flash Preview 3.0 chosen for:

Multimodal capabilities (PDF → structured JSON)
Large context window (handles long CVs)
Structured output with consistent formatting
Speed for real-time extraction

Design Decisions

Why Graphs?

Traditional CVs are tree structures (chronological). Professional identities are graphs (relational). The mismatch creates information loss.

Example: My "WordPress to Astro Migration" project connects to:

Astro framework (USES)
WordPress (USES)
Web Performance (DEMONSTRATES)
Migration Engineering (DEMONSTRATES)
SSG Ecosystem (IMPLEMENTED_IN)

A timeline can't represent this richness. A graph can.

Why Three Visualizations?

Network Graph: For exploration and discovery

Best for: Deep dives, understanding connections
Audience: Technical leads, fellow developers

Flow Diagram: For storytelling

Best for: Quick pitches, visual narratives
Audience: Recruiters, hiring managers

Skills Matrix: For scanning

Best for: 30-second skill assessment
Audience: HR, technical screeners

One visualization can't serve all audiences. This was the key insight.

Why Demo-First?

Inspired by product design principles: reduce friction to zero.

Before: "Upload your CV to see how it works" → 50% bounce rate
After: "Here's mine already loaded, explore now" → Instant engagement

What I'm Most Proud Of

1. Bidirectional Semantic Relationships

The graph doesn't just show that "Newsletter Engine uses Python"—it shows that:

Python ENABLES AI Automation (capability)
AI Automation is IMPLEMENTED_IN Newsletter Engine (evidence)
Newsletter Engine DEMONSTRATES AI Automation (showcase)

This bidirectionality creates semantic completeness. Each project isn't just a container of technologies—it's proof of conceptual expertise.

2. Dense Graph Quality (70+ Relationships)

Most CV extractors produce sparse graphs (1.0-1.5 edges per node). This achieves density 2.4 (72 relationships for 30 nodes) by:

Extracting ALL mentioned technologies (not just "main" skills)
Creating technology chains (Docker RUNS_ON Linux)
Linking related projects (wp2md RELATED_TO WordPress Migration)

A dense graph is a truthful graph.

3. Zero-Config Demo Experience

The app loads with my CV pre-analyzed. No authentication, no API keys to configure, no upload required.

This aligns with "New Year, New You"—the portfolio shows transformation immediately rather than promising it.

4. Real-Time Adaptation to Feedback

Every version (V1 → V8.2) incorporated user feedback:

"Nodes overlap" → Mega Wide spacing mode
"Labels unreadable" → Verdana sans-serif, size optimization
"Need different views" → Multi-view dashboard
"Too much friction" → Demo auto-loading

Built in public, refined through dialogue.

5. Technical Elegance

The entire extraction happens in a single prompt. No multi-stage pipeline, no external tools.

response = model.generate_content([
    {"mime_type": "application/pdf", "data": cv_bytes},
    EXTRACTION_PROMPT
])
graph_data = json.loads(response.text)

Input: PDF bytes + prompt
Output: Complete knowledge graph

That's it. The complexity is in the prompt design (crafted in AI Studio), not the code.

Personal Reflection: New Year, New Perspective

This project started as a personal need and became something more: an invitation to view professional identity differently.

We spend so much energy trying to fit our careers into templates. What if the template was wrong?

A knowledge graph doesn't judge whether your path was "correct." It simply represents what is: the skills you have, the projects you built, and how they connect.

In the spirit of "New Year, New You," this isn't about reinventing yourself. It's about representing yourself with more accuracy. Sometimes that's enough.

Try It Yourself

📂 Source Code: https://github.com/pcescato/knowledge-graph-cv

Technical Metrics

Extraction Time: ~15-25 seconds (Gemini Flash Preview 3.0)
Average Graph: 25-35 nodes, 60-80 relationships
Density: 2.0-2.8 (edges per node)
Supported Formats: PDF only
Visualizations: 3 (Network, Flow, Matrix)
Languages: English interface

What's Next?

This MVP was built in 3 days as a proof of concept for the Google AI Challenge.

Technical roadmap (not yet implemented):

Export formats: JSON, GraphML, Neo4j cypher for data portability
Comparison mode: Side-by-side CV analysis to track career evolution
Skill gap analysis: Compare your graph against target job descriptions
Temporal dimension: Visualize career progression over time

But I see potential beyond personal portfolios:

HR Tech: Intelligent candidate matching based on skill graphs, not keywords
Internal Talent Mapping: Companies understanding who knows what across teams
Career Coaching: Visualizing skill gaps and growth paths

The graph-based approach reveals connections that traditional CVs hide. If you're building in this space or interested in exploring applications for recruitment, talent analytics, or knowledge management—I'd love to chat.

The FinOps Victory: Slashing my Cloud Bill by 97% Against a Botnet

The biggest challenge of this project wasn't the AI—it was budgetary survival. Within 48 hours, my application went from a quiet demo to the target of an intensive piloning (bots from Poland, Vietnam, and the USA).

The Final Architecture: The "Thermal Shield"

The problem? Streamlit (Python) is notoriously bad at closing persistent WebSocket connections quickly, which kept my Cloud Run instances running (and billing) indefinitely.

The solution: Injecting a Caddy server (written in Go) as a Reverse Proxy inside the same Cloud Run container.

Cloud Run Container (512Mi)
├── Caddy (:8080) ← The "Bouncer" at the door
│   ├── IP Filtering (via X-Forwarded-For headers) → 403 Forbidden
│   └── Proxy legitimate traffic → localhost:8501
└── Streamlit (:8501) ← The (now protected) App

The Numbers (Last Hour Report)

Using a custom monitoring script, I isolated the efficiency of this defense during a high-traffic hour:

Traffic Type	Requests	Action	CPU Time	Projected Budget
Bot Attacks	945	Blocked (403)	2.17s	€0.01 / month
Human Sessions	12	Allowed (101)	328.68s	€1.58 / month
TOTAL	957	-	330.85s	€1.59 / month ✅

Cost Evolution (Monthly Projection)

Day 1 (Initial Deploy): ~€25/mo (No protection).
Day 3 (Attack Detected): ~€42/mo (Python-level filtering failed to close sockets).
Day 6 (Caddy "Sniper" Active): €1.59/mo (Bots are ejected in under 2ms).

Drastic Reduction: -96% from the worst-case scenario.

Lessons Learned "From the Trenches"

The App is not a Firewall: In Serverless environments, if traffic hits your Python code, you’ve already paid. You must block the attack as early as possible in the network stack.
The IPv6 Trap: Modern bots use IPv6 tunnels extensively (Comcast, Indian ISPs) which bypass traditional IPv4 filters.
The Internal Sidecar: Running two processes (Caddy + Streamlit) in a single container is an elegant, free, and ultra-robust way to secure a public demo without the cost of a Load Balancer or Cloud Armor.

The irony of the challenge: I probably learned more about reverse proxies, X-Forwarded-For headers, and cloud cost optimization than I did about Knowledge Graphs. But that's the reality of production: **Production > Tutorials, always.

The full story: Why Streamlit + Cloud Run is a Billing Trap (and How I Fixed It)

Thanks for reading! If this resonates with you, I'd love to hear your thoughts.

Does your career fit into a timeline, or is it a graph? 💭

DEV Community: Pascal CESCATO

Unboxable in Tech

Exhibit 1 — The Unlikely Internship

Exhibit 2 — The Printer

Exhibit 3 — The Cleaning Company

Exhibit 4 — The SELECT COUNT(*)

Exhibit 5 — The Open Space

Exhibit 6 — Logic-immo

Exhibit 7 — The Regional Directory

Exhibit 8 — The B2B Platform

Exhibit 9 — The Projects Nobody Asked For

Exhibit 10 — The Handover and the Veto

Exhibit 11 — The Classroom Aide

The Mechanism

The Verdict

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

The Community

What I Built

The protocol, in brief

Demo

Code

pcescato / htbmcp

HTBMCP/1.0 — Hyper Text Beer Mug Control Protocol

What is this?

The uvicorn problem — and the solution

Temperature validation — MUST vs SHOULD NOT

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

How I Built It

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

A Brief History of the Web's Most Honorable RFC

The error codes

What the RFC Actually Defines

The new methods

The Accept-Additions header

Step 1 — Play First: The Standalone Simulator

Step 2 — Ship It: The Production Server

A word on uvicorn

Architecture: a pot registry

Parsing the Accept-Additions header

The HTCPCP endpoints

Middleware: enforce HTCPCP headers

Structured logs — because we're professionals

What This Actually Teaches You

Conclusion

Your Article Isn’t the Real Content

What actually happens when you write with real specifics

Publishing without the discussion is publishing an incomplete object.

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

Who Are We Still Writing Technical Articles For?

A Long-Term Trajectory

How We Consume Technical Knowledge Today

Technical Articles Haven't Disappeared — They've Evolved

Why I No Longer Write Tutorials

What Writing Still Allows

What Holds Its Value

A Different Audience

Why Write Publicly?

An Assumed Choice

Continuing

Actually Static: When WordPress Stops Being the Enemy

Summary

What I Built

The Search for an Alternative

Existing Tools: Effective but Heavy

Tech Stack

Demo

Why I Finally Stopped Fighting My Publishing Workflow | AJC Bridge

The Real-World Gauntlet

Where Copilot CLI Accelerated Development

Why Local Image Optimization Matters

Architecture

How It Works

Resources

Production Update: Multi-Destination Publishing

Five Publishing Strategies

Why This Matters

Technical Implementation

Real-World Usage

What's Next

Technical Highlights

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

2. Full Content: `wp-jamstack-sync.php`