How to Build a Small Prototype With an AI Coding Agent

How to Build a Small Prototype With an AI Coding Agent

Build the first AI-assisted prototype as a private, disposable learning artifact. Give it one narrow user job, synthetic data, limited permissions, explicit acceptance cases, small change sets, human inspection, and a reviewed rollback point.

The goal is not to prove that the agent can produce a lot of code. It is to answer one useful question without creating a public risk you did not intend to own.

Choose a harmless question

A good first prototype asks something like: Can a user understand this interaction? Can this data shape support the workflow? Can the team reproduce one calculation? Can a builder turn one step into a visible artifact?

It should not begin with customer records, production credentials, payment capability, regulated decisions, public write access, a live database, or authority to change infrastructure.

For a simple example, use a one-person task tracker with invented tasks stored locally in the browser. No account, network, payment, analytics, or external service is needed. If the entire prototype disappears, nobody loses money, access, rights, or a business record.

Write the brief and tests first

Define the user job, included behavior, exclusions, interface states, data, rules, accessibility expectations, security boundary, and delivery limit.

Then write acceptance cases for adding a task, rejecting blank input, preserving order, completing a task, deleting a task, refreshing the page, simulating storage failure, and recovering. Each case should say what a person observes and what must not happen.

This work may take longer than the first generated screen. That is not delay. It is how the prototype becomes a learning instrument instead of a visual surprise.

[[How to Write a Build Brief for an AI Coding Agent]] contains the fuller requirements method.

Prepare a controlled workspace

Start from a known repository state. Record the branch or revision. Keep unrelated user changes out of the prototype. Create a recoverable baseline before the agent edits.

Limit the agent to the intended directory and development environment. Decide whether it may run commands, install packages, contact the network, read other files, or change configuration. For the task tracker, prohibit new dependencies and all external access.

Use fabricated data. Do not paste credentials, private source, customer records, regulated information, or confidential business material into the model or platform without an authorized environment and current terms review.

Ask for a plan before code

The plan should restate the job, identify unknowns, name files and dependencies, propose the smallest implementation slice, list commands, connect tests to acceptance cases, and flag anything outside authority.

Current Replit guidance recommends planning, context, review, testing, and checkpoints. The same control applies across tools even though the interface will differ.

If the agent proposes accounts, a database, telemetry, an external package, or deployment for the local task tracker, reject the expansion. A prototype becomes harder to learn from when it quietly adds systems unrelated to the question.

flowchart TD
    A["Brief and acceptance cases"] --> B["Clean private workspace"]
    B --> C["Review agent plan"]
    C --> D["Generate one small slice"]
    D --> E["Inspect diff and dependencies"]
    E --> F["Run tests and exercise failures"]
    F --> G{"Evidence acceptable?"}
    G -->|"No"| H["Revise brief or implementation"]
    H --> D
    G -->|"Yes"| I["Create reviewed checkpoint"]
    I --> J["Repeat or write handoff"]

Generate one small slice

Ask for the minimum behavior that can be observed. For the example, that might be the empty state, one text field, one Add control, and an in-memory task list.

Do not request the entire imagined product in one turn. A smaller change makes the diff easier to explain, reduces hidden dependency and scope changes, and gives the builder a clear place to stop.

After generation, inspect the changed files before judging the interface. Look for unrelated edits, new packages, copied assets, network calls, telemetry, hard-coded values, disabled checks, broad error handling, unsafe HTML, and code the owner cannot explain.

Test behavior, including failure

Run the agreed automated checks. Then exercise the interface as a user.

Try the main action, keyboard-only operation, blank input, rapid repeated input, refresh, deletion, and a simulated storage error. Inspect the browser console and stored data. Confirm that the interface represents failure and recovery instead of hiding them.

E057's Pong demo is a useful model. The first app ran, but the opponent did not play. The builder observed the gap and gave focused feedback. The failed acceptance was evidence, not embarrassment.

Ask the agent to explain the cause and proposed correction before accepting another broad rewrite. After the change, rerun the earlier cases as well as the failed one.

Checkpoint only reviewed states

A checkpoint is a recovery aid. It is not a quality label.

Replit's current checkpoint and rollback documentation describes how its product captures and restores project state. Other tools may use commits, snapshots, branches, or worktrees.

Name the checkpoint for the behavior and evidence it preserves, not for confidence. "Task add and blank-input cases pass; storage failure still unresolved" is more useful than "perfect version."

Keep source control and a separate build record when the platform checkpoint does not provide enough independent history or portability.

Preserve the build record

Record the date, model, platform, account or plan, prompts, attachments, starting revision, generated changes, human edits, packages, commands, tests, manual observations, failures, costs, checkpoints, and final decision.

State what was not tested. The local task tracker may have no evidence for another browser, another device, screen-reader behavior, long-term data migration, concurrency, malicious input, dependency compromise, or public deployment.

The NIST Secure Software Development Framework reinforces the need to protect software, track provenance and decisions, produce secure releases, and respond to vulnerabilities. A prototype can begin that evidence trail without pretending to satisfy a full release.

Stop with a truthful handoff

The handoff should name the user question, what the artifact does, the accepted cases, failed or skipped cases, known risks, data and permission boundary, current maturity stage, source revision, rollback point, owner, and next gate.

For the example, the correct conclusion might be: "This private prototype shows that one user can add, complete, delete, and recover synthetic tasks locally. It is not an account system, shared service, accessibility conformance result, security-reviewed application, or deployment candidate."

That sentence creates a safe stopping point. The team can choose to learn more, discard the artifact, or fund the evidence needed for another stage.

Public deployment is a different decision

Adding authentication, real data, external writes, payment, regulated workflows, or public access changes the risk and evidence. It requires qualified ownership and the release gate in [[How to Review AI-Generated Code Before Deployment]].

A generated preview can be delightful. The prototype succeeds when the delight is paired with inspectable evidence, limited authority, and an honest maturity label.

This page was developed with AI assistance from the E057 transcript and linked primary sources, then structured for human engineering, security, privacy, accessibility, platform, and editorial review. It does not authorize access to data, credentials, infrastructure, external services, or deployment.