We threw away seventeen versions.
Then we built it right.

The trap of "we'll fix it next sprint."

The prior effort got to V17 by adding. Each version inherited every assumption from the last — the model architecture, the feature naming, the eval shape, the deployment flow. Most of those assumptions were never re-examined; they were just there. By V15, the team was tuning hyperparameters on a harness that quietly leaked future-week data into training folds. The model looked good on paper. It was wrong.

The hardest thing in ML engineering isn't the model. It's the discipline to throw away the parts that no longer serve the goal. We didn't have that discipline. So we made the only move that scales: ignore the prior code completely, re-derive everything from PRD intent, and let an independent reviewer audit every milestone before we tag it.

"Don't believe in any previous claims and targets. Complete ignore the previous efforts." — Edward, Day 0 directive

Agent-orchestrated, not human-engineered.

Snapcount is built by four AI agents and one human. The human is the chairman: he sets product direction, gates risky decisions, and rejects bad code. The agents do the rest — modeling, news ingestion, formula authoring, API serving. None of them sleep. None of them forget what was decided yesterday. None of them write code without a tagged spec to anchor against.

The split is not a gimmick. It's an organizational pattern: each agent has a tagged spec, a write-only domain, and an independent review surface. The modeling agent can't ship into the API without TB12. The news agent can't change the eval harness. The chief of staff can't merge code. Boundaries make velocity possible.

Boil the lake. AI makes completeness cheap.

The old engineering instinct says: do the minimum that demos. Ship the happy path. Add edge cases later. That instinct is calibrated for a world where every line of code costs human-minutes. We're not in that world anymore.

When the marginal cost of writing a test is near-zero, you write all the tests. When the marginal cost of validating every column in every parquet is near-zero, you validate every column in every parquet. When an independent LLM can audit your work in five minutes for the price of a coffee, you run the audit before every tag.

Twenty-four hours, three milestones.

Greenfield doesn't mean slow. The path from git init to a tagged baseline-with-actual-numbers ran roughly one working day, end to end. Each milestone gated on an independent codex audit; every CRITICAL finding closed before tag.

The features matter more than the model.

The M2 milestone produced an uncomfortable result for the "just throw XGBoost at it" school of thought. On the same lagged-feature surface as Ridge, XGBoost's MAE on QB passing yards improved by 3.74%. On RB rushing TDs, by 0.84%. Most targets were within rounding of each other.

The interpretation isn't that XGBoost is bad. It's that both models were squeezing the same juice. With only 19 features (lagged versions of six source columns), there was almost no non-linear interaction for trees to exploit. The bottleneck wasn't model class; it was feature surface.

This is why M3 is the next milestone, not "M2.5: hyperparameter tune XGBoost." Until SnapScore can condition on opponent defensive EPA allowed, on Vegas implied team totals, on the weekly NGS separation metric for receivers, on injury status from Adam's live scrape — the model can't do better than recite the player's prior-game averages back at you.

"The hard part is knowing what to build. AI can build anything; the constraint is the spec." — Internal post-M2 review

The roadmap to a live model.

From here, three workstreams unblock production. M3 lifts the feature surface so XGBoost can actually do work. M_serve formalizes the live-snapshot contract so prediction-time inputs match the training distribution. M_inf adds spatiotemporal tracking once the Big Data Bowl data lands.

Along the way: continuous codex audits at every milestone tag. SnapForm formulas refreshed weekly by Adam. SnapCall fine-tuned on SnapScore's SHAP traces. SnapPro API wrapped by TB12. Laura ships the program brief and queues the §9 business questions.

Update (July 2026): the bet paid off — though not the way this chapter guessed. The lever turned out to be projecting a player’s opportunity (targets, carries, snaps), not richer point-accuracy features. On the weekly ranking scoreboard the model now beats a recent-form baseline at RB, WR, and TE, every projection ships as a calibrated range, and the receipts are public: the 2024 replay and the 2025 frozen-model proof.