Building Custom Linting Rules with LLMs

Traditional code review is essential for quality, but it’s time-consuming and can be inconsistent. Static analysis tools like linters are fast but limited to syntax and style. What if you could automate the deep, contextual feedback of a senior engineer? This is where AI-powered code review comes in, using Large Language Models (LLMs) to enforce complex rules that go far beyond what traditional tools can do.

This guide explains how to build your own custom, AI-powered code review bot. You’ll learn how it works, why it’s a game-changer for engineering teams, and how to create rules that check for everything from architectural patterns to security vulnerabilities.

AI-powered code review uses LLMs to analyze code changes and provide feedback based on a custom set of rules defined in natural language. Unlike traditional linters that rely on predefined, rigid checks, AI reviewers can understand the intent and context of code, allowing them to enforce nuanced, team-specific standards.

Think of it as the difference between a spell checker and a professional editor. A linter is the spell checker, catching obvious errors. An AI reviewer is the editor, suggesting improvements to structure, clarity, and adherence to a style guide—only the guide is your team’s unique architecture and best practices.

Automating code review with an LLM typically involves integrating it with your CI/CD pipeline, such as GitHub Actions or GitLab CI. When a developer opens a pull request, a job is triggered that sends the code changes and your custom rules to an LLM for analysis.

Here’s a step-by-step breakdown of the process:

1. Trigger Event: A developer pushes commits to a pull request.
2. CI/CD Pipeline Starts: A workflow in GitHub Actions or GitLab CI is initiated.
3. Gather Context: The workflow script checks out the code and uses Git commands to isolate the changes (the diff). It may also pull in related files for broader context.
4. Define Rules: You create a set of “rules” in a simple text file. These are natural language instructions for the LLM, such as “Ensure all new public API endpoints include rate limiting” or “Verify that database transactions have proper error handling and rollback mechanisms.”
5. Construct the Prompt: The script combines the code diff, relevant context, and your custom rules into a single, detailed prompt for the LLM.
6. Call the LLM API: The prompt is sent to an LLM API (like OpenAI’s, Anthropic’s, or one you host yourself).
7. Post Feedback: The LLM’s response is parsed, formatted, and posted back to the pull request as a comment, flagging potential issues just like a human reviewer would.

This entire process provides targeted, actionable feedback directly in the development workflow, helping developers learn and adhere to standards in real-time.

The true power of this approach is the ability to enforce rules that are impossible for traditional static analysis to handle. These rules often involve business logic, architectural patterns, and team conventions.

• Enforce Architectural Consistency: Ensure microservices adhere to domain boundaries. For example: “The auth-service should never make a direct database call; it must always go through the user-management-service API.”
• Catch Security Vulnerabilities: Identify potential security flaws based on logic patterns, not just known code snippets. For example: “Scan for indirect object reference vulnerabilities where a user-controlled ID is used to fetch a resource without an ownership check.”
• Improve Code Quality and Maintainability: Check for team-specific best practices that improve readability. For example: “If a function is longer than 50 lines, suggest refactoring it into smaller, more focused functions.”
• Ensure Proper Documentation: Mandate that changes to critical components are properly documented. For example: “Any modification to the Billing module requires an update to the corresponding section in CHANGELOG.md.”

These examples highlight how AI can move beyond syntax to help teams build better, more secure, and more maintainable software at scale.

While powerful, building an AI code reviewer comes with its own set of challenges and things to keep in mind.

• It’s a reviewer, not a dictator: LLMs can make mistakes or “hallucinate.” Their feedback should be treated as suggestions for the developer and human reviewer to consider, not as a hard gate that blocks merging. Start by having the AI post comments, not fail the build.
• Cost can be a factor: Every pull request triggers API calls, and costs can add up quickly, especially with large models and extensive code changes. It’s important to monitor usage and optimize your process to control expenses.
• Latency in feedback: An LLM review will be slower than a traditional linter. A comprehensive review could take a few minutes. Teams must decide if the value of the feedback is worth the slight delay in the development loop.
• Prompt engineering is key: The quality of the AI’s feedback is directly proportional to the quality of your prompt. You will need to experiment and refine your prompts, rules, and the context you provide to get consistently useful results.

Ready to build your own AI reviewer? Here are some tips to help you get started successfully.

• Start small: Begin with one or two simple, high-value rules. Get the pipeline working and see how your team responds to the feedback before adding more complexity.
• Iterate on your rules: Your rules are not set in stone. As your codebase and team practices evolve, so should your AI’s rulebook. Treat your rules as a living document.
• Combine with traditional tools: AI review should augment, not replace, your existing tools. Continue using linters and static analysis for fast feedback on syntax and style, and use the LLM for deeper, more contextual analysis.
• Secure your API keys: Your LLM API key is a secret. Store it securely in your CI/CD system’s encrypted secrets management tool (e.g., GitHub Secrets, GitLab CI/CD variables) and never hard-code it.
• Be specific in your instructions: Vague rules lead to vague feedback. Instead of “Check for good code,” write “Ensure every function has a JSDoc-style comment block explaining its purpose, parameters, and return value.”

While Kinde doesn’t provide a built-in AI code review feature, its Workflows engine can be a key component in your automation strategy.

Kinde Workflows allows you to orchestrate complex processes triggered by events. You could, for example, use a webhook from your CI/CD pipeline to trigger a Kinde Workflow. This workflow could then call an external service—like your new AI code reviewer—and, based on the results, take actions using the Kinde Management API. For instance, you could tag a user, grant a permission, or even manage a feature flag to enable a new capability once the code is approved and merged.

This allows you to connect your code-level quality gates with your user-level business logic, creating powerful, end-to-end automations.

• Connect your workflows repo and branch
• Manage code and deployments