QodoAI founder: Agentic SDLC is not equal to a software factory; teams must build and own a bounded L4 system

Agentic SDLC is not yet equal to a software factory; engineering teams must build and own a bounded L4 system.

From a share by @QodoAI founder @itamar_mar, who argues: having Agents at every stage ≠ already having a software factory; the factory's goal is a bounded L4: on defined classes of work, it can autonomously complete the authorized lifecycle, produce verifiable evidence, and fail safely; without relying on engineers to rescue it every time. The team's advantage lies in building and owning this system (boundaries, evidence, permissions, feedback), rather than stacking models or buying a black box.

Core distinction Agentic SDLC vs. Software Factory Agents participate in planning/implementation/review/testing stages vs. a production system around delivery: inputs, context, execution environment, verification, permissions, release, feedback Code is almost entirely written by Agents, but humans still string stages together and fill in judgment vs. the question: can the system, within its authorized scope, carry a class of changes through to completion without repeatedly asking humans to supply the "missing judgment"

Priority slogan: System > Agents > LLMs. Stronger models can improve the system, but they cannot decide acceptable risk for the organization.

Why the "factory" is the unit of improvement Once implementation becomes cheap, the bottlenecks are often: whether a change should be made, architectural constraints, downstream impact, whether it holds up for users. The factory engineers the entire chain "from idea to releasable, observable, high-quality software," so one improvement can benefit tens of thousands of changes. Reports such as OpenAI's harness engineering also show investment shifting toward environments, repository knowledge, constraints, and feedback loops.

Borrowing from autonomous driving: L3 vs. L4 (the author's own framework) L0–L1: human execution / AI-assisted single-point activities L2: Agents do large chunks of work, humans actively supervise and connect L3 (agentic-SDLC): under limited conditions can run the delivery flow, but humans remain a necessary approval or rescue dependency L4 (lights-on factory): for bounded classes of changes, can complete the authorized lifecycle (verification, permitted release actions, safe rollback), without relying on timely human intervention to contain failures; engineers still own the boundaries and evolution ("lights on") L5 (dark factory): covers almost all software engineering, still requires goals, authorization, and accountability

Key: L4 ≠ omnipotent; the operating boundary itself is part of the capability. You can push for L4 on "routine changes to mature internal services," while keeping tight control over things like payment authorization; do not label the whole company "L4."

Moving from Agentic SDLC to L4: the extra step is "engineering the boundary" 1. The work itself: repositories, change types, dependencies, environments, permissions, and spending caps; what counts as unacceptable. Routine dependency upgrades ≠ core authorization model changes. 2. Evaluable success: a ticket is not a complete spec; architectural decisions, incident history, customer commitments, and engineer memory must be accessible to the factory, and ambiguities must be surfaced before implementation. 3. Verification that withstands generation incentives: cases such as StrongDM emphasize scenarios/harnesses/replicas of external dependency behavior; acceptance criteria need independent authority to prevent Agents from "changing the conditions for passing the exam." Calling a second Agent a "reviewer" ≠ independent. Anthropic's generator/evaluator, Dex's "Harness Engineering is not Enough": green tests ≠ long-term maintainability. 4. Evidence > confidence: inspectable reasons for release (requirements, checks, constraints, deployment results, unresolved uncertainties). Account with qualified work completion rate, remaining human effort, escapes, and cost of failure; not with number of Agents, lines generated, or unattended hours. 5. Safe rollback: refuse release, stop rollout, turn off features, roll back; destructive migrations may not be rollbackable, and the boundary must account for this in advance. You can bring in humans after reaching a safe state; the hard standard for L4 is that containing failures does not depend on humans taking over immediately.

Ownership > Implementation Owning = controlling what the factory produces and when it is acceptable: organizational context, architecture, acceptance, permissions, evidence, operating boundaries; being able to diagnose failures and change "the system that produces the failures." Buying a platform/specialized Agent is fine, but like buying cloud: architecture, orchestration, application logic, and operations still belong to the engineering organization. Echoing Kief Morris's "on the loop": repeated human judgment should be captured as rules, tests, or persistent context; otherwise the factory has not yet absorbed the team's knowledge.

Implementation advice First pick a class of work whose requirements and risks are clear enough → define eligibility rules, verification, permissions, rollback → humans supervise operation and measure intervention points → some go into tools/context, some never enter autonomy. Use a bounded L4 as a pragmatic goal, not a fantasy L5.