DEV Community: Mayur Agnani

How Sorting Your Prompts Speeds Up a Mixture-of-Experts Batch Job

Mayur Agnani — Wed, 21 Oct 2026 10:50:14 +0000

Engineer's view. This is a batch job that touches records in arrival order. Each record needs a different index page, so the cache keeps reloading pages. Sort by key and each page loads once per batch. A mixture-of-experts model loads expert weights the same way, so a mixed batch pays for reads nobody shares.

TL;DR. A mixture-of-experts model reads only the experts the batch asked for, and similar prompts ask for the same ones. Sort an offline job by topic, and each step reads less, so the job finishes sooner.

Explain Like I'm 5

A library has a hundred shelves. A helper runs to fetch books for everyone at one table. If the table holds a cook, a pilot and a poet, the helper runs to many shelves each round. If everyone at the table is a cook, they mostly want the same cooking shelf. The helper makes fewer trips, and the table gets its books sooner. Nobody reads faster. The seating just changed.

The Problem

You have shipped this bug before, in a system with no AI in it.

A nightly job processes a million records in the order they arrived. Each record looks up a row in a big table. Records from the same customer sit on the same index pages, but arrival order scatters them. So the database keeps loading a page, evicting it, and loading it again an hour later. The job is slow, and the code is fine. Someone sorts the input by customer ID, and the job runs twice as fast. Nothing about the work changed. Only the order did.

A mixture-of-experts model has the same bug inside every decode step. Each layer holds many small blocks of weights, called experts. Each token uses only a few of them. Qwen3-30B-A3B has 128 experts per layer, and each token picks 8. But a server runs many requests together as one batch. On each step it must read every expert that any request in the batch picked.

That read is the expensive part. Producing one token per request is limited by how fast the GPU reads weights from memory, not by arithmetic. A random batch of 32 Qwen requests touches about 94 of the 128 experts in a layer. Code prompts favor one set of experts, French prompts another. Mix them, and the step reads both sets.

The fix: before an offline batch job, sort the prompts so similar ones run together. Then each step reads fewer experts. Hugging Face measured this on unchanged vLLM and got 5 to 17% more throughput.

The Fix: Group Similar Prompts Before the Batch Job

New to how a model produces text one token at a time? Start at AI basics → Tokens and sampling.

Why does the order of a list change what the GPU reads?

Because the server fills its batch from the front of the list. vLLM admits waiting requests first come, first served. So neighbors in your list end up decoding side by side. Sort the list, and each batch is mostly one topic.

Topics really do prefer their own experts. In one layer of Qwen3-30B-A3B, a topic's 32 favorite experts took 68 to 80% of its routing decisions. Even routing would give them 25%.

How much does one expert cost?

About 2.9 microseconds per layer on an AMD MI300X. That is the time to read about 9.4 MB of expert weights. The MoE layer's time rose in a straight line with the number of distinct experts the batch touched.

Why was the measured gain smaller than the reads saved?

Sorted Qwen batches read 19 to 25% fewer experts, which predicts a 20 to 27% speedup. The measured gain was about half that. Only the expert layers got cheaper. Attention, sampling and scheduling cost the same as before.

Do I need topic labels?

No. Embed each prompt with a small embedding model, cluster the vectors with k-means, and sort by cluster. On unlabeled chat data, this still gave Qwen about 5% more throughput.

What This Means for You

When this matters. You run offline jobs on a mixture-of-experts model that you host yourself. Think evals, synthetic data, labeling, summarizing a backlog. Qwen3 MoE, gpt-oss, DeepSeek and Mixtral are all this kind of model. The job generates many tokens per prompt, and nobody waits on any single answer.

How it affects you. The win is GPU hours. A ten-hour job on a rented node can finish in about nine. Your outputs will also shift a little. In the Hugging Face run, 92% of greedy outputs matched between sorted and shuffled order. Two shuffled runs matched each other 90% of the time. That drift is ordinary batch nondeterminism, the effect from How the Same Model Gives Two Different Answers. Sorting does not add new drift.

The gain also depends on where your batch size sits. The simulation in code_example.py shows the shape: zero at batch 1, largest at small and middle batches, fading once a one-topic batch reads nearly every expert.

What to do about it. Today, look at your next offline job's input file. If it already has a dataset, task or language column, sort by it before you submit. That costs one line. If it has no labels, add the clustering step below. Then run the A/B test in Implementing It before you trust any percentage, including the one in this article.

Implementing It

The change.

Three roles touch this. Whoever builds the input file groups the prompts. Whoever runs the job submits them in that order and restores the original order. Whoever owns the cluster checks the gain is real. The serving side changes nothing for an offline job.

Role 1, grouping. Use labels when you have them. Otherwise, cluster embeddings. The source used Qwen3-Embedding-0.6B and 16 clusters:

import numpy as np
from sentence_transformers import SentenceTransformer
from sklearn.cluster import KMeans

emb = SentenceTransformer("Qwen/Qwen3-Embedding-0.6B").encode(
    prompts, normalize_embeddings=True, batch_size=64)
labels = KMeans(n_clusters=16, n_init="auto", random_state=0).fit_predict(emb)
order = np.argsort(labels, kind="stable")  # stable keeps file order inside a cluster

Keep the embedding model small. It runs once over the file, before the expensive model loads.

You may not be able to sort the whole file at once, for example when you stream it in pieces. Then sort inside each piece. At batch 32, sorting within chunks of 128 prompts gave +11.7%, and chunks of 256 gave +14.8%, against +17.3% for a full sort. Make each piece several batches long, so every batch can fill from one cluster.

Role 2, the batch job. vLLM returns outputs in the order you submitted. So submit in sorted order, then put each output back where its prompt came from:

# before
outs = llm.generate(prompts, params)

# after
outs = llm.generate([prompts[i] for i in order], params)
results = [None] * len(prompts)
for pos, i in enumerate(order):
    results[i] = outs[pos]

Skip the restore step and every downstream join is wrong. You will see it as answers attached to the wrong question, not as an error.

Your batch size is max_num_seqs on the LLM constructor. It decides where you sit on the curve above, so record it with every result.

Role 3, measuring. Run the same prompts in both orders and compare tokens per second. Force equal output lengths so only the order differs:

import time
params = SamplingParams(temperature=0, max_tokens=256, ignore_eos=True)

def tok_per_s(batch):
    t = time.perf_counter()
    outs = llm.generate(batch, params)
    return sum(len(o.outputs[0].token_ids) for o in outs) / (time.perf_counter() - t)

Alternate the runs: shuffled, sorted, shuffled, sorted. A single pair can be skewed by a warm cache. The author's full harness is vllm_bench.py in the sort-your-prompts repository on GitHub. It had no license file when this was written, so read it for the method.

How you know it worked.

The sorted runs should beat the shuffled runs on every repeat, not just on average. On a mixture-of-experts model with labeled topics, expect something near 10%. Then run the same test on a dense model of similar size as a control. It should show no gain, because a dense model reads every weight on every step. If the dense model "improves" too, your measurement is noise. Last, compare outputs. The share that differs between sorted and shuffled should match the share that differs between two shuffled runs. If it is much higher, check the restore step.

When Sorting Prompts Is the Wrong Tool

When someone is waiting. Grouping means holding a request until similar ones arrive. In online serving, that queueing delay costs more than the step time it saves.

When the model is dense. Every weight is read on every step, whatever the order. A dense model like Llama 3 gains nothing.

When the work is mostly prefill. A long prompt with a short answer spends its time reading the prompt. Thousands of prompt tokens touch nearly every expert anyway. A classifier that emits one label per document is this case.

When batches are very large. Once even a one-topic batch touches almost every expert, there is nothing left to save. On unlabeled chat data, gpt-oss-120b at batch 128 showed no measurable gain.

When the model has few experts. A coarse model with 32 experts per layer saved 8 to 11% of reads, against 19 to 25% for 128 experts.

Before you adopt it, ask:

Is my model a mixture of experts, and is this job decode-heavy?
What batch size does my job really run at?
Did a dense control show zero gain on the same A/B test?

Glossary

experts — small blocks of weights in a layer; each token is routed to a few of them.
mixture-of-experts — a model whose layers hold many experts and use only a few per token.
decode step — one round in which every request in the batch produces its next token.
batch — the set of requests the server runs together on each step.
k-means — a clustering method that groups vectors around a chosen number of centers.
batch nondeterminism — small output changes caused only by which requests shared a batch.

How to Stop a Coding Agent and an AI Reviewer From Looping on One Pull Request

Mayur Agnani — Tue, 20 Oct 2026 11:29:01 +0000

Engineer's view. This is "retry until green" on a flaky test suite. The job stops at the first green run, so noise decides when it ends, and one green run proves little. An agent and an AI reviewer stop the same way: at the first review with nothing to fix. It costs rounds and missed bugs.

TL;DR. An agent and an AI reviewer stop looping only when a review finds nothing to fix. Let only new, important problems on changed lines block, and stop after two clean reviews in a row.

Explain Like I'm 5

You ask a friend to check your story for mistakes. Every time they find something, you fix it and hand it back. Some of their notes are real mistakes. Some are just "I'd use a different word." Each fix gives them a fresh page to find new little things on. So you go back and forth all afternoon. Then one time they glance and say "looks fine," and you stop. But a glance can miss a real mistake. Better rules: only fix real mistakes, and stop when they've read it carefully twice and found nothing.

The Problem

You have shipped this loop before, in CI.

A test suite has a few flaky tests. Someone adds a retry: run the suite until it passes, up to five times. Two things go wrong. Builds take longer, because the flaky tests keep failing for no reason. And a real failure that only shows up half the time now gets through. One lucky green run is enough. The stop rule was "the first green run," and noise decided when that came.

A coding agent working with an AI reviewer runs the same loop. The reviewer reads the pull request and leaves comments. The agent fixes every one, because to an agent a comment is an instruction. Each fix is a new commit, so the reviewer runs again. The loop ends at the first review that finds nothing to fix.

Anthropic's Claude Code team, where Claude writes about 90% of the code, measured this. Before they changed their rules, 8.9% of internal pull requests needed five or more review rounds. One pull request ran more than fifty rounds overnight. About 59% of what the reviewer kept flagging in later rounds was code that was already there before the change.

The long tail costs CI time and attention. The quieter cost is the one the flaky suite taught you: a single clean review is weak evidence when the reviewer misses half the bugs on any one pass.

Decide what is allowed to block, and decide when the loop may stop. Block only new, important findings on lines the change touched. Stop after two clean reviews in a row. After three fix rounds, hand the pull request to a person.

The Fix: Let Only Real Findings Block, and Require Two Clean Passes

New to how an agent works through a task? Start at AI basics → The agent loop.

Why does the loop run so long?

Because the stop rule counts every comment. A review pass is one full read of the pull request by the reviewer. A fix round is one commit the agent makes in answer to it. The loop stops at the first pass with nothing to fix.

Three kinds of comment keep that from happening. Nits are new on every pass, because the reviewer samples them fresh. Findings in old code reappear, because the old code is still there. And the same finding can come back in new words. The agent fixes all of them, and each fix starts another round.

Why not just cap the rounds, or re-review only the new lines?

Both cut rounds, and both lose bugs. Each full pass is another independent look at the real bugs the last pass missed. In the simulation in code_example.py, the reviewer's recall is 50%: it catches each real bug half the time per pass. Cutting the noise but stopping at one clean pass let 24.4% of bugs escape. The noisy loop let 13.1% escape. Its extra rounds were accidental second looks.

So what should block, and when should it stop?

Only a blocking finding starts a fix round. That means new, tagged important, and on a line the pull request changed. A pre-existing finding goes on a list once. A finding is identified by its file, line, and rule, so a repeat is dropped. A clean pass must happen twice in a row before the gate passes. The second clean pass costs a review, but no agent commit and no CI run.

What This Means for You

When this matters. You run a coding agent that answers review comments on its own. That might be the Claude Code GitHub Action, Copilot's coding agent with Copilot review, or your own loop. It matters most on large pull requests. The Claude Code team found most pull requests over 1,000 lines get findings, while most small ones come back clean.

How it affects you. The first thing you notice is CI cost and slow merges. The thing you don't notice is escapes. Loosening the loop to save rounds can quietly double the bugs that get through. The agent's fix commits are the expensive part. Each one reruns CI, and each one can add a bug of its own. In the simulation, the two-clean-pass gate cut agent fix rounds from 2.07 to 1.01 per pull request. No pull request needed five rounds. Escapes stayed at 13.1%, the same as the noisy loop. The cost: 13.4% of pull requests went to a person after three rounds.

What to do about it. Today, count how many review rounds your last twenty agent pull requests took. Look for rounds where the agent fixed only nits or old code; those are the rounds the gate removes. Then write down what is allowed to block. Change the stop rule last, and only together with the blocking rule.

Implementing It

The change.

Three roles touch this. Whoever configures the reviewer decides what it tags important. Whoever owns CI runs the gate. Whoever writes the agent's instructions stops it from fixing what does not block.

Role 1, the reviewer's configuration. If you use Claude's managed code review, put this in REVIEW.md at the repo root. Other reviewers take the same text as part of their prompt:

## What counts as Important here
- A bug on a line this pull request changed, with file:line evidence.
- Not style, naming or cleanup. Tag those Nit.
- Code the pull request did not touch: tag Pre-existing, never Important.
Start your summary with the count of Important findings.

Ask the reviewer to emit its findings as JSON: path, line, rule, severity. The gate reads that. Keep the rule names stable from pass to pass, because the gate matches repeats on them.

Role 2, CI. The gate is a required status check on every push. It keeps a small state file per pull request, so it can count clean passes and fix rounds across pushes:

def decide(self, findings):
    blocking = [f for f in self.new(findings)
                if f.severity == "important" and (f.path, f.line) in self.changed]
    if not blocking:
        self.clean_streak += 1
        return "pass" if self.clean_streak >= REQUIRED_CLEAN else "review"
    self.clean_streak = 0
    if self.fix_rounds >= MAX_FIX_ROUNDS:
        return "escalate"
    self.fix_rounds += 1
    return "fix"

self.new() drops any finding whose path, line, and rule were already seen. On "review", run the reviewer again without waiting for a commit. On "escalate", fail the check and request a human reviewer. Get the changed lines from git diff --unified=0 against the merge base, so a rebase does not count old lines as new. Store the state as a hidden comment on the pull request or in the CI cache. Either one survives between pushes.

Role 3, the agent's instructions. Add this to CLAUDE.md, or to whatever file your agent reads:

When you answer review comments, fix only findings the review gate lists as blocking.
Do not fix Nit or Pre-existing findings in this pull request. Do not edit lines
outside the diff to satisfy a comment.

Without this, the agent fixes nits anyway, and every nit still costs a commit.

How you know it worked.

Before you switch, record three numbers over twenty pull requests: fix rounds per pull request, the share needing five or more rounds, and reverts within a week of merge. After two weeks, rounds should fall and the five-round tail should vanish. Escalations should stay near one in ten; far above that, the important tag is too loose. Reverts must not rise. If they do, you have only moved the work, so raise the required clean passes before anything else.

When a Two-Clean-Pass Gate Is the Wrong Tool

When two passes are not independent. The second pass helps only if it can miss different things than the first. A reviewer at temperature zero, with the same prompt and the same context, may return the same answer twice. Then the second clean pass proves nothing. Vary something between passes: a second model, a different focus, or parallel reviewers that vote.

When a person writes the code. A human author pushes back on nits and rarely fixes all of them. The loop that this gate controls mostly doesn't form.

When the change is small and low risk. A docs fix or a flagged, additive change can pass on one clean review. Match the passes to the risk, as the Claude Code team does with its review tiers.

When nobody reads the escalations. A gate that sends 13% of pull requests to a person needs a person. Otherwise those pull requests just sit, and engineers learn to route around the check.

Before you adopt it, ask:

Do my reviewer's passes actually differ from each other?
Who picks up a pull request after three fix rounds?
Do I know my revert rate today?

Glossary

review pass — one full read of the pull request by the AI reviewer.
fix round — one commit the agent makes in answer to a review pass.
blocking finding — a new finding, tagged important, on a line the pull request changed.
pre-existing finding — a finding in code the pull request did not touch; listed, never blocking.
clean pass — a review pass with no blocking findings.
recall — the share of real bugs one review pass catches.

How to Make Your Agent Check the Records It Changed Before It Says Done

Mayur Agnani — Tue, 20 Oct 2026 01:14:16 +0000

Engineer's view. This is an endpoint that returns 200 after writing the wrong value. The handler logged success, and only a look at the row shows the bug. An agent's "done" is that 200: it comes from what its tools returned. Checking the records it changed is the test it never ran.

TL;DR. An agent decides it is done from what its tools returned, and a wrong write returns success just like a right one. Check the records it actually changed against what the task required, before it closes the task.

Explain Like I'm 5

You ask a friend to put the milk in the fridge. They say "done!" You believe them, because they did walk to the kitchen. Later you find the milk in the cupboard. Your friend was not lying. They opened a door, put the milk behind it, and the door closed fine. Nothing went wrong that they could hear. The only way to know is to open the fridge. So before you say thanks, you look inside.

The Problem

You have shipped this bug before, in an API.

A support tool calls PATCH /orders/A17 to put an order on hold. A mapping bug sends resolved instead of on_hold. The endpoint validates the value, writes it, and returns 200. The client logs success. Your dashboard of error rates stays flat. A week later the customer calls, because nobody ever followed up. The bug was never in the transport. It was in the row, and nothing looked at the row.

An agent that writes to a backend has the same blind spot, at a larger scale. It decides it is done by reading its own transcript. The transcript holds what each tool returned. A write with the wrong value returns "ok" just like a right one.

Microsoft's ThinkingBox team measured how often this happens. Their example is a customer whose $745 appliance sat in a carrier exception for fifteen days. The agent made nine well-formed tool calls and read the refund policy correctly. Then it closed the ticket as resolved. The policy said it had to stay on hold while the exception was open.

That was not a rare case. Across 12 models, they ran 121,680 trials and saw 79,853 failures. Of those failures, 67% ended cleanly. The agent changed state, reported no tool error, and said it was done. A check on the transcript would have passed two thirds of the failures.

Check the records the agent changed, not the messages it wrote. Log every write the agent makes, compare those writes to what the task requires, and refuse to close the task until they match.

The Fix: Check the Agent's Writes Before It Closes the Task

New to how an agent decides it is finished? Start at AI basics → The agent loop.

Why doesn't the agent notice on its own?

Because nothing it can see is wrong. The model reads tool results, not your database. If update_ticket returns {"ok": true}, the model has no signal that the value it sent was the wrong one. Asking it to "double-check" only makes it reread the same transcript.

So the check has to read state. Every write the agent makes is an effect: a table, a row, a field, and its value before and after.

What does the check compare?

A contract per task type. It lists the fields that must end at a given value and the fields the task may touch. Comparing the effects to the contract finds three kinds of failure:

In ThinkingBox's failures, 78% had a wrong field value, 43% had an extra effect, and 25% missed a required one. One run can have more than one.

Where does the check go?

On the tool that ends the task, such as close_ticket. If the check finds a problem, the tool refuses and returns the list of problems as its result. The agent then reads a real signal: which field is wrong, and what it should be. It can fix the field, or hand the ticket to a person.

What This Means for You

When this matters. Any agent that writes to a system of record: tickets, orders, refunds, a CRM, a calendar. It matters most where a wrong write is quiet. A ticket marked resolved sends no alert. A refund issued twice shows up only at month end.

How it affects you. Most of your agent's failures will look like successes in your logs. ThinkingBox's authors read the failures as mostly a problem of tool use and recovery, not reasoning. That is good news, because tool use is the part you control.

There is a second cost. A single run tells you little about the next one. One open-weight model in the study solved 94% of tasks at least once, but only 13% on all 20 tries. Claude Opus 5 solved fewer at least once, yet passed 48% on every try. The code_example.py file shows why. Two simulated agents both pass about 72% of single runs. One fails a little on every task, and passes all 20 runs on none of them. The other is reliable on most tasks and hopeless on a few, and passes all 20 on 38%.

What to do about it. Log every write at the tool layer. Write a contract for each task type that changes records. Put the check on the closing tool. Then score your agent by how many tasks pass every run, not by its average.

Implementing It

The change.

Three roles touch this. Whoever writes the tools records each write. Whoever builds the agent puts the check on the closing tool. Whoever runs the evals scores every task over several clean runs.

Role 1, whoever writes the tools. Route every state-changing tool through one write function. It records the effect before it returns:

def write(self, table, key, field, value):
    row = self.db[table].setdefault(key, {})
    self.effects.append(Effect(table, key, field, row.get(field), value))
    row[field] = value
    return "ok"            # all the model will ever see

Read-only tools skip it. A tool that calls another service records what it asked for, plus the id that service returned. Keep one log per run, never one per process, so two runs never share effects.

Role 2, whoever builds the agent. Write the contract from your policy, not from a golden run. A ticket with an open carrier exception must end on hold:

HOLD = Contract(
    required={("tickets", "T9", "status"): "on_hold"},
    allowed={("tickets", "T9", "note"), ("tickets", "T9", "closed")},
)

The check reads final values for the required fields, and flags any effect outside both sets. Put it on the closing tool. In the OpenAI Agents SDK, a tool input guardrail runs before the tool executes and can reject the call with a message:

from agents import ToolGuardrailFunctionOutput
from agents.decorators import tool, tool_input_guardrail

@tool_input_guardrail
def records_match_task(data):
    problems = contract_for(current_task()).check(db, effect_log.effects)
    if problems:
        return ToolGuardrailFunctionOutput.reject_content(
            "Not closed. Fix these first:\n" + "\n".join(problems))
    return ToolGuardrailFunctionOutput.allow()

@tool(tool_input_guardrails=[records_match_task])
def close_ticket(ticket_id: str) -> str: ...

The rejection message goes back to the model as the tool's output. Without that SDK, do the same check at the top of the tool function. Cap the retries, then escalate to a person.

Role 3, whoever runs the evals. Run each task several times, each from a fresh copy of the data, and count the tasks that pass every run. The fresh copy matters: a run that starts on rows an earlier run changed can pass for the wrong reason. That number is called pass^k:

every = sum(all(run_task(t, fresh_db()) for _ in range(k)) for t in tasks)
print(f"pass^{k}: {every / len(tasks):.0%}")

How you know it worked.

Replay four runs: one right, one with a wrong value, one with an extra write, one with a missing write. A transcript check passes all four. Your gate must close the first and refuse the other three, naming the field each time. In production, count refusals by kind. A rising count of extra effects usually means the agent has a tool it should not have.

When a Completion Check Is the Wrong Tool

When you cannot say what the end state should be. A research agent or a drafting agent has no record to check. Review its output instead, or grade it with a rubric.

When the effect leaves your system. An email, a payment to a third party, or a message in someone else's queue cannot be read back or undone. A check after the fact only tells you what went wrong. Require a person's approval before those calls instead.

When the task types multiply faster than you can write contracts. Write contracts only for the tasks that change money, status, or anything a customer sees. Let the rest through with an effect log you review weekly.

When the agent only reads. A read-only agent has no effects. Its failures are wrong answers, and those belong in an answer eval.

The authors did not measure how much a check like this raises the pass rate, and neither did this session. Measure it on your own tasks before you promise anyone a number.

Before you add a gate, ask:

Can I write down, for this task type, which fields must change and to what?
Does every write go through a layer I can log?
What happens to the customer if the gate refuses and nobody picks it up?

Glossary

transcript — the messages and tool results an agent has seen so far in a run.
effect — one write the agent made: table, row, field, and the value before and after.
contract — for one task type, the fields that must end at a value and those it may touch.
extra effect — a write to a field the task's contract does not allow.
tool input guardrail — an Agents SDK check that runs before a tool and can reject the call.
pass^k — the share of tasks an agent passes on every one of k clean runs.

DEV Community: Mayur Agnani

How Sorting Your Prompts Speeds Up a Mixture-of-Experts Batch Job

Explain Like I'm 5

The Problem

The Fix: Group Similar Prompts Before the Batch Job

Why does the order of a list change what the GPU reads?

How much does one expert cost?

Why was the measured gain smaller than the reads saved?

Do I need topic labels?

What This Means for You

Implementing It

When Sorting Prompts Is the Wrong Tool

Glossary

Further reading

How to Stop a Coding Agent and an AI Reviewer From Looping on One Pull Request

Explain Like I'm 5

The Problem

The Fix: Let Only Real Findings Block, and Require Two Clean Passes

Why does the loop run so long?

Why not just cap the rounds, or re-review only the new lines?

So what should block, and when should it stop?

What This Means for You

Implementing It

When a Two-Clean-Pass Gate Is the Wrong Tool

Glossary

Further reading

How to Make Your Agent Check the Records It Changed Before It Says Done

Explain Like I'm 5

The Problem

The Fix: Check the Agent's Writes Before It Closes the Task

Why doesn't the agent notice on its own?

What does the check compare?

Where does the check go?

What This Means for You

Implementing It

When a Completion Check Is the Wrong Tool

Glossary

Further reading