AI / Agentic
Agent Scaffolding and Architecture Advice Need Different Evidence
By Vivek Jalondhara · 5 min read
Published
Compare generating a review-panel scaffold with deciding who owns draft acceptance, using an illustrative Sheet Parser workflow.
An agent can create a component skeleton and propose a system architecture in the same response. Those outputs have different consequences. A placeholder component is easy to replace; a decision about who owns accepted vendor data shapes interfaces, permissions, persistence, and recovery.
This comparison uses an illustrative Sheet Parser review panel. The confirmed project connects React, Node.js, OpenRouter, Prisma, and PostgreSQL. The panel contract and alternative designs discussed here are proposed educational examples, rather than a reconstruction of its implementation.
Define what scaffolding is allowed to assume
Suppose the panel receives a list of draft rows and callbacks for selecting a row or requesting a refresh. The agent can generate the component structure, loading placeholder, empty state, and event wiring from that contract. It should use synthetic fixtures with unmistakably fictional values.
Scaffolding is useful when the surrounding decisions already exist. Label placeholder behaviour directly. A local callback that marks a row accepted for demonstration must not look like durable acceptance. Better still, keep that action disabled until the real response contract is available, with an explanation in the development fixture.
Recognize the architectural question underneath the screen
Who can accept a draft? Which version do they accept? Where does the accepted record become authoritative? These questions are not answered by a component registry or an attractive folder layout. They determine which operations belong to the browser and which belong to an authorised server workflow.
Ask the agent to present the responsibility boundary and alternatives before implementation. C4 container diagrams describe applications, data stores, and their responsibilities and communication. That level of view can help explain the proposed browser, API, model-provider, and database relationships without pretending to specify every deployment detail.
Compare alternatives against a concrete failure
One proposal lets the browser maintain a local accepted flag and synchronise later. Another asks the server to accept a specific draft revision and returns the resulting record. Compare them using a reviewer who refreshes the page or a second reviewer who changes the same draft.
The first proposal needs explicit reconciliation and an honest pending-sync state. The second needs conflict handling and a recoverable response when the network result is uncertain. Neither should receive approval merely because the agent drew fewer boxes. The product's durability and collaboration requirements decide which complexity is appropriate.
Use contracts to connect the two kinds of work
Define the request, success result, and expected error outcomes before connecting the scaffold to a server. OpenAPI provides a standard format for describing HTTP API operations and responses. Such a description can coordinate work, but the server implementation still has to enforce the promised behaviour.
In the exercise, a panel can render a stale-draft conflict from a fixture while the acceptance operation is still being designed. That is a productive separation: the UI contract is concrete enough to review, and the fixture does not claim the persistence or permission checks already exist.
Ask for evidence appropriate to each output
For scaffolding, inspect structure, readable states, event wiring, and whether the component fits the existing UI conventions. For architecture advice, inspect assumptions, state ownership, failure behaviour, and the cost of changing the decision later. A screenshot supports one kind of claim more than the other.
An agent can help investigate both. It can locate existing API patterns, identify a durable state transition, or compare alternatives against acceptance cases. Its architectural proposal remains a draft until the constraints and consequences are reviewed. A long explanation is not stronger evidence just because the implementation would be difficult.
Promote a scaffold deliberately
Before treating generated scaffolding as a feature, remove demonstration-only state changes, replace synthetic data with validated responses, and verify recovery paths. Check that empty, loading, and failed states still communicate the server's actual outcome. Otherwise a convenient demo assumption becomes an accidental production rule.
The tradeoff is separating quick construction from slower decisions that establish the feature's meaning. Avoid freezing every visual detail before exploring the workflow, but do not let a finished-looking panel settle unresolved ownership questions. Accept each artefact for the evidence it provides.
Two briefs for two different outputs
These briefs use the same proposed feature while giving scaffolding and architecture work separate deliverables. The component contract is illustrative; the architecture brief asks for a decision rather than assuming one.
Illustrative example · Task brief · Simplified for explanation
Scaffold task:
Render supplied draft rows and explicit loading/error states.
Use synthetic fixtures and existing UI conventions.
Emit selection and refresh callbacks; do not simulate persistence.
Architecture task:
Explain who may accept a draft and where acceptance is stored.
Compare local pending synchronization with server acceptance.
Walk through stale revisions and a lost response.
Return assumptions, alternatives, and evidence needed to choose.- Identify the responsibility decision
- Review the API contract
- Scaffold against explicit fixtures
- Implement the chosen boundary
- Verify real states and recovery
Conceptual flow for the example above.
Tradeoff to keep in mind
Separating the briefs adds a handoff, but makes their assumptions reviewable. It does not imply that architecture requires a different agent or that a component cannot inform the design through a small prototype.