Building the Infra page took 14 hours 44 minutes, and reading the client’s code afterward corrected several stale facts.
A prototype loaded with real data
The task was a customer Infra page. It started as a prototype, and I loaded it with one client’s real infrastructure. Then I iterated on it hard on feedback, until the page opened as seven collapsed categories. Each one drills into a detail page with linked cross-references and full history.
I also added staff view-as deep links, so a client’s page can be shared straight into.
Stepping back to read the code
With the page working, I stepped back and did a deep audit of the client’s repo, to answer what the admin app actually does. The audit corrected several stale facts.
Two reviewers
Then came a two-reviewer design pass. One was a Manus run. The other was a Codex run at high effort. Manus said to revise before expanding the prototype, and to use a governed, first-class Infra graph while preserving the existing Record type and its slot taxonomy. Codex said to revise before implementation.
The design pass settled on an architecture that carries audit, handoff, and a customer’s own AI.
From prototype to a filed program
The work is now a filed program: a set of tickets in dependency order, gated on standing up a real test database. The ledger for the whole program sits on a single ticket, so a fresh session can pick it up cold. Two findings from the client repo went into separate tickets, because they need my partner.
The test database comes first.
AI Skills
Use this lesson with the AI assistant you already use
A customer infrastructure prototype rendered one client's real data across seven collapsed categories. A deep audit of the client's repository then corrected several stale facts, and two independent design reviews recommended revising the model before expanding the prototype.
Paste the prompt, share only the context needed to answer it, and treat the result as a draft for your review. Do not include confidential information or let an AI assistant make changes without your approval.
Optional: for a visual report and saved memory, run /dxdev first.
Don’t have it? Get it at dxdev.com/skills/dxdev. The prompt works without it.
dxdev LESSON · paste into your AI coding agent
LESSON: Let An Early UI Expose Questions, Then Audit Before Expanding
SOURCE: dxdev.com/blog/building-ui-validates-architecture
WHAT HAPPENED: The author built an internal infrastructure page loaded with a client's real data and added detail pages, cross references, history, and staff deep links. The author then stepped back and audited the client repository to learn what the admin app actually does, and the audit corrected several stale facts. Two reviewers independently advised revising the design before expanding the prototype. The resulting program calls for a governed first class infrastructure graph, preserves the existing Record taxonomy, and requires a real test database before migrations proceed.
THE RULE: Use an early UI to reveal what the data model must explain, then audit the running system before expanding the prototype into a model people rely on. Validate migrations against real rows before work that depends on them proceeds.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
1. Before expanding a prototype, verify each displayed operational fact against the code or running system rather than documentation alone.
2. Ensure the model records who changed each infrastructure fact and when.
3. Run proposed schema migrations against a real test database before work that depends on them proceeds.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.
