Spotlight by Backplanes - Session reports for Claude Code & Codex to improve your code

Amazing! FYI you can see a sample report here: https://www.backplanes.com/features/session-reports

Curious to have your thoughts about it

@david_marko, the end-of-session log is the certified power-user move, and you've described our origin from the other side: we were hand-rolling the same ritual and got tired of it. :)

If you're open to it, I'd love to see what would happen if you ran your hand-rolled log running for a week alongside Spotlight, and then let us know what your log caught that we missed, or vice versa. That kind of feedback is gold for us, and it sounds like you're exactly the right type of person to give it.

@daniel_oyetunde Great questions! Windows support is a priority for us now. It's being actively worked on, and we expect to have it out in the very near-term.

@jay_steele "we're slow, and that acts as a natural fishing net" might be the best articulation of "why now?" I've read all day. Review capacity was never really designed; it was a byproduct of human pace. Agents removed the pace, and the net went with it. :)

Your secret-sauce instinct is right too: every model and harness has its own screw-up signatures, and they drift with every release. Two things keep that tractable. The "what happened" layer is built per harness, so each platform gets read faithfully on its own terms. And the "what it means" layer judges behavior in context rather than pattern-matching known failure modes, so a new model's novel mistakes still surface as "this session did something worth your attention" before anyone's named the signature. When something genuinely can't be read, the report says so rather than guessing. The tuning never ends, you're right about that.

The design just keeps it shallow.

@jay_steele thanks, Jay, appreciate this comment! To the secret sauce being tricky across platforms-- we were worried about that, too. We've been surprised how well what we're doing works, and can not only discover things in a single platform, but across multiple ones. Would love to hear what you're seeing, and what we could improve for you!

@the_esc Yes and yes! Every session ends with a report of what actually happened: files touched, commands run, external services reached out to -- exactly the "what is Claude doing on my behalf" question. And the boss conversation is honestly half of why we built it: "trust me" is a hard sell; "here's a report of everything the agent did" and "I did some clever things you should leverage, too!" is a much easier one. It's built with solo engineers and and teams in mind, so the experiment costs your boss nothing.

Hey @the_esc ! Yes and yes, and the second one is one my favorite uses of Spotlight. :)

On tracking: that's a core purpose of the product. Every session becomes a report of what Claude actually did on your behalf: files touched, commands run, what needs fixing, what would save you time, and what's worth keeping.

On the boss: the report is deliberately written for two readers. There's the detail for you, and a summary of what shipped, review and CI status, and an overall risk posture. And here's the counterintuitive part: the most convincing report to show a boss isn't a spotless one. It's the one where something got caught and fixed, because what a boss actually fears isn't agents, it's unwatched agents.

Showing up with evidence that you see everything and act when it matters, is how "can I use coding agents?" turns into "why isn't everyone doing it like Evan?"

@ozandag Thanks for comment Ozan. This is a great question!

We don't do code quality analysis yet, but what we do is deep analysis of specific sessions and also all your sessions in aggregate. The report covers a few major areas:

1. Things you really should watch out for:

   • Was a credential sent out inappropriately?

   • Was PII sent to a website that wasn't known?

   • Did the agent access production without knowledge consent?

   • etc

2. The second thing we do is we look for patterns that should be replicated for you and across your teams. There are certain things you do really well replicate in those and other places. Like TDD use.
   

3. The third thing we do is we also find ways to speed you up. If there are certain things that you're doing that could be optimized, both from a token perspective or a speed perspective, we highlight those as well. For instance, I had an instance that auth'ed to the same service 4 times, killing 25 minutes.
   

4. The fourth major thing we do is we actually just talk about how you use your tokens: where do they go, what MCPS/etc are being used.

In addition to that, we also give stats on what code bases you work in the most, CI/CD pass/fails, abandoned work, github activity. And we do this across all sessions for both Codex and Claude Code together.

If you work with somebody else, we team level insights as well.

Code quality is not a bad idea though! We'll add it to our backlog. Thanks so much for the great question Ozan!

@vicky_fu Vicky! Two insights stand out.

1. coding agents are shockingly sloppy with credentials -- secrets land in places they have no business being, constantly, and almost nobody notices.

2. long sessions quietly leak a surprising amount of time, tokens, and money -- and once you can see what's going on, it's easy to tighten up with the right patterns and replicate them everywhere you work. Recursive self-improvement, with you in the loop.

Can't wait to hear what your first report shows you, and what you'd like to see next!

@ansari_adin excellent question! We generate suggestions you can feed back into your agent setup, and are soon building automations so that this can truly be self-improving!

@walkeriwilliams Walker! You believed before there was anything to test, and you've kept the feedback sharp and neverending ever since -- in the best way. Spotlight is better for every round of it. Thank you. Keep it coming!

@keirodev Kévin, speaking as the Neil in the story and a career-long security and privacy nerd: agreed, the scare is the pitch. :)

Your "drift is invisible at scale" line is exactly the problem statement, too: one engineer can review one session, but nobody reviews session forty-seven across six teammates.

On "really an audit trail": half yes, and the half matters. It has the rigor of one, every finding cites the exact moment in the session it came from. But it's pointed forward, not backward. An audit trail waits for the auditor; these reports feed your next session: what to fix, what to codify, what's worth sharing. Same evidence discipline, opposite direction.

And good news on file-level visibility: that's not roadmap, it's already in there. The 47 is the headline number, and the report under it lists the files, read vs written, inside or outside the project, with risky paths tagged, env files and credential-shaped paths included. For content-level changes we go finding-first: when a write matters, the finding cites it with evidence, rather than re-rendering diffs git already shows you better.

@retain_dev Gaurav, "filesystem boundary decisions" tells me we've fought some of the same battles. :)

Short answer: the anchor is identity, not inference. The CLI is signed in as you, so every session carries the same account identity no matter which repo or machine it ran on, with the repo, harness, and model riding along as context. Patterns aggregate across the account, so the same retry habit surfaces whether it happened in your API repo on a desktop or a scratch project on a laptop. That's literally how Spotlight started for us: stitching our own sessions together across machines, and being floored by how much we'd missed and how few of our good patterns traveled.

One thing we deliberately don't do is behavioral fingerprinting to guess "same agent" across accounts: identity stays explicit and predictable. And since you mentioned boundaries: every report flags file access outside the project, per session, so drift is visible long before it needs to be policy.