Flow PHP — Telemetry — Norbert Orzechowicz
An interesting write-up on why the creator of Flow PHP decided to build his own telemetry library rather than adopt the existing OpenTelemetry PHP SDK. The core problem was dependencies: the OpenTelemetry SDK alone would have nearly doubled Flow’s dependency count. But beyond that, the API relies heavily on global state and singletons designed for auto-instrumentation convenience, a design fundamentally at odds with Flow’s architecture. The result is flow-php/telemetry, a non-invasive library that depends mainly on contracts, ships lightweight in-memory and void implementations for testing, and bridges to OTLP through a separate package that serialises to JSON or Protobuf and sends via curl, gRPC, or HTTP. PHP’s OpenTelemetry adoption is notably behind Java and .NET, and this is a thoughtful take on why and what can be done about it.
Hoard Things You Know How to Do — Simon Willison (Agentic Engineering Patterns)
The first of three chapters I’m linking from Simon’s new guide, and the one that resonates most with me. The idea: build and maintain a personal collection of working code examples, because coding agents mean you only ever need to figure out a useful trick once. If that trick is then documented somewhere with a working code example, your agents can consult that example and use it to solve any similar-shaped project in the future. The OCR + PDF.js example he walks through is a good illustration: two snippets he already had, combined into a full working tool in minutes by telling the agent to use both. This is an underrated leverage point in the current tooling landscape.
Interactive Explanations — Simon Willison (Agentic Engineering Patterns)
The second chapter worth bookmarking, and probably the most immediately actionable one for anyone who has ended up with a codebase full of agent-written code they don’t fully understand. The framing: when we lose track of how code written by our agents works, we take on cognitive debt. If the core of our application becomes a black box we don’t fully understand, we can no longer confidently reason about it, which makes planning new features harder and eventually slows our progress in the same way that accumulated technical debt does. His solution is to ask the agent to build an animated, interactive explanation of the algorithm in question. The word cloud visualiser he uses as an example, where you can watch the spiral placement algorithm try different positions in real time, is a compelling demonstration of how far this technique can go.
GIF Optimization Tool Using WebAssembly and Gifsicle — Simon Willison (Agentic Engineering Patterns)
The third chapter, this time an annotated prompt walkthrough rather than a conceptual pattern. Simon uses a GIF optimisation tool as a case study, breaking down each part of the prompt sentence by sentence and explaining the reasoning behind every word. Coding agents are fantastic at trial and error, they can often brute force their way to a solution where a human would have given up after the fifth inscrutable compiler error. Saying “Compile gifsicle to WASM” is doing a lot of work, because compiling a project like Gifsicle to WebAssembly involves a complex toolchain that involves a lot of trial and error to get working. The section on giving the agent a browser automation tool for testing while it works is also worth noting, a pattern I want to adopt more consistently.
Use Laravel’s Built-in SetUp Hooks for Application Test Traits — Paul Redmond (Laravel News)
A small but genuinely useful discovery in the framework internals. Laravel’s setUpTraits() method loops through all traits on a test class and checks for the existence of a setup or teardown method that matches the trait name, so a MyUsefulHelper trait will automatically trigger setUpMyUsefulHelper() and tearDownMyUsefulHelper() without any explicit setUp() override needed. If you have test helpers that need setup boilerplate scattered across multiple test classes, this is the clean way to centralise it.
Speed Up Your Livewire Tests — Michael Dyrynda
Very short, very immediately useful. The difference between fill and set in Livewire tests is that fill triggers one Livewire round-trip per field, while set only triggers one total. Switching from fill to set reduced a full test suite from around 22 seconds, with many tests in the 0.9 to 1.3 second range, down to around 4 seconds. The kind of thing that’s completely invisible until you notice your suite is hanging, then obvious once you see it.
Joy & Curiosity #76 — Thorsten Ball (Register Spill)
Thorsten’s weekly link digest is one of my regular reads, and this edition has a particularly good lede. He found himself writing code by hand, ten or twenty lines in total, and was asked at a conference: “You just told us agents can work well with a longer leash, yet you wrote code by hand, how come?” His answer: writing code by hand is one way to learn what the software is actually supposed to do, because you truly bump into what you don’t know when you have to type something out. An agent is happy to pick an answer for you, without telling you. The rest of the digest is dense with good links, including the Ladybird Rust port approach, a piece on cognitive debt in AI-assisted codebases, and a sharp hiring process update for the AI era.
Evaluating Frameworks for Mobile Performance — Chris Coyier (Frontend Masters Blog)
A quick pointer to Loren Stewart’s detailed experiment building the same kanban app ten times in different frameworks to measure mobile web performance. All the frameworks have an instant initial load, but bundle sizes differ substantially. Tanstack Start is 35% smaller than Next.js while staying on React. SolidStart retains JSX but leaves React for Solid. Marko has the smallest bundle size and an MPA approach with streaming HTML. Best developer experience is SvelteKit. Worth bookmarking the underlying comparison repo if you’re making framework decisions for mobile-first projects.
Using systemd Units for Cronjobs and Background Processes — Command-G
A clear, practical guide for running Laravel cronjobs and queue workers with systemd instead of Supervisor and crontab. The advantages are real: systemd offers dependency management to ensure your queue worker starts after MySQL or Redis have started, centralised logging via journalctl, and the ability to limit resources like CPU and memory per unit, useful when multiple apps are running on one server. The pattern of separating the cron trigger into a .timer unit and the actual work into a .service unit is slightly more verbose than a crontab entry but pays off in debuggability and control.
We Deserve a Better Streams API for JavaScript — James M Snell (Cloudflare Blog)
A long, technically dense read, but one of the most interesting pieces of platform engineering writing I’ve seen this year. Snell, one of the core Node.js maintainers, argues that the WHATWG Web Streams specification has fundamental usability and performance problems that can’t be fixed incrementally, and proposes an alternative API built around async iterables. In benchmarks, the alternative runs between 2x and 120x faster than Web streams across every runtime tested, including Cloudflare Workers, Node.js, Deno, Bun, and every major browser. The improvements are not due to clever optimisations, but fundamentally different design choices that more effectively leverage modern JavaScript language features. The section cataloguing the real-world failure modes of the current API, the tee() memory cliff, BYOB complexity, broken back pressure, is worth reading even if you don’t follow the full proposal. This is the beginning of a standards conversation, not a finished proposal.