After 15,700 agent sessions: David Ondrej's agentic engineering workflow, reviewed

Most 'agentic engineering workflow' content is moodboard material: a stack of sub-agents, a dashboard screenshot, a diagram. David Ondrej's newest video does the opposite. 'My Agentic Engineering Workflow (after 15,700 sessions)' is his two-month update. The previous installment pulled close to 200,000 views; the new one is harder on process and more skeptical of tooling. He cites more than 2,500 hours of AI coding across four years and three AI startups as the basis. The part worth stealing is not the shopping list. It is a review discipline: he has his own session history analyzed, counts open agent threads as a hard number, and turns that into a pipeline meant to run with no human in the loop. I run agents continuously myself, and three points in the video match what I see day to day: one task per session, cross-review by a second frontier model, and the finding that nine out of ten agent-written tests are slop that verifies nothing.

The model talk is almost a footnote, which is itself notable. Anthropic's Opus 5.5 is his pick for the best model right now, fast enough that both of his subscriptions went dark and he jokes about a third account. On the OpenAI side he weighs Astra against Soul and favors Astra's frontier character. Google, Meta and Kimi models are usable in his words, just not frontier. The sharper claim is architectural. He currently moves between pi, Claude Code, Hermes and Open Code, and his conclusion, reinforced by two Anthropic engineers he spoke to at an office event, is blunt: once a strong model has terminal access and internet, harness differences basically stop mattering, whether that harness is Devvin, Droid or Claude Code. For anyone operating agents long-term that is an instruction: invest in session standards and review loops, not in harness comparisons.

The core habit is session discipline. Every agent thread handles exactly one task, one feature, one bug fix, one research question. New focus means a fork into a new session, never a mix. He gives a mundane example: OBS crashed while he was about to record, and a separate thread existed just to reproduce that. When the task is a bug, the agent first reproduces it end to end like a real user, through simulation, tests or experiments, until the failure is reliably understood. Only then does a frontier model, his choice is Opus 5.5, implement the fix, followed by automated checks and, when the change is visible, screenshots of the real app so there is proof of what changed. He treats screenshots as evidence, not decoration. After the fix come tests, security checks and a review loop before the pull request merges to main. Break the one-task-per-session rule and diffs become unreadable, because the context of your billing fix bleeds into your UI experiment.

The second pillar is how output gets judged. Ondrej puts his own throughput on the table: 100 to 200 contributions per day reaching production, which he counts as more than 700 commits a week on his GitHub profile. The safety net for that volume is cross-review. Small changes get a standard review pass; big or risky ones get read against by a second frontier model with high reasoning effort. The point is not which tool runs the review but that the loop exists: the reviewer catches what the first agent papered over, found issues trigger a re-review until the fix is clean, and a separate loop watches for side effects and security problems. He adds a warning worth quoting: if you accept review output without your own look, you produce slop, and a reviewer that fires constantly gets re-examined in his setup instead of being obeyed blindly.

The most misunderstood part gets a counterintuitive answer. He repeats the quip that sub-agent orchestration has become 'astrology for vibe coders' and draws the line sharply. Sub-agents earn their keep when the work is clear, parallel and chunkable into predictable sessions: classifying 2,000 documents, categorizing your own agent sessions, processing an inbox of PDFs. In that case the pattern is one strong main agent plus ten or twenty small sub-agents running in parallel, something in the Haiku class, with the main agent collecting results and deciding what happens next. Innovative work is the exception. Building something new means dead ends, surprises and unexpected coupling across the codebase, and for that he wants a frontier model with full context figuring things out itself. The failure mode of small agents on unknown terrain: one fixes a bug, discovers mid-patch that the code is coupled with billing, and keeps going blind because it never had the context the main agent had. Rule of thumb: the more unpredictable the work, the fewer sub-agents and the more context in the main agent.

Two more threads sharpen the picture. The first is his case against agent-written tests. Ondrej is openly test-skeptical, because by his estimate over 90 percent of the tests an agent writes are pure slop: code that exists to turn the suite green without verifying anything. Tests get written to pass the test, not to catch defects. His correction is curation over volume: strategic tests at real regression points, on critical user paths, around security boundaries, and beyond that, trust in the review loop. Let agents spawn thousands of lines of test code and you get a suite that fires constantly while proving nothing. The second thread is self-measurement. He insists on quantifying your own productivity instead of trusting feel, with the GitHub contribution chart as the hard proxy, because without the number people drift into building internal tooling and call it progress while real output stalls. His chart reads in three phases: an inactive stretch, a pickup from late spring, and the steep acceleration since September and October that he attributes to leaning on cloud agents, with growth he expects to keep compounding.

The framing around all of this is the self-improving software factory: software that gets better with every user and every reported error because agents absorb the repair, verify it and keep shipping. There is also a meta-moment about how the workflow itself was made. Ondrej did not write it out from memory. He had Opus, through a room CLI, analyze his own session history, over 550 open threads in that snapshot, more than 800 the day before, literally thousands across recent weeks, and the process description in the video is the distilled output of that analysis. He also names his sources: interviews with the CEO of Vercel, the CTO of Supabase and the CTO of Fireworks, plus time with the productive end of the field. In his telling those conversations reduce to the same two variables: session discipline and verified output. Model names, harness chrome and sub-agent cosplay are second order, and the video keeps its emphasis there on purpose. He also mentions Windows support for his tool Cloud Room as that day's news, minor for him, practical for anyone running agents on mixed setups.

None of this requires his own tool, and he says so while showing it. The principles port to any harness with multi-session support and terminal access, including Hermes and pi: one task per session, a frontier model with full context as the workhorse, cross-review by a second frontier model, sub-agents only for parallel chunks, and loops that log and fix every error users hit while verifying their own work. He frames the fully automated version as still under construction, the human is not yet out of the loop, and the stretch into 2027 is where he expects that to be decided. The 15,700 figure matters because the workflow is derived from session history rather than invented. By his account and mine, the weakest point of most current setups is unverified agent output: test suites that assert nothing, reviews that rubber-stamp. Cross-review of frontier models is the cheapest insurance against exactly that, and it costs no new tooling.