N-Flow Agentic Inception: What's Hidden Behind It, and the AI-Driven Factory Line I Built

---

In my last post, 1.3M Changes in 10 Days !!! "N-Flow Agentic Inception" - The NEXT4I Agentic Workflow I shared how we modified approximately 1.3 million lines of code across 1,243 tickets (a figure that has now reached 1.8M). I'm guessing a lot of people read that and thought, "Letting AI churn out that much work? Won't it be a mess?"

That's a fair question. That 1.8 million figure is exactly why I'm writing this, because there's a lot hidden inside it. If you just tell an AI to keep writing code, you'll never get that number. And even if you did, the result probably wouldn't be usable.

In this article, I'll walk through what's behind it, and how I took principles from more than 15 years of my own work experience, plus what I've picked up from the people around me, and adapted them to manage AI.

---

What problems are hidden in 1.8 million lines?

The way N-Flow Agentic Inception (the workflow I'm building) works has a lot of problems hidden inside it. One part is the flow of taking a ticket through to implementation. Here's a partial summary, point by point:

• Keeping it running: The run can't stop, or at least has to stop and break as rarely as possible. If it stalls all the time, or you have to sit and watch it all day, getting that many commits in 10 days is really hard.
• Managing the context window: 1.8 million changed lines is more than Claude Opus or Sonnet can hold in context. So keeping the context from filling up is essential.
• Keeping the AI from hallucinating: while still letting it work for long, continuous stretches. My longest continuous run so far was almost 2 days.
• Controlling cost and quota limits: If you let Opus run long, or your prompts aren't good enough and you let it do everything, you risk hitting the weekly limit or the 5-hour limit early, or getting only a little done before you're stuck. (I even set a limit on token spend.)
• Verifying the work: How does the AI know it's finished? And how do we check that each ticket is really closed, not "passing but unusable"?
• Handling problem tickets: When a ticket errors or fails, how do we fix it, rerun it, or pull it and cancel it, so the work keeps flowing smoothly like a factory conveyor belt?
• Tracking ticket status: Tracing this data is how you track down problems, improve, and build on what you have.

Put simply, I took the production-line way of working, plus the SDLC (Software Development Life Cycle, which we already use with teams of real people), and applied them to AI. Think of yourself as a PM or PO and ask: what mechanisms would let me trust the team to work on its own and still deliver work that's correct and complete?

As both the owner and the developer at the same time, I wanted to change how I look at building software, to treat it like a factory with a production line. Each ticket runs down a line I planned, and each station does its own job, keeping things SOLID. (I brought in the SOLID principles from software development as part of this too.)

---

Why don't I review every line of code?

From my experience in software development, both what I've run into myself and what I've heard from people around me, I've come to this conclusion:

A PO doesn't need to review every line of code. (Most don't review any.)

They focus on the main features, and they're willing to hand smaller features or functions to people they trust enough. They trust the team to reach the goal in whatever way the team decides.

But that trust isn't blind. (A good owner or lead has to know how to trust their people, but they also need good enough rules and practices in place to keep that trust in check.)

One more thing: when a ticket needs to be adjusted or changed, I don't edit the original ticket. I leave it as it is, as history and a log, and I create a new ticket and add it in instead. That's Open-Closed (the "O" in SOLID: open for extension, closed for modification). Only after that do I update the Requirement Summary document.

Same with AI. There's no way I can read every PR. What I can do is set rules, design the production line, and build a Quality Gate (the checkpoint a ticket has to pass before it counts as done) that's good enough to trust.

---

If I don't review every line, how do I test?

I'm not saying skip testing, or blindly trust whatever comes out. Quite the opposite: every feature and every function has to pass testing. It's just that the level and type of testing should scale with what each piece of work needs.

In a factory, every bolt has to go through QC. But as the owner, I don't need to pick up every bolt and test it myself.

On my production line, the main testing method is TDD (Test-Driven Development, meaning you write the test before the code). The order is:

Write a test that fails first
      │
      ▼
Write code until the test passes
      │
      ▼
Refactor
      │
      ▼
Keep evidence: the failing run + the passing run

The key is having evidence on both sides. The evidence from the failing run proves the test actually checks the work, and isn't a test that always passes (always true). The evidence from the passing run proves the code does what the ticket asked for.

---

Why should one ticket do just one thing?

This is the "S" in SOLID, which I really like (S = Single Responsibility): do one thing, own one thing. This works really well with AI, because the context gets very little tangled up when it's only working on one thing. On top of that, the ticket has a small scope.

Think of a production line in a factory. Each station does just one small, short job, then passes the work down the conveyor belt. That's faster and more accurate than having one station do lots of things.

Tickets are the same. One ticket should be one small concern, nothing more. With a small task, the AI can focus, the context doesn't bloat, and the chance of hallucination goes down. That's why this project has as many as 1,243 tickets.

Each ticket also has to pass its own quality check before it enters the production line. (I'll hold off on the details of that in this article.)

Another really important point: every ticket has to be ready to be pulled out, put back, or swapped at any time. If one has a problem, I need to be able to pull it off the line without stopping the whole line, and tracing and impact management need to be strong enough to tell me what pulling that ticket affects.

---

Why not give easy work to the smartest model?

Give the job to the right person. Some work is straightforward, not hard or complex, so it doesn't need your best person. Sometimes someone who's brilliant and thinks too far outside the box ends up going beyond the goal we set, or overthinking it.

AI is the same. I give easy work to lower-tier models, which saves money too. And the production side should think less and focus on following the instructions in the ticket rather than thinking for itself, because the structural thinking already happened during planning and ticket breakdown. (This was inspired by the Refinement and Planning events in Scrum, except the output is a set of tickets that are already planned and ready to hand to the AI.)

Harder work goes to models that are smarter and more expensive. In my workflow, each tier has its own spending ceiling. If a ticket needs a tier that costs more than that ceiling, I have to approve it first, so costs don't spiral. Or it can be a sign that the ticket is too big or too complex and needs to be broken down further.

---

How strict should the Quality Gate be?

We have to be willing to trust the Quality Gate and trust the implementation. But before we can, the planning has to be good enough, and the quality controls have to be just strict enough for the work.

Some tickets should come with a suitable solution right in the ticket, plus enough testing or QC for that piece of work. But control that's too tight comes with a trade-off: it can stop work from coming out at all, or make things more complex than they need to be.

If you want a picture, it's a bit like mineral refining. A plant that produces 99.9999% pure material and a plant that produces 95% are very different systems, with different machines, steps and costs. If your work only needs 95% but you build a 99.9999% plant, you waste time and money for nothing.

---

Work that fails has to be allowed to fail

A factory has a machine that kicks substandard products off the production line. In my AI Factory, there's one more step available: for example, sending the ticket to a smarter model to take a look first. If it still doesn't pass, it may have to be rejected to a human for review, and the process starts over.

Numbers from this project's log (as of October 30, 2026) show that the gate really does send work back:

• Passed on the first try: 1,087 of 1,243 tickets (about 87.4%)
• Needed rework: 156 tickets (about 12.6%). Of those, 54 actually FAILED. The rest were escalations, incomplete runs, or blocked.
• Most common reason: a mid-tier model could only reach DONE_WITH_CONCERNS (done, but with concerns still open), so the system automatically escalated to a higher tier, about 106 times. Next was failing validation or tests, about 63 times.

I see that 12.6% as a good thing. If the gate never sent anything back, I'd start doubting the gate itself, and whether it controls quality well enough.

But these numbers have to be read with a limitation: tickets closed as DONE_WITH_CONCERNS still need a person, or a real command, to confirm the evidence, for example load tests that haven't been measured for real yet. That part is still human work. Human in the loop.

---

Wrapping up: the factory owner has to build a good enough Quality Gate

The 1.7 to 1.8 million lines in 10 days that I mentioned at the start didn't come from throwing work at AI carelessly. It came from a planned production line, tickets small enough, models matched to the work, and a Quality Gate willing to send work back.

In the end, whoever owns the factory has to plan and build a good enough Quality Gate. Because any time we're not confident in the controls or the output, or the work comes out wrong or not the way we want, we have to go back and restructure, again and again.

And of course, it may have to break and fail first. That's just the nature of building systems, following the principles of the SDLC.