Use case

By Specship · Last updated May 26, 2026

Test-driven AI coding that reviewers can trust.

Specship makes test order part of the workflow. The agent turns a ticket into acceptance criteria, drafts failing tests, implements the change, and opens a pull request with the test evidence next to the code diff.

specship / tdd loop
-> criteria saved
-> writing failing tests
FAIL exports filtered rows
FAIL streams large datasets

-> implementing
PASS exports filtered rows
PASS streams large datasets
PASS records analytics event

coverage: 94.2%
status: ready for review
Test-first bug fix workflow showing a bug report, failing test, scoped fix, passing checks, and ready for review state.
Direct answer: test-driven AI coding means the agent captures expected behavior in failing tests before implementation, then opens a pull request where reviewers can inspect both the test evidence and the code diff.
Why tests first

AI code moves fast. Tests make the intent inspectable.

Acceptance criteria before code

The ticket has to say what done means before the agent starts editing files.

Failure before implementation

The first useful signal is a failing test that proves the existing behavior is incomplete.

Coverage and CI stay central

Specship fits the checks your repo already uses: Vitest, Playwright, pytest, go test, or your CI gate.

Reviewer comments become code

When a reviewer asks for a change, the agent updates tests and code on the same branch.

Example: adding CSV export safely

An agent-ready ticket for CSV export should not say only "add export." It should define filtered rows, pagination behavior, large-dataset handling, permissions, analytics, and the expected test files. That turns a vague request into a reviewable PR.

Ticket input

Add CSV export to the invoices table. It should respect filters and work on large accounts.

Acceptance criteria
  • Export includes all filtered rows, not only the visible page.
  • Export is permission-gated for billing admins.
  • Large exports stream without request timeout.
Tests first
  • Unit test for filter serialization.
  • Integration test for streamed response.
  • Permission test for non-admin users.

This is an illustrative product example, not a customer case study. Real customer proof should be added only after the team has approval to publish it.

Make "write the tests first" the default.

Use Specship for tickets where the expected behavior is clear enough to encode in tests.

Join the waitlist