Contains some AI-generated content

  1. How much autonomy should you give your agents? posthog.com

    Jina Yoon’s framework: autonomy should depend on the task, not the model. “Trusting your agents just because the models got smarter is like skipping your seatbelt because you got a nicer car.” Two questions decide it: is the work easy to check, and are mistakes cheap to undo? That yields four levels, from assistant mode (hard to check, costly to undo) up to self-driving (easy to check, cheap to undo, like dependency updates), with PostHog examples of moving work up the ladder.

    The checkability axis is doing the same work as the constraint-building in constrain the agent.

  2. Gergely Orosz: code reviews fading away x.com

    Gergely Orosz “cannot help but see the concept of code reviews fading away”. A rock-solid, very experienced engineer he spoke to reviewed all their AI-generated code until Fable, then concluded the review was pointless and stopped, except for key parts. One anecdote, but from a careful observer of engineering practice, and consistent with where Uncle Bob and antirez already landed. The open question is what replaces review as the quality gate; Graphite is betting it doesn’t need replacing.

  3. Prompting agents without reading the code is just management x.com

    Kenton Varda: building software by prompting agents without ever reading or editing the code “isn’t actually a new thing. It’s just called being an engineering manager”, a different skill with decades of accumulated practice behind it. The analogy is genuinely useful, but it has a gap worth holding onto: a human team carries far more durable memory and shared context between tasks than an agent team does, so the management playbook doesn’t transfer cleanly.

  4. Steps of AI Adoption x.com

    Boris Cherny (creator of Claude Code) hears the same thing everywhere: one person is 10x-ing their output with Claude and the rest of the org hasn’t caught up. He maps adoption as four steps, and the key observation is that tokens alone never move you forward: each step needs the next set of bottlenecks broken and the next set of guardrails built. In practice that means giving Claude ways to verify its own work end to end, auto permissions, automated code and security review, and interfaces for managing multiple agents. On measuring return, prefer the counterfactual to usage dashboards: would you have spent the engineering hours anyway, and what would they have cost?

  5. Come up with cool things for agents to work on x.com

    Dax Raad: being in the loop matters, but people misread what the loop is for. Your job isn’t to micromanage the agent into executing steps the way you would; “it’s to come up with cool things for it to work on”. A neat one-line answer to the bottleneck question Patrick JS raised: deciding what should exist.

  6. AI coding is addictive. Engineers are paying the price leaddev.com

    Chantal Kapani on the gambling-machine quality of AI coding: intermittent rewards, an immediate next step to every problem, and no natural stopping points. 45 per cent of engineers report working more hours than last year, and CTO burnout has more than doubled. Steve Yegge compares the random rewards to casinos: “your brain gets a chemical bath”. Suggested defences are unexciting but sane: time-box sessions, separate exploration from execution, treat recovery as maintenance.

  7. Cognitive Surrender addyosmani.com

    Addy Osmani separates cognitive offloading (delegating while keeping your own judgment) from cognitive surrender (accepting AI output without forming an understanding of your own). Engineers are unusually exposed: code looks correct by default, and productivity metrics can’t tell understanding from approval. The habit compounds into what he calls comprehension debt. His countermeasures are small and practical: form an expectation before reading the output, read diffs critically, ask the model for counter-arguments, and notice when fatigue is making you rubber-stamp.

    Another name in the growing vocabulary around cognitive debt and cognitive coverage.

  8. Why I'm not worried about AI job loss davidoks.blog

    David Oks argues that AI job loss will be slower and less sudden than the current panic suggests. His case is that humans and AI will stay useful together for a long time, because real work has bottlenecks, demand grows when things get cheaper, and society adapts more slowly than models improve.

  9. Finding Comfort in the Uncertainty annievella.com

    Annie Vella on a Thoughtworks retreat about the future of AI-driven software development. People are starting to name the questions around cognitive load, trust, platform foundations, agent governance, and the changing shape of engineering work. The key lesson for her was “Nobody has this figured out”