The Coding Bot

Overview

The Coding Bot is an automated code-review and fix-generation assistant. It analyses code changes as they are pushed. It detects problems, opens tickets, generates safe fixes, raises pull requests and notifies reviewers. Human approval stays mandatory before anything merges or deploys. It serves engineering teams who want the speed of automation without giving up control of what reaches production.

Challenges

Engineers spent far too much time reviewing each code change and preparing fixes by hand. That slowed delivery across the team. Code quality enforcement was inconsistent. Static analysis and project-specific rules were applied ad hoc instead of automatically on each push and pull request. Tenant-safety gaps slipped through review. Missing schema context and isolation risks reached production unnoticed. API endpoints shipped without consistent authorisation so permission checks were missing. Hardcoded secrets, injection risks and unsafe patterns went undetected without automated scanning. Pull requests lacked the context reviewers actually needed. No rationale for a fix. No risk notes, no test results and no manual verification steps. Alerts arrived as a stream of noisy one-off notifications. Severe and trivial looked the same. Automation carried its own risk too. Unsafe autonomous merges. Broad AI-generated changes landing without oversight. And scanning the whole codebase on each change simply couldn't scale.

Solution highlights

We built a bot that does the tedious part and stops short of the dangerous part. Analysis triggers automatically on push and pull-request events. It looks at changed files first so it scales as the codebase grows. It runs static analysis across backend and front-end code. It applies custom rule checks for tenant safety, permission coverage and project conventions. It scans for hardcoded secrets, injection risks and unsafe patterns. Where an issue is low-risk the bot generates a fix using AI. That fix is gated by a confidence score. The score decides whether to open a pull request or just file an issue for a human. Lint and test validation runs before any pull request is created. A fix that fails those checks is downgraded to issue-only rather than raised as an unsafe pull request. Pull requests that do get opened carry what reviewers need: fix details, risk notes, test results and manual verification steps. Reviewer and admin notification workflows surface issue status, severity, affected files and results. Severity-based batching cuts the noise. The bot deploys via Docker with minimal configuration for rules, alert recipients and AI vendor settings. It can be disabled per-rule or entirely.

Key Features

• Automated code analysis on push and pull-request events with changed files scanned first
• Static analysis for backend and front-end code
• Custom rule checks for tenant safety, permission coverage and project conventions
• Security scanning for secrets, injection risks and unsafe patterns
• AI-assisted fix generation for low-risk issues with confidence scoring
• Lint and test validation before any pull request is created
• Automatic issue creation and pull requests for high-confidence fixes only
• Pull requests including fix rationale, risk notes, test results and verification steps
• Reviewer and admin notification workflows with severity-based batching
• Docker-based deployment with minimal admin configuration and kill switches
• Planned runtime log monitoring and natural-language bug and feature requests
• Planned admin dashboard with metrics, audit history, live status and AI usage

Our Role & Approach

Our role was to build automation the engineering team would actually trust. That meant being explicit about what the bot must never do. We deferred fully autonomous operation, auto-merge and browser-console monitoring entirely. Human review, dev deployment and approval stay mandatory for each generated change. Automatic pull requests were limited to high-confidence low-risk categories. Anything else gets downgraded to an issue. We designed the validation chain so failure is safe by default. If lint or tests fail the bot files an issue instead of pushing a change. For scale we made analysis incremental rather than full-codebase. And we structured delivery in phases. The core review loop had to prove itself before we extended into runtime log monitoring, natural-language requests, multi-vendor AI with fallback and a full admin dashboard.

Technology Stack

Backend: Django, Python, Celery, Redis, RabbitMQ, PostgreSQL. Frontend: React, TypeScript, Vite, MUI, Tailwind CSS. DevOps: GitHub API, GitHub webhooks, Issues and Pull Requests, Docker, Docker Compose. Static analysis: Ruff, ESLint, Prettier, Bandit, Semgrep. AI: OpenAI, Anthropic, Gemini. Notifications: email/SMTP, GitHub notifications, optional SMS.

Outcomes

Teams cut manual review effort a lot. Issue detection and initial fix preparation now happen automatically on each change. Code quality is enforced consistently through repeatable static analysis and project-specific rules. It doesn't depend on whoever happens to be reviewing that day. Tenant-safety risks get caught early through automated schema and isolation validation. Authorisation gaps surface automatically when the bot finds missing permission checks. Security coverage improved with automated scanning for secrets, injection risks and unsafe patterns. Reviewers get better pull requests carrying rationale, risk notes, test results and verification steps. Review is faster as well as lighter. Releases stay safe because human review and approval are still mandatory before any merge or deployment. Alert handling became manageable through severity-based batching instead of constant notifications. Each bot action is traceable through issue creation, pull request history, notifications and audit-ready status reporting. There's a clear path to extend into logs, dashboards and multi-vendor AI.