I designed and built the frontend, including its architecture, API integration and interaction design. Most of my early effort went into understanding what the product needed to become and revising the first implementations around that goal. The visible feature count grew slowly.
Later, delivery accelerated. Agents had examples of finished work to follow, including the decisions I had already tested and changed. The useful result was in the pull requests. Most were close to ready to merge, with small corrections rather than critical issues.
What an instruction leaves undecided
A request to add another screen can sound complete while leaving the consequential choices open. Where does a business rule belong? How does a failed operation appear to the user? Which part of the application owns the state?
If those questions are still open, each delegated feature can answer them differently. The implementations may work individually and still require substantial redesign when brought together.
I worked through those choices in the initial code. Shared API contracts and validation helped make boundaries explicit. The first complete implementations also showed how those boundaries should appear in the interface. Types could catch a mismatched property; they could not decide whether an interaction made sense.
The code carried the decisions
The source of truth was the implementation I had refined. Simple instructions could point agents to work that already expressed the structure and quality I expected. I needed little orchestration once that reference existed.
That is why I would hesitate to describe this as a specification-driven success. A longer collection of Markdown documents would not, by itself, have resolved the choices I had to make while building the product.
Review remained my responsibility. I checked whether the new work followed the established decisions and whether the behavior was right. The mostly minor corrections in later PRs mattered more to me than how much code the agents produced.
Which decisions deserve the early investment?
This experience does not give me a universal factory to install in every repository. The foundations worked because I understood the product direction and built around it. If that direction were still uncertain, polishing an extensive architecture could make the wrong product cheaper to repeat.
The judgment is in identifying decisions that later features will inherit. Leaving them unresolved pushes design work into every review. Settling details the product may never need spends the same time without the return.
The final few days were fast because much of that thinking was already present in the code. That earlier work belongs in any honest account of the delivery time.
Planning a product that agents will help build?
Describe your case ↗