Closing the Loop on /insights
Anthropic quietly shipped /insights a few days ago—announced on X, but not yet prominent on the main docs. Type / in Claude Code and it's there.
Run it and Claude reviews your last 30 days of session transcripts. The output reads like a team retrospective. It starts with what's working—here's where you're getting real leverage, here's what the collaboration does well. Then it gets specific about friction, and it's careful to separate concerns: "On Claude's side..." followed by "On your side..." Shared accountability. It ends with action items: CLAUDE.md additions, hooks to try, workflow changes.
The report I got back covered 496 sessions. Nearly 200 friction events, neatly categorized: buggy code (43%), wrong approach (39%), misunderstood requests (11%), and a smattering of "Claude went rogue." None of the findings surprised me—I recognized every incident. What I didn't have was clarity on cost. The premature branch merges, the tasks started before I'd specified what to work on, the auth system nobody requested. Each felt like a one-off. Stacked up, they told a different story.
The report noted I was "more often dissatisfied or only likely satisfied than genuinely satisfied." That stung until I thought about it. The "likely satisfied" bucket probably absorbed a lot of solid sessions that just didn't stand out—quiet wins that don't register.
Wrong-layer fixes came up constantly. Claude would burn tokens investigating the database when the problem was stale localStorage. Or apply a client-side band-aid when the fix belonged on the server. Each incident felt like bad luck. Seeing them stacked up reframed it: I wasn't giving enough architectural context upfront, and Claude wasn't asking for clarification before going deep on the wrong path. Shared failure. Shared fix.
The retro proposes action items. I could have copied them into my projects manually. Instead, I fed the reports to the Claude instance that manages my personal plugin setup—the collection of skills and commands I share across projects—and asked it to figure out how to integrate the recommendations.
This is where it got interesting. I ran a /council deliberation—multiple Claude perspectives debating how to best apply the feedback. They converged on a tiered approach: prevention (session orientation checklists), detection (circuit breakers after repeated failures), and enforcement (hooks that block bad patterns at the tool level). The recommendations went beyond the original report, customized for my specific environment and workflows.
Then we iterated. Claude proposed changes to my plugins. I deployed them to projects already in flight. We tested, hit edge cases, debugged, refined. By the end of the session, the improvements were live and confirmed working—not theoretical action items in a doc somewhere, but actual guardrails catching actual problems.
Stop and think about what just happened. An AI analyzed hundreds of its own collaboration sessions, identified where it was falling short, convened a panel of itself to debate solutions, proposed changes to its own operational constraints, deployed those changes, tested them against live work, and debugged until they stuck. I was there—reviewing, approving, occasionally steering—but the cognitive work was almost entirely on the other side of the conversation.
This is a feedback loop that barely needs me. The retro runs itself. The action items implement themselves. The validation happens in real time. I'm less the engineer and more the product owner nodding along as the team ships its own process improvements.
I don't know what to call this yet. It's not quite self-improvement—I'm still in the loop. But the loop is getting very short, and I'm not sure I'm the load-bearing part anymore.
I'll report back after our next retro. Assuming Claude doesn't schedule it without me.