Atlas empowers Quarkus developers in 2026 to review pull requests comprehensively by fetching the branch, analyzing the diff with semantic and keyword retrieval, and then running JUnit 5 (@QuarkusTest) tests via Maven to validate changes. It ensures code quality by checking for broken references with lsp and applying Spotless formatting before committing, catching bugs a simple line-by-line read would miss.
How Atlas Fetches and Analyzes Quarkus Pull Request Diffs
Atlas begins reviewing a Quarkus pull request by fetching the specific branch and producing a unified diff using its bash tool, ensuring you see all 100% of the changes. It then uses its read tool to pull the full changed files, not just hunks, providing crucial surrounding context often missed in traditional diff views.
Atlas integrates directly with your Git repository to streamline the initial steps of a pull request review in Quarkus. When you initiate a review, Atlas first leverages its bash tool to fetch the target branch and generate a comprehensive diff. This ensures that every modification, from new CDI beans to updated JAX-RS resources, is captured. Unlike standard diff tools that might only show isolated hunks, Atlas employs its read tool to retrieve the complete content of all changed files. This full-file context is critical for Quarkus development, where build-time augmentation and native-image constraints mean that a small change in one area can have cascading effects on seemingly unrelated code. By seeing the entire file, developers can better understand the architectural implications of a change, such as how a new annotation might interact with existing application.properties configurations or other framework-specific idioms. Atlas's VCS layer exposes status, diff, diffRaw, and commits operations, providing a robust foundation for understanding the codebase's current state.
Validating Quarkus Code Changes with LSP and Grep
To catch subtle bugs in Quarkus pull requests, Atlas employs its lsp tool to findReferences for every changed function signature, ensuring no callers are broken, even if they are 0 lines away from the diff. It also uses grep to identify outdated constant names or stale copies that the diff might not explicitly highlight.
After analyzing the raw diff, Atlas moves to a deeper semantic validation, crucial for the intricate nature of Quarkus applications. It utilizes its lsp tool to perform findReferences operations on any modified function signatures. This is particularly vital in Quarkus, where CDI beans and JAX-RS resources often have implicit dependencies that a simple line-by-line diff would never reveal. For instance, if a method signature used by a RestAssured test in a @QuarkusTest class is altered, Atlas's lsp tool will identify all calling sites, even those outside the immediate diff, preventing runtime errors that could otherwise slip through. Furthermore, Atlas employs its grep tool to search for specific patterns that should have been updated but were overlooked. This includes old constant names, stale copies of code, or feature flags that might need adjustment across multiple files, including application.properties. This proactive search helps maintain consistency and prevents hard-to-diagnose issues related to build-time augmentation or native-image compilation, which are central to Quarkus's performance benefits.
Running Quarkus Tests and Applying Spotless Formatting
Atlas ensures the integrity of Quarkus pull requests by running JUnit 5 (@QuarkusTest) cases using the Maven package manager, executing ./mvnw test behind a permission prompt. After successful testing, it applies Spotless formatting to maintain code style consistency, preventing 100% of style-related merge conflicts.
A critical step in any Quarkus pull request review is thorough testing. Atlas automates this by using its bash tool to execute the project's test suite. Specifically, it runs JUnit 5 (@QuarkusTest) cases, which are standard for Quarkus applications, by invoking the Maven command ./mvnw test. This command is executed only after a permission prompt, ensuring the developer retains control. Atlas then collects the test results and reports any findings as a todowrite list, ordered by severity, allowing for immediate action on failures. This process validates that the changes haven't introduced regressions or broken existing functionality, especially important for CDI beans and JAX-RS resources that rely on Quarkus's build-time processing. Finally, before any changes are committed, Atlas ensures code style consistency by applying Spotless formatting. This step, also permission-gated, automatically corrects any formatting discrepancies, aligning the code with the project's standards defined in the pom.xml and preventing trivial style-related issues from cluttering the review process. Atlas can even add new @QuarkusTest cases with RestAssured if needed, further enhancing test coverage.
Atlas's Safety and Control Mechanisms for Quarkus Reviews
Atlas prioritizes safety and developer control during Quarkus pull request reviews, employing a multi-stage approval process. Every Atlas tool call is permission-gated against allow, ask, and deny rules, ensuring no action is taken without explicit consent. It drafts a plan in a read-only plan agent before switching to a build agent, providing 2 distinct phases of operation.
Atlas is designed with robust safety and control mechanisms, giving Quarkus developers full oversight during the review process. Before any bash command, lsp query, or grep operation is executed, Atlas checks against predefined permission rules (allow, ask, deny). This means that running ./mvnw test or applying Spotless formatting always requires explicit approval, preventing unintended modifications. The review workflow itself is structured for transparency: Atlas first drafts a comprehensive plan in a read-only plan agent, detailing its intended actions, such as fetching the branch, reading files, or running tests. Only after this plan is reviewed and approved does Atlas switch to a build agent to execute the steps. Furthermore, for every file edit, Atlas computes a unified diff and surfaces it for approval before writing, allowing developers to inspect and roll back changes if necessary. Atlas also snapshots file changes as Git patches, providing an additional layer of safety for rolling back edits. This meticulous approach ensures that while Atlas automates complex review tasks, the developer remains in complete control of their Quarkus codebase.
Step by step
- 01Fetch the pull request branch and generate the diff using Atlas's bash tool, ensuring all changes to CDI beans and JAX-RS resources are visible.
- 02Read the full content of all changed files with Atlas's read tool, gaining context beyond the diff hunks, especially for application.properties or pom.xml modifications.
- 03For every changed function signature, use Atlas's lsp tool to findReferences and verify that no callers are broken, crucial for Quarkus's build-time augmentation.
- 04Employ Atlas's grep tool to search for old constant names, stale copies, or feature flags that should have been updated but were missed across the Quarkus project.
- 05Run the JUnit 5 (@QuarkusTest) test suite using Maven via Atlas's bash tool with the command ./mvnw test, approving the permission prompt.
- 06Review the todowrite list of findings reported by Atlas, addressing any test failures or identified issues.
- 07Let Atlas apply Spotless formatting to all modified files, ensuring code style consistency before committing, as defined in your pom.xml.
- 08Approve Atlas's proposed commit, which includes the reviewed changes and Spotless formatting, leveraging its unified diff for final verification.
Frequently asked questions
- How does Atlas ensure Quarkus code quality beyond simple diffs?
- Atlas goes beyond simple diffs by using its lsp tool to findReferences for changed signatures, ensuring no callers are broken. It also employs grep to find missed updates like old constant names or stale copies, which are critical for maintaining consistency in Quarkus projects with build-time augmentation.
- Can Atlas run my Quarkus tests automatically during a PR review?
- Yes, Atlas can automatically run your Quarkus tests. It uses its bash tool to execute JUnit 5 (@QuarkusTest) cases via the Maven command ./mvnw test. This action is permission-gated, requiring your approval before execution, and results are reported as a todowrite list.
- How does Atlas handle Quarkus-specific formatting with Spotless?
- Atlas integrates with your Quarkus project's Spotless configuration. After reviewing changes and running tests, Atlas can apply Spotless formatting to all modified files, ensuring adherence to your project's code style defined in pom.xml. This step is also permission-gated for your control.
- What safety features does Atlas offer for modifying Quarkus code?
- Atlas offers multiple safety features. Every tool call is permission-gated, requiring explicit approval. It drafts a read-only plan before execution, computes a unified diff for every file edit for approval, and snapshots changes as Git patches, allowing for easy rollback of Quarkus code modifications.
- How does Atlas provide context for Quarkus file changes?
- Atlas provides extensive context by using its read tool to pull the full content of changed files, not just diff hunks. This allows Quarkus developers to see surrounding code, application.properties configurations, or pom.xml dependencies that might be relevant but outside the immediate diff.
- Can Atlas help with Quarkus native-image compatibility during reviews?
- While Atlas doesn't directly compile native images, it helps ensure compatibility by allowing you to ask it to replace runtime reflection with build-time-friendly patterns. Its lsp and grep tools also help catch issues that could impact native-image constraints, such as broken references or unhandled feature flags.
- Does Atlas support Quarkus projects using Maven?
- Yes, Atlas fully supports Quarkus projects that use Maven as their package manager. It expects a pom.xml file and can execute Maven commands like ./mvnw test through its bash tool, integrating direct into your existing Quarkus development workflow.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Review a Pull Request with Atlas (2026 Workflow)
How to review a pull request with Atlas in 2026: bash produces the raw patch, read pulls whole files, the lsp tool's findReferences checks callers the diff never shows.
Atlas for Quarkus in 2026
Atlas is a terminal-native AI coding agent for Quarkus in 2026. It reads CDI beans and JAX-RS resources, then runs ./mvnw test behind a permission prompt.
Refactor a legacy module in Quarkus with Atlas in 2026
Streamline Quarkus module refactoring in 2026 with Atlas. Safely restructure old code, maintain behavior, and prevent breaking callers using Maven, JUnit 5, and Spotless.
Extract a Shared Helper from Duplicated Quarkus Code with Atlas in 2026
Streamline your Quarkus applications in 2026 by extracting duplicated logic into shared, tested helpers using Atlas. Find semantic duplicates, refactor with confidence, and ensure code quality with Maven and JUnit 5.
Locate where a behavior is implemented in Quarkus with Atlas in 2026
Pinpoint Quarkus behavior implementation with Atlas in 2026. Use semantic search, grep, and LSP to find exact files and symbols in your Maven project, ensuring build-time compatibility and code quality.
Write Unit Tests for Untested Quarkus Code with Atlas in 2026
In 2026, use Atlas to write robust unit tests for untested Quarkus modules. Atlas understands your existing JUnit 5 (@QuarkusTest) and Maven conventions, ensuring new tests integrate direct.
Upgrade a Quarkus Dependency and Fix Breakage with Atlas in 2026
In 2026, Atlas helps Quarkus developers upgrade major dependencies, fixing compile and test failures. It drives Maven, reads compiler output, and repairs code with LSP, ensuring JUnit 5 and Spotless compliance.
Self-review your working diff before committing in Quarkus with Atlas in 2026
Catch your own mistakes in uncommitted Quarkus diffs using Atlas. Integrate with Maven, JUnit 5 (@QuarkusTest), and Spotless for a robust self-review workflow.