An agentic engineering workflow you can copy: what senior devs actually run

Three weeks ago the first piece on agentic engineering covered what the discipline is and what a founder who does not code can take from it. This is the sequel for everyone who kept typing "workflow" into the search bar. An interview series keeps spiking on my competitor tracker, every episode promising a senior engineer's setup. I pulled the transcripts, checked what could be checked, and boiled their setups down to five steps. The surprise is how boring the good parts are - and the boring parts are the ones that transfer.

Published October 10, 2026 · By Dmitry Tolstoi · 9 min read

What does an agentic engineering workflow actually mean?

In short: the workflow is the loop around the agent - decide, brief, verify, review, ship - and it outlives whichever tool is hot this month.

The term has a home at agenticengineer.com, but the plain version fits in a sentence: agentic engineering is running coding agents as the workforce while you keep the decisions, the context and the checks. A workflow, then, is your standing answer to five questions: who makes the design choices, what the agent reads before it starts, what counts as done, who reviews the output, and what physically stops the mistake you cannot undo.

Stack Overflow's 2026 developer survey, published October 6, shows why the loop matters more than the tooling. Sixty-six percent of respondents use coding assistants or agents and 73 percent use AI tools daily - yet 48 percent only trust output they can easily validate, and just 16 percent go further. The industry sits in the gap between "everyone runs agents" and "almost nobody believes them." A workflow is the bridge you build across it for your own repos.

What do the viral workflow interviews actually show?

In short: the clicks go to tool tours that expire within months, while the senior engineers interviewed run local, conservative loops built around verification.

On my competitor tracker, David Ondrej's interview "Pi Agent dev reveals his Agentic Engineering Workflow" sat at 203,200 views on September 21 - 4.4 times his channel median - and passed 226,000 a week later. His own "My Agentic Engineering Workflow (after 6,775 sessions)" measured 152,900. By early October a new episode was adding 23,200 views a day. People badly want someone else's setup.

The transcripts tell a split story. The host's own video is a tour of interfaces, voice dictation, snippet macros and stacked subscriptions - and he says himself the whole thing could look different in two months. The guest of the biggest episode is Armin Ronacher, creator of Flask, whose company Earendil now runs the minimal Pi agent. His description of his own practice runs the other way: agents on his own Mac, one Linux box over SSH for long jobs, a little CI automation. Most of his time, he says, goes to figuring out how things should work rather than generating code. He calls his setup very conservative. The five steps below are the overlap - the habits the maximalist and the conservative agree on.

Step one: decide before the agent builds

In short: models implement well and choose badly, so senior setups extract the decisions first and write them down where the next agent will look.

Ondrej runs a skill he calls ask-then-build: before any feature work, the agent must present the main choices as options - keep platform parity or ship binary-only, that class of decision - and wait for a human pick. His reasoning holds up in my practice too: current models are strong at implementing a plan and weak at taste. Anthropic's own guidance on building agents points the same direction - simple, composable patterns with the human owning the design.

The second half of the step is writing the choice down. He keeps a decisions folder in each repo: one short markdown file per architectural decision, with the reasoning and the project state at the time. Future sessions read it instead of re-litigating. My pipeline does the same job with a written brief and a policy file the agent loads at start - cheaper than re-explaining constraints forever.

Step two: put the context in files, not in your head

In short: anything you tell an agent twice belongs in a file it reads itself - prompts become snippets, procedures become skills.

The mechanics: a prompt you have typed twice becomes a text snippet; a procedure you have walked an agent through twice becomes a skill file in the repo. Subtract the interfaces and Ondrej's public collection of skills is most of what his viral setup consists of.

Ronacher's angle explains why plain files keep winning: markdown, JSON and Unix pipelines ended up as the underpinning of agent work because humans can read them too. Pi, the minimal agent his company maintains, is the bet taken to its limit: four default tools (read, write, edit, bash) and a system prompt under 1,000 tokens. There is no MCP, no subagent layer, no plan mode - a design implicator.ai's teardown describes as deliberate. If a frontier model no longer needs an instruction manual for engineering, your context files only need to carry what is special about your repo: conventions, run commands, and the three mistakes agents keep repeating there.

Step three: verify the artifact, not the report

In short: an agent's success message is a claim; the tests that ran, the pages that render and the rows that changed are the evidence.

The sharpest story in the Ronacher interview is a debugging session, retold from the transcript. He was helping a developer who built everything through a cloud coding environment, and asked how the database tests run there. The answer, after they dug in, was that they never had. No Postgres instance had ever started in that environment - the setup had quietly mocked the database away, and the tests kept reporting green the whole time.

My own operation runs on this rule: a step counts as done when the artifact can be checked, and the check itself is written down. The pipeline that publishes these articles on a schedule with no human in the loop survives on it - the operator's checklist piece walks through what that looks like. One warning from the same video: Ondrej notes that current models add tests compulsively, so you have to tell them when not to. Verification is a signal problem, and a hundred pointless green checks are noise hiding the one red that matters.

Step four: review once, with a different model

In short: one cross-model review pass catches real defects; looped reviews invent imaginary ones and nothing ships.

Ondrej's review pattern is worth copying exactly. Build with one model, review the diff with a model from a different family, merge the findings into a single deduplicated list, fix the worst items, ship. He is equally specific about the failure mode: do not loop it. Ask any model for the five biggest issues and it returns five, clean codebase or not - no current model answers "this is fine, go ship." Recursive review is how a change dies of imaginary bugs. Small cosmetic diffs do not get the ritual at all.

The reason to keep the pass honest is measured, not felt. METR's randomized trial - 16 experienced open-source developers, 246 real tasks - found them 19 percent slower with AI assistance while believing they were faster. Review time is real time. Spend it once, where the diff is big.

Step five: lock everything you cannot undo

In short: guard hooks, a single ship lock and read-only database roles cost minutes to set up, and each exists because somebody lost something.

Three locks recur across these setups. First, a guard hook that fires before every tool call and blocks dangerous patterns outright: recursive deletes, git history rewrites, anything touching a password manager. Ondrej calls it the precondition for running agents with permission prompts off. He is right. Second, a ship lock - an OS-level lock so only one agent at a time may run the merge, verify, push, deploy, health-check sequence. Third, a read-only database role for production data: agents get answers for their work, never a DELETE.

I earned the second lock personally. Two windows of my own pipeline once deployed the same article a minute apart; their test runs shared one database and overwrote each other's data, and for a night it read as a product regression. The actual regression was two agents holding one door. The fix was a lock file and has held since.

When do worktrees, subagents and cloud actually pay off?

In short: parallel machinery has thresholds - worktrees past a dozen simultaneous agents, subagents only when you pick them deliberately, cloud when sessions must outlive your laptop.

A git worktree is a copy of your checkout on its own branch, so parallel agents stop reverting each other's edits. His threshold: pointless on small projects, unavoidable somewhere past fifteen agents working at once. Subagents get the same treatment - he launches them through his own rules and picks their models, because the tool defaults happily delegate to the cheapest one available. On cloud agents he shows a chart attributed to Cursor's internal data: nearly 60 percent of merged pull requests there now come from cloud agents. I could not verify that figure; read it as a vendor slide. Ronacher, for contrast, keeps nearly everything on his own hardware, because it is faster and the data already lives there.

The one economic point both make: subscriptions, never per-token API pricing, for day-to-day agent work - Ronacher says plainly he would barely use AI at API prices. Running several agents as one person is its own craft - the operator's playbook covers it. Start local and single-threaded; add machinery when the pain arrives, not in advance.

What does a copyable first week look like?

1. Day one: pick one repo and one agent tool. Write the context file - conventions, run commands, the three mistakes agents keep making in this codebase.
2. Day two: add a decisions folder. Before the next feature, have the agent present the main choices, pick yourself, and record each pick as a one-page note.
3. Day three: define done for one task type - the artifact plus the command that checks it - and stop accepting the agent's own report as proof.
4. Day four: install a guard hook, create the read-only database role, and put a lock on your deploy path.
5. Day five: run one real change end to end - decide, build, one cross-model review, fix the worst finding, ship.

By Friday you have shipped once and left files behind that make next week cheaper. That compounding is the workflow. Everything else in the videos is accessories.

Where this comes from

The two David Ondrej videos are linked where cited; I read them through their transcripts, and every workflow detail from them is reported as his claim. That includes the fifteen-agent worktree threshold and the Cursor cloud-agent chart, a vendor figure I could not verify. The Armin Ronacher material is paraphrased from his interview on the same channel, because auto-transcripts garble names and wording. Pi's design facts and the Earendil acquisition are from pi.dev, implicator.ai's analysis and the Syntax episode with Ronacher and Mario Zechner. Survey figures are from Stack Overflow's 2026 developer survey, published October 6, 2026. The 19 percent result is METR's randomized trial, linked where cited. View counts are my own competitor-tracker measurements from September 14 to October 5, 2026. The pipeline stories are my own operation's rules, stated as mine and promising nothing about your results.