Building an AI PR Reviewer and Standup Bot That Actually Works

Engineering teams waste enormous time on two things: reviewing boilerplate code feedback, and writing repetitive standup updates. At Edelta Corporation, I built two internal AI developer tools that cut both of these down significantly.

Tool 1: The Automated GitHub PR Reviewer

The Problem

Our team reviews 15–30 PRs per week across 16+ client portals. Code reviewers were spending cycles on the same class of issues: missing error handling, inconsistent naming, no input validation. These are the things a machine should catch, freeing the human reviewer to focus on architecture and business logic.

How It Works

The bot is a Node.js service triggered via GitHub Webhooks on every pull_request event.

The Prompt Design

The system prompt matters more than the model. I structured the prompt to return a consistent JSON schema:

{
  "file": "src/routes/claims.ts",
  "line": 42,
  "severity": "warning",
  "category": "error-handling",
  "comment": "This async function is not wrapped in try/catch. Unhandled rejections will crash the process."
}

This way, parsing is deterministic and the GitHub API call is mechanical.

Rules the Bot Enforces

• Missing try/catch in async functions
• Hardcoded secrets or credentials (regex + LLM double-check)
• console.log left in production code
• Functions exceeding 50 lines without a comment
• Missing TypeScript return types on exported functions

Results

• ~30% reduction in review round trips for junior PRs
• Senior reviewers now focus only on architecture-level feedback
• Zero false positives on secret detection (regex first, LLM second pattern)

Tool 2: The Standup Bot

The Problem

Daily standups were running 20–30 minutes for an 8-person team. Half the time was spent context-switching between projects people didn't work on. The actual engineering blockers were buried in conversation noise.

The Architecture

The Extraction Prompt

The prompt instructs the model to:

1. Identify each speaker (by voice or name reference)
2. Extract what they completed yesterday
3. Extract what they plan today
4. Critically: identify explicit blockers and implicit blockers (e.g., "I'm waiting on the client to send those credentials" is an implicit blocker even if not stated as one)

Sample Output

📋 Daily Standup Summary — March 8, 2025

Darshan
  ✅ Done: Deployed auth service to staging, fixed Redis TTL bug
  🗓 Today: Migrate claims PDF generator to Lambda
  🚧 Blocker: Need DB schema approval from client before proceeding

Rahul
  ✅ Done: Completed HRM leave module UI
  🗓 Today: Start payroll integration
  🚧 Blocker: None

Async standups replaced ~70% of our live standup time. The remaining 30% is now a focused blockers-only call.

Key Engineering Learnings

1. Prompts are APIs — treat them like code. Version them, test them, review changes.
2. LLMs hallucinate structure — always validate the JSON response with Zod before trusting it.
3. Whisper accuracy varies with audio quality — we added a "confidence" threshold; low-confidence transcripts trigger a human review flag instead of auto-posting.
4. GitHub Webhook retries matter — implement idempotency keys to prevent duplicate review comments if webhooks fire twice.

Both tools are internal, but the patterns are transferable to any team looking to reduce the mechanical overhead of engineering processes.