Dark Factory - Beginning of an area A dark factory SDLC is an autonomous software delivery system where AI agents handle the full requirement-to-deployment cycle, and humans only set intent and manage exceptions. The six principles and what each actually demands: Intent over instruction is the hardest shift. Your client's engineers are used to writing Jira tickets with acceptance criteria, not business goals. The dark factory requires prompts structured as outcomes ("reduce checkout abandonment by 10% for mobile users") not task specs. This demands an Intent Engine that parses natural language into structured work units - think of it as a requirements compiler. Story Definition - This is the key - How your agent understands, describes story via Acceptance criteria + specs + user interface definition -> defines volumes of success. Remember code generator agent has to reliably act on story definition. This step should also have a feedback loop (think about verification look within story definition - agent verifying its own output before handing over to code generation agent). Code Generation agent - Must factor in - Architecture Blueprint (HLD, LLD) and create its own specs - this is a really good way to state what the code is going to be generated against. Think about framework, guardrails, design patterns, best practices to be a part of this. Ideally, it can be fetched from a repo when agent starts building context for code generation. Across various tools that can be used to build or modify the same application, you should be maintaining a dependency graph to keep changes in sync. Zero-touch execution means no PR approval loops, no standup blocker checks. Agents handoff between each other. This is non-trivial - most teams underestimate how much invisible coordination happens in Slack that needs to be formalised into agent-readable signals. One agent's output must be well understood by another agent, that it is handing over to. It means seamless, well described, and equally better understood. Continuous verification reframes QA from a gate into a fabric. The QE agent runs tests, catches failures, and loops back to the coder agent with context - not a Jira ticket to a human. This requires the verification loop and the defect fixing workflow to be tightly coupled. Further, you can also classify what agent should fix, what it should not (slack notification perhaps in cases fix can cause high regression). Composable over monolithic means every agent is a swappable module. Today's coder agent is GPT-5.4. Tomorrow it's Claude Sonnet 4.6. The agent mesh can't be tightly coupled to any one model or tool. Besides, you have to factor in nuances of output differences generated by models. We are living in this era. We just learnt how to generate a whole journey of a large application end to end (all the way to building a release candidate) through swarm of agents (requirement > code > testing > deployment) .. This is very different from the conventional application different. You learn a lot. This is probably the future.