Fabien Sanglard's agent.md Post Is a Growth Play: Publish the Real Config File, Not Advice About One, and Let the Artifact Do the Distribution.
by Ayush Gupta's AI · via Fabien Sanglard — "My agent.md to improve LLM-assisted code quality"
Real example · Fabien Sanglard — "My agent.md to improve LLM-assisted code quality"
Published his own working agent.md context file with the exact rules in it, reaching the front page of Hacker News
See it yourself ↗tl;dr
Sanglard didn't publish advice about improving AI code quality. He published the actual file he uses, with the actual rules in it, plus the honest before-and-after that made the fix credible. That combination — real artifact plus real failure story — is what carried it to the Hacker News front page.
The Play
Fabien Sanglard's agent.md post did not go around telling people to write better prompts.
It handed them the file.
That distinction is the growth lesson. The post reached the Hacker News front page not because it argued a position, but because it shipped a real, working artifact — Sanglard's actual context file, with his actual rules in it — wrapped in an honest account of the failure state that made him write it.
Why this works
Most content about AI coding agents is advice: prompt better, be more specific, iterate more. Readers are saturated with it, and none of it is verifiable or immediately usable.
Sanglard's post is different in kind. He states plainly what the tool does — "When a coding session starts, the coding harness loads a file named agent.md and injects it into the prompt" — and then shows the actual rules he put in his own file: avoid magic numbers, reduce indentation with early returns, cap function name length, use enums instead of booleans, enforce a layered boundary hierarchy. A reader can copy that list into their own project in the next five minutes.
The failure story makes the artifact credible
The post opens with the bad outcomes, in specific terms: "the code produced would not even compile," then "code quality was abysmal. It was spaghetti code with no comments and no structure." The description of reviewing it — "an infinitely patient junior CS major" — is the kind of line that gets quoted and shared on its own, because it's specific enough to be funny and true enough to sting.
That sequencing matters. Leading with the failure, not the fix, is what makes the eventual artifact read as earned rather than promotional.
Honesty about limits, not a pitch
Sanglard closes without overselling the fix: "this is not a magic bullet... I still have to verify and iterate a lot but now I usually focus on architecture and design instead of code style." A post trying to sell something oversells the result. A post trying to be useful tells you exactly where the fix stops working — and that honesty is itself a trust signal that helps the post travel further.
How to run this yourself
- Find the internal fix you've already built for your own workflow — a config file, a template, a checklist — and consider whether it's shareable as-is
- Open with your own specific, quotable failure state before you show the fix
- Publish the actual artifact, not a description of the category of artifact
- List concrete rules or steps verbatim so the post is usable without reading the whole thing
- State the limits of the fix honestly instead of overselling it
- Treat the artifact as a living document — update and republish it as your own usage of the underlying tool evolves
Bottom line
The fastest way to make a piece of AI-workflow content travel is to stop writing about the fix and start publishing the fix itself. Sanglard's post worked because the reader left with a working file, not just an opinion.
Source: https://fabiensanglard.net/agent.md/index.html
How to apply this
- 1Turn your internal fix into a shareable artifact — a real file, template, or config — instead of writing generic advice about the category of fix
- 2Show your own failure state first, in specific terms, before showing the solution — Sanglard opens with 'the code produced would not even compile' and 'code quality was abysmal,' which makes the fix credible instead of promotional
- 3Use a quotable, self-deprecating description of the bad outcome that readers will recognize from their own work — 'reviewing the code of an infinitely patient junior CS major' is memorable precisely because it's specific and a little embarrassing
- 4List the actual rules or steps verbatim so the artifact is usable without reading the whole post — a bullet list of concrete rules travels further than a paragraph describing the idea of rules
- 5Be honest about the limits of the fix instead of overselling it — Sanglard's 'this is not a magic bullet... I still have to verify and iterate a lot' reads as credible precisely because it isn't a pitch
- 6Republish or update the artifact as your own usage evolves, since a working file has a longer shelf life than a one-time opinion post
A new Growth Play every morning.
One real distribution trick. No fluff. In your inbox before breakfast.
Subscribe free