How to use acceptance tests to get features working on first review

Maybe this sounds familiar: you spend a long time creating a detailed plan with a coding agent. You explain what needs to be built. The agent implements the feature, writes tests, runs a code review loop, and declares the work complete.

Then you try the feature, and it does not behave the way you expected.

This happened to me enough times that I started requiring the agent to run an acceptance test before it calls a feature done.

The acceptance test forces me to clarify what I expect from the product. It then turns that expectation into a real user flow the agent can run and verify before I review the pull request.

What is an acceptance test?

An acceptance test verifies that a feature delivers the outcome it was built to provide.

It starts from the user’s perspective. What should the user be able to do? What should happen as a result? What evidence would prove that the feature works?

For a new file upload feature in a Slack agent, the acceptance test might be:

1. Post a message in Slack that attaches the file.
2. Mention the agent.
3. Ask the agent to summarize the file.
4. Confirm that the response uses information from the file.

Contrast this with a unit or integration test. Those tests might confirm that the upload handler accepts a file or that the file moves successfully through the system. Both can pass even though the user never receives a useful response.

The acceptance test adds the product perspective. It defines what the feature should accomplish and what a successful experience should look like for the user.

Step 1: Define the behavior

Write down how the user should interact with the feature and what visible result would prove that it works.

A simple version

Behavior: [what the user can do]
Success: [what the user sees when it works]

For the file upload example:

Behavior: A user attaches a file and asks the Slack agent to summarize it.
Success: The agent responds with an accurate summary based on the file contents.

The success state should be specific enough to verify. “The agent replies” is not enough. The reply must demonstrate that the agent received, processed, and used the file.

Step 2: Choose the runner

Once the behavior is clear, determine what the agent needs access to in order to run the flow.

Some features can be tested in a browser. Others require an API call, Slack, email, payments, a database, file uploads, or a scheduler.

I use different tools depending on where the feature lives. I use an agent inbox to confirm email delivery, sequencing, and triggers. I keep a separate Slack profile for sending test requests and evaluating the responses. I use an agent-controlled browser to open pages, trigger actions, take screenshots, and verify visible results.

The runner should be the smallest setup that can drive the real user flow.

Anything that touches a real product surface also needs a safe test lane. I do not want an agent posting test messages in a customer channel, sending emails to real users, charging real cards, or leaving behind records that I have to clean up later.

The acceptance test should define that safe lane:

1. Test accounts.
2. Test Slack channels.
3. Test inboxes.
4. Payment sandbox credentials or test cards.
5. Unique values in messages and records.
6. Required environment variables.
7. Cleanup instructions.

Step 3: Create the test before the feature

I create the acceptance test before I ask the agent to build the feature.

It defines the expected user flow, the environment required to run it, and the evidence that will count as success.

Creating it first prevents the test from becoming a description of whatever the agent happened to build. Instead, it becomes an executable definition of what the product is supposed to do.

For the file upload example, the test might:

1. Open the test Slack channel.
2. Post a message containing a unique test value.
3. Attach a known file.
4. Ask Pipa to summarize it.
5. Wait for the response.
6. Confirm that the response includes facts found only in the attached file.
7. Save a link to the Slack thread as evidence.

Step 4: Run and verify

Once the feature is built, the agent runs the acceptance test and keeps iterating until it passes.

I use the LFG loop by Compound Engineering for the broader implementation, review, and testing process. The acceptance test gives that loop a concrete product outcome to work toward.

The test should drive the real user flow and collect evidence that the flow worked.

For a Slack feature, that means posting the message, uploading the file, mentioning Pipa, waiting for the reply, and verifying that the response uses the file contents.

What an acceptance test does not prove

A passing acceptance test does not mean the feature is correct in every possible situation.

It does not prove that invalid inputs are handled well, permissions are enforced, failures recover cleanly, retries are safe, or the feature performs well under load.

Those concerns still need unit tests, integration tests, negative-path tests, security checks, and human judgment.

The acceptance test prevents the agent from declaring success when the underlying components work but the user-facing outcome does not.

Conclusion

Coding agents can write tests, inspect logs, edit files, and try again. What they cannot reliably infer is the exact product outcome you had in your head.

An acceptance test turns that outcome into an executable standard. It gives the agent a concrete definition of done and gives you evidence that the feature works before you begin reviewing it.

If you are building with coding agents, define the acceptance test before the implementation gets too far. Start with one important feature, one real user flow, and one observable success state.

If you are building with agents and want a set of operational skills to get more out of the ones you already use, so you can stay focused on the work itself, you can find them at usepipa.com.