Experience Report: How we Built an Optimization Engine With AI and RPG Elements?

A vehicle-routing optimization engine built with AI agents and a single human engineer.
Camilo Rodríguez
July 2026

Abstract

This is an experience report about specifying and building Orbital, a route-optimization engine for the Vehicle-Routing Problem with Simultaneous Pickup and Delivery (VRPSPD), in which one fleet serves stops that can both receive and return goods, with time-dependent travel costs. I was the project’s only human engineer. Thw work was done within the 3rd cohort of the Hardcore AI Certification program by 30x. Artificial intelligence (AI) agents—software agents driven by language models—participated in requirements analysis, design, adversarial review, implementation, code review and testing.

The work happened in two distinct phases. I spent roughly ten calendar days, part time, specifying the system through the AI-Driven Development Life Cycle (AI-DLC), a staged process that turns intent into approved requirements and designs through explicit human gates. I then built the accepted minimum viable product (MVP)—the smallest complete release intended to prove the system end to end—in a roughly five-and-a-half-day sprint, from July 8 to July 13, 2026, using Normandy, a custom multi-agent construction pipeline with four builder personas and four reviewer personas.

The compressed construction time is the obvious result, but it is not the most important one. In my experience, agentic construction worked because the specification that preceded it was unusually explicit. Specification is already one of my strengths, yet AI-DLC repeatedly exposed decisions that were clear in my head and ambiguous, stale or absent on the page. Human teams often resolve that kind of ambiguity while they build. Agents resolve it too—but by selecting a plausible interpretation and implementing it confidently. AI-DLC moved much of that repair work before the first production code. Three conclusions organize this report. First, high-quality specification is a prerequisite for a good agentic-building experience, and AI-DLC was particularly effective at producing one. Second, AI judgment is valuable but cannot be treated as authority: adversarial panels caught a fundamental objective mismatch during specification, then later offered confident recommendations based on application programming interfaces (APIs)—the callable capabilities exposed by a software library—that did not exist. Third, plausible-but-wrong output requires structural controls, not greater vigilance: pre-registered experiments, an independently implemented deterministic validator, enforced module isolation, measured acceptance gates and a normally human-controlled merge policy.

By the end of the sprint, thirty-two merge commits had landed on main; twenty-seven were merged by the human and five under one bounded, pre-authorized autonomous exception. The project’s benchmark and acceptance suites internally certified the engine to 200 stops across eight vehicles and five fixed seeds. That is not a proof or a production pilot. It is the observed boundary of the MVP described here.

1.The question behind the build

On July 13, Orbital could accept a routing problem, choose vehicles and routes, respect its hard capacity rules, improve a plan within a finite search budget, validate the result independently and return an honest failure when it could not find an acceptable plan. Five and a half days earlier, the repository contained a completed specification but no accepted MVP implementation.

That result is easy to summarize as «one engineer and eight agents built an optimization engine in a week.» It is also easy to misunderstand. The agents did not receive a product idea and autonomously turn it into reliable software. They received a detailed, staged specification; worked inside narrow roles; produced reviewable artifacts; failed in several plausible ways; and were corrected by experiments, Independent checks and human decisions.
The question I want this report to answer is therefore not whether agents can write code quickly. They can. It is:

What did it take for one engineer to use AI agents to build a consequential optimization system
quickly without surrendering control of what the system meant or whether its output was valid?

I tell the story in the order I experienced it: first the problem and its risk, then specification under AI-DLC, the failed construction start, the creation of Normandy, the turning points of the build, and finally what I believe another engineer can—and cannot—take from the result.

2. The system had to fail honestly

Orbital grew from a problem I encountered while working on logistics software for home medical-oxygen delivery across Colombia from 2008 to 2021. The daily planning problem is familiar: which vehicles should go out, which stops should each serve, and in what order? In practice, planners may begin the work the evening before and continue into the following morning.

Orbital is an API-first engine for that decision. Its MVP solves a single-depot VRPSPD. Every vehicle leaves one depot, visits stops that may both deliver and collect equipment, and returns. Vehicles have heterogeneous capacities by equipment type and a weight limit. Travel time and distance depend on the departure hour. The objective is the customer’s real operating cost—fuel, dispatch and overtime—not a proxy such as distance or duration alone. The number of vehicles used is a decision produced by that cost model within a configured range.

The domain gave the project a hard correctness boundary. An overloaded route is not a lower-quality route; it is invalid. A route that silently omits a stop is not useful. An engine that calls a difficult instance infeasible merely because a heuristic ran out of time is misleading. Orbital may report «no solution within budget.» It may not present a structurally invalid plan as a valid one.

During specification this became R-11: plausible-but-wrong solver output. The name mattered. An optimizer can return a polished answer that appears reasonable while violating a capacity recurrence, misreporting its cost or dropping part of the problem. Software built by agents adds another source of the same failure: an implementation can be coherent, tested and wrong in exactly the same way its author misunderstood the requirement.

R-11 shaped the architecture more than any feature. It eventually produced an independently implemented validator, a continuous-integration firewall between that validator and the optimizer, explicit failure semantics and measured gates around the solver. Before it shaped the code, however, it had to shape the specification.

3. Specification was the first engineering act

3.1. Why I started with AI-DLC

Specification is one of my strengths. I enjoy taking an unclear operational problem, finding the real decision inside it and describing the system precisely enough that a team can build it. That background made me receptive to AI-DLC, but it also gave me something useful to test: would the process improve a discipline in which I was already confident, or merely add ceremony?

AI-DLC divided the work into staged artifacts and approval gates. Inception covered requirements, stories, workflow planning, application design and units of work. Construction added functional design, non-functional requirements, infrastructure decisions, code-generation plans, implementation and build-and-test. User input and decisions were written to an append-only audit trail. Each design stage ended with an explicit human decision before the next one began.

In conventional development, even a strong specification contains shadows. A sentence admits two interpretations. A decision has been made but survives only in the author’s head. Two sections were written at different times and no longer agree. A human implementation team often repairs these defects through questions, hallway conversations and judgment while coding.

Agentic builders change the cost of those shadows. An agent rarely stops at every ambiguity. It can pick the most plausible interpretation, build it cleanly and surround it with tests. The result may be internally consistent while implementing the wrong product. More coding speed then means faster amplification of the original ambiguity.

AI-DLC was unusually good at pulling that repair work forward. The value did not come from an agent magically knowing the requirements. It came from repeatedly forcing intent through different forms: requirements, stories, business rules, component boundaries, domain entities, acceptance properties and adversarial questions. Every transformation created another opportunity to find what was missing or contradictory. The approval gates kept those discoveries from being silently absorbed as agent decisions.

3.2. Specification is one of my strengths.

I enjoy taking an unclear operational problem, finding the real decision inside it and describing the system precisely enough that a team can build it. That background made me receptive to AI-DLC, but it also gave me something useful to test: would the process improve a discipline in which I was already confident, or merely add ceremony?

AI-DLC divided the work into staged artifacts and approval gates. Inception covered requirements, stories, workflow planning, application design and units of work. Construction added functional design, non-functional requirements, infrastructure decisions, code-generation plans, implementation and build-and-test. User input and decisions were written to an append-only audit trail. Each design stage ended with an explicit human decision before the next one began.

In conventional development, even a strong specification contains shadows. A sentence admits two interpretations. A decision has been made but survives only in the author’s head. Two sections were written at different times and no longer agree. A human implementation team often repairs these defects through questions, hallway conversations and judgment while coding.

Agentic builders change the cost of those shadows. An agent rarely stops at every ambiguity. It can pick
the most plausible interpretation, build it cleanly and surround it with tests. The result may be internally
consistent while implementing the wrong product. More coding speed then means faster amplification of the
original ambiguity.

AI-DLC was unusually good at pulling that repair work forward. The value did not come from an agent magically knowing the requirements. It came from repeatedly forcing intent through different forms: requirements, stories, business rules, component boundaries, domain entities, acceptance properties and adversarial questions. Every transformation created another opportunity to find what was missing or contradictory. The approval gates kept those discoveries from being silently absorbed as agent decisions.

The clearest example concerned the objective function. Early discovery material inherited a model that minimized time. By the time I wrote the product requirements, I had already decided that Orbital should minimize real operating cost. Dispatching another vehicle can shorten total time, but it carries a fixed cost and consumes a crew. In this operation, a time-minimizing objective could overspend precisely the resources that constrain the day.

The product narrative said «cost.» The inherited mathematical model still said «time.» I knew what I meant, but the specification did not

On June 22, an adversarial panel of five AI reviewer personas—operations research, quantum computing, product, engineering and startup strategy—read the document as written and found the contradiction.
That intervention changed the project. I re-derived the objective around fixed dispatch cost, time-dependent fuel cost, overtime and optional fairness. The panel also demoted quantum solving from a headline to an explicit roadmap: classical today, quantum-inspired later, real quantum hardware only when it becomes technically and economically defensible
.
This is the strongest evidence I have for AI-DLC’s specification value. It did not compensate for an inexperienced spec writer. It found a consequential inconsistency in the work of someone who considers specification a strength. The process made the written contract better than the intent I had been carrying privately.

3.3. From product intent to an executable contract

From June 24 through July 4, the specification grew into seven units on a dependency graph:

Unit	Name	Responsability
U0	Scaffold	Django skeleton, Docker, continuous integration and the R-11 isolation rule
U1	Edge and contract	OpenAPI contract, tenant authentication, idempotency, rate limiting and health
U2	Persistence and tenancy	Tenant-scoped jobs and write-once solutions containing no personal health information
U3	Problem preparation	Canonical model and the time-bucketed travel-cost cube behind a traffic port
U4	Optimization engine	The adapter for Google OR-Tools, an open-source optimization toolkit, behind a solver port
U5	Independent validation	The deterministic validator, forbidden from importing U4
U6	Orchestration and delivery	Job lifecycle, compute budget, validation gate and signed callbacks

The detailed designs defined entities, business rules, ports, failure states, tests and non-functional constraints. The mathematical model was co-defined in dialogue with agents, adversarially reviewed and then locked. Three requirements that later became construction blockers were already explicit: the initial load must equal everything a route will deliver; strict fairness requires two lexicographic passes rather than a dangerously large penalty coefficient; and time-dependent profiles must obey the first-in, first-out property.

The specification phase felt heavy for a solo project. That feeling was real. It took roughly ten calendar days of part-time work before accepted MVP construction began. But those documents later served three purposes simultaneously: instructions for builders, grading criteria for reviewers and an arbiter when intent and implementation diverged. By construction week, I was no longer asking agents to infer a system. I was asking them to realize a contract.

That distinction is the foundation of the rest of this report.

4. The first construction approach did not fit

My first construction attempt used OpenHands, an open-source agentic-development platform, following a community orchestration blueprint called Symphony. The blueprint had the shape I wanted: issues as units of work, separate builders and reviewers, and explicit review rounds before merge. The attempt produced scaffold and persistence work, but it did not reach an accepted construction rhythm.

Two problems emerged. In my use of it, progress was slower and more token-intensive than with the agent command-line interface I already operated daily. More importantly, the substrate did not match the project. The borrowed workflow assumed GitHub, Linear and OpenHands; Orbital lived in GitLab and my existing agent tooling. In the middle of a short sprint, I was learning someone else’s stack instead of building the engine.

I kept the orchestration idea and discarded the stack. Agents made the replacement cheap enough to be a rational decision: I could treat Symphony as a workflow specification and port its useful constraints to tools already in muscle memory. The result was Normandy, operational in roughly a day.

This changed my view of agent orchestration frameworks. Their most durable asset may be the loop they describe, not the software package that implements it. For this project, adopting the loop while owning the substrate was faster than adapting the project to the framework.

5. Normandy turned the specification into a production line

Normandy was deliberately small. It coordinated GitLab issues, isolated worktrees and agent sessions through five mechanisms.

5.1. A visible state machine

Each task was one GitLab issue with exactly one active workflow label:
‘backlog → ready-for-construction → in-progress → agentic-review ⇄ changes-requested → human-review → done‘
Dependencies could place a task in blocked. A human moved an issue to ready-for-construction; no builder started before that signal. One issue produced one branch and one merge request. Progress was therefore a reviewable artifact against an authoritative spec, not an agent-session transcript.

5.2. Pure builders

Four builder personas—Tali, Garrus, Grunt and Vega—were assigned round-robin. A builder received the issue, the relevant design documents, an isolated worktree and file and shell tools. It implemented, tested, committed and pushed. It could not change workflow labels or the central state and audit files.

That limitation made builders closer to pure functions: specification in, code and evidence out.

5.3. Read-only review panels

Four reviewer personas each carried one lens: Mordin for correctness and tests, Liara for design and specification conformance, Thane for security, and Samara for engineering standards. A panel used the relevant subset, commonly three reviewers and security when the change warranted it. Every dispatched lens had to pass.
A blocking finding sent the issue to changes-requested. A builder then received the findings as a new work packet. Automated rework was capped at three rounds before mandatory human escalation.

5.4. One writer for shared state

Only the orchestrator changed GitLab workflow labels and the central AI-DLC state and audit documents.
This avoided concurrent agents producing competing versions of project truth. The rule later proved valuable during a workstation crash: GitLab and committed artifacts remained coherent even though an uncommitted portion of the local state and audit trail had to be reconstructed.

5.5. A human merge gate, with one explicit exception

Under the normal rule, I reviewed and merged every accepted change. Twenty-seven of the sprint’s thirty-two mainline merge commits followed that path. The other five belonged to a single overnight demo-integration stream for which I explicitly authorized Normandy to merge after clean panel results, subject to the existing three-round escalation cap. The exception was bounded by task, time and conditions; it did not silently become the new rule.

5.6. The personas were for the operator

The eight agents were named and signed as a familiar video-game squad. Each had an email identity, co-author trailer and characteristic sign-off. At this stage, that theme was the whole of the gamification: no points, leaderboards or agent statistics existed.

I did observe an effect on myself. At one in the morning, reviewing «Tali’s scaffold» was easier to return to than reviewing feat/U0-scaffold. The names gave continuity to a punishing week and helped me hold different responsibilities in my head. I have no controlled evidence that they improved code quality. I treat persona theming as an observed human-factors intervention and an untested quality lever.

6. What happened during construction

The sprint did not proceed as a clean execution of a perfect plan. The specification constrained the work, but the engine still had to collide with the behavior of a real solver. The most important progress came from the moments when an attractive idea failed measurement.

6.1. The foundations made later disagreements cheap

The early units established the project skeleton, tenant boundaries, API contract, persistence model and canonical optimization input. This work was less dramatic than the solver, but it proved the pipeline.
Builders had exact unit designs. Reviewers could point to a violated rule rather than debate preference.
Rework returned as a bounded issue instead of dissolving into a broad conversation.

The process also showed that detail does not eliminate interpretation. Reviewers sometimes applied an instruction more literally than I intended, and implementation exposed design amendments that had to be rippled through multiple documents. The difference was that the disagreement was visible.
The spec gave us a location to resolve it and a record of the resolution.

6.2. A pre-registered spike killed the engine I intended to build

The locked design originally assumed that OR-Tools could search directly over time-dependent monetary arc costs: the cost of traversing an edge would depend on the accumulated departure time at that point in the route. Before building the production engine, the U4 plan required a throwaway spike comparing that native approach with an iterative alternative that froze costs, solved, re-froze them at realized times and repeated.

The acceptance rules were written before the results. That mattered because I wanted the sophisticated design to work.
Both candidates failed differently. Native time-dependent monetary arc cost was not merely difficult in the selected solver; the required mechanism did not exist. OR-Tools exposed a cumul-dependent hook for transit, not for the complete arc-cost function the model required.

The iterative prototype ran and returned plausible plans. It was also unsound. On one measured instance
it reported the cheapest cost seen across iterations while returning the route from the final iteration,
a 5.1% mismatch. Its claim that it had «converged in four iterations» meant that it had reached the
iteration cap every time.

A six-persona review panel—the four Normandy lenses plus specialists in solver internals and metaheuristics—initially split into three positions with two votes each: build the corrected loop, reopen the question, or accept a degraded design. After structured discussion, the decision locked on July 10:

• Search once using costs frozen at the problem’s departure hour.
• Re-evaluate the selected route exactly at its true departure times.
• Report the exact delivered cost.
• Leave the corrected iterative wrapper for future work behind a solver seam.

The plan was less ambitious and more honest. More importantly, the spike had prevented the intended architecture from becoming production code merely because it appeared in an approved design.
This was also where I felt the human role most sharply. During the crisis, an agent could spend hours making a harness fail correctly while the existential question—whether any candidate algorithm worked— remained unanswered. I repeatedly had to pull the work back to the reason for the experiment. Agents pursued the written goal faithfully; I remained responsible for deciding when that goal no longer answered the project’s real question.

6.3. The validator made correctness a separate program

R-11’s architectural answer arrived in U5. The validator re-walked every delivered plan with deterministic arithmetic: route continuity, exact stop coverage, capacity by equipment type at every stop, weight, vehicle use and other hard invariants. Its result was an itemized verdict with a top-level valid o invalid decision.
Three properties kept it from becoming a second copy of the optimizer’s mistake:

• It derived checks directly from the business rules rather than reusing solver logic.
• A continuous-integration rule forbade U5 from importing U4.
• Given the same canonical problem and plan, it returned the same verdict.

The optimizer could reject its own candidate during extraction, and the independent validator checked the delivered result again. If either hard gate failed, orchestration failed closed. Correctness did not depend on persuading another model that the plan looked reasonable.

One invariant exposed the difference between mathematical requirement and scalable search model. A vehicle must leave carrying everything its route will deliver. Encoding that cross-route equality directly prevented OR-Tools’ first-solution heuristics from constructing larger instances. Production therefore searched a necessary relaxation, constrained total route deliveries and collections, derived the true initial load during extraction, re-walked the route exactly and rejected any failure. U5 then repeated the invariant independently. The requirement remained hard even though its scalable realization was not a literal transcription into the search model.

6.4. The experts were confidently wrong—and still useful

By July 12, the engine was reliable only to roughly fifty stops. I convened a three-persona panel framed as world experts in OR-Tools architecture, VRPSPD modeling and heuristic search. It produced nineteen recommendations and emphasized one flagship maneuver.
Measurement was unforgiving:

• The flagship recommendation certified zero additional instances.
• One recommended setting was already the solver’s default behavior.
• Several recommendations were no-ops or referenced configuration fields absent from the installed solver version.

The same general technique—an adversarial panel—had caught the objective-function error that changed the project. Now it was fabricating library knowledge with equal confidence. The difference was not simply «panels work» or «panels fail.» They reasoned well about structure and poorly about the current surface of a fast-moving dependency.

Their advice still created value. To test it, we built an ablation harness. That instrument made the real model gap visible. The rule that emerged was simple: panels propose; benchmarks dispose.

6.5. One missing bound moved the limit from 50 to 100

The first scaling fix was almost embarrassing in its simplicity. The model required that the equipment collected along a route fit on the vehicle when it returned. The search model constrained pointwise net load but had omitted a route-level cap on total collections.

Adding that logically required bound moved internal certification from roughly 50 to 100 stops.
This was a specification success and an implementation failure at once. The business rule existed. The engine did not enforce all of it. The independent reasoning and benchmark ladder made the omission observable before release.

6.6. The path from 100 to 200 was a search-bias problem

At 200 stops across eight vehicles, diagnostics showed another failure. Around twenty-five stops per vehicle, arc-cost-guided search interleaved deliveries and collections so aggressively that load peaked above capacity mid-route, even on instances constructed to contain a feasible ordering. The median overshoot was four units.

Reordering rescued every examined over-capacity route. That changed the diagnosis: the engine did not lack a feasibility bound; its search was biased away from the feasible structure already present in the instances.
The fix was a soft penalty favoring deliver-first orderings above fifteen stops per vehicle. Smaller instances were left untouched and solved byte-identically with the feature disabled. With the bias, the engine passed the 200-stop gate across five fixed generated seeds.

We also corrected the benchmark generator. It had produced too many pure deliveries and pure collections, while the real operation contains mostly interchange stops that deliver full cylinders and collect empty ones in the same visit. Scaling claims are only as useful as the distribution behind them. The final gate used feasible-by-construction instances shaped more like the intended operation, while remaining an internal synthetic benchmark rather than a production validation.

6.7. Measurement redirected the optimization effort

Throughout the sprint, I carried a feared estimate that freezing traffic costs might introduce 7–10% error. The residual gate separated two quantities that had been hiding under the same word:

• The frozen-estimate residual—the part an iterative traffic loop could improve—measured about 0.2% at the median, 2.8% at worst under the reference traffic amplitude, and 5.1% under deliberately exaggerated amplitudes.
• The total residual of delivered plans ranged from 1.4% to 23.5%, dominated by search variation. In the worst case, the heuristic used four vehicles where the optimum used three.

The wall-clock-bounded guided local search was not bit-for-bit deterministic across machines. The sophisticated iterative mechanism we nearly built attacked the small, stable error while leaving the larger, machine-dependent search error untouched.
The sprint report captured the lesson better than any abstraction: the frozen estimate is cheap; the search is expensive; and the fancy loop attacks the first, not the second.

6.8. The state model survived a physical failure

On July 12, the workstation shut down from overheating. Uncommitted edits to the local AI-DLC state and audit documents were lost. Recent user inputs were restored verbatim where available; the remaining gap was reconstructed and disclosed as a summary.

The failure exposed a process weakness: state and audit changes had been left uncommitted for too long.
It also validated Normandy’s source-of-truth boundaries. GitLab issue and merge-request state remained intact. Committed code remained intact. Builders had not been allowed to mutate the central record. After the incident, state and audit updates were committed more frequently.

6.9. The autonomous night was an exception, not the conclusion

Once the MVP and build-and-test work were complete, I still needed a demonstrable interface using real solver output. It was late, I was exhausted, and five demo-integration tasks remained. I explicitly authorized Normandy to run that bounded stream overnight and merge only after clean review panels, with the existing escalation limit.
Five features landed with zero escalations. The combined builder, orchestrator and review loop found and corrected four integration problems before merge: conflicting service exports, a failed idempotency case for empty capture runs, a missing return-to-depot leg in reported distance, and an Angular component still wired to synthetic rather than real solver data.

The next morning I performed the browser-level verification the agents could not complete in their environment. The demo rendered real, pre-seeded solver trajectories for 20-, 50- and 100-stop problems.
It was not solving live in the browser, and its display coefficients were synthetic. I do not interpret that night as evidence that the human gate should disappear. It was evidence that a human can make a bounded operational decision about where machine gates are sufficient, provided the authority, scope, escalation rule and follow-up verification are explicit.

7. What we shipped

Between July 8 and July 13, 2026, the project moved from a specification-complete repository with no accepted MVP implementation to:

• Seven implemented units of work and six completed build-and-test tasks.
• Thirty-two mainline merge commits: twenty-seven human-merged and five autonomously merged under the bounded overnight authorization.
• An API-first optimization pipeline covering ingestion, persistence, canonical preparation, solving, independent validation, orchestration and signed result delivery.
• Internal certification to 200 stops across eight vehicles over five fixed, generated, feasible-by-construction seeds.
• Explicit separation between «no solution within budget» and structural infeasibility.
• A measured decision record for the degraded time-dependent design and a seam for future solvers.
• A demonstration interface using real offline solver output and the chronological improvement trajectory rather than a fabricated animation.

The central observed property was the never-invalid invariant: across the exercised acceptance and benchmark corpus, the engine could fail to find a plan, but it did not deliver a plan the independent validator rejected. This statement is intentionally narrower than a proof. It describes the tests we ran, not every problem the engine might encounter.

8. What I would carry into the next agentic build

8.1. Treat specification quality as infrastructure

AI-DLC’s largest contribution to this project was not code generation. It was the production of a detailed, internally connected specification before builders began amplifying its contents.

Human-led specifications often depend on tacit repair during implementation. That can work with a stable team sharing context. It is a dangerous assumption for agents that enter with only the written work packet and can implement an ambiguity convincingly. Requirements, stories, business rules, domain models, unit boundaries and acceptance properties should agree before construction—not because every design can survive contact with code, but because deviations then become explicit engineering decisions.

AI-DLC did not remove the need for specification skill. It gave that skill leverage. I still had to know the domain, make the product decisions, reject false precision and approve the result. The process helped me externalize more of that knowledge, expose contradictions and leave less essential intent trapped in my head.

8.2. Let experiments overrule approved designs

The time-dependent design had passed multiple specification gates. The pre-registered spike still killed it. A specification should be authoritative about required behavior and current decisions without becoming immune to evidence. Pre-registration made changing course disciplined rather than arbitrary.

8.3. Use AI panels to widen inquiry, not settle facts

The panels found a foundational objective mismatch and later hallucinated solver APIs. Both outcomes came from the same capability: producing plausible reasoning across multiple perspectives. Use panels to generate objections and hypotheses. Verify dependency claims against installed software and grade recommendations through measurement.

8.4. Build separate programs for separate failure modes

The validator was valuable because it did not share the optimizer’s implementation. The import firewall made that independence enforceable. Review, tests and human attention all matter, but none substitutes for a deterministic program that checks the exact failure the architecture fears.

8.5. Keep agents bounded and shared state singular

One issue, one branch and one merge request made progress inspectable. Pure builders and read-only reviewers limited the blast radius of a mistaken agent. A single writer kept workflow state coherent.
These restrictions reduced autonomy locally and made the overall system more operable.

8.6. The human is the source of purpose, not merely approval

I began the sprint thinking of the human primarily as the final gate. In practice, the more important role was deciding what mattered. Agents could optimize a harness, pursue a dead design or resolve the wrong question with great persistence. I had to remember why the task existed, regroup the work and sometimes declare that an apparently valid goal no longer deserved time.

The human merge gate was also the main throughput bottleneck. That is a reason to protect human attention, keep changes task-sized and improve visibility—not automatically to remove the gate.

8.7. Visibility is an orchestration feature

More than once, an agent completed its task and waited unnoticed. The lost hours were not compute or model failures; they were failures to surface «done, awaiting you.» Better notification and queue visibility are Normandy’s most valuable pending operational features.

8.8. The costume helped me carry the work

The personas made the week more legible and more enjoyable. That effect matters even if it never improves a benchmark. Engineering systems are operated by people, and sustained attention is part of their performance envelope. Whether theming also changes output quality remains an open empirical question.

9. Limits of this report

This is one project with one human participant. I was simultaneously product owner, architect, pipeline operator and evaluator. Selection, recall and confirmation bias apply throughout.
The project also began with advantages that do not transfer automatically: specification is one of my strong suits, and I brought more than a decade of prior familiarity with the operational domain, gained from 2008 to 2021. AI-DLC helped externalize and test that knowledge; it did not create it.

There was no controlled baseline. I cannot say how quickly the same engineer would have built the same system with a well-operated off-the-shelf orchestration platform, unthemed agents, a conventional human team or no agents. Token and time comparisons from the abandoned construction attempt were operational observations, not a controlled experiment.

The 200-stop result is internal certification over generated, feasible-by-construction instances and five fixed seeds. It is not external certification, exhaustive proof or validation against historical oxygen-delivery routes. The guided local search is wall-clock bounded and can vary across machines. The demo uses pre-seeded offline results and synthetic display coefficients.

Finally, the append-only audit trail contains a disclosed reconstructed interval after the July 12 crash.
Recent inputs were restored verbatim where possible; the remainder is a summary rather than a complete primary record.

10. Where the work goes next

For Orbital, the next meaningful gate is operational: replay the engine against historical routes, compare its decisions with real plans and costs, and then run a controlled pilot. The solver architecture preserves a path to a corrected iterative time-dependent wrapper, genetic and quantum-inspired solvers, and eventually real quantum hardware. Those are roadmap items, not claims about the MVP.

For Normandy, the immediate need is visibility: clear notification when an agent has finished, when a review is waiting and when a human decision is blocking the queue. A reusable theme library, points and per-agent statistics remain optional experiments. The interesting research question is whether persona-driven pipelines change engineering quality or only—still usefully—change the operator’s ability to remain engaged.

For AI-DLC, the question I would test next is specification transfer. This project suggests that the method can turn strong domain knowledge and specification practice into a higher-quality contract for agents. It does not yet tell us how well the process performs when the domain is unfamiliar, the initial intent is weak or several humans disagree about the product.

11. Conclusion

I began with a routing engine to build and a methodology to try. I ended with a more specific view of agentic engineering.
The code came quickly because much of the difficult thinking had already been forced into the open.
AI-DLC made specification—the part of engineering I already considered a strength—more explicit, more internally consistent and more useful as a construction contract. Normandy then made that contract operational through bounded builders, independent review lenses, a single writer and reviewable changes.

Neither system made the agents reliable by assumption. The build succeeded by expecting plausible failure: an approved design died in a spike, experts invented APIs, a missing constraint limited scale, and an apparently sophisticated optimization targeted the smaller error. Measurement, independent validation and human ownership changed the course each time.

Five and a half days is therefore not the lesson. The lesson is that agentic speed becomes useful only after intent is made explicit and failure is made observable. The methods that mattered were familiar software-engineering virtues—specification, review, measurement, independence and accountable ownership— reinstantiated for tools that can build faster than ambiguity can safely survive.

Appendix A — Timeline

Date (2026)	Event
Jun 22	Five-persona adversarial review found the objective mismatch and helped name R-11
Jun 24 – 27	AI-DLC Inception: requirements, stories, workflow, application design and seven units
Jul 2 – 3	Mathematical model co-defined with agents, adversarially reviewed and locked
Jul 2 – 4	Per-unit functional, non-functional and infrastructure designs approved; code plans completed
Jul 7 – 8	Construction issues seeded; the borrowed-stack attempt ended; Normandy became operational
Jul 8	First accepted scaffold merged; MVP construction proceeded through the unit dependency graph
Jul 10	Spike rejected native and iterative designs; degraded plan locked
Jul 12	Expert panel recommendations measured; workstation crash exposed the uncommitted audit gap
Jul 13	Scaling gate reached 200 stops; build-and-test completed; demo-integration stream ran
Jul 13 onward	Browser verification, presentation work and factual reconciliation of the project record

Appendix B — The locked optimization contract

The main report keeps the mathematical model out of the narrative path. This appendix records the objective and the implementation distinctions that drove the construction decisions. The complete symbol definitions and constraint families live in the project’s locked model document.
The locked objective was:
$$\min_{x,,y}; \sum_{k \in \mathcal{K}} \Biggl[, c^{fij}k y_k + \sum{(i,j)} \mu_{ijk}(\theta_i)x_{ijk} + c^{OT}k O_k \Biggr] + \Lambda{eq}V$$

• $x_{ijk}$ routes vehicle $k$ over arc $(i,j)$ and $y_k$ dispatches it.
• Fixed dispatch cost makes fleet size emerge from cost within configured minimum and maximum bounds.
• $\mu_{ijk}(\theta)$ combines time-dependent distance and driving-time cost for an arc departed at time $\theta$.
• $c^{OT}_k$ is the overtime rate and $O_k$ is the overtime beyond ordinary productive time.
• $V$ represents fairness violation when fairness is enabled.

Strict fairness uses lexicographic optimization in two passes; soft fairness prices the violation; absent a tenant tolerance, fairness is reported rather than optimized. Customer-reported cost excludes the fairness pseudo-cost and is re-evaluated at the route’s actual departure times.

The hard delivery invariants include exact stop coverage, depot-anchored route integrity, capacity by equipment type at every stop, vehicle weight, valid time propagation and a route initial load equal to all deliveries assigned to that route. Human-shaped constraints such as overtime, lunch placement and fairness produce warnings or ranked preferences rather than silently dropping work.

Appendix C — Terminology

Term	Meaning
AI-DLC	AI-Driven Development Life Cycle, the staged and human-gated specification method
VRPSPD	Vehicle-Routing Problem with Simultaneous Pickup and Delivery, where each stop can both receive and return goods
PRD	Product Requirements Document, the approved definition of what the product must do
PHI	Personal Health Information; Orbital’s input contract excludes it
R-11	The project risk of plausible-but-wrong solver output
OE-Tools	Google’s open-source operations-research toolkit used by the MVP
GLS	Guided Local Search, the solver’s wall-clock-bounded metaheuristic
The degraded plan	Frozen-cost search followed by exact time-dependent re-evaluation
The validator	U5’s deterministic, independently implemented plan checker
Normandy	The custom GitLab-centered multi-agent construction pipeline

A note on the companion memoir

This project also produced Orbital — A Commander’s Log, a memoir of the same sprint told inside the Mass Effect universe. It preserves the engineering events while taking disclosed liberties with setting, continuity and scale. Readers who want the build with its emotional register attached are pointed there; its appendix maps the fiction back to the record. (Link to be added on publication.)

Acknowledgments

To the Hardcore AI by 30X program (Cohort 3), in whose crucible the sprint happened.