motyl.dev Weekly #20: Week 28 (Jul 6 – Jul 12, 2026)
A curated digest of what I found worth reading this week.
This week leans hard into the question of what we actually do all day now that machines write so much of the code. A few pieces poke at the metrics we use to judge AI, a few at the humans left holding the review queue, and a couple at the older, stranger idea that code was always a medium for thinking. A good mix to read slowly.
🤖 AI
Context engineering with Dex Horthy The term "prompt engineering" is quietly giving way to "context engineering," and this conversation makes a solid case for why. It's less about clever wording and more about what you feed the model, when, and in what shape.
Adversarial Machine Learning and Its Role in Fooling AI A grounded look at how models get tricked, from crafted inputs to poisoned training data, and why robustness is still an unsolved problem rather than a checkbox.
The Machines That Dream in Physics On models that learn physical intuition rather than just pattern-matching pixels, and what that shift means for simulation and scientific work.
💻 Coding
Announcing TypeScript 7.0 The big one. The native Go port lands as 7.0, promising the order-of-magnitude compile speedups the team has been teasing. If you maintain a large codebase, this is the release to plan around.
The Human-in-the-Loop is Tired A sharp piece on the quiet cost of making humans the safety net for every AI decision. When approval fatigue sets in, the loop stops protecting anything, and Pydantic's team argues for designing systems that respect that limit.
Code was our medium for thought Amelia Wattenberger reflects on what we lose when code becomes something we prompt rather than write. A thoughtful, beautifully made argument that the act of writing code was never just about the output.
🧪 Productivity
Introducing ReactBench A new benchmark aimed squarely at React performance work, giving teams a shared yardstick instead of ad-hoc profiling anecdotes.
📰 Other
Why Cost Per Token Is the Wrong AI Metric Cheap tokens can still add up to expensive systems. This piece argues we should be measuring cost per resolved task, not per token, and reframes a lot of the "which model is cheaper" debate along the way.
Curated by Grzegorz Motyl. Subscribe for weekly updates.