PR #342 opened by @dev-junior. Review complete. Security: auth-utils library with CVE-2024-8821 (high severity), patch in 3.2.4. Quality: variable user_id uses snake_case; team convention requires camelCase. Test coverage: new function validateSession has no unit tests; suggested test pattern attached.
AGENT · CODE REVIEW PRE-MERGE
Pull requests go through an automated review before merge.
Code Review Pre-Merge activates on every new pull request in the customer's repository. It runs an automated review against security standards, code quality, and test coverage configured by the team. It leaves structured comments directly on the PR; the senior developer decides the merge.
Code Review Pre-Merge at work.
Applying all three. Pushing new commit.
Re-review PR #342: CVE resolved, naming corrected, tests added. All signals green. Ready for senior review.
Why it exists.
Code review is one of the core processes in software development. Most mid-to-large companies have documented security and quality standards, but applying those standards to each PR is usually manual: the senior developer reads the PR, applies the standards from memory, leaves comments. The process is slow, prone to skipping steps when PR volume is high, and dependent on the senior's availability.
How it works on every PR.
Code Review Pre-Merge activates on a new PR trigger (via GitHub webhook). It reads the PR diff and applies the customer's declarative standards: security (language-specific security patterns, recognition of common vulnerabilities, flagging of libraries with known CVEs), code quality (style conventions, naming, structure), and test coverage (presence of tests for new functions, sufficient coverage of the change). It leaves structured comments on the PR with specific detail and a proposed correction where possible.
The decision stays with the team.
The senior developer reviews the PR together with the agent's comments and decides the merge. The agent does not merge autonomously.
Three technical functions that change the way code review is managed.
Engineering manager
Reclaims the senior team's time from standard PR review. The team's capacity concentrates on reviews requiring architectural judgement.
10 active controls
policy.evaluate 14:02:11 ALLOW
pii-detector 14:01:58 BLOCK
tool.invoke 14:01:42 WARN
memory.write 14:01:09 BLOCK
Senior developer
Receives pre-reviewed PRs on standard patterns. Focuses on high-level review (architecture, design choices, consistency with the existing codebase).
Proposal no. 2024-081 In review
Missing disclosure
MiFID II art. · regulated financial instrument
Alt. 1 …in compliance with MiFID II and applicable supervisory provisions.
Alt. 2 …with full disclosure attached to the offer document.
Audit trace recorded · 14:31
Junior developer
Gets real-time feedback on their PRs. The learning curve on team standards accelerates — feedback arrives on concrete code, not in a workshop held weeks later.
$ git clone github.com/polyant-ai/polyant
$ cd polyant
$ docker compose up -d
polyant agent runtime · active
AGPLv3 · code within the customer's perimeter
A PR on Tuesday morning, from trigger to senior decision.
GitHub webhook: a PR has been opened.
For a B2B SaaS development team of 15 engineers, the agent is integrated with the GitHub repository via webhook. A PR is opened by a junior developer on Tuesday morning. The agent reads the diff. It finds three observations: the new authentication function uses a library with a known CVE (high severity) and suggests upgrading to the patch version; a variable name does not follow the team convention and proposes the correction; the new function has no unit tests and suggests adding them with an example pattern.
Three comments, three fixes, a new green review.
The agent posts the comments directly on the GitHub PR thread. The junior developer updates the library, fixes the naming, writes the unit tests, and pushes a new commit. The agent re-runs the review: three observations resolved, new patterns green.
The senior focuses on architecture and design.
The senior developer reviews the PR that afternoon. The high-level review (architecture, design choices) focuses on the points that require judgement. They approve the merge.
Declarative rules from the engineering team.
Rules are declarative. The engineering team defines in a human-readable format the security standards per language, style conventions, test coverage rules, and review patterns. Rules live in the customer's repository, version-controlled, validated at agent startup.
- Language
- TypeScript (Node.js)
- LLM model
- customer's choice: Anthropic, OpenAI, Mistral, open source models hosted internally, AWS Bedrock for a private model
- Built-in controls used
- pii-detector, credential-detector, prompt-injection, tool-rate-limit
- Native channels
- Slack, Telegram, OpenAI-compatible HTTP (GitHub webhook)
- GitHub integration
- native via ghPR and ghIssue runtime tools
- GitLab, Bitbucket, proprietary systems
- dedicated adapter delivered during the project
- Memory
- persistent per instance, pgvector + PostgreSQL FTS on patterns in the customer's repository
- Registry
- immutable, queryable with a standard SQL client
Frequently asked questions about the agent.
No. The agent leaves structured comments on the PR and waits for the senior developer or engineering manager to merge. The merge decision always stays with the human team, following the project's own procedures.
A developer can mark an agent comment as false positive with a note. The agent learns from the repository's patterns to reduce future false positives on the same pattern. Declarative rules can be calibrated by the team without involving the vendor.
GitHub is integrated natively via the ghPR and ghIssue runtime tools. For GitLab, Bitbucket, and proprietary systems, the integration is delivered during the project by the Exelab team.
The typical pattern for Code Review Pre-Merge is 4-8 weeks. Discovery one week, review rule configuration 2-3 weeks, integration with the customer's repository 1-2 weeks, hand-off to the engineering team one or two weeks.
From a 30-minute conversation to the squad in production.
A 30-45 minute conversation to understand how Code Review Pre-Merge would be configured for the customer's case. Repository, languages, team security standards.