--- title: "3 Hours 40 Minutes Into a Prototype Nobody Asked For" canonical: https://dxdev.com/blog/build-from-mockups-not-inference/ datePublished: 2026-06-30 --- Three hours and 40 minutes into an event Accounts-tab prototype, we had a working branch that deserved to be deleted. It wasn't broken. It had a toggle between an event diagram and a list view. In diagram mode, an Available Accounts rail sat beside the real event diagram, and the advancement slots were grayed out. We could run it on a local clone and show the behavior end to end. That made it worse than a bug, because we had built a coherent answer to a question nobody had asked. We had started from inference instead of opening the designer mockups. ## The direction we invented The ticket was a feature overhaul, not a small defect. That should have changed the first step. Instead, we read the ticket language, looked at the existing event flow, and let the agent work forward from the codebase. The result was a plausible interaction model: let staff move between a list and a visual diagram, keep unplaced accounts available in a side rail, and make unavailable advancement positions visibly inert. That model was internally consistent. It was also ours. There were two ways to begin. One was to pull the designer screenshots into the task context and implement the shapes, hierarchy and interactions they specified. The other was to infer the intended screen from the existing application, the task wording and the data already visible in the event diagram. We took the second route because it felt faster. The code was nearby, the feature sounded familiar, and the agent could start immediately. That was the wrong optimization. Existing code tells an agent what the system currently permits. A ticket tells it what must change. Neither can say how a redesign resolves the choices that remain open: which control carries the primary action, which state deserves visual weight, what moves together, what a user should notice first. For an interface overhaul, a mockup is part of the specification. It isn't decoration added after the architecture. ## The local demo that passed and still failed Nothing failed in the usual way. We found no failing command, no bad response, no missing record. We opened the local clone, exercised the toggle, inspected the diagram view and saw the available-accounts rail beside the event diagram. The inactive advancement slots were gray. The view could be demonstrated. That made the failure easy to misfile. We could have called it a polish gap and spent another session adjusting spacing, labels or edge states. We could have treated the visual feedback as a request for incremental revisions. Both would have kept the original mistake alive: the implementation came from inference, not from the design artifact that defined the work. We stopped before that happened. On review, we decided to abandon the direction rather than negotiate it into compliance. The local branch was deleted and the ticket was reset to preparing. The next session would begin clean, from the mockups. Deleting a branch is often described as waste. Here it was containment. The longer the prototype stayed alive, the more likely its assumptions were to harden into constraints. A working UI is persuasive. Once people can click it, it becomes tempting to ask how to save it, and that is a dangerous question when the visual model is wrong at the root. ## What we changed in the agent handoff The fix was to change the handoff. A prompt that said "be more faithful to design" would have left the agent with the same incomplete evidence and asked it to guess more carefully. The handoff now names the source order. For a visual overhaul, the agent gets the mockups first, then the ticket's acceptance criteria, then the existing code. The implementation plan traces each meaningful interface decision back to one of those sources. If the mockup doesn't answer a behavior question, the agent surfaces the gap instead of quietly borrowing a pattern from the old screen. That order also sharpens review. We no longer judge whether a prototype seems reasonable in isolation. If the answer is a screenshot, a stated requirement or an explicit design decision, we can review the implementation. If the answer is "it seemed like the natural way to do it," the work isn't ready to build. We don't regret making the prototype. Seeing the event diagram and the rail together made the error obvious in a way a planning note wouldn't have. What we regret is letting an agent reach for code before we gave it the visual source of truth. The branch was coherent. That was never the standard. It needed to be faithful. ## What to check first On an interface overhaul, check whether the design mockups were the first input to the work, ahead of the ticket and the existing code. Ours weren't, and at 3 hours and 40 minutes into a prototype built from inference, the branch had to go. Require each meaningful interface decision to trace back to a mockup, a stated requirement or an explicit design decision, and require gaps to be raised instead of filled by guesswork.