David Ondrej's Agentic Engineering Workflow: Review and Loops

David Ondrej’s agentic engineering walkthrough is less about a magic prompt than an operating system for coding work. His sequence is to give an agent one task, make it reproduce or understand the problem, let it implement, apply a review proportional to risk, and move predictable work into repeatable loops. The striking numbers in the title and video are David’s own activity figures, not an independent measure of software quality.

Watch David’s Full Workflow

David built and promotes Cloudroom, the environment shown throughout. His claims of 15,700 sessions, 10,540+ yearly commits and automated production throughput are self-reported; we did not inspect his private session history or production incident rate.

Start With One Task Per Thread

David’s day-to-day flow begins by separating tasks. For a bug, he asks the agent to reproduce the user-facing failure before touching code, then implement the fix, run checks and show screenshots when the UI changes. For a larger feature, he spends more effort on product and architecture decisions before generation. That distinction matters: a failed reproduction can mean the agent misunderstood the report, and a passing test can still miss a bad product decision.

He argues that knowing the system’s vocabulary matters more than perfect prompt phrasing: boundaries, coupling, observability, failure modes and blast radius. The practical translation is to tell the agent what must remain true and how the result will be checked. His high-volume setup uses Claude Code with Opus 5.5 inside Cloudroom, but his public skills repository says its instructions can be used with other coding agents too.

Increase Review Effort With Risk, Not Commit Size Alone

David’s review ladder starts light for small, reversible edits and becomes more demanding for broad or customer-visible changes. He has one model implement and asks a model from another provider for a neutral review. He then deduplicates and verifies findings rather than accepting every speculative warning. For his rare highest-risk changes he describes a multi-model “total review.” The public skill confirms that this is a resource-heavy, manually invoked process, not a default for every typo.

This last column is our recommended guardrail, not a claim that David always pauses. He advocates fully autonomous fixes for some production loops. Two models agreeing does not independently prove a change is safe: they may share the same blind spot or the same misleading test. Anthropic’s security guidance and permission controls are useful context before giving an agent write, network or deployment access.

Five Public Skills Worth Inspecting

These are instructions in David’s MIT-licensed skills repo, not guarantees of a safe outcome. Read a skill before installing it: some require particular models, a Cloudroom command interface or broad permissions.

Use Sub-Agents and Cloud Machines Selectively

At 22:36, David says delegation pays off when jobs can be partitioned with clear inputs and outputs, such as analyzing many independent documents. A vague feature request that needs one coherent design often gets slower when split among agents. The coordination and reconciliation cost is real, even when the model calls are parallel.

His cloud-versus-local section favors cloud work for long-running parallel tasks and local work when he needs his own machine. Cloudroom’s README describes separate cloud sandboxes and Git branches, but also says cloud agents can access a Mac under Off, Read-only, Ask first or Full settings. The same README says cloud agents run without approval prompts. Isolation therefore depends on the actual permissions, credentials and connections, not merely the word “cloud.” For local parallel branches, Git worktrees provide separate working directories while sharing repository data; they are not full independent Git clones.

Automate the Repeatable Step, Then Measure It

David’s most ambitious claim is that small agent loops compound into a software factory. He describes 33 loops and about 2,000 runs a day at the time of filming. Those are his operating numbers, not a benchmark readers should chase. His own advice is to find a repetitive task in your sessions, rather than install every skill he uses. The public Goal Loop skill is more restrained than “run forever”: it calls for a measurable stop condition, validation command and explicit constraints.

A useful first loop might classify incoming bug reports, collect reproduction details and draft a proposed fix. Keep deployment outside the loop until you know its false-positive rate, average cost, failure recovery and effect on actual defects. A dashboard of commits alone cannot answer those questions. David also discusses local inference near the end, but his headline workflow predominantly uses hosted frontier models; running a local model is an option, not a requirement for the method.

Try One Bounded Change This Week

Choose a reversible bug or small internal feature with a known owner. State the expected behavior, let the agent inspect and plan, approve the edit, then compare the result with an independent review and your normal CI. Record time saved and correction work. That gives you a credible baseline before adding sub-agents, cloud access or unattended loops.

Video Chapters

Sources and Scope

Source note, 31 October 2026: The video and supplied transcript establish what David demonstrates and claims. We checked the named skills against his public repository, Cloudroom’s feature and security descriptions against its source README, permission behavior against Anthropic’s documentation, and worktree behavior against Git’s manual. We did not reproduce his builds, audit commit history, verify session totals, measure his defect rate or test Cloudroom’s security claims. David is Cloudroom’s creator; the tool receives sustained promotion in the video. The review and release gates above include our editorial recommendations and are not a transcript of his exact policy.