Idea #1
The right unit of agentic automation is the AI Developer Workflow (ADW), not the loop. A loop is a generic, undifferentiated retry cycle; an ADW is a structured, repeatable sequence that maps to how a real developer actually walks through a task — plan, build, test, deliver — with agents and code executing each phase at the right time using the right model. The distinction matters because ADWs compose: once you have several well-defined ADWs (feature build, hot fix, prototype, ideation, deploy to staging), you can compose them into something that starts resembling a software factory — a system where multiple workflows operate in parallel or in sequence, covering the full SDLC without requiring the engineer to drive each step manually. The software factory is not just running a plan-build-test-deliver loop repeatedly; it's the hot fix, the feature prototype, the ideation pass, the staging deploy, and the permutation test all running as coordinated workflows. The concrete implication for practitioners is to stop thinking in terms of 'I'm going to run a loop' and start thinking 'I'm going to define a repeatable workflow for this class of work, then eventually automate the workflow itself.' Each ADW is a leverage multiplier; composing them is an exponential one.
Idea #2
The right mental model for agentic work is a bidirectional operating stack, not a one-way escalator to 'higher leverage.' The stack runs from individual lines of code up through functions, files, directory structure, database tables, scripts/CLIs, application, repository, planning/documentation, agent workflows, and software factory. Moving up gains leverage and speed; moving down gains control and understanding — and both directions are permanently in play. The error most engineers make is treating 'move up' as the only goal, which produces systems they can't debug, steer, or correct when they break. The real skill is knowing when to shift direction: move up when the work is familiar and repeated, when the domain is understood, and when the output has many parallel artifacts; move down when the domain is unfamiliar, the system is new, the risk is high, or the debugging evidence is weak. The framework is explicitly not about where you sit statically — it's about the range you can move across dynamically. A concrete illustration: an engineer who can only inspect the running application (vibe coder level) is capped in impact because they have no way to reason about what's wrong below the surface; a senior engineer who can fluidly move from reading database table schemas all the way up to designing multi-agent workflows has a much larger effective range and can make qualitatively different interventions.
Idea #3
You cannot scale what you do not understand — and this constraint applies both to your own domain expertise and to the model's knowledge. Attempting to operate a software factory or AI developer workflow in a domain you haven't internalized produces compounding errors with no ability to detect them, because expertise is fundamentally the ability to distinguish good outcomes from bad ones given certain inputs. If you can't make that distinction, you have no fitness function, and agent outputs become unverifiable noise. The same logic applies to the model: 'out of distribution' means not just gaps in what the model knows, but also behaviors it has been trained against — things it actively does wrong. Both forms of out-of-distribution failure require the practitioner to step down the stack, apply their expertise, and effectively extend the model's useful range through in-context examples, structured prompts, fine-tuning, or multi-model fusion that fills the gaps of individual models. The practical rule offered is: don't collaborate with an agent (or person) who doesn't know what you're trying to do; if you must, you'll have to teach them. The hardware robot example makes this concrete — someone with no embedded/hardware domain knowledge cannot productively run agentic workflows on hardware control code without first going all the way down to the line-of-code level and building foundational understanding, because they have no basis for judging whether anything the agent produces is correct.
Source: Agentic Engineering Operating Level: WHERE to FOCUS your AGENTS? (IndyDevDan)
Text summarized and optimized using Anthropic’s models and reviewed by a human.