Launching today

Spotlight by Backplanes
Session reports for Claude Code & Codex to improve your code
594 followers
Session reports for Claude Code & Codex to improve your code
594 followers
Keep up with your agents. Spotlight reads your Claude Code and Codex sessions and shows you what your agents actually did, and how to get recursively better every session: what to fix now, what to ship better next time, what's worth sharing. One harness or seven, solo or across your team. Free.





The Neil story is the real pitch here, not productivity, but security. Most devs assume they're reviewing what the agent does, but at scale (multiple sessions, multiple team members), drift is invisible. The framing as "session reports" makes it feel like a dev tool, but this is really an audit trail. Smart. Curious whether you'll add diff-level visibility (which files were read, not just that 47 were).
@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.
Tabstack
FWIW you can see a sample report here: https://www.backplanes.com/features/session-reports
@keirodev give @Spotlight by Backplanes a spin and go generate your first report - would love to have your thoughts about it! cc @gogogadgetneil
@gogogadgetneil @fmerian Thanks ! Will spin it up this week.
@keirodev amazing, super excited to hear your feedback and what more you'd like to see!
@gogogadgetneil Good to know the file list is already there, I missed it in the demo. The risky path tagging (env files, credential-shaped paths) is exactly the kind of signal I'd want surfaced automatically.
Tabstack
had a blast collaborating with @gogogadgetneil @natwar86 and team!
Some recent discussions here pointed out that using a terminal like @Claude Code might feel too "zoomed out" from the code. Many prefer to stay in the loop and see what their agents are actually doing. [1]
@Spotlight by Backplanes fixed just that. It brings clarity to your agentic coding sessions and, more importantly, it compounds, making you a better engineer every session.
Go to backplanes.com to generate your first report in minutes - or see sample report here.
S/O to the ?makers, keep up the great work 👏👏
[1]: How do you like to work with AI coding agents?
The scary part of vibe coding fast isn't the bug you catch, it's the secret you committed three sessions ago and never noticed. I spent years in risk and security before I ever touched Claude Code, so "what my agent actually did" is exactly the report I always wished I had. Does Spotlight call out the security stuff specifically, leaked keys, missing checks, or is it more about code quality and patterns?
@luca_capone, "the secret you committed three sessions ago" is almost word-for-word how Spotlight actually started for us: I asked Claude to fix one file, and an API key ended up in a tracked .env that we only caught by accident. So yes, security is very much called out specifically, and it leads the report rather than riding along. Findings arrive severity-ordered in their own stream: secrets landing in files git tracks, prod-touching commands that skipped a dry run, an agent quietly reaching a service you've never used, each with the evidence behind it and a concrete fix.
Code quality and patterns that can help make you more effective with your harness are in there too, so the report always gives you value, even when there are no security-related findings. And since those transcripts are already sitting on your machine, the first report can start with the sessions you've already run. Your "three sessions ago" is still catchable. :)
Tabstack
FWIW you can see a sample report here: https://www.backplanes.com/features/session-reports
@luca_capone exactly! Would love for you to give Spotlight a spin and tell us what lands for you, and what we could improve!
The "what your agents actually did" angle is great, that read-47-files scare is too real. When you're running several harnesses at once, does Spotlight give you one combined report or one per session?
Thanks@ianhxu. "Too real" is exactly how it felt on the inside too. :) The answer is both, at different layers. Each session gets its own report, with its own findings and evidence, so you know exactly which session did what, and exactly what to do about it.
Running several harnesses at once just means several reports, and your Claude Code and Codex reports live side by side in Spotlight. But your highest-leverage opportunities are often in the trends and patterns across sessions, and so Spotlight gives you a report of what's important across all of them. And finally, connect your whole team and the view widens even further: patterns and trends across every engineer in an org.
One individual or a team, one harness or seven, Spotlight gives you both the detail and the big picture.
Tabstack
@ianhxu Fun fact: This "read-47-files scare" actually is a true story! See background story by @antifreeze here
Well done! Was post-session reporting a deliberate call over an inline guardrail that interrupts the agent mid-write (i.e. less intrusive, keeps you in flow)?
@artstavenka1 Thanks, Art! Definitely deliberate, but one (good!) clarification: it's not limited to being post-session. Spotlight reports actually build while you work, just minutes behind your agent, so you're not waiting for a session to end to find out what happened.
What we deliberately avoided is the inline path. A guardrail that interrupts mid-write has to sit between you and the model, with the latency and potential breakage that path implies, and we very much want to help keep you in flow. :)
Trellis
So cool. Will this help me track what actions Claude is actually taking on my behalf? Is there a way that I can use this report to help convince my boss that it's ok for me to use coding agents?
@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?"
This is a useful direction. For coding agents, the hard part is usually not generating more code, it is making the session reviewable afterward.
The report I’d want is pretty boring: changed files, risky assumptions, tests/checks run, failed attempts, and a short “what a human should look at first” section.
@kevinzrzgg, you seem to have written our report spec almost exactly. :)
Changed files: all files read and written are in there. Tests and checks: flagged with their outcomes when the session shows them. Failed attempts: called out, including the distinction between deliberate re-verification and flailing retries. "What a human should look at first": that's the top of the report, a one-line verdict with the main outcome, then findings ordered by severity and guidance on what to do for each.
The one we can only claim half credit on is risky assumptions: concrete risky choices surface as findings, and a blind-spots section names what the report couldn't verify, but a dedicated assumptions section is a great idea.
And we're with you on boring: the standing rule inside the report is no invented findings and no padded advice, an empty section beats a manufactured one.