An interactive prototype can make a feature feel nearly finished. A pull request reveals how much still needs to be decided: data ownership, validation, failure handling, dependencies and compatibility with the rest of the application. AI can help bridge that distance, but only when the work is small enough to inspect and the responsibilities are explicit.
A shared workflow lets designers participate beyond visual review and lets developers influence the experience before implementation hardens. The agent contributes drafts, explanations and bounded changes. It does not become the product owner, reviewer and release authority at once.
Start with a bounded change
Use an illustrative saved-search feature. The first slice might let a signed-in person save a named filter and retrieve it later. Exclude sharing, notifications and AI recommendations. These exclusions are not signs of an incomplete vision; they keep the first change reviewable.
Write a short task brief with the user outcome, supported states, relevant existing components and explicit non-goals. Link the current prototype and identify which behaviours were validated. Note where the prototype still uses fictional data.
Ask the agent to inspect the existing implementation and propose a plan before changing files. Require it to identify assumptions and existing patterns. A plausible architecture described without examining the application is not yet an implementation plan.
Agree on a vertical slice
A vertical slice connects one meaningful user action through the interface, server and storage rather than generating every screen first. For saved search, that means the name field, validation, save request, persisted record and resulting list entry.
The designer checks whether the person can understand what is being saved. The developer checks ownership, schema constraints and request handling. Together they define what happens if the name is empty, the request fails or the session expires.
Ask the agent to implement only that slice, preserving existing conventions. Introduce new dependencies only with a reason and review. “It generated successfully” is not a reason to accept an unfamiliar package or replace a working application pattern.
Keep tests independent of generated implementation
Define important outcomes before inspecting the final generated code. Otherwise the agent may produce tests that merely restate its own assumptions. For example, the requirement is not “the success handler runs.” It is “the saved search remains available after reload for its owner and is not available to another account.”
Run appropriate automated checks, but inspect what they actually cover. A passing build verifies a different property from a permission test. A screenshot verifies a different property from keyboard operation. Record checks that were not run and the reason rather than allowing a green summary to imply complete coverage.
GitHub's guidance on reviewing AI-generated code combines functional checks, project-context review, dependency scrutiny and human collaboration. These are complementary activities, not alternative ways to approve a change.
Review the pull request from two directions
Review the diff and the experience. The diff exposes unrequested changes, dependencies, shortcuts and missing validation. The running interface exposes misleading feedback, focus problems, layout failures and incomplete recovery.
A designer should be able to connect the implemented behaviour to the intended outcome. A developer should be able to explain the changed data flow and failure paths. Neither needs to pretend to have the other's full expertise, but both need enough shared evidence to challenge a weak implementation.
Use AI as an additional critic: ask for potential regressions or uncovered cases. Verify its findings. A second generated opinion is useful input, not independent proof that the first generated change is correct.
A pull-request readiness checklist
- One bounded outcome, with non-goals recorded.
- Existing patterns inspected before implementation.
- Interface and backend failure states defined together.
- Tests tied to outcomes, not just internal functions.
- Dependencies, permissions and unexpected diff changes reviewed.
- Preview findings and unrun checks documented.
- Human approval retained for merge and release.
This workflow is not about making designers act as unattended developers or asking developers to accept generated design decisions. It creates a shared sequence: clarify, inspect, build a slice, test, review and decide. AI helps move the work through that sequence; accountable people decide when the change is ready.
Sources
Key takeaways
- Bound the change before promptingAgree on the user outcome, scope, constraints and acceptance criteria before implementation begins.
- Build a vertical sliceConnect the relevant design, UI, data and interaction paths so the team can test an end-to-end outcome.
- Review from design and engineeringCheck the pull request against product intent, accessibility, security, tests and existing project conventions.