DEV Community: Mael Bourdin

Our AI coding agents ignored their instructions for a month. Nothing errored.

Mael Bourdin — Fri, 16 Oct 2026 07:00:01 +0000

In August we wrote a careful instructions file for the coding agents that work in our repository. How to run the checks, what is unsafe to run locally, which database the dev server really talks to, how to name commits. Hard-won knowledge, written down once so nobody had to learn it twice.
For a month, no agent read a single line of it.

How instructions silently disappear

The agent tool we use reads one file automatically at the root of the repository. Anything else only loads if that file imports it with a single line. Our root file did not have that line.
Nothing failed. No warning, no error, no missing-file message. The agents simply did their work without the rules, and because they are capable, most of that work looked fine. The damage was the kind you only notice later: a check skipped here, a convention ignored there.
We found it by asking an obvious question very late: "what exactly is loaded when a session starts?"

The fix was one line. The guard is a test.

Adding the import took ten seconds. The interesting part is what we did next. We wrote a test that fails if that import line ever disappears again. It runs with the rest of the suite.
The general lesson: if a piece of configuration matters and fails silently, it needs a test, not a reminder. We now treat agent instructions like any other config. They are code that can break, so something has to notice when they break.

Errors are read by agents now

Writing that test changed how we write every check. A message like expected false to be true is useless to a human and worse for an agent, which will happily guess at a fix.
Our rule is that a failing check prints the file name and the fix. For example, a docs test fails with the path of the dead link and the file it was found in. A config test fails with the name of the CI job that drifted and the command it should run. When the reader of your error message is another program, the message is the interface.

One command, one exit code

The same principle shaped our quality gate. There is a single command that runs types, formatting, lint and the full test suite. It runs every gate even when an earlier one fails, so one run tells you everything that is wrong, and it finishes by printing the command that re-runs just the broken part.
Two details turned out to matter more than expected:

It never stops early. An agent that fixes the type error, re-runs, then discovers a lint error, then a test failure, burns three cycles on what one run could have reported.- The exit code is trustworthy. If you pipe the output into something else, the pipeline returns the last command's status, not the gate's. We wrote that trap into the instructions file, which is now actually loaded.## Things that fail without failing The missing import was not our only silent failure. Two others from the same period:
A CI workflow file that was valid YAML but referenced a job we had deleted. GitHub rejected the whole file at startup, reported a failure with zero jobs and no log, and it stayed red through two more merges. We now run a workflow linter that catches exactly this.- A nightly test run that was red sixteen nights in a row while nobody acted on it. We removed it. A gate everyone ignores teaches the team that red is normal, which is worse than having no gate.The pattern in all three: the system was quiet when it should have been loud. Most of the work was not fixing the bug. It was making sure the next one makes noise. ## If you use coding agents Check what actually loads at session start. Not what you think loads. Then write a test for the part you cannot afford to lose.

We deleted a fully tested feature 48 hours after shipping it

Mael Bourdin — Wed, 14 Oct 2026 07:00:07 +0000

On a Monday we shipped a feature to every organisation on our platform. It had a written spec, a careful implementation and a full test suite. On Wednesday we deleted it.
Nothing was broken. The feature worked exactly as designed. The problem was simpler and more expensive: nobody needed it. The table sitting right next to it on the same page already answered the question it was built to answer.
This post is about what we changed in how we decide what to build, because a good test suite turned out to be no protection at all against this kind of mistake.

Tests answer "does it work", not "should it exist"

Our feature was a comparison panel for the prompts our customers track. You could pick two prompts and see them side by side. It looked useful in the spec. It was useful in isolation. But the prompts table already showed every prompt with the same columns, sortable, in one place. Comparing two rows of a table is something people already know how to do.
Every check we had was green. Types, lint, unit tests, component tests. None of them can fail on "this duplicates something users already have", because that is not a property of the code. It is a property of the product.
The only place that question can be asked is before the work starts.

The filter we use now

Before an issue gets scheduled, we ask one question: what data does this need, and do we already hold it? The answer sorts every idea into one of four buckets.

We hold the data and do not show it. The cheapest work there is.- We show the data wrongly. Cheap, and it is where trust is won or lost.- We do not hold it, but we can derive it from data we already fetch.- We do not hold it and must start collecting it. A new pipeline, a vendor, or setup on the customer's side.Buckets 1 and 2 are where credibility comes from. Bucket 4 is where features get built and then deleted. So bucket 4 work now needs a named customer who asked for it, not an inference from a competitor's feature list. ## The red 0% The same week, we fixed a bug that shows the other side of this. Every prompt that had never been tested displayed a red 0% in the dashboard. To a customer, that reads as "you are invisible here". In reality it meant "we have not measured this yet". Those are very different statements, and the dashboard was making the wrong one to every customer. The fix was to render a count we already stored on every row. One field, one afternoon. A number that had been lying started telling the truth. No new pipeline, no new screen. That is a bucket 2 fix, and it did more for user trust than the comparison panel ever could have. ## An empty table is not a missing feature One more lesson from the same period. Someone opened an issue asking us to show device, browser and country on a visitor card. The whole pipeline already existed. It had shipped a few hours earlier. The table simply had no rows yet. If you look at production data and see nothing, check when the code that fills it shipped before you conclude it does not exist. It is an easy mistake, and it is how teams end up building the same thing twice. ## Three checks before we write an issue
Is it already fixed? Our issues only auto-close from the release branch, so open issues routinely describe work that already shipped.- Is it already built? See the empty table above.- Which bucket is it? If it is bucket 4, name the customer.## What we did not do We did not add a process document with approval steps. Process tends to grow into the thing it was meant to prevent. The filter is a single question that anyone on the team, or any coding agent working in the repo, can ask in thirty seconds. We also did not stop building new things. We just stopped pretending that "well tested" and "worth having" are the same claim. If you have deleted a feature shortly after shipping it, I would like to hear what tipped you off.

AI crawlers and robots.txt: a practical guide for developers

Mael Bourdin — Sat, 10 Oct 2026 07:00:11 +0000

A surprising number of sites block the exact AI crawlers they would like to be cited by, usually because someone copied a robots.txt snippet during the "block all AI" wave and never revisited it. Here is how to think about it as a developer, without breaking anything.

Not all AI crawlers do the same job

The key distinction: some bots collect content to train models, others fetch pages to answer a user's question right now. Blocking them has very different consequences.

Training crawlers gather data used to build future models. Blocking them is a policy choice about your content.- Search and retrieval crawlers index or fetch pages so an assistant can cite them in answers. Blocking them can remove you from those answers.- User-triggered fetchers visit a page because a user asked the assistant to read it.Major providers document separate user agents for these roles. OpenAI, for example, documents GPTBot for training, OAI-SearchBot for search, and ChatGPT-User for user-triggered visits. Anthropic, Perplexity, Google and Apple publish their own lists. Check each provider's official documentation before you write rules, because names and roles evolve. ## Audit what you have today
Open /robots.txt on your production domain, not on staging.- Look for blanket rules like User-agent: * with Disallow: /, and for any AI-specific user agents.- Check your CDN or firewall too. Bot protection settings can block AI crawlers even when robots.txt allows them.- Check your server logs for these user agents to see who actually visits and what status codes they get.## A sensible default If you want to be cited in AI answers but prefer not to feed training, a common pattern is to allow the search and user-triggered agents and disallow the training ones. Conceptually:

User-agent: GPTBot
Disallow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: ChatGPT-User
Allow: /

Treat this as a pattern, not a copy-paste list. Confirm each user agent against the provider's current documentation, and remember that robots.txt is a request that well-behaved crawlers follow, not an access control mechanism.

Make the allowed pages worth fetching

Allowing a crawler is only half the job. Retrieval systems need content they can actually read:

Server-render important content. Text that only appears after client-side JavaScript runs may never be seen by some crawlers.- Return correct status codes. A soft 404 or a page that returns 200 with an error message wastes the visit.- Keep pages fast. Slow responses and timeouts mean the page gets skipped.- Use clean semantic HTML. Headings, lists and tables make passages easier to extract.- Keep a sitemap up to date so new pages get discovered.## What about llms.txt? llms.txt is a proposed convention: a Markdown file at your site root that points language models to your most useful pages. It is cheap to add and can help tools that support it, but support across engines is inconsistent, so do not treat it as a replacement for crawlable pages. ## Verify, then monitor After changing rules, watch your logs for the user agents you allowed, and confirm they receive 200 responses. Then check the outcome that actually matters: whether assistants start citing your pages. That last part is what CiteMe was built to track, across engines and over time. Robots.txt mistakes are silent. Nothing breaks, you just quietly disappear from answers. Ten minutes of auditing is worth it.

7 page types AI engines love to cite (and how to build them)

Mael Bourdin — Thu, 08 Oct 2026 07:00:03 +0000

When you look at the sources behind AI answers, the same kinds of pages keep showing up. Not homepages. Not vague "about us" pages. Pages that answer one question clearly enough that a model can lift a passage and move on.
Here are seven page types worth having, and what makes each one quotable.

1. The honest comparison page

People constantly ask assistants "X vs Y" and "alternatives to Z". A comparison page that is genuinely fair, including where a competitor is the better choice, gives the model exactly the material it needs.
Build it with: a short summary at the top, a comparison table, and a "who should choose what" section. Avoid pure marketing claims; models tend to skip them.

2. The definition page

"What is X?" is one of the most common question shapes. A page whose first sentence is a clean definition is easy to quote.
Build it with: a one-sentence definition, a slightly longer explanation, a concrete example, and links to related concepts.

3. The step-by-step guide

"How do I…?" questions get answered with steps. If your guide already has numbered steps with clear headings, the engine does not have to reconstruct them from prose.
Build it with: numbered steps, one action per step, the expected result after each step, and the common mistakes at the end.

4. The FAQ that uses real wording

A FAQ written with your customers' exact questions matches the way people talk to assistants. Pull the questions from support tickets, sales calls and community threads.
Build it with: the question as a heading, a direct answer in the first sentence, then detail. One question per entry.

5. The pricing and plans page, kept public

Assistants get asked "how much does X cost?" all the time. If your pricing sits behind a form or a login, the model will guess, or quote an old third-party page.
Build it with: plain text prices, what each plan includes, and the date of the last update.

6. The use-case page

"Best tool for [specific situation]" questions are where small brands can win. A page dedicated to one audience or one situation tells the model exactly when to recommend you.
Build it with: who it is for, the problem in their words, how you solve it, and a short real example.

7. The original data or research page

Numbers get quoted. If you publish a small study, a benchmark or a survey with a clear methodology, it can become a source that many answers lean on.
Build it with: the key findings at the top, the method explained plainly, the date, and the raw numbers in a table.

What all seven have in common

The answer comes first, the detail after.- One page, one main question.- Clear headings that read like questions or claims.- Facts that are easy to verify and kept up to date.- Server-rendered content that crawlers can fetch.## How to know if it works Publish, wait a few weeks, then ask the same questions again across several assistants and check whether your new page appears among the cited sources. If you want that on autopilot, CiteMe tracks which of your pages get cited, prompt by prompt. Either way, measure it: some page types will work much better than others in your market.

GEO vs SEO: what actually changes when AI answers the question

Mael Bourdin — Tue, 06 Oct 2026 07:00:01 +0000

Generative Engine Optimization, or GEO, gets described either as "SEO is dead" or as "nothing new, just do good SEO". Both are wrong. A lot carries over, but the goal, the unit of success and the way you measure it all change.

The goal: from a click to a mention

Classic SEO optimizes for a position in a list of links, and success is a click. In an AI answer there is often no list to rank in. There is a paragraph that names two or three options, sometimes with sources, sometimes without. Success is being one of the names, described correctly, ideally with a link.
That is a different shape of outcome. You can be cited without getting a click, and you can lose a sale without ever seeing the impression.

The unit: from a keyword to a question

People type short keywords into a search box. They type full, specific questions into an assistant: "what's a good CRM for a five person agency that already uses Google Workspace?". Small changes in phrasing can change which brands come back.
So instead of tracking a few hundred keywords, you track a set of realistic questions, grouped by intent. The question set becomes your main asset.

What carries over from SEO

Crawlability. If a crawler cannot fetch your page, no engine can quote it. Server-rendered content, clean HTML and sensible robots rules still matter.- Clear structure. Headings, short paragraphs and lists help retrieval systems extract the right passage.- Authority and mentions. Being referenced by trusted, relevant sources still helps, perhaps more than ever, because models echo what many sources agree on.- Answering the question. Pages that genuinely explain something keep winning.## What changes ### Passages matter more than pages Retrieval-based engines often pull a passage, not a whole page. A page that states its answer in the first two sentences of a section is easier to quote than one that builds up to it over six paragraphs. ### Entity clarity matters a lot Models need to understand what your brand is and what it does. If your site, your social profiles and the directories that list you describe you in different ways, the model's picture of you gets blurry. Repeating a consistent one-line description of your brand helps. ### Off-site content carries more weight Forums, community threads, comparison articles, review platforms and videos regularly appear among the sources of AI answers. Your own website is only one of the places that shape how you are described. ### Each engine behaves differently Some engines cite sources inline, some rarely do, some lean on fresh web results, some lean on what the model already learned. A strategy tuned for one assistant does not automatically transfer to another, which is why measuring across several engines matters. ## Measuring it Rankings do not translate to this world. The useful metrics look more like this:
Mention rate: on how many of your target questions are you named?- Share of voice: how often are you named compared with competitors?- Accuracy: is what the engine says about you true?- Cited sources: which pages are behind the answers, yours or someone else's?Tracking those by hand works for a first audit. Over time you want them on a schedule, across engines, with history, which is what tools like CiteMe do. ## The short version SEO taught us to be findable. GEO asks us to be quotable. Keep the technical basics, write pages that answer one question clearly, be talked about where models read, and measure mentions instead of positions.

How to check if ChatGPT recommends your brand: a 30-minute manual audit

Mael Bourdin — Sun, 04 Oct 2026 07:00:01 +0000

More and more people skip the search results page entirely. They open ChatGPT, Perplexity or Gemini, type a question like "what's the best invoicing tool for freelancers?", and pick one of the two or three names the answer gives them.
If your brand is not one of those names, you never even enter the race. The good news: you can find out where you stand in about thirty minutes, with nothing but a spreadsheet and a few AI assistants.

Step 1: write down the questions your customers actually ask

Forget keywords for a moment. AI assistants receive full questions, often with context. Write 15 to 20 of them, split into three groups:

Discovery questions: "what tools help with X?", "how do small teams handle Y?"- Comparison questions: "X vs Y", "alternatives to Z", "is X worth it?"- Problem questions: the pain your product solves, phrased the way a frustrated person would type it.The best source for these is your own support inbox, sales calls and the questions people ask in communities. Copy their wording, not your marketing wording. ## Step 2: ask every engine, in a clean session Run each question in at least three assistants. Use a fresh chat or a private window so your history does not bias the answer. For each answer, note:
Is your brand mentioned? Yes or no.- In which position: first name, second, buried at the end?- Which competitors are mentioned instead?- Which sources are cited, when the engine shows them?- Is what the engine says about you actually correct?## Step 3: build the table One row per question, one column per engine. Mark each cell with the brands named. After twenty questions, patterns appear fast:
Some competitors show up everywhere. Those are your real competitors in AI search, and they are not always the ones you watch on Google.- Some questions never mention you, even though you clearly answer them. Those are content gaps.- Some engines describe you with outdated information. That usually means an old page, a review site or a directory says something your website no longer says.## Step 4: look at the sources When an engine cites its sources, open them. You will often find the same small set of pages behind many answers: a comparison article, a Reddit thread, a review site, a well structured guide. Those pages are what the model is echoing. Two practical moves come out of this:
If a cited page is yours, keep it accurate and keep it alive. It is doing more work than your homepage.- If a cited page is not yours, ask yourself why it explains your category better than you do, and whether you should be mentioned on it.## Step 5: repeat it, because answers move AI answers are not stable. The same question can return different brands a week later, after a model update, a new article or a change in how the engine retrieves sources. A one-off audit is a snapshot, not a ranking. That is the part that gets tedious by hand: the same twenty questions, across several engines, every week, with the history kept somewhere. It is the reason we built CiteMe, which runs those prompts on a schedule and shows who gets cited instead of you. But start manually. Thirty minutes of asking the right questions will tell you more about your AI visibility than any dashboard you have never opened. ## A quick checklist
20 real customer questions, in their words- 3 or more AI engines, clean sessions- One table: brands named per question and engine- The cited sources opened and read- Errors about your brand listed and fixed at the source- A reminder to run it again next month