The Smallest Testable Slice

In plain words

Before a big project, you build a small piece first. But most teams build the easiest small piece, not the one that answers their real doubt. So first write down the two or three things you are genuinely unsure about. Then any small build that does not test all of them is rejected, however cheap it looks. Among the rest, pick the one giving the most evidence for the least effort and least damage.

How it flows

A tiny example

REQUIRED = {"real_data_works", "users_trust_it"}

for slice in candidates:
    if REQUIRED - slice.proves:
        reject(slice)          # gate comes first
    else:
        slice.points = score(slice)

build(best(eligible))

Notice the reject happens before any scoring, so a cheap high-scoring slice can never sneak through.

What you will learn

• Why "small" is not the goal, and what the real goal is.
• How to write down the proof you need before you build anything.
• How to reject a cheap slice that skips the risky part.
• How to write a stop rule so your experiment can actually fail.

The problem, simply

Think about your final year project. Your team wants to build an agent that answers hostel mess complaints automatically. Eight months of work is planned. Everybody is excited.

Now, your guide asks one question: "How do you know this will work at all?"

The honest answer is, you don't. Something in the plan is uncertain. Maybe the complaint data is too messy. Maybe students will not trust an automatic reply. Maybe the agent gets it right only half the time. You will find out in month seven, when it is too late to change anything.

So you decide to build a small piece first. Good instinct. But here is where most teams go wrong. They build the small piece that is easiest, not the small piece that answers the question. A pretty screen with fake complaints on it is easy. It also teaches you nothing about whether the real data works.

IMPRemember: a small build that cannot change your next decision is not an experiment. It is just an unfinished project.

The idea

A slice is defined by what it proves

A slice is one thin path through the real work, end to end. Narrow is fine. You can narrow the number of users, the amount of data, the number of days it runs, and how much the agent is allowed to do.

What you must never narrow away is the uncertain part itself. That is the whole point of building it.

Write the required proof first

Take your two or three riskiest assumptions and turn them into a list. This list is your required proof set. Now a candidate slice is eligible only if it touches every item on that list.

Notice the order. Eligibility comes first. Only after that do you compare eligible slices on five things:

• Outcome value — how much does it matter if it works? More is better.
• Uncertainty reduced — how much doubt does it remove? More is better.
• Effort — how many weeks? Less is better.
• Consequence — what breaks if it goes wrong? Less is better.
• Reversibility — can you undo it easily? More is better.

The scoring maths is deliberately dumb. The gate is what matters. A slice with a beautiful score that misses required proof is still rejected.

Warning

Warning: Never let a high score rescue an ineligible slice. That is how teams spend six months proving something they were never unsure about.

A worked example

Suppose Priya is building an agent that reads production incident alerts and says which service is broken. Her two risky guesses are: (1) real alert logs are clean enough for the model to work with, and (2) the on-call engineer will actually trust the answer.

She has three candidate slices.

Slice A: a polished dashboard on fake alerts. Two weeks, zero risk, looks great in a demo. But the alerts are fake, so guess 1 is untested. Ineligible.

Slice B: an auto-fixer running live in production. It proves everything. It also can take down a real service at 3 AM. Consequence is huge, reversibility is near zero. Eligible, but a terrible first step.

Slice C: a read-only replay over ten real past incidents, shown to two on-call engineers. Real data, so guess 1 is tested. Real engineers giving an opinion, so guess 2 is tested. It changes nothing in production, so if it is wrong, nothing breaks.

Priya picks C. It is not the smallest build. It is the smallest build that can change her decision.

The stop rule

Before you write code, write down what you will do if the slice fails. This is your stop rule.

Your options are things like: drop this outcome entirely, aim at a different user, try a different mechanism, go collect better data, or give the agent even less authority.

If every possible result leads to "keep building," you did not run an experiment. You ran a ceremony.

Build it

# Pick the smallest slice that can actually change your decision.

# The two risky guesses we must test. This is the required proof set.
REQUIRED = {"real_data_works", "engineers_trust_it"}

CANDIDATES = [
    # name, what it proves, value, uncertainty cut, weeks, blast radius, undo-ability
    ("Pretty dashboard, fake alerts", {"engineers_trust_it"}, 3, 2, 2, 1, 5),
    ("Live auto-fixer in production", {"real_data_works", "engineers_trust_it"}, 5, 5, 8, 5, 1),
    ("Read-only replay, 10 real incidents", {"real_data_works", "engineers_trust_it"}, 4, 4, 2, 1, 5),
    ("Log cleaner script only", {"real_data_works"}, 2, 3, 1, 1, 5),
]

def score(value, uncertainty, weeks, blast, undo):
    """More value, more doubt removed, less effort, less damage, easier undo."""
    return (value + uncertainty + undo) - (weeks + blast)

print("Required proof:", ", ".join(sorted(REQUIRED)))
print()

eligible = []
for name, proves, value, uncertainty, weeks, blast, undo in CANDIDATES:
    missing = REQUIRED - proves          # what this slice fails to test
    points = score(value, uncertainty, weeks, blast, undo)
    if missing:
        # The gate comes BEFORE the arithmetic. Score cannot save it.
        print(f"REJECT  {name:38}  score {points:>3}  misses: {', '.join(sorted(missing))}")
    else:
        eligible.append((points, name, weeks, blast))
        print(f"OK      {name:38}  score {points:>3}")

print()
if not eligible:
    print("No eligible slice. Shrink the proof set or think of a new slice.")
else:
    eligible.sort(reverse=True)
    best_score, best_name, best_weeks, best_blast = eligible[0]
    print(f"BUILD THIS -> {best_name}")
    print(f"  score {best_score}, about {best_weeks} weeks, blast radius {best_blast}/5")
    print("  Stop rule: if engineers disagree with the agent on 3+ of 10 incidents,")
    print("  we stop, and go test a different mechanism instead of building more.")

Look at the output carefully. The "Pretty dashboard" gets rejected even though it is cheap and safe, because it never touches real data.

Also notice the "Log cleaner script only" line. It is the cheapest thing on the list, but it never asks a human anything, so it cannot answer the trust question.

The last two lines print the stop rule. Write yours before you start coding, never after.

Where you will see this

• Coding agents like Claude Code and Cursor shipped narrow first: edit one file, run one test, show the diff. Only later did they take on whole repositories.
• Support bots in Indian fintech apps usually start read-only. They draft a reply for a human agent to approve before they are ever allowed to send it themselves.
• Swiggy or Zomato style assistants test order tracking, one clear question type, before touching refunds or payments.
• Internal company chatbots almost always begin with one team and one document set, not the entire organisation's data.
• Any pilot you see in a placement case study interview: one branch, one city, one month, then decide.

Common mistakes

• The UI-only slice. You build a nice screen on fake data. It proves people understand the idea, but it proves nothing about whether your real data or your real pipeline can support it.
• The infrastructure-only slice. You build queues, workers and a clean deployment. It proves the machine runs. It does not prove anybody wants the output.
• The happy-path slice. You test only the neat cases. The messy exception is exactly where the risk lives, so you have tested the easy 80% and left the dangerous 20% untouched.
• The demo slice. It is built to impress in a review meeting, not to be measured again next week. You get applause and no data.
• The platform slice. You build reusable components for five future workflows before even one workflow has earned its keep. That is a lot of code maintaining a guess.

If they ask in an interview

Q: How do you decide the scope of an agent pilot?

A: I first write down the two or three assumptions I am least sure about, and turn them into a required proof set. Then any candidate slice that does not touch all of them is rejected, no matter how cheap it is. Among the ones left, I pick the one giving the most evidence for the least effort and the least blast radius.

Q: Your manager wants a demo dashboard in one week. Is that a good first slice?

A: It depends on what is actually uncertain. If the risk is that stakeholders will not understand the output, a dashboard is a fine test. If the risk is that the data is too messy or that the model is not accurate enough, a dashboard on fake data proves nothing, and I would push for a read-only run over real historical records instead.

Q: What is a stop rule and why does it matter?

A: A stop rule is written before the pilot and says exactly what result would make us change direction or stop. It matters because without it, every outcome gets read as encouraging and the team keeps building. If no result can stop you, you are not running an experiment.

Try these

1. Take any idea you have, write your three riskiest assumptions, and turn them into a required proof set of three lines.
2. Write three candidate slices for that idea at three different consequence levels: read-only, human-approved, and fully automatic.
3. Add a fourth candidate to the program above that is very cheap and scores high, but proves only one required item. Confirm it still gets rejected.
4. Take one candidate and remove a capability from it without losing any required proof. That is a genuinely smaller slice.

Words, simply

Quick recap

• A slice is small enough only if it can still change your next decision.
• Write the required proof first; a slice that misses it is rejected no matter how good its score looks.
• Write a stop rule before you code, otherwise every result will just mean "keep building".