About
A publication for engineers who want the reasoning, not the recipe
fellowcoder covers AI engineering, systems, and software craft — written by people who ship, for people who ship.
There is no shortage of writing about AI and software right now. Most of it falls into two piles: marketing dressed as engineering, and tutorials that stop exactly where the interesting problems start. This site aims at the gap between them.
Articles here assume you can already write code. They skip the setup boilerplate you can get from any README and spend their length on the part that actually took someone three days to work out — the retry semantics, the cache invalidation, the prompt that looked fine until it met real users.
What gets published
Two formats. Articles are essays and deep dives: a problem, the approaches considered, and what held up. Tutorials are build-alongs that end with something running on your machine, with every command shown and every dead end labelled.
Topics cluster around AI engineering (retrieval, evaluation, agent design, context management), the systems work underneath it (queues, caching, databases), and the craft that keeps a codebase workable after the first year.
Editorial standards
These are the rules pieces are held to before they go out. They are the reason articles take a while.
Ship small
Every technique here has been run, not just read about. If a snippet is untested, it says so.
Measure honestly
Benchmarks come with the machine, the sample size, and the version numbers. Wins that vanish under scrutiny are not wins.
Read the source
Documentation drifts. When behaviour and docs disagree, we go to the implementation and quote it.
Name the tradeoff
There is no free abstraction. Each article states what the approach costs, and when to reach for something else.
Process
How a piece gets made
Build the thing
An article starts as a real problem in a real codebase — never as a keyword with an audience attached.
Strip it to a reproduction
The example gets cut down until only load-bearing code remains, then rebuilt from scratch to prove nothing is missing.
Write the reasoning, not the recipe
Steps are cheap. The valuable part is why this shape and not the four obvious alternatives.
Break it on purpose
Before publishing, we push the approach until it fails, and document exactly where the edge is.
Corrections and contributions
Found something wrong? Corrections are edits, not footnotes — the article gets fixed and the change is noted. Open an issue or a pull request; every piece on this site lives in the same repository as the site itself.