DEV Community: Médéric Burlet

An AI detector flagged my draft 97% machine. The rewrite scored 0%.

Médéric Burlet — Mon, 20 Jul 2026 05:20:33 +0000

You can usually feel it now. You read a couple of lines and something is off before you can name it. Nobody actually says "delve," but there it sits. The points show up in neat little threes. Every sentence the same polite length as the one before, no rush, no pause. A long dash you would never type by hand. And under all of that, characters you cannot even see: invisible marks that hitch a ride in copied text and quietly rat it out as machine-made.

I got tired of spotting it, so I built something to strip it. Ghostwriter. Free, open source.

Then, instead of trusting my own eye, I checked. A raw AI draft scored 97% machine on ZeroGPT. Same words run back through the tool, scanned again: zero. The detector called it human and moved on.

The part that caught me off guard was that you cannot patch this at the end. The cheap tells, the dashes and the hidden characters, those wipe off in a second. Vocabulary and rhythm are rewrite rules. But the tell that really sticks is not a word. It is the shape of the thing. Whether the last line dutifully explains the point you already made. Whether it names an actual book or waves at "a classic example" and hopes you nod along. And that shape gets decided while you draft, which is the whole reason those one-click "humanize" buttons flop. Click one and the bones are already wrong under the polish.

One warning, because this corner of the internet runs thick with snake oil. Detectors get jumpy on short text, and no tool turns a dull paragraph into a good one. Ghostwriter takes the machine fingerprint off. Whether there is anything worth reading underneath is still your problem, not the tool's.

The long version walks through all three layers, the runs across a few Claude models, and how the whole thing drops into Claude and Copilot as one folder you copy across: read it here

Real question, not a rhetorical one: which tell ruined AI text for you? The one you now catch in every newsletter that hits your inbox.

I shipped 40 cyberpunk UI components. The neon was the easy part.

Médéric Burlet — Sat, 18 Jul 2026 10:08:50 +0000

The Cyberpunk 2077 interface look is everywhere in games and film, and almost nobody ships it as something you can actually build on.

It is easy to fake: near-black background, one hot neon accent, a glow filter, done. That is also exactly where almost every attempt stops. A palette and a glow are not a design system.

So I built Nocturne, an open-source design system for that Night City look: 40 components, one source of truth for color, type, spacing, radii, shadows, and motion. And honestly, the neon was the easy part.

The hard part was contrast. Neon-on-black looks incredible and fails accessibility contrast checks constantly. A hot yellow on near-black works as an accent; use that same yellow for body text and it quietly drops below the ratio that keeps it readable for real people. So the system treats contrast as a first-class constraint, with an actual contrast table, not a "we care about a11y" line in the README.

The other decision that ate the time: every component is built twice. Once as a framework-agnostic CSS class API, once as a typed React wrapper over the exact same classes. Same visual language either way, so you adopt a layer, not a framework.

That is the whole point of the three-package split. Take just the tokens to theme something you already have. Drop the plain CSS into any stack, Vue, Svelte, Astro, or raw HTML:

<link rel="stylesheet" href="https://unpkg.com/nocturne-css/dist/nocturne.css" />
<button class="noct-btn noct-btn--primary">Jack in</button>

Or pull in the React components if that is your stack. Nothing forces a rewrite to get the look.

The full write-up has all three packages, the complete component list, the quick-start for each layer, and the under-the-hood choices (Rajdhani, JetBrains Mono, zero-runtime CSS): https://mederic.me/blog/nocturne-design-system

Honest question: what visual style do you wish shipped as a real, accessible component library, instead of a Dribbble shot you have to rebuild from scratch every time?

10 small AI wins that quietly give you your afternoon back

Médéric Burlet — Wed, 08 Jul 2026 03:04:11 +0000

Most people save AI for the big, impressive project, the thing worth a screenshot. Then they never quite find the project, and the tool just sits there unused.

Meanwhile the real value was in the ten dull tasks you already do every single day. None of them make headlines. That is exactly why they add up.

None of these need any skill. You type what you want in plain words and refine from there. A few that pay off immediately:

Summarise before a meeting. Drop in the report, ask for the five key points. Caught up in a minute instead of skimming for ten.
Rewrite for tone. Message sounds too blunt, or too stiff? Ask for a warmer or shorter version. You keep control of the final wording.
Meal ideas from what you already have. List what is in the fridge, ask for three dinners. It is surprisingly good at turning odds and ends into a plan.

The gap between a useful answer and generic AI slop comes down to three habits:

Be specific. "Suggest dinner" is weak. "Three quick vegetarian dinners using rice, eggs, and spinach" is strong.
Edit the output. The first draft is raw material, not the finished thing. Shaping it into your own voice is the whole job.
Check the facts. It can sound completely sure and still be wrong. For anything that matters, verify before you rely on it.

And one hard rule on what never goes in: if you would not email it to a stranger, do not paste it into a chatbot. No passwords, no bank details, no confidential work files, no one else's private information.

None of this is dramatic. That is the point. Everyday AI is not one giant leap, it is a hundred small ones that hand you your afternoon back.

That is three of the ten. The full list, including the spreadsheet cleanup and the translate-then-verify trick most people skip, is here: https://mederic.me/blog/ai-for-your-day-10-wins

What is the smallest, most unglamorous thing you use AI for that you would genuinely miss?

My feed format is "62% smaller than JSON Feed." That number is a cop-out.

Médéric Burlet — Tue, 07 Jul 2026 18:24:34 +0000

I keep quoting one number for my compact feed format: "62% smaller than JSON Feed." It is a convenient midpoint, and honestly a bit of a cop-out, because a single headline figure hides where a compact format actually earns its keep.

Here is the real spread. Same serializer, single-source feed, measured at three sizes:

Items	JSON Feed	NWF	Reduction
10	5.6 KB	1.8 KB	67%
100	53.7 KB	16.8 KB	69%
1000	538.8 KB	170.6 KB	68%

Notice the ratio barely moves as the feed grows. That is the good news.

The catch: those are single-source feeds, and they hit 67 to 69%. Mixed, multi-source feeds only save about 50 to 54%. The "62%" I quote everywhere is just the midpoint between those two cases.

Why the gap? Interning. Authors, tags, and sources are stored once in a table and referenced by index (a:0 means author index 0). If one author wrote forty items, their name appears once, not forty times. A single-source feed repeats itself constantly, so the interning table pays off hugely. A multi-source merge has far less repetition to fold away, so it saves less. The compression is honest about what it is: redundancy removal, not magic.

And here is the part most "I designed a format" posts skip, the part about when not to use it.

If you publish to clients you do not control, keep emitting JSON Feed 1.1. NWF is for machine-to-machine work: syncing feeds between servers, caching large merged outputs, storing a mesh that pulled hundreds of items together. Because the canonical model is the contract, the same feed serializes to both formats, so reaching for the compact one is never a lock-in.

The full design write-up covers the line grammar (one letter per record, TAB-separated cells, LF-separated lines), the byte-for-byte round-trip guarantee, and the complete benchmark method: https://mederic.me/blog/nwf-format-design

If you have ever shipped a compact or binary format: did you publish the honest range, or just the best-case number?

The 30-second check that catches a confidently wrong AI

Médéric Burlet — Tue, 07 Jul 2026 08:03:17 +0000

An AI model writes in the same calm, authoritative voice whether it is right or inventing the answer on the spot.

So the confidence you feel while reading a fluent answer is not evidence. It is style. The voice tells you nothing, and a quick check is the only thing that does.

Here is the 30-second version I run before trusting anything that matters. Three steps.

1. Does the cited source actually say it? If the AI links or names a source, open it and find the exact claim. Surprisingly often the source is real but does not back up the point being made.

2. Cross-check one independent source. Find a second, unrelated source that agrees. Two independent sources saying the same thing is far stronger than one. If the AI gave no source at all, treat that as a yellow flag and go find one yourself before relying on the answer.

3. Trust, verify more, or drop. If both agree, trust it. If they clash, dig deeper or leave the claim out.

The trick that keeps this at 30 seconds: you do not audit every sentence. Pick the one or two load-bearing facts, the ones the whole answer rests on, and check only those.

And aim your suspicion where models actually break: numbers, dates, names, and exact quotes. A model can be off by a single digit or a year while everything around it reads perfectly. It has no feeling of doubt to warn you with, which is exactly why you have to supply the doubt yourself.

For an everyday creative question, relax. For a figure you are about to put in a report, or advice you are about to act on, run the full check every time.

The full version covers which claims are high-stakes enough to always verify (legal, medical, anything you are about to act on) and how to make this a lightweight habit instead of a chore: https://mederic.me/blog/fact-check-ai-answer

What is the last confidently-wrong AI answer that almost got past you?

Your best AI demo is a vanity metric

Médéric Burlet — Tue, 07 Jul 2026 01:17:30 +0000

The most impressive AI demo you have ever given told you almost nothing about whether it would actually work.

That is uncomfortable, because the demo is the thing that got the room excited and the budget approved. But a pilot is judged on a single impressive run. Production is judged on the thousandth unremarkable one.

A demo is a curated event. Someone picks the input, polishes the prompt, and runs it until it shines. That tells you the ceiling of what is possible in perfect conditions, which is genuinely interesting and almost useless for predicting daily value.

Daily value comes from the floor, not the ceiling. It is what happens when a tired engineer on a Friday reaches for the tool on a messy, real ticket. If that interaction is smooth enough to repeat without thinking, it compounds. If it needs the demo conditions to work, it gets abandoned the first busy week. Which is every week.

So I stopped asking "how impressed was the room" and started tracking the things that actually accumulate:

Throughput - how much the team ships per cycle, not how fast one task went once.
Cycle time - averaged across real tickets, including the ugly ones.
Default usage - what fraction of eligible work touches the tool without anyone being reminded.

Notice what is missing from that list: the wow factor. "How impressed was the room" feels like progress and predicts nothing about month three. It is a vanity metric wearing a nice suit.

A single spike looks bigger in the moment. The broad, steady area of many boring daily uses is what compounds, and it ends up ahead of the demo that peaked once and went flat.

The full argument, including why the exact skills that win a demo are the ones that never generalize to real work, is here: https://mederic.me/blog/unremarkable-workflow

So, honest question: think about the last AI tool your team actually kept using. Was it the demo that sold it, or some boring Tuesday when a teammate reached for it without being told to? Which one made it stick?

I vetted 271 RSS sources so you don't have to hunt them down

Médéric Burlet — Mon, 06 Jul 2026 01:59:01 +0000

Everyone blames RSS for dying. For a while I was convinced the problem was technical: brittle feeds, missing endpoints, formats nobody agrees on.

It wasn't. The hard part was never the plumbing. It was knowing which sources are actually worth following.

An empty feed reader is useless. Setting one up properly means hunting down RSS and Atom URLs one at a time, guessing which blogs still post, and finding out weeks later that half of them went quiet in 2021. That afternoon of link-hunting is the real reason people give up and go back to an algorithmic timeline that decides for them.

So I did the boring part. 271 vetted feeds, grouped into 24 themes, as a ready-made pack you point a reader at instead of assembling by hand.

A few of the themes and how many sources each carries:

Frontier AI Labs (12), AI Tools & ML Platforms (12), AI Research & Academia (12)
Languages & Frameworks (13), Developer Tools (12), Cloud & Infrastructure (13), Security (12)
Databases & Data (12), Hardware & Chips (11)

And it is not all work. There are themes for Space, Science, Gaming, Anime, Movies & TV, Music, Books, and Food, because a reader you actually enjoy opening is a reader you keep using.

Every entry is a real, stable source, organized so a theme reads as a coherent feed instead of noise. You choose the themes; the vetting is already done. That is the middle path between an algorithm choosing for you and a blank reader making you do everything.

The full theme list, the key for each one, and every source in the pack is here: https://mederic.me/blog/neurowire-taps-pack

Honest question for anyone still running a feed reader: how do you actually find new sources worth adding? Or did the blank-page problem win, and you quietly stopped?

3 tricks that made my feed format 62% smaller than JSON Feed

Médéric Burlet — Sun, 05 Jul 2026 15:37:13 +0000

JSON Feed is comfortable. It is also bigger than it needs to be.

While building a feed engine that emits six formats from one canonical model, I wanted a native format that stayed human-readable but stopped paying for the same strings over and over. The result, NWF, comes out roughly 62% smaller than the equivalent JSON Feed, and it still round-trips losslessly back to the same model.

Three tricks get it there. None of them are gzip. You can still open the file and read it.

1. Intern repeated values. Authors, tags, and sources are listed once and then referenced by index. A feed of 50 posts by one author stores that author string one time, not fifty.

2. Relativize links. Every URL is stored relative to a shared base prefix instead of repeating https://your-domain.com/... on every single entry.

3. Store dates as deltas. Instead of a full ISO timestamp per item, each date is a small delta from the feed's own update time.

The wire format itself is line-oriented on purpose: LF-separated lines, TAB-separated cells, a one-letter kind per line. Media type text/x-neurowire, extension .nwf. Compact enough for machines, still legible when you are debugging it by eye.

Why bother when gzip exists? Because interning and relativizing shrink the model before the transport layer ever sees it, and the file stays diffable and greppable in a way a gzipped blob never will. You get the size win and keep the ability to eyeball a feed in your terminal.

The full write-up covers the rest of the engine: the "taps" that turn feed-less HTML pages into real feeds, "meshes" that merge multiple sources into one, and why one canonical model beats writing the same brittle scraper twice. It's here: https://mederic.me/blog/neurowire-docs-launch

If you have ever designed a wire format, what did you strip out first: the repeated strings, or the timestamps?

I Trained 700 Engineers on AI. The Tool Was Never the Problem.

Médéric Burlet — Sat, 04 Jul 2026 05:42:53 +0000

Every company I walk into has the same plan for AI adoption: buy the tool, book a workshop, send the calendar invite. Three weeks later usage has cratered, and nobody can say why.

I have run that training for more than 700 engineers across SIA, Maybank, Prudential, and Manulife. The pattern is boringly consistent, and it has almost nothing to do with the tool.

The mandate is the tell

A mandate from leadership buys you compliance during the workshop and reversion the week after. People nod, they do the exercises, and then they quietly go back to how they worked before. Compliance looks like adoption for exactly one day.

If your rollout is a tool announcement plus a generic workshop, expect a spike and a fade. That is not a motivation problem. It is a design problem.

What actually predicted whether a cohort stuck

One thing, above everything else: whether the training used the team's real work instead of toy examples.

Slides about prompting change nothing. Exercises built on the team's own codebase change behaviour, because people adopt what they have already used successfully under realistic conditions. A generic "here is how to prompt" session hands everyone material that is half relevant to their actual job.

Champions beat mandates

The other half is a person, not a policy. A respected peer who uses AI well and helps others is what sustains the change after the trainer goes home. I grow these champions deliberately in every engagement, because they are what keeps adoption compounding once the workshop energy is gone.

A mandate gets you a week. A champion gets you a quarter.

Your turn

Be honest: after your last mandated AI workshop, are you still using the thing, or did you drift back to the old way inside a month?

And if you drifted, was it really the tool that failed, or was there just nobody around to keep it alive?

The full post breaks down the three levers that separate a spike-and-fade rollout from durable change: role-specific tracks, real-work practice, and champions seeded inside the team.

Read the full post: What 700 trained engineers taught me about adoption

Why AI pilots stall before production

Médéric Burlet — Wed, 01 Jul 2026 03:44:59 +0000

Most enterprise AI pilots stall for the same reason: they were built to impress a steering committee, not to survive contact with a real delivery team. The pilot proves the model can do something. Production requires that people change how they work, that output is trustworthy under pressure, and that the system fits the existing pipeline. Those are organisational and architectural problems, not model problems. A better model does not solve them.

The demo trap

A pilot is judged on a single impressive run. Production is judged on the thousandth unremarkable one. The skills that win a demo (a clever prompt, a hand-picked example) are exactly the ones that do not generalise. Treat the pilot as the finish line and you discover the gap to daily use is far wider than the gap to the demo.

What production actually requires

Three things, none of which a model upgrade provides:

Architecture that fits your pipeline. AI has to live in the repos, review process, and ticket flow people already use. Bolted-on tools get abandoned.
Guardrails and evaluation. Output has to be trustworthy without a human double-checking every line. That means evals, review practices, and clear failure modes.
A change in how teams work. Adoption is a behaviour change. Without deliberate enablement, people revert to the old way the moment they get busy, which is always.

How to get past the stall

Start where delivery actually happens, not in a sandbox. Pick a real project, embed AI into the real workflow, and measure the change in throughput, not the wow factor. Grow internal champions so the practice compounds. The teams that reach production treated adoption as the goal from day one.

I wrote the full version, with the failure patterns broken down, here: Why AI pilots stall before production.

Typescript - T3 / Chakra UI Boilerplate

Médéric Burlet — Thu, 08 Jun 2023 14:14:34 +0000

Recently i've been working a lot with T3 stack.

I have loved using it but i've found tailwind to be too descriptive and thus wanted a version ready to use with chakra-ui.

crimson-med / t3-chakra-template

T3 template incorporating Chakra UI

Create T3 App

This is a T3 Stack project but that incorporates Chakra-UI and user login and password with prisma.

Installation

Run the installation with: yarn
Make a copy of .env.example to .env and fill in: NEXTAUTH_SECRET and NEXTAUTH_URL
Run the seeding to create users and posts: yarn migrate/seed you can find the passwords in: prisma/seed.ts
If you want to configure Discord Login you can add the API info in: .env and uncomment the discord config in src/server/auth.ts

Boilerplate Examples

This boilerplate shares a few different aspects of T3 while making a few changes.

Signin & Signup

This currently has nextauth which can integrate many login system: NextAuth.js

This template was also configured to allow signin / signup…

View on GitHub

For those unfamiliar with T3 it uses Next, NextAuth, Prisma, tRPC and in this case Chakra-UI.

For now it supports simple signup / signin with username and password.

A simple data seeding script creates 3 users with some random posts.

You can see your own posts once logged in.

All default passwords are in the seed file.

Burlet Mederic

https://twitter.com/crimson_med

Create Random team names for projects

Médéric Burlet — Tue, 22 Mar 2022 08:26:55 +0000

Introduction

Here at Pixium Digital we often need to create sets of random usernames or team names.

This is either due to bench-marking with a need to simulate individuals groups or users.

Or for a need to anonymize leader-boards in various applications. This can be due to the fact that some applications have big firms as client that they want to keep anonymous hence we generate a random team or group name that can be displayed publicly without risking information leakage.

For this we have decided to build a small library that we can re-use to help us generate this content easily.

Basics

We first started to create a list of various information we would need. This includes adjectives, nouns, gamertags, colors, extended colors.

You find the more detailed list here:

https://github.com/pixiumdigital/random-namer/tree/master/src/data

We then wanted to create the possibility to add an ID at the end of the random generated content (discord like) so we could have a result like this:

myC00lUsername#3948
thundering-memory#8682

For this we used a little trick of Math.random()

/**
 * Generates a random ID (discord style)
 * @returns string
 */
export const randomId = () => {
    return Math.random().toString().substring(2, 6)
}

Formats

Most of the random lists will be in the following format string[] however there will be specifications. For example teams will be composed in this format:

adjective-noun

For example:

[
    'icy-dinosaurs',
    'mighty-scarecrow',
    'aquatic-squirrels',
    'defiant-camp',
    'natural-memory'
]

Then we have the Extended Colors which are of the following format:

interface ExtendedColor {
    id: string
    name: string
    hex: string
    r: number
    g: number
    b: number
}

Usage

To use the library you simply need to do the following:

yarn install @pixium-digital/random-namer

Then you can use it like this:

import { RandomNamer, RandomType } from "@pixium-digital/random-namer"

const list = RandomNamer(RandomType.TEAM, { toGenerate: 3, allUnique: true, addId: true })
// ['voiceless-sea#4457', 'delicate-star#6563', 'even-nest#9988']

const list = RandomNamer(RandomType.GAMERTAG, { toGenerate: 2 })
// ['The Best Yoda', 'I_Cant_Play']

Link

pixiumdigital / random-namer

Simple random name generator for various utilities

Random Namer

This project aims to simply provide random usernames, team names, gamertags, adjectives, colors to use in testing data.

Installation

yarn install @pixium-digital/random-namer

Usage

import { RandomNamer, RandomType } from "@pixium-digital/random-namer"
const list = RandomNamer(RandomType.TEAM, { toGenerate: 3, allUnique: true, addId: true })
// ['voiceless-sea#4457', 'delicate-star#6563', 'even-nest#9988']

const list = RandomNamer(RandomType.GAMERTAG, { toGenerate: 2 })
// ['The Best Yoda', 'I_Cant_Play']

Here is the list of random types that can be passed:

export enum RandomType {
    ADJECTIVE,
    COLOR,
    EXTENDED_COLOR,
    GAMERTAG,
    NOUN,
    TEAM,
}

Here are the parameters available to pass to the function

{
    toGenerate: number // Number of items to generate
    allUnique?: boolean // Should the generated items be unique?
    addId?: boolean //

…

View on GitHub

Pixium Digital - Shaping your project with technology and innovation
https://pixiumdigital.com
https://github.com/pixiumdigital

DEV Community: Médéric Burlet

An AI detector flagged my draft 97% machine. The rewrite scored 0%.

I shipped 40 cyberpunk UI components. The neon was the easy part.

10 small AI wins that quietly give you your afternoon back

My feed format is "62% smaller than JSON Feed." That number is a cop-out.

The 30-second check that catches a confidently wrong AI

Your best AI demo is a vanity metric

I vetted 271 RSS sources so you don't have to hunt them down

3 tricks that made my feed format 62% smaller than JSON Feed

I Trained 700 Engineers on AI. The Tool Was Never the Problem.

The mandate is the tell

What actually predicted whether a cohort stuck

Champions beat mandates

Your turn

Why AI pilots stall before production

The demo trap

What production actually requires

How to get past the stall

Typescript - T3 / Chakra UI Boilerplate

crimson-med / t3-chakra-template

T3 template incorporating Chakra UI

Create T3 App

Installation

Boilerplate Examples

Menu

Signin & Signup

Create Random team names for projects

Introduction

Basics

Formats

Usage

Link

pixiumdigital / random-namer

Simple random name generator for various utilities

Random Namer

Installation

Usage