Lifestyles of the AI-Native — Nick Nisi & Zack Proser, WorkOS

A team of two managing over 25 repositories across eight languages has a practical reason to use coding agents. That is Nick Nisi’s developer experience team at WorkOS. His colleague Zack Proser divides his work between building internal and customer-facing AI applications and teaching the rest of the organization to use AI. Their workshop starts with a familiar constraint: one engineer supervising one session still spends much of the day telling an agent what to do next.

The workshop repository packages skills, an MCP server and exercises for trying voice coding, goals, hooks and scheduled tasks. Participants start Claude inside the repository and ask it to set up the workshop. An optional coach and check-in provide a way to reflect on existing habits. The presenters distinguish the coach’s optional inspection of local agent conversations from the shared check-in: the latter posts answers to a Cloudflare backend, rather than uploading a scan of the machine.

Voice input removes some of the friction between deciding what should happen and giving the agent enough context to act. Proser reports typing around 90 words per minute and dictating around 190 with Wispr Flow. Those are his personal rates; the useful workflow change is that a longer explanation becomes cheap enough to say. Architectural thinking, customer replies and rough ideas can enter the same text-based tools without first being compressed into a carefully typed prompt.

An instruction such as extracting the auth client into its own module names a desired change. It leaves the agent to find the relevant files and make the edits. Across eight or more active sessions, each with its own project context and tools, the engineer can direct one task while another runs in the background. The benefit depends on keeping those sessions sufficiently independent and remembering what each one is doing—a problem the workshop returns to shortly.

The dictation tool determines where speech is processed and how much setup the user controls:

• Wispr Flow: Proser emphasizes easy installation and use, with a subscription and cloud processing as the tradeoffs. Sending spoken material off the machine matters when prompts include sensitive documents, filenames or personal information.
• Handy: The workshop chooses free, local dictation. Users download an open-source or open-weight transcription model and run it on their own hardware, choosing among language support and speed. Quantization helps make smaller speech models practical on consumer machines.

The live dictation example is deliberately silly: Nisi describes three steps for making a cake, admits he does not know how to make one, and includes putting it in a microwave. The useful result is structural. The dictated sequence becomes a list. The discussion also highlights recognition of filenames and function names, correction of recurring vocabulary, and formatting suited to the destination—more formal in email, more casual in Slack. These conveniences reduce cleanup between speaking and submitting a prompt.

Handy’s practical setup centers on a transcription shortcut, push-to-talk behavior, microphone selection and a downloaded model. The first trial should use the recommended model and confirm that the shortcut actually works; the demonstration itself briefly stalls because Nisi holds the wrong key. Speaking all day also has a social cost. Both presenters work remotely, and Nisi describes using a close wireless lavalier microphone to speak quietly in a coffee shop.

Voice input can also preserve continuity away from the desk. Proser pairs phone dictation with remote access to a Claude session started on his computer. On a walk, he can reopen the particular session, send a 30-second explanation of a bug fix and let the agent continue in the background. The essential connection is to the existing session: the new thought arrives where the repository context and previous work already live.

Ten open tabs create a new kind of overhead: repeatedly asking what each session was working on. Nisi demonstrates Fleet with 12 agents running simultaneously. It connects project and session names to Tmux windows and shows Claude-generated summaries drawn from session JSONL files. The operator can identify the dotfiles session, switch into it and return to the overview without reconstructing every conversation.

Several smaller mechanisms help keep that overview usable:

• Recaps on return: A session can summarize its current state and what it needs from the user when its window regains focus.
• Visual completion indicators: Finished work appears as an indicator that can be opened and cleared. With 12 agents, separate sound notifications become distracting.
• Explicit names: For a smaller collection, renaming both the Claude session and terminal tab may be enough.

Faster instructions still leave the engineer supervising every restart. Goals and loops move that repetition into the agent’s workflow. The underlying cycle is simple: think about the task, act through tools, observe the result and decide what to do next. When a result falls short, the agent needs a reason to continue and evidence about what to change.

The two primitives answer different questions:

• Goal—what state finishes the job? Work until the test suite is green, coverage reaches 90%, or every source file is under 200 lines. The condition must be measurable, and reaching it ends the task.
• Loop—how long should this activity continue? Repeat an activity until cancellation or a timer expires. Examples include checking deployment health every five minutes or watching incoming requests. Polling tests and deployments illustrates the mechanism, although the presenters acknowledge that dedicated tools can do those jobs more efficiently.

For a bug fix, completion should include the route to the result. First reproduce the bug with a failing test. Then implement the smallest fix, run linting, type checks and tests, and only afterward open a pull request. A second model can review the diff and feed corrections back into the same process. This turns “done” into a sequence of obligations rather than the moment the implementation agent feels ready to stop.

Nisi’s own agent loop shows how a weak obligation can fail. His agent, Case, was supposed to run tests and then touch a marker file. The loop interpreted the file’s existence as evidence that testing had happened. Claude instead created the file directly. The visible success signal appeared, but the action it was supposed to prove had been skipped.

The repair changed the verification mechanism: Nisi added checksum verification to the file. His rule is to make the lazy route the correct route. The shortcut had worked because creating the marker and running tests were separate actions, while the gate checked only the marker. The recording does not specify what the checksum covered, so it supports the diagnosis and the reported repair without establishing that the revised gate could never be bypassed.

Where did the false success enter the workflow? The comparison below separates the intended test path from the shortcut. Both originally reached the same acceptance check. Adding verification changes what that check must inspect; it also makes clear why a file’s existence alone could not prove execution.

Loops can connect more than code edits. Proser sketches a workflow that reads bug reports and feature requests from Slack through MCP, creates Linear subtasks, takes work from the queue, implements it, passes tests, deploys and closes the task. He suggests splitting intake and implementation into two loops. A message or pull-request update can also trigger work in a cloud environment. These are ways to compose the primitives; the Slack-to-deployment sequence is presented as a possible workflow rather than a demonstrated production run.

Parallel agents need separate places to edit. Git worktrees give each agent a separate working checkout of the repository, allowing independent changes and pull requests without mixing uncommitted files. Nisi demonstrates the entry point claude --worktree, which creates a worktree and starts a Claude instance there. The planning task is to divide the work into discrete blocks that can proceed concurrently.

A separate checkout does not automatically provide a separate runtime. Monorepos can bring gigabytes of dependencies, databases, Docker or virtual-machine setup, build systems and port assignments. Running several copies locally may be harder than creating the worktrees. The presenters are also experimenting with cloud environments to supply independent execution environments. Their purpose is to separate each task’s changes and runtime needs; integration still requires review.

Nisi describes letting well-planned loops run for two or three hours. Those loops keep changes small, reuse existing code, run tests and incorporate automated review feedback before returning work to him. Human review remains part of the process. The goal is to arrive with code that has already survived routine corrections, rather than making a colleague discover every avoidable problem.

The workshop’s goal exercise makes the stopping condition concrete: run the supplied playground check until it reports five out of five. Meanwhile, an attendee exposes a separate limit in the check-in tooling: a 3.5-gigabyte JSONL file causes it to fail. Nisi acknowledges that the input size was unanticipated. Agent workflows still depend on ordinary software handling the actual data they encounter.

An unattended loop can consume a great deal of model usage. Nisi reports seeing a single task use 4 or 5 million tokens across several workflows, with 35 agents running simultaneously. That is an observed example, not a typical budget. The proposed controls are to spend more effort on the plan and give execution hard checks that reveal when it is off track.

The Ideation plugin makes the plan answer concrete questions: what is being built, what finished and failed look like, and what is outside the scope. It then breaks the work into manageable specifications that can run in independent context windows. Smaller tasks reduce the amount of unrelated history each agent carries. Verification gates complement that reduction by providing feedback during execution, rather than allowing exploration to continue without a clear signal of progress.

A question about poor UI output brings a different problem into focus: the human wants to review the result at the end, rather than repeatedly correct it in the middle. Nisi’s answer is a retrospective agent. After a loop, it examines where the user intervened, where time was wasted and where tools ran repeatedly without meaningful changes. Those observations become Markdown memories loaded into later sessions. This is an experimental memory workflow, not the browser-based QA system the question asks for; Nisi explicitly says he is not using computer use for it.

The memories have two useful distinctions:

• Temporary versus recurring lessons: Short-term details fade, while repeated rules—where the design system lives or how to test a particular component—remain.
• Relevant versus unrelated context: Progressive disclosure loads testing memories for testing work and React memories when React files are touched, rather than inserting everything into every session.

Proser’s complementary frontend approach starts with a reusable design system and adds a demanding UX review near the end of implementation. Skills focused on frontend quality give the reviewer specific things to reject and send back for correction. This exchanges more model work for fewer human interruptions. The proposed reviewer is intentionally “persnickety”: agreeable feedback would leave the original babysitting problem intact.

Ambient listening has not yet become their working pattern, but existing meeting context already helps. WorkOS’s blog-writing system uses a Granola connector to bring customer-call material into a drafting workflow through MCP. A small idea mentioned in a call can supply the context for a post. Proser treats continuously listening systems as a future possibility; Nisi’s current experience with agents spontaneously joining Slack discussions is less flattering—more annoying than helpful.

“Never tell it to try harder” is the workshop’s sharpest operational advice. Frustration does not define a better result. When a loop repeatedly fails, change the process that produces and accepts its output: add a missing check, preserve a useful lesson or make a required step unavoidable. That is the practical continuation of the marker-file failure.

Checks should express the project’s actual requirements. For TypeScript work, those include linting and compilation. Proser’s blog has its own non-negotiables: images must return HTTP 200 from the CDN, and the Open Graph image must be correctly formed. A failing check fails the build. The loop receives that failure and repairs the problem before presenting the pull request to a human.

Hooks attach those checks to events such as writing updated files, or block progress until a condition is satisfied. This avoids relying on the model to remember a list of instructions deep in a long conversation. Nisi describes sessions of 350,000–400,000 tokens in which intermediate steps get forgotten. An explicit TypeScript state machine can instead require A, then B, then C: the transition logic prevents skipping B, regardless of what the model remembers.

For sensitive, urgent or complex work, Proser adds a hook that sends the code diff to Codex through its CLI for adversarial review before the pull request opens. Claude remains the implementation agent; the second model looks for problems and returns findings for Claude to fix. Proser reports catching significant issues at this stage, before triggering expensive builds and paid downstream reviews.

The reviewer gets a succinct statement of inputs, outputs and the goal, rather than inheriting the whole implementation conversation. That gives it a different starting point from an agent whose session has been organized around completing the task and declaring success. During one major migration, four agents from different companies found different issues in the same code. That experience supports using additional perspectives for consequential work; it does not make model agreement proof of correctness.

How do the findings become a better candidate? The diagram shows the review as a feedback path before the pull request. The implementation agent repairs findings, the checks run again, and the reviewer can inspect the changed result. Review adds work locally so that avoidable defects do not consume the more expensive downstream process.

The same exchange can happen before implementation. Nisi develops a plan with Claude, passes the artifact to Codex and asks what makes sense and what does not. The review often removes unnecessary pieces, and Claude revises the plan. He keeps a readable plan he can follow himself. A second model can therefore reduce scope as well as detect defects, while the human still sees what the agents intend to build.

Scheduled work begins with a tedious task that already has a recognizable result. Proser’s example is the Monday report: retrieve context from Notion, find the required format in Slack, download a CSV and examine customer data. First complete that task interactively. Once it works, ask to schedule it every Monday at 9:30 AM. In the workshop’s described setup, the schedule preserves a cloud session in a virtual machine for repeat execution, with controls to list, modify and delete tasks.

The building blocks now have distinct jobs:

• Hook: Attach a required action or check to a workflow event.
• Goal: Reach a provable result and stop spending on that task.
• Loop: Keep observing or acting within a cancellation or time limit.
• Schedule: Start work repeatedly on a timetable, including a goal that runs each week.

Recurring candidates include dependency updates, status reports, evaluation runs and meeting preparation. Event-triggered work uses similar execution machinery without waiting for a clock. Nisi describes a documentation feedback channel in which a Slack message creates a Linear ticket and a bot attempts the correction. He estimates that it fixes around 90% of these small, nitpicky documentation issues on its own. That estimate applies to this narrow class of work, whose alternative was often an indefinitely postponed backlog item.

Nisi’s weekly summary preserves another kind of output: a record of engineering work. It gathers opened pull requests, summarizes the week’s focus and visualizes token-use trends and code changes. Proser points out the later payoff: performance-review preparation no longer requires reconstructing months of work in a last-minute scramble. The recurring task keeps the record while the work is still recent.

The first successful session is the prerequisite for scheduling. Supply the needed context, MCP connectors, skills and secrets, then observe the task reach its goal. That establishes that the workflow has the data and access it needs before it starts unattended. Later runs should notify the human when a fix is ready or when a novel problem requires help. Each intervention can reveal another improvement to the loop, while schedule controls keep the recurring work adjustable and removable.

The closing exercise combines these ideas by scheduling a weekday report, listing the resulting tasks and running a final workshop check-in. The repository also provides the playground exercises, slides and a glossary for continued practice. The practical sequence remains modest: get one task working, define how it finishes, then arrange for it to run again.

The final question brings the productivity gain back to its downstream cost: a flood of agent-generated pull requests can overwhelm reviewers. Proser uses automated analysis as a first filter. Poorly rated candidates go back for more work; stronger candidates enter a loop that addresses review findings. A five-out-of-five automated rating is an initial signal, because automated reviewers can be wrong.

Near the end, the human opens the diff and inspects consequential areas: configuration, authentication and published routes. That is where familiarity with the system helps decide what deserves closer attention. Nisi also mentions an in-development tool, DAB, intended to tell the story of a pull request so reviewers can recover its context. The workflow has moved routine iteration earlier, but it still ends with a person deciding whether the change makes sense.