Claude Code Now Posts to This Blog — Brad Feld
Short, practical, and exactly the kind of thing I want to be doing more of. Brad built a /blog-feld command in Claude Code that handles the whole posting workflow: look at whatever is being discussed in the current conversation, assemble it into a post, edit interactively, and push it to WordPress as a draft, never publishing directly. The whole setup took about ten minutes. The observation that stuck with me most: thinking-in-conversation and writing-for-the-blog are the same thing now. The friction of the last step, copy, paste, reformat, fix the formatting that broke, is gone. Worth reading as a small concrete example of what it looks like when your tools start collapsing together in useful ways.
Nobody Rips Out the Plumbing — Regionally Famous
A well-argued defence of WordPress in the AI era that makes a point I haven’t seen put this cleanly before. The argument is simple: when you renovate a house you rip out the ugly kitchen, tear down a wall, repaint everything. What you don’t do is rip out the plumbing. You don’t tear out the electrical. WordPress is the plumbing, content management, user accounts, media library, SEO, contact form submissions, client-editable pages. All the invisible, boring, essential stuff that AI-generated frontends still need behind them. The historical pattern he traces is also worth noting: mobile was going to kill WordPress, then Wix, then JAMstack. Every time, the pattern is the same: someone declares WordPress dead, WordPress absorbs the thing that was supposed to kill it, and WordPress gets bigger.
Data Provider or Properties? — Sebastian Bergmann (phpunit.expert)
From the creator of PHPUnit himself, a clear explanation of when to use data providers versus property-based testing, two tools that look similar on the surface but solve fundamentally different problems. The conceptual distinction is clean: data providers answer “what should happen with this specific input?” while properties answer “what general statements must apply to all inputs?” Data providers document your current state of knowledge. Properties plus generators help uncover the gaps in that knowledge. There’s also a technical gotcha in here that I hadn’t thought about before: with data providers, PHPUnit creates a fresh instance of the test class for each data set. With property-based tests, all iterations run in a single test context, setUp() and tearDown() are only called once, so isolation between iterations is not automatically guaranteed. His recommended strategy: use both, and when property-based tests find an interesting counterexample, promote it to an explicit data provider test as a regression case.
Context Engineering for Coding Agents — Birgitta Böckeler (martinfowler.com)
A thorough, clear-headed primer on the current landscape of context configuration for coding agents, published on Martin Fowler’s site. The framing I found most useful is the distinction between instructions (“write an E2E test in the following way”) and guidance (“always write tests that are independent of each other”), and between context the LLM decides to load versus context triggered deterministically. One of the goals of context engineering is to balance the amount of context given, not too little, not too much. Even though context windows have technically gotten very large, that doesn’t mean it’s a good idea to indiscriminately dump information in there. An agent’s effectiveness goes down when it gets too much context, and too much context is a cost factor as well. There’s also an honest warning tucked in at the end: despite the name, this isn’t really engineering, once the agent gets all these instructions, execution still depends on how well the LLM interprets them. Context engineering can increase the probability of useful results, but as long as LLMs are involved, we can never be certain of anything.
No More Code Reviews: Lights-Out Codebases Ahead — Philip Su (Molochinations)
A deliberately provocative piece that I think earns its provocation. The core argument: code reviews aren’t just impractical, they’re becoming impracticable. When a developer lands 417 PRs in a single day, and typical productivity boosts with AI are running 5-20x, the volume of code being produced simply cannot be reviewed by humans. You become the rate-limiting step, and you will tire of the deluge. His vision of the endpoint is “lights-out codebases”, fully automated, where no human ever sees the code, verified entirely through tests and AI-checking-AI. His two most recent apps are both lights-out codebases where he hasn’t seen or edited code at all, from creating the GitHub repos all the way through releasing to production. He’s honest about how unsettling he finds this even as he argues for it, and the comments section has some excellent pushback worth reading, particularly around whether AI can capture the tacit domain knowledge that code review was always quietly encoding.