Maya Shenoi

Disclaimer: This is an AI-simulated worked example, not a real project. “Meridian Industrial” does not exist, and every figure below is illustrative — generated to show how the HELIX methodology works turn by turn. The process is the proposal; the numbers are the demonstration.

It’s easy to nod along to a methodology diagram. It’s much harder to picture what your team actually does on a Tuesday.

So let’s fix that. This article follows one squad through three back-to-back turns of the simulated Meridian inventory modernization — what they did each day, what got rejected, what broke, and what they kept for next time. If you read only one HELIX piece before trying it, read this one.

Scope and outcome

Here’s the slice we’re looking at, and where it ends up — so you know the destination before we start the trip.

The scope. One squad — Replenishment & Integration — in month 4 of a 13-month program. Five engineers: an Intent Owner (paired with a supply-chain product manager), three Navigators who steer the agents, and a Verifier role that rotates weekly. Plus four named AI agents with locked-down credentials. Their job across these three turns: build automated replenishment for C-class SKUs — the thousands of cheap parts that eat planner hours — and take it live at three pilot plants (P4, P7, P9). This work creates purchase requisitions, which means it spends real money. So it’s tier R2: humans stay in the loop for each task, reviews go deeper, a threat model is required, and nothing ships without a canary.

The outcome, 26 days later. The engine went from a signed one-page brief to live operation at a pilot plant. 94 changes merged, every one with a verification record. One production escape — a duplicate requisition — caught in minutes, fixed the same day, and turned into a permanent test so it can never sneak back. First-pass acceptance rose from 74% to 80%, and the cost of a verified change fell 24%. Rollout to more plants: approved.

Now let’s watch how.

First, what’s a “turn”?

A turn is one full trip around the HELIX loop — Frame → Specify → Architect → Generate → Verify → Release → Evolve — for one small piece of value. Not a feature epic. A slice. The program ran 118 turns in total; the median one took 9 days. These are the squad’s turns 41, 42 and 43.

Turn 41 · Build the engine (11 days)

Frame — day 1, half a day. The Intent Owner writes one page: cut manual requisition work for C-class SKUs by 80% at the three pilot plants, with zero increase in stockouts. Tier: R2. Budget: two weeks and a set token spend. The supply-chain director signs it. Rule number one in HELIX: no tier, no work. It took one meeting.

Specify — days 1–3. Planners and the product manager write the spec with agent help, in plain language everyone can read: When projected on-hand plus on-order drops below the reorder point, and supplier lead time is under 30 days, create a requisition up to the economic order quantity. Never auto-release anything above $50,000. Never order SKUs flagged obsolete. They also write down how someone could abuse the system — fake count feeds, hostile text hidden in supplier catalogs, replayed order confirmations.

Then comes the step that feels odd the first time: an AI attacks the spec. It comes back with three holes. Units of measure aren’t defined (eaches vs cases vs pallets — the classic inventory trap). Nobody said how netting works when two plants share a warehouse. And cancelled purchase orders aren’t covered. All three get fixed in the document. Three future production incidents, deleted before a line of code exists.

Architect — days 3–4. Agents draft three ways to build it, with trade-offs. Humans pick one and write it down as ADR-041: event-driven engine, writing only to a staging area, with one approved adapter as the only path to a real requisition. The team also writes the verification plan — what proof this thing will owe before it ships — and issues the agents their permissions for the turn: read inventory data, write staging, nothing else.

Generate — days 4–8. The work breaks into 23 small tasks. Four agents build them while the Navigators steer. Before any human sees a diff, it has to pass the machine gate — tests, security scans, spec checks. Out of 61 candidate diffs, 14 die at the gate: five failed tests, two had a hardcoded password copied from old sample code, one pulled in a banned library, six broke conventions. No human wasted a minute on any of them.

Verify — days 5–9, overlapping. A second AI — a different model, told to attack rather than approve — reviews the survivors. It finds two real bugs: a race condition when two plants share a warehouse, and an off-by-one in lead-time handling that would have ordered a day late for the most time-critical parts. Then humans review what only humans can judge: a senior engineer pushes back on the approval routing, and a planner challenges one acceptance rule — and wins. The spec changes. 47 changes merge, each with a verification record. Nobody signs off on their own work — not people, not agents.

Release — days 9–11. Nothing goes live. Instead, the engine starts running in shadow mode: it makes recommendations silently next to the planners’ real decisions, and every disagreement gets logged.

Evolve — day 11, two hours. Quick retro: no escapes (nothing shipped yet), 74% of agent work accepted first pass, about $225 per verified change. The team saves what it built for reuse — the spec, the decision record, the test suite, and a reusable “ERP staging adapter” skill.

Turn 42 · Feed reality back in (7 days)

Turn 42 starts with something turn 41 produced: three weeks of shadow-mode data. This is the part diagrams never show you — each loop runs on evidence from the last one.

Frame — two hours. The shadow log shows 92% agreement between the engine and the planners. New goal: close the 8% gap and get ready for a live canary. Because the spec, design and permissions already exist, framing is a review, not a rebuild.

Specify — one day. The squad sits with the planners and goes through every disagreement. Three spec changes come out of it: a unit-of-measure edge case at plant P7 that nobody could have guessed, a seasonal stocking rule that lived only in one planner’s head (now written down as clause 14.3), and clear handling for orders cancelled mid-cycle. One finding cuts the other way: the engine caught a systematic over-ordering habit, and the planners agree it was right. The AI red-team runs again — on the changed clauses only.

This is how HELIX handles changing requirements: a change shows up as a spec edit plus regenerated code, not a month of archaeology.

Architect — half a day. The design holds; no new decisions needed. One line gets added to the verification plan: replay the three new rules against the full shadow log to prove they close the gap without opening a new one.

Generate + Verify — days 2–6. Fourteen tasks, 26 changes merged, four rejected at the gate. Here the saved assets start paying: the test suite from turn 41 catches a regression in the seasonal-rule code within minutes, for pennies. First-pass acceptance ticks up to 78% — not because the agents got smarter, but because the spec got clearer.

Release — day 6. The replay shows 97% agreement now. The canary board — Intent Owner, platform lead, and plant P7’s manager — signs off: go live at P7 only, auto-create requisitions under $10,000, planner approval queue on, rollback one feature flag away.

Evolve — two hours. Cost per verified change is down to about $195. One flag for next turn: test-writing tasks are burning expensive model tokens. Noted.

Turn 43 · Go live, and get punched (8 days)

Frame through Architect — day 1. Goal: run the canary, harden for wider rollout. One addition to the threat model: alerts if the pattern of requisition values starts drifting.

Release — running from day 1. The canary goes live at P7. For five days the dashboards are boring. Boring is the goal.

Day 6 — the escape. A supplier’s order confirmation arrives late and races the reconciliation job. The engine creates a duplicate requisition. The drift alert fires; the feature flag is off within minutes. Damage: one plant, small orders, zero money lost. An agent drafts the root-cause analysis within the hour. A human approves the fix that day. The Verifier — not the person who wrote the fix — signs the merge.

Evolve — days 7–8, and this is the phase that matters. The escape becomes a permanent test: the “late confirmation race” now runs against every future change to this engine, forever. In HELIX, a defect class gets to fool you exactly once. The retro also closes last turn’s flag: routine test-writing moves to a cheaper model — 40% off that cost, zero quality drop. Turn 43 closes with 21 changes merged, 80% first-pass acceptance, about $170 per verified change including the escape’s cleanup, and the canary back on and green. Wider rollout: approved.

The scoreboard

	Turn 41	Turn 42	Turn 43
Duration	11 days	7 days	8 days
Focus	Build the engine, start shadow mode	Fold in shadow learnings, approve canary	Go live, handle the escape, harden
Changes merged / rejected at gate	47 / 14	26 / 4	21 / 3
First-pass acceptance	74%	78%	80%
Cost per verified change	~$225	~$195	~$170
Kept for reuse	Spec, ADR-041, test suite, adapter skill	3 spec clauses, planner know-how captured	Permanent race test, cheaper model routing, drift alerts

What three turns show that one can’t

The gates never move — the effort inside them shrinks. Every turn crossed the same checkpoints. What changed is how much human attention each one needed, because earlier turns kept doing work for later ones.

Reality is fuel, not interruption. The shadow log rewrote the spec. The escape rewrote the test suite. In most processes those would be a change request and an incident ticket, filed and forgotten. Here, they’re the input to the next turn.

Trust grew, but the tier didn’t. The work stayed R2 the whole time. The engine earned wider rollout not because anyone decided to trust it more, but because it kept producing evidence — 92%, then 97%, then a caught escape and a green canary.

The economics bend fast. Acceptance up six points and cost down 24% in under a month — from clearer specs, reused tests and one model-routing decision. That’s the “helix rises” claim, shown on an actual calendar.

One squad. Twenty-six days. Ninety-four verified changes. One escape that can never come back untested. That’s the whole process — and the rest of HELIX exists to make these 26 days boring enough to repeat 118 times.

Disclaimer, repeated on purpose: the squad, turns and figures above are an AI-simulated illustration of HELIX at work, consistent with the simulated Meridian case study — not a real delivery. Use them to understand the mechanics; use your own pilot to produce the evidence.

#AIFirstSDLC #SDLC #SoftwareEngineering #ProjectManagement