Most people think of tests as something you add after a feature works, to keep it working. On Stardeck it pays to flip that order: describe how the feature should behave first, have the agent write tests for that behavior, then have it build until the tests pass.
This is what developers call test-driven development. You don’t need to know that term or write any code—you just need to say what should happen before asking for the feature.
Why Build This Way
When you delegate building to an agent, the hardest part isn’t the building—it’s agreeing on what “done” means. A prompt like “add a loyalty points feature” leaves a lot of room for interpretation. A set of tests doesn’t:
- someone earns one point per dollar when their order is paid
- someone redeems 100 points for a discount at checkout
- someone can’t redeem more points than they have
Each of those is a workflow test the agent can write before the feature exists. Once you’ve read the list and agreed it’s what you meant, the agent builds until every test passes. The tests are your acceptance criteria, and you can read them in plain English in the Tests tab—each test’s name appears under its workflow.
Because tests run in an isolated copy of your app—no real data, emails, or charges—the agent can run them as many times as it needs while building, at no risk to your customers.
How to Do It
Ask for the tests first, review them, then ask for the feature:
Describe the behavior
Tell the agent what the feature should do, as a list of things a person does and what should happen:Before building anything, write tests for a gift card feature:
- someone buys a $50 gift card and receives the code by email
- someone pays for part of an order with a gift card and the rest by credit card
- someone can't spend the same gift card balance twice
Review the test names
The agent writes the tests and they appear in the Tests tab, named as the sentences you gave. Read the list—does it cover what you meant? Anything missing, ask the agent to add it. At this point the tests fail, which is correct: the feature doesn’t exist yet. Ask for the feature
Now build the gift card feature until all those tests pass
Phrase each test as a sentence about what a person does—“someone pays for part of an order with a
gift card”—not as a technical assertion. That’s how they’ll read in your dashboard, and it keeps
you and the agent talking about behavior instead of implementation.
Changing Features That Already Work
The same order applies to changes. Before asking the agent to rework something that works today, have it pin down the current behavior:
Before changing anything: make sure the checkout workflow has tests covering
ordering, payment, and the confirmation email. Then change shipping to be
calculated by weight instead of a flat rate.
When Not to Bother
Not everything needs a test first. Copy changes, styling, layout, and one-off content edits are faster to just ask for and check in the preview. Reach for tests when the feature involves money, bookings, inventory, accounts, or anything with rules—the workflows where a quiet mistake is expensive.
Common Questions
Do I have to say “write tests first” every time?
No—asking the agent to cover a workflow at any point is still worthwhile. Test-first is simply the strongest version: it turns your description into acceptance criteria before any building starts, so there’s no ambiguity about what you asked for.
What if the agent’s tests don’t match what I meant?
That’s the point of reviewing them before the build. Test names read as plain sentences in the Tests tab—if one is wrong or missing, say so and the agent revises the list. Catching a misunderstanding at this stage costs a minute; catching it after the feature is built costs a rebuild.
Can I see the tests run while the agent builds?
Yes. Open the Tests tab anytime and run the workflow yourself—you’ll see each test go from failing to passing as the feature comes together. 
