How a Cloudflare Engineer Ships Production Code He Didn't Write | Dillon Mulroy

Dillon Mulroy describes a workflow in which agents write most of the implementation, but he still chooses the architecture, steers the context, and reads every line. His practical contribution is a way to agree on the shape of a change before generating it: types, call paths, error cases, and planned tests, followed by local review in small increments.

This summary uses the saved English auto-generated captions, which contain transcription errors; it is not an original-audio verification. Productivity and organizational claims are the speakers' accounts. The video was published September 10, 2026, but the speakers identify the conversation date as June 25, so model, pricing, and tooling remarks should be read in that earlier context.

Main takeaways

• Delegating implementation does not delegate accountability. 08:19–11:21(opens in a new tab): Mulroy distinguishes his workflow from leaving agents running unattended and accepting their commits. He says he reads every line and applies the same engineering principles and experience as before; the means of producing the code changes, not the person responsible for its effects.
• More output can coexist with less satisfaction and more fatigue. 13:28–17:45(opens in a new tab): he previously alternated large design decisions with smaller implementation problems that supplied frequent moments of progress. Agents remove much of that second activity, leaving a succession of demanding design decisions without the same flow. This is his explanation of his own experience, not a measured effect for all developers.
• Training engineering judgment remains an open problem. 19:53–22:52(opens in a new tab): both speakers learned through implementation mistakes and production failures. Mulroy attributes architectural intuition to seeing many patterns succeed and fail, but offers no settled replacement for that learning process when newcomers can prompt past the struggle.
• Broader participation does not make specialties interchangeable. 26:43–34:49(opens in a new tab): Mulroy describes agents generating Playwright tests and recordings for changes, and product managers making prototypes to communicate ideas to engineers. Wortmann questions whether this implies one person can do every role; Mulroy agrees that a useful prototype is not a production-ready change and that skilled product management retains distinct value.
• Expensive autonomous loops are not his default workflow. 34:49–40:10(opens in a new tab): Mulroy argues that the token budgets and uneven results of lab-promoted workflows make them impractical for many developers. He wants stronger evidence of consistent quality before treating those workflows as generally economical. This is a dated assessment, not a current price comparison or benchmark.

The workflow in detail

• Keep the harness stable enough to learn its behavior. 45:47–48:56(opens in a new tab): his tools include Ghostty, Herdr, Pi, and Plannotator. He values Pi's small system prompt and limited tool set because changes to a harness—the instructions and tools around the model—can change its behavior even when the model stays the same. He prefers modest customization and less automatically injected context.
• Review locally before asking the team to review. 48:56–51:01(opens in a new tab): Plannotator presents a local diff with file-level review comments that feed back into the agent session. Mulroy keeps individual changes around 300–800 lines so he can understand them without his attention collapsing. Stacked pull requests let a later change build on an earlier, still-unmerged branch while keeping each review scoped; the line range is his working preference, not a universal quality threshold.
• Build shared understanding before freezing a spec. 51:01–53:08(opens in a new tab): he annotates either a Markdown document or the agent's latest message and returns that feedback to the conversation. The discussion gradually becomes a spec; he writes it to a file and starts implementation only once he trusts that they agree on what to build.
• Use conversation branches to control which research enters the working context. 53:08–55:08(opens in a new tab), 58:04–1:01:12(opens in a new tab): he asks questions whose answers he already knows about libraries or existing abstractions, checks the agent's understanding, and develops separate branches for topics such as Hono and SQLite storage in Durable Objects. Pi's /tree lets him return to an earlier conversation point with no summary, an automatic summary, or a prompted summary. He often copies a selected conclusion or saves it to Markdown. This changes conversation context, not Git history. His preference over subagents is control over the returned evidence, not a claim that subagents cannot isolate research.
• Make the spec describe code structure, not only product requirements. 54:02–57:01(opens in a new tab): his specs contain TypeScript types, interfaces, required adapters, and a call path showing inputs, outputs, and possible errors at each step. He also asks for the tests the agent will write using a red–green–refactor cycle. He trusts agents more with implementing a bounded function than with choosing and composing abstractions, so he spends the planning effort on those boundaries. He explicitly says this still requires correction; the approach does not eliminate mistakes.
• Automating his steering process is a proposal, not the current result. 1:02:03–1:04:31(opens in a new tab): Mulroy imagines a queue that moves work through technology exploration, spec drafting, and review, with him involved at each stage. He is trying to capture recurring design preferences in skills so an automated first review can remove repetitive corrections. His near-term goal is saving some review time, not replacing human judgment.

Other discussion and evidence limits

The interview also covers Cloudflare's layoffs and Mulroy's interpretation of their relationship to AI 23:42–26:43(opens in a new tab), plus criticism of a model's data-retention and automatic-routing behavior 41:13–43:40(opens in a new tab). These passages are commentary, not independently verified company explanations or provider-policy documentation; use current official sources for employment figures, procurement, or privacy decisions.

Source

Jan-Niklas Wortmann — How a Cloudflare Engineer Ships Production Code He Didn't Write | Dillon Mulroy(opens in a new tab), published September 10, 2026. Tool-name spellings follow the publisher's video description where the captions are inconsistent.