DEV Community: Médéric Burlet

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

How we handled 350+ online connections on a video game

Médéric Burlet — Mon, 20 Sep 2021 03:21:28 +0000

We were working with a client on building a video game that had multiplayer integrated.

The game is more of a tabletop turn based game (think monopoly, life). We had to make sure turns and actions were synchronized across the board.

Furthermore we had the restraint that only one of the players is essentially the one enables to perform the actions. This means we had to account for scenarios where the client would be disconnected and we had to pass the power of decision to another user.

Choosing the stack

Having had some experience with game jams and other multiplayer games we decided to go with a typescript server leveraging Socket.IO

This would let use easily create a client / server using the same typescript types for exchanging data information.

Session Context

Introduction

First we wanted to setup our context. This means we could then interact with any game session or client data throughout any Socket.IO event.

export class SessionContext {
    activeSessions: Record<string, GameSession>
    clientSockets: string[]
    constructor () {
        this.activeSessions = {};
        this.clientSockets = [];
    }
}

Here we can see our context is consisted of activeSessions and clientSockets

clientSockets is just an array of strings of the ids of each clients connection. This is used later on on handling disconnection.

activeSessions are were we have a list of game session. We use here the type Record as this lets us access information on a faster scale with just the following:

const mySession = sessionContext.activeSessions[sessionId]

Our class then had a few extra functions that don't need explanation such as (addActiveSession, getSessionByClientSocket, etc.)

Handling Disconnections

It was important for us to handle disconnections as if a client in power gets disconnected we want to give that power to someone else.

This is where the clientSockets comes in as it lets us do a difference with the list of clients handled by Socket.IO. This is needed as the disconnect event does not tell us exactly who disconnected.

We can then have something like this:

reconcileDisconnect(ioClients: string[], io: SocketIO.Server) {
    // Compare the list of the IO Server clients vs the one we stored
    const disconnectedClient = this.clientSockets.filter(x => !ioClients.includes(x));
    // If we have more than one disconnected user then we have discrepancy
    if (disconnectedClient.length > 0) {
        // Loop through all the disconnected clients
        for (let i = 0; i < disconnectedClient.length; i++) {
            // Init local variables for easy access
            const tmpClient = disconnectedClient[i]
            const sessionOfDisconnected = this.getSessionByClientSocket(tmpClient)
            // If disconnected client was in a session
            if (sessionOfDisconnected) {
                const tmpSession = this.activeSessions[sessionOfDisconnected]
                console.log("GM : " + tmpSession.master);
                // Remove him from the GameSession Client list
                delete tmpSession.clients[tmpClient]
                // Remove him from the global pool of connections
                this.clientSockets.splice(this.clientSockets.indexOf(tmpClient), 1)
                // Check if there are no more clients in the GameSession
                if (Object.keys(tmpSession.clients).length <= 0) {
                    // Delete GameSession if there are no more users
                    delete this.activeSessions[sessionOfDisconnected]
                } else {
                    // Check if he was has power
                    if (tmpSession.hasPower === tmpClient) {
                        // Log a message if we switched master
                        if (tmpSession.switchMaster()) {
                            log(`Power of the Session (${tmpSession.hash}) has been changed to Client (${tmpSession.hasPower})`);
                            let newPowerClient = tmpSession.getClientFromSocketId(tmpSession.hasPower);
                            tmpSession.broadcast({ type: "newGameMaster", query: newPowerClient.hash }, io, true);
                        }
                    }
                }
            }
        }
    }
}

And we now have a new person in power or our session deleted if the person was the last user in the session.

Conclusion

We have a few other functions for getting and setting information but the main point of this article was to show how to handle identity of disconnections and how to access data efficiently using context.

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

Deploying React with Express with route integrity

Médéric Burlet — Wed, 25 Aug 2021 03:36:34 +0000

Background

As you may or may not know React often uses routing through the browser history API

A few of the common libraries that you might encounter would be:

React Router DOM: https://www.npmjs.com/package/react-router-dom
Wouter: https://www.npmjs.com/package/wouter (personal favorite)

These libraries will let you define routes and which components are being rendered.

Quick Example:

<Route path="/about"><AboutPage/></Route>
<Route path="/user/:id">
    {params => <UserPage id={params.id} />}
</Route>

Running this in dev mode will work fine.

Issue

If you build the react app and try to host it with express you'll notice we run in an issue:

import * as express from 'express'
const app = express()
app.use(express.static(configuration.buildDirectory));
app.listen(8080, () => {
    console.log(`Server started on port 8080`);
});

If you navigate to http://127.0.0.1:8080 you'll see your react app.

However if you navigate to http://127.0.0.1:8080/about

You will receive an error:

Can't GET /about

Solving the Issue

Our issue comes from the fact that express will only allow the route '/' to be used.

The idea is that we want to preserve the routes but still display our built index.html

For this we can add the following statement:

app.all('*', (req, res) => {
    res.sendFile(path.join(configuration.buildDirectory, '/index.html'), (err) => {
        if (err) {
            res.status(500).send(err)
        }
    })
});

This means that for every route we will render the index.html however since we are not redirecting we will preserve the URL scheme.

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

DEV Community: Médéric Burlet

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

How we handled 350+ online connections on a video game

Choosing the stack

Session Context

Introduction

Handling Disconnections

Conclusion

Deploying React with Express with route integrity

Background

Issue

Solving the Issue