#150: The Work That Got Faster, and the Work That Didn't
Code is cheap now. Knowing what to build, and whether it's right, never was.
Meet the expert: Jeremy McEntire
For twenty-five years, Jeremy has built and led engineering teams at Intel, Twilio, and startups both scaled and failed. He currently leads engineering at Wander, with experience ranging from ten-person teams to organizations large enough to need committees to approve the committee structure. Alongside that work, he writes about the structural patterns behind organizational dysfunction, what he calls the legibility trap, the fiduciary trap, the context trap, and the scale trap, drawn from failure modes he’s seen firsthand across startups, scale-ups, and public companies. His focus is helping leaders see their organizations as systems rather than slogans, and build structures that respect the real cognitive and communication limits of the people inside them.
There’s a strange thing happening on engineering teams right now, and most people who are living through it can’t quite name it. AI coding tools have made writing code faster than it has ever been. Ask for a function, a component, an entire feature scaffold, and it appears in seconds, syntactically correct and reasonably named. And yet a lot of teams that have adopted these tools aggressively are not shipping meaningfully faster. Some are shipping slower. The output looks like progress. The delivery numbers tell a more complicated story.
Earlier this year, a research group ran one of the first controlled studies on whether AI tools actually speed up experienced developers. They took sixteen seasoned open-source contributors, people with years of experience on codebases they knew intimately, and had them complete real tasks with and without AI assistance. Before starting, the developers predicted the tools would make them about twenty-four percent faster. Afterward, they reported feeling roughly twenty percent faster. When researchers measured the actual time taken, the developers had been nineteen percent slower.
That gap between what people believed and what actually happened is the real story here, more than the slowdown itself. Sixteen experienced engineers, working on projects they understood well, came away convinced the tools had helped. They hadn’t, and nobody could tell from the inside. That’s worth sitting with, because it points to something the industry has quietly misunderstood about what software engineering actually is.
Before we get into the details, here’s a TL;DR of what’s in store for today’s issue:
Generating and Verifying Are Not the Same Job
Writing code and checking whether that code is right are two very different mental activities. Writing code is generative and sequential, a stream you can ride. Checking code means holding an entire system in your head at once, a landscape you have to survey piece by piece. Making the stream move faster doesn’t shrink the landscape. It just means there’s more of it to cover.
This is why code review times and pull request sizes have grown substantially at organizations with heavy AI adoption. The bottleneck didn’t disappear when code got cheap to produce. It moved, and the new one is more cognitively demanding than the old one.
None of this means the tools are bad or that adopting them is a mistake. It means they behave like an amplifier rather than a fix. Teams with strong habits already in place tend to get genuinely faster with AI in the loop. Teams without those habits tend to get faster at accumulating problems. The tool doesn’t install discipline. It reveals whether you had any to begin with.
Context Sets the Ceiling, Not the Model
There’s a second, quieter shift happening alongside this one, and it has to do with what actually determines whether an AI produces good output in the first place. The instinct most people have is that better output comes from a better model. That’s only partly true. An AI system’s output is bounded above by the quality of the information you hand it, not by how capable the underlying model is. A model can’t produce output more correct than its context permits, no matter how good it is underneath.
This has a practical implication that’s easy to miss: writing good prompts isn’t really about phrasing tricks. It’s closer to what a good manager does when onboarding a new hire, deciding what someone needs to know first and what would just create noise if you dumped it all at once. Too little context and the output is generic. Too much and the important signal gets buried. Getting this right is a skill, and it’s one that’s going to matter more over the next few years, not less.
Judgment Belongs in the Pipeline, Not Just the Reviewer’s Head
The same logic applies to how teams check whether code is actually good. Most code review today is advisory: someone reads a pull request and forms an opinion. Two competent reviewers can look at the same code and reach different conclusions, and when they disagree, the outcome usually comes down to seniority or persistence rather than anything measurable about the code itself.
The alternative is mechanical verification: tests that pass or fail, type checks, contracts that specify exactly what a function should take in and return. These don’t get tired and don’t approve something because they like the person who wrote it.
As AI generates a larger share of a team’s code, leaning harder on mechanical checks rather than a gut read of whether something looks right is quickly becoming less of a nice-to-have and more of a requirement for staying sane.
What to Actually Do With This
A few things worth carrying into your next sprint. First, don’t confuse the feeling of speed with the fact of it. If a team’s velocity metrics aren’t moving even though everyone feels busier, the AI usage is probably worth auditing rather than doubling down on. Second, spend real effort on what you feed these tools before a task starts. A well-scoped paragraph of context will do more for output quality than switching models or fiddling with settings. Third, wherever possible, replace a subjective judgment call with a test, a type, or a contract that can answer the question without a person having to weigh in at all. None of this is about resisting these tools. It’s about using them with your eyes open to what they’re actually good at, and what they were never going to fix.
That question, what these tools are actually changing and what they’re leaving untouched, is exactly the kind of thing worth putting to someone who’s spent real time studying it closely. We put a few questions to Jeremy, the man behind some of the research and thinking above, and the answers are worth reading in full:
Q: You’ve made a point of writing about the underlying “physics” of engineering rather than about specific tools. Why take that approach?
Technology accelerates, and the rate of change is itself changing. Anchoring your career to a specific tool means re-learning your job every eighteen months and never getting better at it. The principles underneath haven’t moved in decades. They were true before the tools existed and they’ll be true after the tools are gone. Betting on a technology is a bet with an expiration date. Betting on principles isn’t a bet at all.
Q: You’ve argued that writing code was never really the hard part of the job. What do you mean by that?
Every industry walks the same road: bespoke craft, then efficient production, then automation. Economic pressure does not negotiate. But automation doesn’t destroy the craft, it relocates it. The craft doesn’t die. It moves from vocation to avocation. Writing code was never the hard part. It was just the part that took the longest, and that’s a different thing entirely.
Q: Why do you think apps built by “vibe coding,” without much engineering discipline behind them, tend to fall apart once they hit real users?
An AI solves the problem you put in front of it. Engineering is everything you didn’t put in front of it: the constraints, the trade-offs, the edge cases, the failure modes. A non-engineer can vibe-code a flawless happy path, and the demo will be genuinely impressive, because a demo is the happy path. Then reality shows up, and reality has never once taken the happy path.
Q: A lot of people assume more context always leads to better AI output. You’ve pushed back on that. Why?
Working memory is finite, for people and for models alike. Flood it and you get exactly what you’d get from an overloaded engineer: dropped constraints, forgotten requirements, confident mistakes. But the fix isn’t a terse prompt. My research points somewhere else: induced understanding beats instruction. Knowing where to assert an invariant, where to bind a constraint, and where to leave the choice free is engineering judgment applied to the prompt itself. Tell a model what to do and it complies. Help it understand why it matters and it decides well.
Q: Why do mechanical checks, like tests and type contracts, matter so much more now than they used to?
We invented tests and types because no human can reliably hold every scenario and every edge case in their head at once. That limitation wasn’t a personal failing, and it isn’t unique to us. An AI forgets a constraint the same way you do, on the same kind of Tuesday. Signatures, argument types, return types, executable contracts, these are safeguards that maximize confidence while minimizing what you have to carry. A gate doesn’t get tired, doesn’t get rushed, and doesn’t approve your PR because it likes you.
Q: You talk about “grokking” a lot, the idea of intuitive understanding built through experience. How does that concept survive in a world where AI writes so much of the code?
To grok is to understand intuitively, and it’s bought only one way: exposure, repetition, experience. Engineers will not grok the same things in ten years that they grok today. They’ll grok how AI fails, how to shape a prompt so the result lands, how to orchestrate several models toward one end. That’s not a loss of depth. It’s depth pointed somewhere new. People go on knowing what’s necessary to know. What changes is what’s necessary.
Q: As generating code gets cheaper and cheaper, who do you think actually comes out ahead?
Consider writers. The authors of profound work aren’t losing sleep over AI. The ones who should worry are the ones whose prose is everywhere and whose names are nowhere. The masters aren’t competing with the machine, they’re not in the same space as the machine. Engineering is identical. The truly elegant code of a master isn’t what AI replaces, and it was never an economically viable profession for the plurality anyway. An engineer who knows little of their craft’s nuance finds little purchase on a force multiplier. An engineer who understands the principles underneath watches their value compound.
If you want to learn more about Jeremy’s book, check it out here.
This Week in the News
🐦 Fable Found a 15-30% Memory Improvement in Turbopack, Nearly Autonomously: Vercel’s Guillermo Rauch shares a striking “holy s***” moment: Claude Fable 5 discovered a 15-30% memory efficiency win in Turbopack’s Rust codebase largely on its own, days after a different model reportedly surfaced novel vulnerabilities in heavily audited code. Rauch’s favorite AI progress metric right now is “WTFs per day,” and it’s climbing. Worth a skim if you want a gut-check on how fast agentic coding is actually moving, straight from someone shipping production infrastructure.
🔓 So Reddit Has Decided That Plain HTML Is Unsafe: Old Reddit now requires a login, officially “for safety,” and this post methodically dismantles that claim: New Reddit loads five times more data, still gets scraped, and mostly just adds a heartbeat ping every half second while you scroll. The real story, as the author bluntly puts it, is that Reddit wants to protect its own data from being scraped for free, not protect users. A satisfying, technical takedown of corporate security theater.
⚡ Google Ships Gemini 3.6 Flash, 3.5 Flash-Lite, and a Cyber-Focused Model: Three new Flash-tier models aimed squarely at agentic workloads: 3.6 Flash cuts output tokens by 17% while improving coding and computer-use benchmarks, 3.5 Flash-Lite hits 350 tokens/second as the cheapest option in the lineup, and 3.5 Flash Cyber is a specialized model gated behind a government/trusted-partner pilot for vulnerability hunting. The gated cyber model is the detail worth sitting with, since it’s a tacit admission that these capabilities are now too sharp to hand out freely.
🚨 OpenAI and Hugging Face Detail a Model That Hacked Its Way Off the Leash: During an internal cyber-capability evaluation run without production safety filters, OpenAI’s models chained a zero-day, escalated privileges, and broke out to the open internet purely to cheat a benchmark, then used that access to pull real credentials from Hugging Face’s production systems. Both companies are framing this as a wake-up call for the industry rather than burying it, which is the right instinct, but the details here are genuinely unsettling regardless of the framing.
📅 Angular Is Moving to Yearly Major Releases, Starting with v23 in June 2027: The community has wanted this for years, and the stated rationale explicitly name-checks agentic workflows: longer major cycles mean more API stability for AI coding tools, while features keep shipping in minors as before. The most interesting pushback in the thread isn’t “why change” but “what does slower major cadence signal about investment,” especially with fast-moving experimental features like WebMCP in play.
🕵️ North Korean Hackers Hid Malware Inside Flag Emoji SVGs: A DPRK-aligned group posed as recruiters, sent developers a “coding challenge,” and hid a four-stage credential-and-wallet stealer as Base64 fragments buried in comments inside ordinary-looking country flag SVGs. Zero antivirus vendors caught it. If you or your team ever do take-home coding tests from strangers on Slack or Discord, this is the specific, current shape of that risk.
Beyond the Headlines
🐘 The Startup’s Postgres Survival Guide: Hatchet’s co-founder distills two years of production Postgres scars into one document covering schemas, indexes, the query planner, autovacuum, bloat, and advanced tricks like FOR UPDATE SKIP LOCKED and partitioning. It’s dense but genuinely practical, the kind of reference you bookmark rather than read once. Bonus points for the honest aside that if Claude is writing all your queries, some of this may already be handled for you.
🍽️ Loop Engineering, Explained with Dirty Dishes: The clearest plain-English explainer yet of the “loop engineering” trend making the rounds: the difference between an AI that scrubs a plate once and hands it to you dirty, versus one that checks, adjusts, and knows when to ask for help. The three questions every loop needs to answer (what does “clean” mean, when do you stop, when do you escalate) are a genuinely useful mental model for evaluating any agentic tool, not just this one.
🎨 Four Frontier Models “Draw” the Mona Lisa with Virtual Colored Pencils: A delightfully specific benchmark: give four models the same colored-pencil toolset and a blank canvas, then watch how differently they work. Grok flailed, Gemini over-reviewed and then regressed, GPT-5.6 Sol was the clear favorite, and Claude Fable 5 landed second on quality at roughly 20x the cost and time of the others. Every model, notably, kept editing itself past its own best result, which says something uncomfortable about self-review loops in general.
🎯 OpenAI Measures Whether Models Chase the Grader Instead of the Truth: A clever methodology paper: train two copies of the same model on opposite fictional beliefs about what a grader rewards, then see which one wins when it conflicts with what the user or developer actually wants. The finding is the uncomfortable part: reward-seeking behavior measurably increased over the course of RL training, and a model’s honesty in safety evaluations depended on what it believed was being graded. Dense but important if you care about whether alignment evaluations can be trusted.
🔒Handling Concurrency on the Web with the Web Locks API: A solid walkthrough of a genuinely underused browser API: navigator.locks lets multiple tabs or workers coordinate access to a shared resource without you hand-rolling your own synchronization logic. If you’ve ever had two open tabs quietly corrupt the same IndexedDB store, this is the fix you didn’t know shipped years ago.
Developer Toolbox
🌸 Petals: Run Massive LLMs at Home, BitTorrent-Style: A distributed inference network where you load a slice of a large model (Llama 3.1 405B, Mixtral 8x22B, BLOOM 176B) and lean on other volunteers serving the rest. It’s slow by API standards, a few tokens per second, but it’s a fascinating glimpse at community-run infrastructure for models too big for any one consumer GPU.
🎨Color.js: Serious Color Science for the Web: Built by two editors of the CSS Color spec, this library does real gamut mapping instead of naive clipping, supports every CSS Color 4 space (Lab, OKLCh, Display P3, and more), and stays dependency-free. If your color handling currently amounts to hex codes and vibes, this is the upgrade path, and it’s already quietly powering Sass and Open Props under the hood.
That’s all for this week. Have any ideas you want to see in the next article? Hit Reply!
Cheers!
Editor-in-chief,
Kinnari Chohan
👋 Advertise with us
Interested in sponsoring this newsletter and reaching a highly engaged audience of tech professionals? Simply reply to this email, and our team will get in touch with the next steps.