Your Attention Is the Bottleneck, Not Your Agents — Zack Proser, WorkOS

How can you produce more software than ever and still feel completely fried before lunch? Zack Proser, who works at WorkOS, describes agent-assisted coding as a mix of increased output, repeated adrenaline spikes, and increasingly expensive context switches. WorkOS supplies APIs that help software companies sell to enterprises; inside that environment, more powerful development tools have not automatically made the working day easier to sustain.

A bug in his Applied AI team’s Slack BlogBot makes the problem concrete. The bot lets colleagues request consistently formatted blog posts without needing to know the publishing process. But its sentence-case pass was damaging acronyms such as SCIM and SSO. Fixing that normally meant moving among the code, the reported issue, and Slack to check whether the actual workflow now behaved correctly.

Proser changed the agent’s access instead. Claude Code already had access to his Linear tickets; he added Slack read and write access through MCP, then instructed it to fix the bug, verify its own work, and continue until verification was complete. The resulting loop crossed the same application boundary that a human tester would have crossed:

1. Claude Code changed the sentence-case enforcer in the working codebase.
2. It submitted a request to the blog channel through Slack MCP.
3. BlogBot picked up that request and ran through the relevant processing step.
4. Claude checked the resulting output before reporting completion.

Proser reports returning to a completed fix rather than another request for him to discover what was still broken. Access to the real verification surface removed a human round trip.

The successful fix was both exciting and unsettling. If an agent can complete that loop, why not keep stacking copies of it? Proser imagines fixing 150 bugs per day, conditional on supplying enough context, explicit verification criteria, and tools that can check those criteria. That is a hypothetical workload, not reported throughput. His constraint is overseeing the quality of all that work and still being able to return for another full working day.

His description of agents scaling infinitely expresses the asymmetry: execution capacity can expand much faster than a person’s attention, which degrades under load. He also points to newly available Claude API capabilities as another expansion of access, without identifying a specific service. Proser attributes to Simon Willison exhaustion by 11 a.m. after running four parallel agents, using the example to argue for discovering individual limits.

The developer still supplies judgment and taste: whether the result actually solves a problem, and whether the stated criteria satisfy human and business needs. Increasing task intake in proportion to agent capacity can consume that judgment faster than it replenishes. Proser organizes his response into four capabilities: signal layers that filter incoming work, voice-first flows, remote control, and a system that improves itself by reviewing its own history. He had already been coding primarily through voice for roughly a year and a half; the other pieces extend that practice into a more sustainable workflow.

Opening Slack to investigate one problem also exposes every other thread and request. Proser estimates his own chance of distraction when combing through Slack at 80%. His signal layer lets Claude Code do that inspection repeatedly instead: look for @mentions, direct messages, and high-priority requests, then use Linear MCP access to deduplicate asks and locate the actual tickets. The developer sees actionable work through the environment already in use, rather than entering a feed that can redirect the day.

Voice addresses the other direction of traffic: getting intent into the tools. Proser reports a personal typing best of 90 words per minute and regular voice input around 184 words per minute. These are his input-speed observations, without an accuracy or correction-overhead comparison; they do not establish a coding-productivity multiplier.

The useful consequence is quicker task dispatch. His illustration has a developer speaking across three Cursor windows, Codex, and multiple Claude tabs, getting agents started while a typist is still entering an initial prompt. He expects small savings to compound over years of work. More immediately, becoming comfortable with spoken instructions makes it possible to keep directing work without remaining at a keyboard.

Before discussing remote access, Proser introduces the shower principle. In his framing, focused IDE work is good for executing a clear blueprint: finding symbols, making precise changes, and getting an implementation over the line. The same concentration can narrow the alternatives you consider. Playing with a dog, walking children to the park, or taking a shower can loosen that focus and make a previously elusive solution apparent. He describes this as diffuse thinking, with background problem solving becoming accessible after stepping away.

The new possibility is that stepping away need not stop the implementation. With Claude Code Remote Control, Proser enables access through a startup option, a command, or configuration. The session continues running on the development machine with its local filesystem and tools; Claude on his phone can reach that same session from another network, including cellular service out on a trail. The phone is another interface to the existing work, not a replacement execution environment.

The sequence matters: first establish the important work in a focused session, start the agents, and confirm that they are proceeding in the intended direction. Then walk. Proser cites his film about working with AI in the woods, which he describes as a 32-minute demonstration including phone-based PR review. Less time in a fixed desk posture, and less exposure to repetitive strain, are motivations for the arrangement. When an idea arrives, he can send it straight back to the session that still has access to his machine, instead of trying to remember it until he returns.

“Speed requires safety” is Proser’s condition for letting this work proceed away from the desk. Browser and computer-use tools expand what agents can inspect, but they need explicit obligations to use them. He separates verification into three gates:

The first gate uses Claude Code hooks to make checking routine. The second requires the agent to exercise behavior rather than infer success from the code alone. For the third, a reviewing agent returns feedback that the implementing agent must address. Proser compares that arrangement to Constitutional AI; it is an analogy to checking against written principles, not an implementation of the research’s training method.

Putting the pieces together changes the shape of the day:

1. Begin with focused setup. Review GitHub backlog items and software-development lifecycle chores, queue suitable work in Codex, and start the priority features in an IDE or Claude Code.
2. Confirm the work tracks. Establish what each agent should be doing before leaving the desk.
3. Review as results arrive. Use the phone to inspect PRs and send instructions while away, including over EDGE or LTE.
4. Send corrections into the existing loop. Leave natural-language feedback in GitHub Mobile for integrations such as Cursor Agent.

Proser cites Opus 4.6 as making this sort of correction practical and says it gets the requested change right most of the time in his experience. The human remains in the loop, directing progress and reviewing results, while spending less time physically at the desk.

Fast execution alone can still produce a disorganized week. Monday and Tuesday feel productive; interruptions accumulate midweek; by Friday, work has shipped but the developer is exhausted and cannot easily reconstruct what happened. Proser’s colleague Nick pointed out that Claude Code saves its conversations locally as JSONL. Those sessions provide a record of both the output and the effort required to obtain it.

A scheduled daily or weekly pass can inspect that record for expensive reasoning, repeated clarification, and missing capabilities. The useful question is specific: which tool, MCP server, or skill would have prevented this particular struggle? Instead of only summarizing completed tasks, the scan produces candidates for improving the next interaction.

Proser describes using a skill that can create, evaluate, and improve other skills from natural-language requests; Anthropic publishes a skill-creator for this purpose. The mechanism depends on preserving working context, whether the main interface is Zed, Cursor, or a terminal. He reports that a single Opus 4.6 pass can reveal useful missing skills. Conversation history becomes material for improving reliability, rather than something discarded when a task ends.

Proser extends that context to his own physical condition by connecting Oura Ring data to Claude through MCP. In one recurring interaction, Claude sees poor sleep and proposes doing only the first part of a project, leaving the rest until tomorrow. Proser jokes that he overrides the suggestion—but at least it makes him consider taking a break.

Sleep and the times when he can focus best belong alongside tickets, colleagues’ requests, and available skills. Delegation should preserve the person who remains responsible for quality, review, and shipping. Without that intention, more powerful tools can simply make burnout arrive faster.

His prepared close proposes a small adoption sequence: connect the highest-cost context switch, such as Slack or Linear, to the working interface; add a verification gate that is currently missing; then spend the recovered margin on a walk, a picnic, or time with the dog. For browser access, he names Claude Code’s Chrome integration:

claude --chrome

The command gives the agent a verification tool; the task still needs an instruction to use it. Product setup is version-dependent: current documentation supplies the requirements for Chrome and Remote Control, and remote execution requires the development machine to remain awake and connected. The goal is to recover usable time, not immediately fill it with another queue of tasks.

The first audience question exposes a dependency in this workflow: where does the developer’s judgment come from? An early-career programmer describes learning through deep work, difficult bugs, and overcoming obstacles. If agents remove those experiences, faster delivery can coincide with a growing skill deficit.

Proser’s advice is to avoid delegating work you do not yet know how to do yourself. He uses agents for TypeScript systems, RAG systems, and AWS deployments because years of doing that work directly help him catch hallucinations and reject bad proposals. He still recommends going deep, writing code by hand, and discovering what makes the task difficult. AI can support that learning by testing understanding and exposing gaps in a murky mental model.

Once that foundation exists, acceleration becomes easier to evaluate: someone who has shipped many Ruby applications can use an LLM to ship the next one faster. The questioner condenses this into delegating only code one is qualified to review, which Proser endorses when the priority is skill growth and a solid foundation. He also sees an advantage for learners: AI can help name concepts they do not yet know how to ask about. Admitting a gap can become the start of deeper learning rather than a reason to conceal it.

Another question challenges the practicality of reviewing raw JSONL: the files can be long and full of material poorly suited to model consumption. Proser reports success pointing Claude directly at them, but also proposes a smaller intermediate record. At the end of a coding session, a hook can ask the agent to save key discussion points, especially places where the work became difficult or consumed unusual effort.

The destination can be Obsidian, a weekly Markdown file, or a simple archive. A weekly analysis then reads those extracted records. Possible triggers include session completion, an explicit declaration that the work is done, or a merged PR. Asked whether the selection is deterministic, Proser clarifies that it is an AI prompt: look for struggle, churn, and opportunities to make future work more efficient. The hook determines when extraction runs; the model decides which parts are worth retaining.

Proser’s overnight experiments use OpenClaw with cron jobs to produce content. The next morning, he reviews the results and merges only a small, unspecified fraction. That experience places the review bottleneck back in view: generating work while asleep does not guarantee that the output is worth shipping.

The more systematic arrangement he wants would put all work in Linear, use subtasks for bugs and feature requests, and mark suitable tickets agent ready. He proposes polling those tickets every fifteen minutes, day and night, for personal and company work. This is a desired workflow dependent on better systems and verification, not an already demonstrated reliable queue.

Voice input does not require voice output. Asked how he handles verbose responses, Proser says his usual Claude Code arrangement is to speak requests and read the written replies. For exploring an idea, he instead uses ChatGPT’s advanced voice mode: walk, talk back and forth, sharpen the architecture, then ask for a succinct transcript or architecture description to paste into the next tool.

An audience member asks whether that voice mode is limited to GPT-4.1, but the exchange does not settle the model version. Proser’s emphasis is on the usefulness of the conversation. He also points to Ghost Pepper, which he describes as an open-source alternative to Wispr Flow that runs locally without an API. His OpenClaw setup connects to Twilio, letting him request a call at night and discuss what he wants done the following day. These are different uses of voice: dictation for directing code, conversation for developing an idea, and a call for planning future work.

The final question draws a boundary around easy parallelism. Small bugs and UI fixes can be dispatched independently. A feature that changes the backend, database, and frontend—or a refactor that alters how the application works—can require enough coordinated attention to bring that parallel workflow to a halt. Proser agrees that discrete tasks fit these arrangements better and that larger changes remain a shared difficulty.

His starting point is Git worktrees, so agents can make changes in separate working directories, followed by agent teams with clearly defined prompts. For example, two worktrees can isolate implementation tracks:

git worktree add -b feature/backend ../app-backend
git worktree add -b feature/frontend ../app-frontend

That separates file edits; it does not define the contract between the backend and frontend. The agents still need explicit responsibilities and a shared specification.

For these larger tasks, verification gates, unit tests, continuous integration, and repeated application testing become more important. Agents build against a specification, and human feedback drives corrections as integration exposes problems. Proser expects more complete execution and verification systems to make this more reliable as models improve, but does not present whole-stack parallel development as solved. The unresolved work is coordinating a coherent change and determining that the application, as a whole, is correct.