Signals

The signals we quietly relied on to judge competence, like clean code, confident writing, and fast turnaround, used to be expensive enough that they carried information; now they are cheap and they carry none. What I keep thinking about is that we have not yet replaced them, so hiring and review are running on instruments that stopped working.

The clearest answer I have found to whether something should be an agent or a fixed workflow: if the steps are known in advance, write a workflow; if the decision tree only opens up at runtime, write an agent. Reading this made me realise that half of my own setups were agents for no good reason.

The argument is that instead of building agent-specific tools, you should let agents use the tools humans already use, because the documentation, error messages, and community knowledge for those are already in the model’s training. Writing your own wrapper throws all of that away and replaces it with an interface nobody has ever seen.

Treats low-quality agent output as an engineering problem rather than a model-quality one: if the rules are not written down, the checks are not automated, and there is no feedback loop, bad output is not surprising. For me the concrete answer to this turned out to be the pnpm verify command itself.

A long thread of the posts that genuinely changed how working engineers think, which is a different list from the posts that were popular. Worth reading for the pattern as much as the links: almost none of them are tutorials, and almost all of them reframe something the reader already knew.

The moment the model runs faster than your CI, the constraint on your product is no longer the model but the CI, which means the build time you have been deferring for years suddenly becomes the priority. After reading this I looked seriously at my own pipeline durations for the first time.