{"slug": "what-to-give-an-ai-vs-a-human-in-frontend-pr-review", "title": "What to Give an AI vs a Human in Frontend PR Review", "summary": "A developer described splitting frontend pull-request review into two passes: an AI pass limited to the diff plus explicit team constraints, returning a severity-tagged checklist with file:line pointers, and a human pass for product judgment, accessibility context, and trust. The developer reported that mechanical review got faster while product discussions improved, and said AI should never be asked to judge product decisions because it invents confidence.", "body_md": "I used to paste the whole PR into a chat model and ask “anything wrong?” That felt productive for about a week. Then I noticed the same misses: accessibility regressions nobody flagged, token churn that looked fine in isolation, and “LGTM” on logic that only a teammate who knew the product would catch.\n\nSo I split the review. AI gets the mechanical pass. Humans get the judgment pass. Same PR, different jobs.\n\nGive it **diff + constraints**, not vibes.\n\nI usually paste:\n\nThen I ask for concrete checks:\n\nI want a checklist back, with file:line pointers. Not a rewrite of the component.\n\nWhat I *don’t* ask the model for: “is this a good product decision?” It will invent confidence. That’s not its job.\n\nHumans review what the model can’t see from a diff alone:\n\nI also keep one human pass for **trust**. If an AI says “looks fine” and a senior says “wait,” I trust the senior. Every time.\n\nMy current loop:\n\nTwo rules that saved me from rubber‑stamping:\n\nSomething like this (trimmed):\n\nYou are reviewing a frontend PR. List issues only — no praise padding.\n\nConstraints: [paste team rules].\n\nFor each issue: severity (block / should‑fix / nit), file path, why it matters, suggested fix in one sentence.\n\nIgnore style nits already covered by the linter.\n\nDo not rewrite large files. Do not invent requirements that aren’t in the ticket.\n\nThe “no praise padding” line matters. Models love to open with “Great work overall!” and bury the real bug.\n\nReviews got faster on the mechanical stuff and slower (in a good way) on product judgment. Teammates stopped arguing with the bot about spacing preferences and started arguing with each other about whether the empty state should deep‑link — which is the conversation we actually needed.\n\nAI is a sharp junior with infinite patience for checklists. Humans still own the merge button. Keep that line clear and frontend PR review stops feeling like theater.\n\nIf you already split AI vs human review on your team, I’d love to hear what you refuse to automate — those refusals are usually the real design system.", "url": "https://wpnews.pro/news/what-to-give-an-ai-vs-a-human-in-frontend-pr-review", "canonical_source": "https://dev.to/sherotree/what-to-give-an-ai-vs-a-human-in-frontend-pr-review-4hbe", "published_at": "2026-10-19 12:35:31+00:00", "updated_at": "2026-10-19 12:44:43.197209+00:00", "lang": "en", "topics": ["ai-tools", "developer-tools", "artificial-intelligence"], "entities": [], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/what-to-give-an-ai-vs-a-human-in-frontend-pr-review", "markdown": "https://wpnews.pro/news/what-to-give-an-ai-vs-a-human-in-frontend-pr-review.md", "text": "https://wpnews.pro/news/what-to-give-an-ai-vs-a-human-in-frontend-pr-review.txt", "jsonld": "https://wpnews.pro/news/what-to-give-an-ai-vs-a-human-in-frontend-pr-review.jsonld"}}