The early mental model of an AI coding agent was simple: one developer, one terminal, one conversation. That framing holds up well enough for solo work. It starts to crack the moment a second person needs to pick up where the first left off — or when someone in sales wants to file a bug without opening Jira.
A small team at Superconductor has spent the past month running nearly all of their pull requests through agents, and the lessons they have shared offer a useful map for teams trying to make the same shift.
The core problem: agents trapped on a laptop
The typical first step when scaling agent use across a team is a Slack bot. It works — until the agent’s context lives in Slack and nowhere else. Switch to GitHub and the history is gone. Open the desktop app and you start fresh. What teams actually need is a single agent session that is reachable from Slack, a desktop or mobile app, and GitHub simultaneously, carrying full context across all three.
This sounds like a product problem, but it is also an architectural discipline. The agent session has to be first-class infrastructure — persisted, addressable, and shared — rather than a subprocess that lives and dies with a terminal window.
Visibility matters as much as capability
Once agent sessions are shared, a new problem surfaces: understanding what an agent actually did. Reading a long thread to reconstruct an agent’s reasoning is tedious. The better approach is to ask the agent directly, in the same session where the work happened.
Superconductor’s setup surfaces every team member who has touched or is watching a session, and routes all artifacts — screenshots, videos, generated code — to every interface, not just the one where the work started. Non-technical staff in support or growth can trigger real engineering work from Slack: describe a bug, the agent builds it, an engineer reviews a screenshot, and it gets merged. No ticket triage required as a prerequisite.
Every external signal is a potential prototype
The more interesting extension of this principle is what the team calls a meeting bot. Invite it to a Google Meet, Zoom, or Teams call; it listens, creates tickets, links them to existing work, and starts building. In a live demo at a conference, a visitor made an offhand suggestion — that agents should define acceptance criteria before declaring themselves done — and the bot created a ticket, built a prototype, and produced a UI screenshot without any human in the loop.
The underlying idea generalises: every customer call, error alert, or support email is a signal that can be routed to an agent and turned into something evaluable. The bottleneck shifts from “can we build this?” to “can we review this fast enough?”
Security scoping and lid anxiety
Running agents on developer laptops creates a subtle security problem. A laptop carries credentials, tokens, and files that an agent has no business touching. Cloud-based agent sandboxes — with explicit allowlists of which external hosts agents can reach, and one-click approval for anything outside them — scope agent access to exactly what a given task needs.
The practical side effect is eliminating what the team calls “lid anxiety”: the habit of keeping a laptop open or staying tethered to a phone so a running session does not die. Moving sessions to the cloud removes that entirely.
Benchmark on your own codebase, not someone else’s
Public benchmarks like SWE-bench (a standard measure of how well agents handle software engineering tasks) run on Python repositories. If the team’s codebase is Ruby on Rails, those numbers are nearly useless for model selection decisions.
The approach worth taking is to pull a representative sample of merged pull requests, run candidate models and harnesses against them, and measure quality, cost, and speed against that actual corpus. Superconductor’s results from a month of this: Codex was fast, high quality, and cheaper; Claude showed consistently improving quality but at higher cost; open-weight models such as GLM 5.2 are becoming competitive. The team’s default shifted to Codex, and when a newer model briefly became available, switching took a day with no workflow disruption.
That flexibility depends on staying model-agnostic from the start. Token vendors’ incentives do not always align with keeping costs predictable, and the best-performing model changes often enough that locking into one is a liability.
Where this points
The direction of travel is clear: agentic engineering is becoming a team sport, not a power-user feature. The infrastructure questions — session persistence, security scoping, signal routing — are not glamorous, but they are what determine whether the whole team can participate or only the people already comfortable in a terminal.
The open question is review velocity. When every customer call yields dozens of prototypes, the constraint becomes how fast humans can evaluate them well. That is probably the next problem worth solving.
Text summarized and optimized using Anthropic’s models and reviewed by a human.