Database Indexing: The Missing Manual for WordPress — Delicious Brains
A thorough ground-up guide to MySQL indexing for WordPress sites that have grown past the point where the default schema handles load gracefully. For most sites, the default indexes provided by WordPress core are sufficient. However, as a site grows and the wp_postmeta and wp_options tables climb into the millions of rows, those standard indexes eventually hit a ceiling, a site might feel fast on the frontend due to page caching, but a crawling dashboard or a ballooning slow query log indicates a database that is struggling. The section on wp_options is particularly worth reading: WordPress queries every row where autoload = 'yes' on every single page load to populate the object cache. If the total size of autoloaded data exceeds the 1MB buffer limit, the cache layer may reject the request entirely, forcing WordPress to repeatedly query the database for the same massive dataset, often resulting in a loop of failed requests and 502 Bad Gateway errors. The guide also covers using EXPLAIN to confirm full table scans, partial indexes for meta_value, and when indexes hurt more than they help.
I Deleted My Source Code — Joppe De Cuyper
A provocative proof-of-concept that pushes the spec-as-source-of-truth idea to its logical limit. The experiment: a fully functional Symfony TODO API with an empty src/ directory. The repo contains spec files — plain language descriptions of features containing business logic and technical spec details, a SQL schema, and a large set of PHPUnit tests as the contract, defined as HTTP requests and assertions. In the CI pipeline, an AI agent reads all of it, generates the implementation, runs the tests, fixes potential failures, and continues until everything is green. The generated code never gets committed. It’s produced on demand, in CI, and thrown out on the next build. The observation I find most compelling isn’t about tooling, it’s about where knowledge actually lives. When a test fails, there’s no point fixing the generated code, it’ll be thrown away next run. The only meaningful fix is improving the spec or the test. You stop debugging implementations and start debugging intentions. Worth reading alongside the closing question he leaves with: if your specs aren’t precise enough to generate correct code from, are they precise enough to build correct code from by hand?
The AI Bubble Is an Information War — Ed Zitron (Where’s Your Ed At)
Ed Zitron’s newsletter is paywalled, but the free portion of this piece is worth flagging. The framing: last week the AI boom wilted under the weight of an NVIDIA earnings report that beat estimates but didn’t make anybody feel better about the overall stability of the industry. Zitron has been one of the more consistent sceptical voices on the AI hype cycle, not a denialist, but someone who keeps asking the revenue and unit economics questions that the industry press tends to skip. The “information war” framing refers to his argument that the dominant narrative around AI productivity and adoption is being actively constructed rather than reported. If you’re not already a subscriber and want more of this angle, the Better Offline podcast covers similar ground in a format that doesn’t require a subscription.
Rules for Writing Software Tutorials — Michael Lynch (Refactoring English)
A long, practical chapter from an upcoming book on writing for developers. The 17 rules are specific enough to actually change how you write, not vague advice like “be clear.” Some highlights that I keep violating myself: never include the shell prompt character ($) in copyable code snippets, because users can’t paste the sequence without picking up the $ character and breaking the command. On command-line flags: always use long versions of flags in tutorials, --recursive rather than -r. They’re more descriptive and make code easier to read, especially for beginners who haven’t memorized all of a tool’s flags. And on scope: a good tutorial should explain one thing and explain it well. People come to a tutorial because they want to learn one new thing, let them learn that one thing in isolation. Save this one and pull it up next time you’re writing a guide.
How to Write Blog Posts that Developers Read — Michael Lynch (Refactoring English)
The companion chapter to the tutorials piece above, and if anything more immediately applicable. The core diagnosis: the biggest mistake software bloggers make is meandering. Often the author has some valuable insight to share, but they squander their first seven paragraphs on the history of functional programming. By the time they get to the interesting part, everyone has closed the browser tab. The “think one degree bigger” section is the most actionable bit, the observation that most bloggers never ask whether a wider audience could find their post valuable, and that the set of all Java developers is about 10x larger than the set of intermediate and advanced Java developers, meaning small tweaks can expand the reach of an article by an order of magnitude. The section on planning the route to your readers, thinking through how anyone actually finds the post before you write it rather than after, is also worth sitting with.
How System Prompts Define Agent Behavior — Drew Breunig
A careful empirical piece co-authored with Srihari Sriraman, analysing and then swapping system prompts between six coding agents to measure how much the prompt determines behaviour independently of the underlying model. The headline finding: system prompts matter far more than most assume. A given model sets the theoretical ceiling of an agent’s performance, but the system prompt determines whether this peak is reached. The prompt-swap experiment is the most interesting part, running the same model (Opus 4.5) with Claude Code’s system prompt versus Codex’s system prompt and watching completely different working styles emerge: the Codex prompt produced a methodical, documentation-first approach, understand fully, then implement once. The Claude prompt produced an iterative approach, try something, see what breaks, fix it. There’s also a good section on how system prompts are actively “fighting the weights” — using all-caps admonishments and repeated instructions to override behaviours the model picked up from training data, like adding comments to code or making serial rather than parallel tool calls.
Teaching a Smol Model to Write SQL Queries — diicell
The best long-form technical post I’ve read this month. The author documents, in honest, sometimes chaotic detail, going from zero RL knowledge to training a Qwen3-4B model to correctly answer 84.8% of held-out SQL questions. The piece is structured as an Disco Elysium-style internal monologue with skill checks, which shouldn’t work but does. The reward function section is the real meat: the reward function went through five distinct designs. Each one fixed a problem and revealed the next one hiding behind it. The progression from binary hash comparison (which caused advantage collapse on harder questions) through partial credit scoring to a composite reward with multiplicative penalties is a masterclass in why RL is hard. The key insight: additive bonuses are suggestions, multiplicative penalties are laws. The model cannot shrug off a 0.15x multiplier, that’s having your entire paycheck docked. There’s also a great observation about watching Claude and DeepSeek reason between tool calls during eval runs, then reverse-engineering that behaviour into a reward signal so the 4B model would learn to do the same thing.