Gito

Gito abstracts LLM provider differences through the ai-microcore library, enabling seamless switching between OpenAI, Anthropic, Google, local models, and 10+ other providers without code changes. The abstraction layer normalizes API schemas, authentication, and response formats, allowing users to configure their preferred LLM via environment variables and swap providers by changing a single config value. This stateless design ensures code never persists in Gito's systems—it flows directly from the user's environment to their chosen LLM endpoint.

Gito implements concurrent processing of code review tasks by batching file diffs and issuing parallel LLM API calls, reducing total review time from linear (sequential file analysis) to near-constant (bounded by slowest API call). The pipeline system orchestrates these parallel requests while managing rate limits and aggregating results into a unified report. This architecture enables reviewing large changesets (50+ files) in seconds rather than minutes by exploiting LLM API concurrency.

Gito implements a pipeline architecture that supports pre-processing (e.g., normalize diffs, extract context) and post-processing (e.g., filter findings, enrich with metadata) steps. Pipelines are composable, allowing teams to add custom transformations without modifying core review logic. This enables use cases like diff summarization before LLM analysis, finding deduplication after analysis, or custom severity reassignment based on project rules.

Gito supports include/exclude patterns (glob-style) to filter which files are reviewed and which auxiliary files (e.g., package.json, requirements.txt) are included as context for the LLM. Patterns are defined in project config and enable teams to skip generated code, test files, or vendor directories while including relevant context files. This reduces LLM API costs by excluding irrelevant files and improves review accuracy by providing relevant context.

Gito is designed as a stateless, client-side tool with zero code retention: code is never stored, logged, or retained by Gito itself. Code flows directly from the user's environment to their chosen LLM provider, with no intermediate storage or Gito backend servers. This architecture ensures privacy compliance (GDPR, HIPAA) and vendor independence—users maintain full control over where their code is sent and how it's processed. The stateless design also simplifies deployment (no database, no backend infrastructure) and enables offline-first workflows.

Gito ships with pre-built GitHub Actions and GitLab CI workflow templates that integrate Gito into CI/CD pipelines with minimal configuration. Templates handle authentication, environment setup, review execution, and result posting to PRs/MRs. Users can copy templates into their repos and customize them with project-specific settings (LLM provider, review criteria). This enables teams to add AI code review to CI/CD in minutes without writing custom pipeline code.

Gito analyzes code changes across all major programming languages (Python, JavaScript, Java, Go, Rust, etc.) using language-agnostic diff analysis combined with LLM reasoning. The tool does not require language-specific parsers or AST analysis; instead, it sends diffs to the LLM, which applies language knowledge to identify issues. This approach enables support for new languages without code changes and handles polyglot codebases (mixed languages) naturally. The LLM can reason about language-specific patterns (e.g., Python decorators, JavaScript async/await) without explicit language detection.

Gito supports comparing code changes against multiple git references: main branch, specific commits, arbitrary branches, or tags. The tool resolves git refs at runtime, extracts diffs using git plumbing commands, and normalizes them into a unified diff format for LLM analysis. This flexibility enables reviewing feature branches, cherry-picks, rebases, and cross-branch comparisons without manual diff extraction or file staging.

Gito generates code review reports in three output formats: JSON (for programmatic consumption and CI/CD integration), Markdown (for human-readable documentation and PR comments), and terminal-formatted text (for CLI display with color coding and severity indicators). The Report class abstracts format generation, allowing the same review findings to be serialized into any format without duplicating analysis logic. This enables seamless integration with downstream tools (issue trackers, dashboards) and human workflows.

Gito categorizes code review findings by severity levels (critical, warning, info, etc.) and enables filtering/prioritization based on severity thresholds. The classification is driven by LLM analysis guided by custom prompts, allowing teams to define what constitutes critical vs. informational issues for their codebase. Severity filtering enables CI/CD gates (e.g., fail on critical, warn on medium) and helps teams focus on high-impact issues first.

Gito integrates with GitHub's REST API to post code review findings as PR comments and respond to interactive bot commands (e.g., '@gito fix issue #123', '@gito ask about performance'). The GitHub integration layer handles authentication via GitHub App or personal tokens, fetches PR metadata, posts comments with proper formatting, and polls for user commands in PR discussions. This enables asynchronous, conversational code review workflows without leaving GitHub.

Gito provides beta-level GitLab integration that posts code review findings as merge request comments and integrates with GitLab CI pipelines. The GitLab integration layer handles authentication via personal tokens, fetches MR metadata, posts comments with GitLab-specific formatting, and supports CI/CD variable injection for pipeline-based reviews. This enables GitLab-native teams to run AI code reviews as part of their CI/CD workflows without external tools.

Gito integrates with Jira and Linear to fetch issue context (ticket descriptions, acceptance criteria, linked issues) and enrich code reviews with this context. The integration layer queries issue trackers via REST APIs, extracts relevant context, and injects it into LLM prompts to improve review accuracy. This enables the LLM to understand business requirements and acceptance criteria when reviewing code, reducing false positives and improving relevance of findings.

Gito implements a two-layer configuration model: environment-level config (LLM provider, API keys, secrets) stored in environment variables or .env files, and project-level config (review behavior, custom prompts, file filters) stored in gito.yaml or similar config files. This separation enables teams to share project configs (review criteria, file patterns) via version control while keeping secrets out of repos. The configuration system supports environment variable interpolation, allowing dynamic config based on CI/CD context.

Gito enables teams to define custom LLM prompts that tailor review criteria to their project's standards. Prompts are stored in project config and can reference variables (file patterns, severity levels, custom rules). The LLM uses these prompts to guide analysis, allowing teams to enforce project-specific best practices (e.g., 'flag all uses of deprecated API X', 'require docstrings for public functions'). This enables fine-grained control over review behavior without modifying Gito's core logic.