state-of-the-art-first

Start at the state of the art

The default failure is building from priors. You reach for the technique you already know, the base model, the single-pass version — and produce something that works but is visibly a tier below what the field is doing. In fast-moving areas your priors are often a year or more stale.

Research first, then build the most capable version you can. Complexity is not a cost in craft work; it is usually the entire difference between "fine" and "beautiful".

The order of operations

1. Search before you build. Find current guides, papers, documentation, implementations, comparisons, benchmarks and workflow write-ups. Search for the year, "best", "vs", "workflow", "pipeline", "production", "failure", and the exact task or medium.
2. Build a broad evidence set. For an ordinary state-of-the-art review, open and assess at least 24 genuinely relevant sources; use 30 or more for fast-moving, consequential or contested topics. Do not count search snippets, mirrors, syndicated copies or several pages repeating one source as separate evidence.
3. Diversify the evidence. Include multiple independent authors/domains and draw from all applicable groups: official documentation/specifications and release notes; research papers/model cards; maintained implementations, repositories and issue discussions; production case studies and expert practitioner workflows; comparative benchmarks, postmortems and substantive community evaluations. Do not let vendor quickstarts dominate the result.
4. Read the sources, not just their titles. Capture the claim each source supports, its publication/update date, whether it is primary or secondary, and the conditions under which its result applies. Prefer recent evidence, but retain older foundational work when newer practice still depends on it.
5. Synthesize rather than vote. Identify convergence, disagreements, outliers, hidden workload assumptions, version differences and trade-offs. Weight direct measurements and primary evidence above popularity. Continue searching until the latest several credible sources add no material new technique, risk or disagreement.
6. Find out what strong practitioners actually use. The quickstart is designed to be simple; the production/community pipeline is designed to be good. Separate widespread practice from one impressive but unreplicated demo.
7. Identify the multi-stage version. Serious pipelines are usually multi-pass: generate then refine, draft then critique, block in then detail, act then verify. If the plan has one stage, check whether it is merely the tutorial version.
8. Then implement the ambitious evidence-backed version. Preserve the user's constraints and choose sophistication only where the research shows an observable benefit.
9. Verify by comparison, not assertion. Test representative cases and compare quality, correctness, latency, cost and failure behavior against the simpler baseline.