Let me tell you that procrastination can look impressively busy! Plenty of stalled projects have died on me because of watching YouTube, write newsletters or just messing with other stuff. They die the emotional texture of the task matters more than the task list... Older work can become stale, loaded with guilt, and weirdly threatening in a way that brand-new work simply isn’t. This mix of novelty, avoidance and moral licensing is persuasive enough to explain why intelligent, motivated people keep circling the runway without landing. Still, the evidence is thinner than the confidence, but trust me, I'm an expert in procrastination! The broader implication here is quite useful, though. In workplaces, “productive procrastination” can become organisationally respectable. Teams polish dashboards, refresh strategy decks and launch internal experiments because these activities feel energetic and legible. Meanwhile the ugly, consequential work sits untouched. There’s always a new tool promising momentum without confrontation... I've been facing that everyday with Agentic AI.

So, this isn’t a quaint story about airlines clinging to relics; it’s a story about infrastructure that solved a horrible, high-stakes coordination problem so well that the rest of the industry had to route around it rather than replace it. That’s the interesting bit. Shared standards, settlement rules and interlining economics do a lot more to shape technology than engineers’ aesthetic preferences ever will. That’s a useful corrective. The airline stack didn’t just “happen”. It was cornered into this shape. What the piece leaves a bit too neatly packaged is power; once an industry settles on a handful of compatible cores, the question stops being “why hasn’t this been rewritten?” and starts being “who benefits from rewrite difficulty?” TPF itself is almost beside the point. The real story is institutional lock-in with a performance justification attached. Sometimes that justification is perfectly real. Sometimes it’s become a very expensive article of faith.

I think the problem isn’t that coding agents write too little code, it’s that they let teams generate too much momentum before anyone agrees what the work is for. That’s a real shift, and she names it cleanly. “Agreeing on what to build is the new bottleneck” is the article’s most distinctive claim, and it’s stronger than the usual productivity chest-thumping. We get a compelling diagnosis and a slick prototype, but not much evidence that today’s teams are actually drowning in misalignment more than they’re drowning in integration, test failures, brittle requirements or plain old organisational indecision. Ace sounds plausible because anyone who’s sat through late-stage PR carnage knows the shape of the problem. GitHub sits in an interesting position here. The piece effectively says the core artefacts of modern software collaboration are becoming too blunt for agentic work, then offers a new collaborative layer that still feeds back into GitHub. Fair enough. Also convenient. The stronger strategic point is that if code generation keeps cheapening, coordination tools become the real battleground. Not models. Not autocomplete. Workflow control. Shared context. Permission to decide. That’s where power accumulates.

History is repeating itself here, just with better interfaces! Every generation seems to rediscover that the polished artefact isn’t the work; it’s the residue of the work. Papers look clean because they’re supposed to. Notebooks look alive because they still contain the argument with reality. For example, I never return to my previous notebooks; as they're just for me to scribble what I think it's relevant and to work on the moment, or at least, go back a few days or week to check on some notes. Never going back years or for me to remember something. It's my visual aid for the moment to get in the mood, to be focused. Newton’s reused Waste Book, Starkey’s tagged alchemical records, Faraday’s numbered diaries and Joule’s dry calculations all show the same thing: notation systems shape what a researcher can notice, revisit and trust. That’s the real lesson. Recording isn’t administrative. It’s cognitive architecture. As research becomes more digital, collaborative and instrument-heavy, the notebook stops being a bound object and starts becoming a systems problem: provenance, versioning, searchability, permissions, reproducibility. That’s where things get political as well as practical. Whoever defines the record format ends up shaping what counts as evidence, what can be audited and what gets lost between experiment and claim. It's a good essay, then, because it treats old notebooks as working machinery rather than museum pieces. If you don’t design for memory, your workflow will design forgetting for you.

Production reality is the thing this article underplays, even as it describes it brilliantly. Reading it, you keep noticing how many fixes arrived only after years of nudging, side channels, personal contacts and patient technical pestering. That’s not a charming anecdote. That’s an operating model. Percival is convincing because he’s concrete. Dates, APIs, Xen versions, oddball edge cases, broken assumptions about metadata, boot modes and signing schemes: this doesn’t read like mythology. It reads like someone who kept turning up with receipts. He also gets something important right about large platforms: the hard part isn’t spotting a better design. It’s getting a running system, existing customers and internal priorities to move at the same time. AWS comes off here as both impressive and faintly alarming. Impressive because it clearly had people willing to listen, escalate and eventually fix things. Alarming because so much seems to have depended on informal trust networks rather than crisp, visible mechanisms for external technical challenge. Platforms externalise more stewardship than they admit and this is an excellent memoir, useful institutional history, and a slightly damning portrait of how infrastructure really gets corrected.