Awesome Reviewers, rebuilt: instructions across AI and infrastructure domains

Awesome Reviewers started as a side effect of a question we kept asking ourselves: where do a team's real engineering standards live? Not in the style guide, and usually not in the docs. They live in review threads, in the moment a maintainer explains why a change is unsafe, and then they disappear the second the pull request merges.

Almost a year after we opened it to the public, the project has grown past the shape we first gave it. So we rebuilt it. The library now includes instructions distilled from review discussions across production repositories, organized into AI and infrastructure domains. The site around it is smaller, faster, and built for a reader who is often not a human.

Here is what changed, and how we got here.

How our thinking evolved

November 2025: the original framing. We launched as a catalog of reusable review prompts, built for a developer browsing a site and copying one prompt into a chat window. That made sense for how people thought about AI guidance at the time: discrete, portable, human-selected.

The nine months after. The requests we fielded told us something different was happening. Teams were not asking "which repositories should we extract from?" They were asking "can you extract from the systems we build against, and put them in a format our own harnesses can consume?" The repositories changed from "popular open source" to the specific domains teams cared about: agent frameworks and coding assistants, inference servers, Kubernetes clusters, query engines, infrastructure as code, telemetry. And the way people wanted to use the guidance shifted too. Instead of copying individual prompts, they wanted bulk access to every instruction in a domain, so their review automation could pull what mattered and serve it where their code was actually being written.

The old site was answering a question we were no longer being asked. Its default categories ("code readability," "testing") revealed nothing about the context where an instruction was written. And every read required navigating a page.

This shift pointed at something bigger: the question was not "do you have good review guidance?" It was "how do we make our team's review standards live as a resource that scales beyond human reviewers?"

What the refresh changed

Domain-centric, not topic-centric. The core insight: the domain where a standard was written is what makes it useful. "Error handling" means something different in an inference server than in a web framework. So we reorganized around 12 domains: AI agents and assistants, LLM serving and gateways, ML frameworks, containers and orchestration, cloud infrastructure, databases, observability, security, language runtimes, developer tooling, application frameworks, and documentation. An instruction extracted from an inference server now tells you, immediately, that it's written by people running inference at scale. Topic and language are filters you apply within a domain, not the other way around.

This mirrors how your own team should think about review standards. If you build on Kubernetes, your scheduler concurrency patterns are different from your database write-path patterns. Domain-aware standards let teams pull exactly what applies to the system they are working in, without wading through irrelevant guidance.

Everything is dated, automatically. Instead of claiming "written today," we derive dates from the source review threads themselves. An instruction looks old when it is old, because its source discussion went quiet. That gives your review automation useful signal: guidance from a codebase that has moved on is less trustworthy than guidance from active repositories. It is a natural deprecation, without manual curation.

Bulk access, not page visits. The mindset shift here is fundamental. Instead of "browse the site and copy a prompt," the model is "pull the corpus into your harness, and let your tools serve guidance where your code is." Everything is available as raw markdown and JSON, with no keys and no rate limits. Your review automation fetches a domain bundle, loads it into memory, and serves excerpts where they matter.

For your own harnesses: keep your review standards in version control as plain markdown. Let your automation layer consume them, not humans. The standards live once and get embedded everywhere they apply.

Backward tracing to the source. Every instruction links to the original review threads it came from. This matters less for automation than for the human moment when a developer asks "why does this rule exist?" Now the answer is not a comment in your repository, but a conversation from a team that solved the same problem. That context builds confidence in the standard, especially when the source team is someone you respect.

What we removed

The refresh meant removing a lot of UI surface that made sense when Awesome Reviewers was a human-browsing experience.

The leaderboards, contributor profiles, organizational dashboards, organization explorer, skills catalog. All of it assumed that a reviewer would visit the site as a destination. But that is not how standards live in a working engineering organization. They live in your pull request tool, your IDE, your agent's context. They are embedded, not visited.

We deleted everything that asked "how can we make this site engaging?" and kept everything that asks "how can we make this useful where our engineers actually work?"

The mental model changed from "Awesome Reviewers is a place" to "Awesome Reviewers is a resource pool." That distinction is crucial for how you build your own in-house harnesses. Your standards are not a wiki that people visit. They are a feed that your automation consumes and serves in context.

How to use it in your own harnesses

The pattern we built here is meant to be replicable in-house. Your team probably has the same untapped asset: years of review threads, containing the actual standards that matter. Here is how you apply this pattern:

Extract standards from your own code review history. The format is simple: markdown files with no framework assumptions, metadata in YAML front matter, and optionally a JSON sibling linking back to source discussions. You can build this yourself, or use our extraction pipeline if your repositories are public.

Organize by your domain, not generic topics. Do you run distributed systems? Microservices? Embedded code? Machine learning pipelines? Those are your domains. Every standard belongs to one, because context determines applicability. A concurrency rule for your scheduler looks different from a concurrency rule for your query engine.

Feed your standards into your harnesses. Load a domain bundle into your review agent. Give your context broker the index so it knows what to pull. Embed standards in your IDE linter configuration. Let your continuous integration tool consume them and flag violations before code review. The standards do not belong in a wiki. They belong in the systems where developers actually work.

Keep them alive. Review standards are not documentation. Documentation rots. Standards rot faster because they encode opinions that code changes prove or disprove. Use versioning and dates to deprecate old guidance. Let your developers propose changes via pull request. Every merge to your standard makes it slightly more real than the last version.

This is the shift from "we have a code review checklist" to "our review standards are a living resource that powers our entire development experience."

---

Awesome Reviewers itself is available in plain markdown, no dependencies, Apache-2.0. You can fork it, extract from your own repositories, or add yours to the sources page. Contribute fixes as pull requests against individual files in _reviewers/.

If you want this running against your private repositories with pull request integration, that is what Baz does. Otherwise, the entire corpus is yours to adapt.

One note from our method page: these standards are distilled from actual code reviews, not official guidance. They are what experienced reviewers kept saying, which is more useful and more honest than documentation.