Idea #1
Design from the software development lifecycle down, not from agents up. A mental model shift is necessay for productivity. Instead of asking ‘what agents do I need?’, start asking ‘what is the complete SDLC for this task?’ and then build that with agents/skills executing and governing each phase.
The SDLC structure and details may depend upon the task at hand, namely a new waterfall project, a legacy thick or web app refactoring, the evolution of an application using agile, or refactoring Cobol code in Java. But the high level structure is similar: plan, build, test/fix loop, review/revise loop, document, commit — and it battle-tested because it separates concerns naturally, defines done at each stage, creates clear handoff points, and places quality gates where engineers already know they belong.
In reality within an Enterprise-level SDLC there is much more. There are different project streams like, for instance, technical architecture, application, and change management governed by different professionals.
Agent-first thinking tends to produce ad-hoc orchestrations that work once but do not scale, and may not capture the essence, the practices, the deliverables, the boundaries of the role, because they lack the structural discipline. SDLC-first thinking also makes model assignment obvious (frontier models for planning and review, cheaper models for mechanical build steps), naturally suggests where deterministic code gates belong (at phase boundaries), and produces pipelines that are easy to inspect and improve because each phase has a single, named purpose.
In this light ‘Loop engineering’ should be rejected as a poor and misleading rebranding of the SDLC.
Idea #2
Stop debating which model is best and start maintaining a model stack that assigns models by role and phase based on cost, speed, and capability.
The insight is that different SDLC phases have genuinely different requirements: planning and review benefit most from deep reasoning quality; building often just needs reliable, fast code execution; scouting needs breadth but not frontier-level depth.
A well-designed model stack assigns tiers accordingly — frontier models (Fable 5, Opus 5) for planning and review, A-tier workhorses (Gemini 3.6 Flash or Sonnet 5) for building, lightweight models for on-device tasks — and the software factory is the mechanism that makes per-phase model assignment practical.
As a side benefit this also distributes vendor risk: mixing Anthropic, Google, OpenAI, and other models available through Open Router or Fireworks per phase means no single provider failure or pricing change breaks the whole pipeline.
An example of the ‘model stack’, that must be explicitly mantained in a document that, tracks tiers and models, could be the following.
Simple scout runs Gemini 3.6 Flash; the light-mode plan/build workflow uses ChemK3 (the first open-weights state-of-the-art model, served via Fireworks for ownership/privacy reasons) for planning and Gemini Flash for building.
The full SDLC uses Opus 5 for planning and review. Some note a subjective preference: despite benchmarks showing Opus 5 above Fable 5, actual production runs still feel like Fable 5 is a notch above for the hardest planning tasks — the model stack is the place to encode and iterate on exactly these kinds of per-role calibrations.
Idea #3
A software factory’s value is purely the leverage it multiplies onto each prompt (read skill definition) — and the amount of leverage is determined entirely by the quality of investment you put into it, how you govern, measure its effectiveness and improve it.
This reframes the question from ‘how do I automate X’ to ‘how do I build a system that makes every future prompt worth more?’ At the lowest level, chaining a few agents gives minor uplift. At the highest level, you build a system that operates without you as well as or better than with you, although some choices may still be needed in the first phases of the session.
Some of the properties that create this leverage are observability (you can see exactly what ran, so you can improve it), customizability (every agent’s context, model, prompt, and tools are independently dialed), and reusability (the same workflows run reliably across several projects with similar characteristics of the codebase and type of project codified in the SDLC) . The optimization target shifts: you are not trying to get the best single output from the best single model — but eventually consolidating skills to be just as good when applied to other projects.
Cost is also important of course and must be tracked per phase. Each agent’s compiled prompt and tool calls inspectable after the fact, any run restartable by session ID. The claim is that these properties together let the factory reproduce the success we all would like to see in our applications over and over and over.
Idea #4
Agents plus SDLC plus code beats agents alone — and most engineers seem to be underusing code inside their pipelines. The core claim is that deterministic code should handle everything it can handle, and only genuinely uncertain or creative work should go to an LLM.
Code runs essentially for free, produces deterministic outputs, creates hard gate checks that break error-compounding chains, and — crucially — is owned by us rather than rented from a model provider.
When routing a test-suite run or, fir example, a JSON schema validation through an agent, you burn tokens on something a subprocess call does for free and more reliably. The failure mode of agent-only pipelines is that one hallucination feeds silently into the next agent’s context.
A code gate that fails ‘loudly’ and hands specific error context back to the agent breaks that chain. You can tag each task or workflow stage (after all an SDLC process is a complex workflow) as ‘agent’ or ‘code’ with a structurally explicit separation. Thus, after every build step, deterministic linting, formatting, and type checks run; if they fail, the failure — with exact error output — is routed back to the build agent. The planner’s output is validated as typed JSON by code.
Source: My Super Simple Software Factory (For Agentic Engineers) (IndyDevDan)
Text summarized and optimized using Anthropic’s models and reviewed by a human.