DEV Community: JavaCoder7

Testing an AI Code Reviewer With an Intentionally Failing JUnit Test

JavaCoder7 — Thu, 29 Oct 2026 17:07:39 +0000

An AI code reviewer should do more than identify suspicious code. It should also report validation results accurately.

For this test, I added the following JUnit assertion to a GitHub pull request:

@test
void shouldDetectIncorrectExpectedValue() {
assertEquals(5, 2 + 2);
}

The test is intentionally incorrect.

What CodeGuard AI reported:

Test execution: FAILED

Tests executed: 1

Tests failed: 1

Expected: 5

Actual: 4

Suggested fix: change the expected value to 4

It also identified the failing assertion in the changed file.

One finding isn't enough to establish overall reliability, so I'm testing CodeGuard against 100 scenarios covering failure detection, test-result evidence, false positives, merge policies, and more.

The next question is just as important: should a failing test automatically block a merge?

I'm building CodeGuard AI with Java 21 and Spring Boot. The source code is available on Gumroad.

What behavior would you expect from an AI reviewer when a test suite fails?

My AI Code Reviewer Found the Failure. Is Its Fix Actually Safe?

JavaCoder7 — Tue, 27 Oct 2026 09:39:12 +0000

I’m testing CodeGuard AI, my AI-powered GitHub PR reviewer, and today I caught an interesting failure.

Here’s the test scenario.

1. The original failing test

assertEquals(2, 1, "Discount calculation is incorrect");

The test expects 2, but the actual result is 1. So it fails, as intended.

2. CodeGuard detected the failure

Good news: CodeGuard correctly identified that the test was failing.

But then came the problem.

3. The suggested fix

The AI suggested changing the assertion to:

assertEquals(1, 1, "Discount calculation is incorrect");

Now the test passes.

But did we fix the underlying problem?

No. We changed the expectation to match the actual result.

The test no longer checks whether the code produces the intended result. It simply confirms that 1 equals 1.

What this tells me

Detecting a failing test is not enough. An AI reviewer must also ensure that its suggested fix preserves the test’s original intent.

I’ve logged this as a bug and will address it after completing the current testing batches. For now, I’m continuing to test the other features and record the failures before fixing them together.

That’s the reality of building in public: sometimes the most useful update is what your own product gets wrong.

What would you want CodeGuard to validate before allowing an AI-suggested test fix?

I'm building CodeGuard AI for developers who want more trustworthy AI-assisted code reviews.

If you'd like to explore the source code, you can find it here: CodeGuard AI on Gumroad

I'm continuing to test it, document the failures, and improve it based on what I learn.

BuildInPublic #Java #SpringBoot #AI #CodeReview

How Do You Find Your First Buyers for a Source-Code Product?

JavaCoder7 — Mon, 26 Oct 2026 11:00:23 +0000

I’ve built two self-hosted developer products and listed them on Gumroad, but I’m still figuring out how to reach people who will actually pay for them.

One is CodeGuard AI, an AI-powered GitHub PR reviewer. The other is ResumeIQ AI, an AI resume analyzer.

Both are sold as source code, not hosted SaaS products.

I’m curious about the business side of building software:

Where do people find their first paying customers?
Which channels have actually worked for selling source code?
What do buyers expect beyond the code itself?
Is it better to keep selling the source code or eventually turn the product into SaaS?

For developers who have sold source code, boilerplates, templates, or developer tools: what helped you get your first few sales?

I’d especially appreciate real experiences and lessons from things that didn’t work. I want to learn how to build a sustainable business around software, not just keep shipping projects.

AI Can Find a Bug. But Can You Trust Its Fix?

JavaCoder7 — Sat, 24 Oct 2026 15:42:01 +0000

AI coding tools are getting better every day. They can write functions, generate tests, review pull requests, and even suggest fixes in seconds.

But there’s a problem I keep thinking about:

What if the AI identifies a real bug but gives you a fix that introduces another one?

Imagine this scenario:

An AI reviewer flags a security vulnerability.
It suggests a patch that looks convincing.
The developer applies it.
The code appears fine, but the fix is incomplete—or the tests have been changed to accommodate the bug.

Now what?

A green test suite doesn't automatically mean the bug is fixed. A confident explanation doesn't prove the patch is correct. And a suggested fix that looks good in a code diff still needs independent verification.

The problem I'm exploring

While building CodeGuard AI, I've been exploring how to evaluate AI code reviews beyond simply counting the number of issues they detect.

Some questions I'm trying to answer:

Can an AI reviewer distinguish real bugs from false positives?
Can it identify incorrect test expectations?
Does its suggested patch actually address the original problem?
Can we verify a fix without letting the patch generator simply change the goalposts?

I'm particularly interested in the gap between finding a problem and proving that the proposed solution works.

That's where I think developer tools have a lot of room to improve.

I'd love to hear from other developers

If you use AI coding assistants or AI-powered code reviewers, I'm curious about your experience:

Have you ever accepted an AI-generated fix that later caused another bug?
Do you trust AI-generated patches, or do you always verify them independently?
What would convince you that an AI code review is reliable enough to use in a real project?

I'm building in this space, so honest criticism and real-world examples would be especially valuable.

What's the biggest thing stopping you from fully trusting AI-generated code?

discuss #ai #programming #webdev

Do developers actually need an AI code reviewer? What features would make it worth paying for?

JavaCoder7 — Wed, 21 Oct 2026 10:00:23 +0000

Do developers actually need an AI code reviewer? What features would make it worth paying for?

I'm exploring whether there's genuine demand for an AI code reviewer that goes beyond simply generating comments on GitHub pull requests.

I'm building CodeGuard AI, a Java 17 and Spring Boot-based AI code reviewer for GitHub PRs. Before spending more time developing it, I want honest feedback from developers, agency owners, and startup founders about whether this solves a problem worth paying for.

What CodeGuard AI already has

AI-powered PR reviews to identify potential bugs and code-quality issues.
Rule-based security and code-quality checks for common problems.
Test-quality analysis to identify issues such as trivial assertions, duplicate tests, and incorrect expectations.
Suggested fixes and patch previews to help developers understand potential corrections before applying them.
Repository-impact analysis to help identify potentially affected code.
Review history to keep track of previous reviews.

I'm currently auditing and improving the system, particularly around false positives, consistency between reviews, the reliability of suggested fixes, and validation.

I'd like your honest feedback on a few things

1. Is there genuine demand for a tool like this?

Would you use a dedicated AI code reviewer in your current workflow, or do existing tools and AI coding assistants already meet your needs?

2. What's missing?

Looking at the features above, what would make this genuinely useful in your day-to-day work? What would you remove, add, or improve? For example, would you prioritize fewer false positives, better repository context, reliable automated fixes, security analysis, or something else?

3. What would you realistically pay?

If a tool like this consistently saved time and caught meaningful issues, what pricing would make sense to you? Would you prefer per-developer pricing, a small-team subscription, usage-based pricing, or a free tier with paid upgrades?

4. What would make you trust it?

Before relying on an AI reviewer, what evidence would you need? For example, verified fixes, reproducible results, fewer irrelevant findings, or successful results on your own repositories?

I'm not assuming that everyone needs another code review tool. If your current workflow works well, I'd genuinely like to understand why.

If you're a developer, freelancer, agency owner, or startup founder, I'd appreciate your perspective. Your feedback will help me decide whether to continue investing in this and which features deserve priority.

I'm looking for honest feedback, not validation for the sake of it.

Before Optimizing Your Resume, Should You Trust the Job Posting?

JavaCoder7 — Mon, 19 Oct 2026 08:02:36 +0000

When applying for jobs, we usually focus on one question:

How can I make my resume a better match for this job?

We optimize keywords, improve our summaries, highlight relevant skills, and prepare for interviews.

But there's another question we don't always ask:

Is this job posting worth our time and personal information in the first place?

That question inspired me to build a new feature in ResumeIQ AI called Job Posting Health.

The problem with focusing only on resumes

A well-written job description can still contain warning signs.

For example:

A recruiter asks candidates to pay a registration or verification fee.
A posting pressures applicants to act immediately without a reasonable explanation.
Candidates are told they must purchase equipment from a specified seller.
The role description and hiring requirements contain suspicious inconsistencies.

Not every unusual requirement means a job is fraudulent. However, these signals deserve closer investigation before someone shares sensitive information or spends hours preparing an application.

Resume optimization tools generally focus on improving the candidate's side of the process. I wanted to explore the other side: evaluating the opportunity itself.

Building Job Posting Health

I implemented Job Posting Health in ResumeIQ AI to analyze a pasted job description and highlight potential warning signs.

The feature produces a health assessment and identifies signals that may deserve further investigation.

During testing, I used a sample posting containing several suspicious elements, including a registration fee, pressure to act quickly, and a mandatory company-approved laptop purchase.

The feature flagged these warning signs rather than treating the posting as an ordinary job opportunity.

The goal isn't to claim that an algorithm can definitively determine whether every job is legitimate. It's to give job seekers specific reasons to pause, investigate, and make a more informed decision.

Why I think this feature matters

Job seekers already spend considerable effort tailoring applications.

If a posting is suspicious, that effort may be wasted—and sharing personal information can create additional risks.

I believe job-search tools should help people make better decisions before applying, not just help them optimize their resumes after choosing a job.

That's the thinking behind Job Posting Health.

Another feature: Resume Freshness

I also implemented Resume Freshness, which looks at the evidence in a resume for the skills mentioned in a job description and highlights areas where recent evidence may be missing.

For example, listing a technology is different from demonstrating recent experience with it through a project, practical work, or relevant learning.

Together, these features explore two complementary questions:

Job Posting Health: Are there warning signs worth investigating before applying?
Resume Freshness: Does my resume demonstrate recent, relevant evidence of the skills this role requires?

What's next?

I'm continuing to develop ResumeIQ AI and explore how it can provide more useful information to job seekers.

One thing I've learned while building it is that a feature doesn't need to be complicated to address a meaningful problem. Sometimes, asking a different question is what makes it useful.

I'd be interested to hear from other developers and job seekers:

When evaluating a job opportunity, what warning signs do you check before applying? And what would make you trust a tool that analyzes job postings?

ResumeIQ AI is available as a source-code product for developers interested in exploring or customizing the application.

ResumeIQ AI — AI Resume Analyzer & ATS SaaS Starter | Spring Boot Source Code

BUILD YOUR OWN AI RESUME ANALYZER SAAS Launch your own AI-powered resume analysis platform without building everything from scratch. ResumeIQ AI is a...

javacoder716.gumroad.com

A Green Test Suite Can Still Hide a Broken PR: 5 Questions to Ask Before Merging

JavaCoder7 — Sat, 17 Oct 2026 16:27:50 +0000

AI coding assistants can write implementation code and tests in minutes. The problem is that both can look correct while the behavior that matters remains untested.

A passing test suite is useful evidence, but it isn't proof that a change is correct.

I've been thinking about this problem while building a Java-focused, AI-powered pull request reviewer. These are five questions I believe developers should ask before approving a PR, especially when AI helped write the code or its tests.

1. What behavior is this test actually verifying?

Start with the expected behavior, not the number of assertions.

Imagine a service that should reject a payment when the account has insufficient funds. A test might call the service and verify that it returns a response.

But what if the test never checks whether the payment was rejected?

The test can execute successfully without verifying the important business rule.

Ask yourself:

What behavior should this test protect?
What result would prove that behavior?
Would the test fail if the behavior were broken?

If you cannot answer these questions, the test may provide less confidence than its green status suggests.

2. Could this test pass without checking anything meaningful?

Consider this JUnit example:

java
@test
void shouldRejectInvalidPayment() {
paymentService.processPayment(invalidPayment);

assertTrue(true);

}

The test passes as long as execution reaches the assertion. It doesn't establish that the payment was rejected.

A more meaningful test would verify the expected outcome, using the appropriate assertion for the application's behavior.

For example, if the contract requires an exception:

java
@test
void shouldRejectInvalidPayment() {
assertThrows(
InvalidPaymentException.class,
() -> paymentService.processPayment(invalidPayment)
);
}

This is only an illustration. The correct assertion depends on the actual application contract.

The important principle is simple: an assertion should verify the behavior the test claims to protect.

3. Are mocks hiding the behavior we need to verify?

Mocks are valuable when testing dependencies, failure conditions, and isolated units of code. But excessive mocking can make a test appear meaningful while avoiding the behavior that matters.

Suppose a test claims to verify that an order is saved correctly, but it mocks the repository and only verifies that save() was called.

That may establish that a method was invoked. It doesn't necessarily establish that the order was persisted correctly or that the resulting state is correct.

Before approving a heavily mocked test, ask:

Is the test checking an outcome or just an interaction?
Is the mocked dependency the behavior being tested?
Would an incorrect implementation still satisfy the assertions?
Should an integration test verify the real interaction between components?

Don't remove mocks indiscriminately. Choose the test boundary that matches the behavior you're trying to protect.

4. Does the test cover the change described in the PR?

A PR can change behavior without changing the test that originally covered it.

For example, a developer might change the conditions under which a user can access a resource. The existing test may still verify the successful access path while failing to check the newly introduced restriction.

Compare the change with the tests:

Which behavior changed?
Which existing tests exercise that behavior?
What new failure scenario could the change introduce?
Are the expected outcomes explicit?

This is also where repository context matters. The affected behavior might involve callers or related files that aren't part of the diff.

A reviewer should consider those relationships rather than treating each changed line as an isolated unit.

5. Would the test catch a deliberately broken implementation?

This is a useful thought experiment.

Imagine the implementation contains a defect that violates the requirement. Would the test fail?

If the answer is no, the test may not protect that requirement.

Mutation testing takes this idea further by making deliberate changes to the implementation and checking whether the tests detect them. It can provide stronger evidence than simply counting assertions, although it has its own limitations and costs.

You don't need a full mutation-testing setup to start asking the question during code review. But actually running tests against controlled mutations is a separate validation step, not something a normal passing test run proves.

The practical takeaway

Before merging a PR, especially one produced with AI assistance, ask:

Does the test verify the intended behavior?
Could it pass without a meaningful assertion?
Are mocks hiding the behavior that matters?
Do the tests cover the changed behavior and relevant regression scenarios?
Would the tests detect a broken implementation?

These checks won't guarantee that every defect is caught. They can, however, help identify tests that create confidence without providing enough evidence.

AI can help write code and tests faster. The review process still needs to establish what those tests actually prove.

Disclosure: I'm building CodeGuard AI, a self-hosted AI-powered pull request reviewer for GitHub. It reviews PR changes alongside repository context and supports custom team review rules. It does not currently run mutation testing or guarantee detection of every weak test assertion.

Learn more about CodeGuard AI

I Built a Self-Hosted AI Code Reviewer for GitHub PRs with Spring Boot

JavaCoder7 — Wed, 30 Sep 2026 01:29:54 +0000

Why I built this

Code review is one of the most important parts of a software development workflow, but reviewing every Pull Request manually can become repetitive.

I wanted to experiment with a different approach:

What if an AI reviewer could inspect a GitHub Pull Request, identify potential problems, explain them, and post the review back to GitHub?

That led me to build CodeGuard AI.

It is a self-hosted AI code-review application built with Java 17+ and Spring Boot.

The goal wasn't to replace human code review.

Instead, the idea was to create an additional automated layer that can identify potential issues before a human reviewer spends time going through the PR.

What CodeGuard does

The workflow is essentially:

GitHub Pull Request
↓
GitHub API / Webhook
↓
Spring Boot Review Service
↓
Fetch PR information + changes
↓
AI Provider
↓
Bug / Security / Performance / Best Practice Analysis
↓
Quality + Risk + Confidence
↓
GitHub Comments
↓
Review History & Trends

The application supports multiple AI providers:

OpenAI
Google Gemini
Ollama

That makes the AI layer replaceable instead of tying the application to a single provider.

The application dashboard

The main dashboard provides two ways to start a review.

A review can be triggered manually by providing a repository and Pull Request number, or the application can work with the GitHub workflow.

It also exposes the major review categories directly in the interface:

Security Review
Performance
Best Practices
Bug Detection

The manual-review interface was particularly useful during development because it allowed me to test the complete review pipeline without depending on a live webhook every time.

Starting a review

For example, I can provide a repository and PR number and start the review.

The application then moves through the review pipeline.

The UI exposes the progress of the operation instead of making the user wonder whether the review is still running.

The basic stages are:

Reading PR
↓
Finding bugs
↓
Checking security
↓
Generating review

This also highlights an important part of AI integrations that can easily be overlooked:

AI operations are asynchronous from the user's perspective.

A review may involve API calls, fetching repository data, preparing the PR changes, sending the analysis request, processing the response, and finally publishing the result.

What does the AI review actually produce?

After the analysis is complete, CodeGuard generates a structured review rather than returning one large block of AI text.

For one of my test Pull Requests, the result included:

Overall score: 8/10
AI confidence: 90%
Critical issues: 0
Suggestions: 2
Merge recommendation
Categorized findings
Code locations
Suggested fixes

This makes the output much easier to consume than simply displaying an LLM response.

The reviewer can immediately see the overall result and then drill down into individual findings.

Findings are categorized

Each finding is classified so that developers can focus on the type of problem they care about.

For example:

Critical
High
Medium
Low
Security
Performance
Best Practice

In one test, CodeGuard identified a potential configuration issue involving GitHub token overrides.

It also detected a repository-name case-sensitivity issue.

The important part here isn't just detecting an issue.

The system also provides:

Location → Explanation → Suggested fix

That makes the result more actionable for a developer.

Posting the result back to GitHub

One of the parts I wanted to experiment with was closing the loop.

The reviewer shouldn't have to stay inside a separate dashboard forever.

CodeGuard can post the review back to GitHub.

The dashboard therefore shows whether the review has been posted successfully.

This creates a workflow closer to:

Developer opens PR
↓
CodeGuard analyzes it
↓
Findings generated
↓
Review posted to GitHub
↓
Developer fixes issues
↓
Human reviewer continues the normal review
Review history

Another feature I wanted was historical visibility.

Instead of treating every PR review as an isolated event, CodeGuard stores review results and exposes them through the review history.

This allows the application to show:

Previous Pull Requests
Quality scores
Issues found
Repository information
Review status
Review details

Review trends

The history also provides a simple trend view.

The dashboard tracks:

Quality Score vs Issues Found

over previous reviews.

This is useful because a single review score doesn't tell the whole story.

For example, if a project repeatedly receives lower-quality reviews or increasing numbers of findings, that pattern may be more interesting than any individual PR.

Making the AI provider configurable

Another engineering decision was avoiding a hard dependency on one AI provider.

CodeGuard supports:

OpenAI
Gemini
Ollama

The provider can be selected/configured through the application settings.

This also makes the project interesting for developers experimenting with local models.

For example, a developer can use a hosted provider during development and experiment with a local Ollama setup when self-hosting is preferred.

Custom review instructions

The settings also allow custom review instructions.

For example, a team could specify additional standards such as:

Flag public methods without Javadoc.

Flag endpoints that don't validate input.

Flag direct System.out usage instead of logging.

Flag newly thrown generic exceptions.

These instructions are added to the review process alongside the built-in review criteria.

This makes the reviewer more adaptable to a project's own engineering standards rather than relying only on generic AI code-review prompts.

The Spring Boot architecture

The backend is built around Spring Boot.

The main pieces include:

GitHub Integration
↓
PR / Diff Retrieval
↓
Review Service
↓
AI Provider Layer
↓
Structured Review Result
↓
Finding Classification
↓
GitHub Comment / Dashboard
↓
Review History

The project uses:

Java 17+
Spring Boot
Spring Security
GitHub REST API
AI provider integrations
REST APIs
Maven
HTML/CSS/Vanilla JavaScript

The important architectural decision was keeping the AI provider layer replaceable.

That means the application isn't fundamentally tied to one model provider.

What I learned building it

AI output needs structure

Sending code to an LLM is relatively easy.

Building a useful code-review product around that response is considerably more involved.

You need to think about:

What constitutes a finding?
How should severity be represented?
How do you identify the relevant code location?
How do you avoid overwhelming the developer?
How should findings be presented?
How should the result get back into the existing GitHub workflow?

Confidence and severity aren't the same thing

An AI system can be highly confident about a low-severity issue.

So I wanted CodeGuard to keep concepts such as:

severity

and

AI confidence

separate.

That gives developers more information when deciding which findings deserve attention.

Human review still matters

The purpose of CodeGuard isn't:

"AI reviewed the PR, therefore merge it."

The more useful model is:

AI performs an additional automated review layer, while humans remain responsible for the final engineering decision.

That distinction became important as I designed the workflow.

What could be improved next?

There are several directions I'd like to explore:

Better inline GitHub comments
More precise code-location mapping
Improved false-positive handling
Repository-level review policies
Custom severity rules
More granular review configuration
Better webhook lifecycle handling
Additional local-model support
More detailed review analytics

The project is intentionally designed as a self-hosted foundation that developers can customize, rather than a hosted SaaS product.

Final thoughts

Building CodeGuard taught me that an AI code reviewer is not simply:

GitHub API + LLM = code reviewer.

The interesting engineering work happens around the model:

GitHub integration → PR processing → review orchestration → structured findings → severity → confidence → developer feedback → history.

That's where the application becomes an actual workflow rather than just an AI prompt.

Want to explore the implementation?

I built CodeGuard AI as a self-hosted Spring Boot source-code project for developers who want to study, customize, and build on this type of AI code-review workflow.

Get the CodeGuard AI source code on Gumroad: https://javacoder716.gumroad.com/l/codeguard-ai

I Built a Multi-Provider AI Resume Analyzer with Spring Boot — Here's How ATS Matching Works

JavaCoder7 — Tue, 29 Sep 2026 15:36:11 +0000

If you've ever tried building an AI-powered resume analyzer, one of the first things you discover is that:

"Send the resume to an AI model and ask for an ATS score" isn't really enough.

A useful resume-analysis system needs to answer several questions:

How well does the resume match a specific job description?
Which skills are missing?
Which keywords are missing or underrepresented?
How strong is the ATS compatibility?
Does the candidate's experience match the role?
What could be improved?
Can AI help rewrite the resume?
Can the system compare different resume versions?

I wanted to explore these problems from a backend-engineering perspective, so I built ResumeIQ AI, a Java and Spring Boot based AI resume-analysis application.

The interesting part wasn't simply connecting an application to an AI API.

It was building the workflow around it.

The Technology Stack

The backend is built around:

Java 17
Spring Boot 3
Spring Security
Spring Data JPA
MySQL
Thymeleaf
Maven
OpenAI
Gemini
Ollama

One of the design decisions I wanted to explore was multi-provider AI support, rather than coupling the application to a single AI provider.

Starting With the Resume and Job Description

An ATS score without a target job isn't particularly meaningful.

Consider a resume containing:

Java
Spring Boot
MySQL
Docker
REST APIs
Microservices

For one position, that could be a strong match.

For another position requiring:

Java
Spring Boot
Kafka
AWS
Kubernetes
Redis

the same resume could have significant gaps.

So instead of asking:

"Is this a good resume?"

the application asks:

"How well does this resume match this particular job?"

The basic workflow is:

Resume
+
Job Description
↓
Resume Analysis
↓
Matching
↓
ATS Score
↓
Skills + Keywords + Gaps
↓
AI Suggestions
↓
Resume Improvement
Here's what the analysis starts with:

ResumeIQ starts with a job description and resume rather than generating a generic resume score.

The user can provide a resume and the complete job description, and the application analyzes the two together.

Resume → Job Description Matching

The matching process can be thought of as:

Resume
↓
Extract relevant skills / experience / keywords
↓
Job Description
↓
Extract required skills / keywords
↓
Compare
↓
Generate analysis

The result isn't intended to be just one number.

It can contain:

Overall match score
ATS compatibility
Matching skills
Missing skills
Keyword analysis
Experience comparison
Score breakdown
Improvement suggestions
Here's an example from the application:

The analysis provides both an overall match score and a more detailed breakdown of the resume against the job description.

The example shows an 88% match along with an ATS compatibility score of 90%.

The important part is that the score is accompanied by additional information explaining what contributed to it.

Breaking Down the Score

A single score can be difficult to interpret.

For that reason, ResumeIQ breaks the analysis into different categories.

For example:

Technical Skills
Experience
Projects
Education
Achievements

Each category contributes to the overall analysis.

The score is broken into multiple categories rather than presenting only a single ATS number.

This makes it easier to identify where the resume is relatively strong and where it needs improvement.

Finding Missing Skills and Keywords

One of the more useful parts of resume-to-job matching is identifying what is missing.

For example, a job description might require:

Java
Spring Boot
Hibernate
PostgreSQL
Microservices
AWS
CI/CD

while the resume may clearly demonstrate some of those skills but not others.

ResumeIQ separates this information into areas such as:

Matching skills
Missing skills
Keyword frequency
Keyword recommendations
Importance of missing skills

The application identifies missing skills and also analyzes how frequently important keywords appear in the resume.

This is more actionable than simply telling someone:

"Your ATS score is 78."

The more useful question is:

"Why is the score 78, and what can I change?"

Looking Beyond Simple Keyword Matching

Traditional keyword matching has limitations.

Suppose a resume contains:

"Built backend services using Spring Boot."

while a job description says:

"Experience developing RESTful microservices using Spring Boot."

A useful system needs to consider more than whether two strings are identical.

This is where AI can become useful.

The application can use AI to interpret the resume and job-description context and generate recommendations around:

wording
experience descriptions
missing information
resume structure
potential improvements

The goal isn't to let the LLM decide everything.

Instead, the application combines structured analysis with AI-generated reasoning.

Turning Analysis Into Suggestions

After identifying potential weaknesses, the system can turn them into concrete recommendations.

For example, the analysis can suggest improvements around:

AWS experience
resume structure
duplicate skills
ATS formatting
experience descriptions

The AI layer turns the analysis into specific suggestions instead of stopping at a score.

This creates a workflow closer to:

Analysis
↓
Identify weakness
↓
Explain weakness
↓
Suggest improvement

rather than simply:

Resume → Score → Done

Before vs After Resume Improvements

One of the more practical features is showing how specific resume statements could be improved.

For example:

Before

Developed and Maintained backend microservices and relational databases in production; reduced API response time by 30% through query optimization and service tuning.

After

Developed and maintained production backend microservices and relational databases using Spring Boot, reducing API response times by 30% via query optimization and database tuning.

The objective isn't to invent experience.

It's to make existing experience clearer and more aligned with the job requirements.

The application shows concrete before-and-after examples rather than only giving general writing advice.

AI Resume Rewriting

The next step is taking those recommendations and generating a complete improved version.

ResumeIQ includes an AI resume-rewriting workflow that can generate an ATS-oriented version based on the selected job description.

The generated resume can then be reviewed and exported in different formats.

The important design principle here is that the system should improve how existing experience is presented rather than fabricate qualifications.

Resume Versions and Comparison

Resume optimization is often iterative.

A candidate might have:

Version 1 → 82%
Version 2 → 88%
Version 3 → 92%

Instead of treating every analysis as completely independent, ResumeIQ includes functionality around:

analysis history
resume versions
comparing resumes
tracking score changes

The application also supports comparing two resumes against the same job description.

This can be useful when experimenting with different versions of the same resume.

Multi-Provider AI

One architectural decision I wanted to explore was avoiding a hard dependency on one AI provider.

ResumeIQ supports:

OpenAI
Gemini
Ollama

Conceptually:

             ┌── OpenAI
             │

Application ── AI Provider Layer ── Gemini
│
└── Ollama

This gives developers flexibility to experiment with different providers and deployment approaches.

For example, a developer might want to use a cloud model in one environment and a locally running model through Ollama in another.

Why Use Spring Boot?

For this project, Spring Boot acts as the backend foundation connecting the different parts of the application.

The application needs to handle:

Authentication
↓
Resume processing
↓
Job-description processing
↓
Matching
↓
AI integration
↓
Persistence
↓
Analysis results

This is where the project becomes more interesting than simply calling an AI API.

The backend has to coordinate multiple workflows and maintain the state of analyses, resumes and versions.

The Interesting Engineering Problem

The most interesting part of building an AI application isn't necessarily:

"How do I call an LLM?"

The harder questions are:

What information should be sent to the model?

How much context is enough?

Which parts should be deterministic?

Which parts actually benefit from an LLM?

How do you avoid coupling the entire application to one provider?

These questions become increasingly important as an AI application grows beyond a simple API demo.

What I Built

The resulting application includes functionality around:

ATS-style resume analysis
Job-description matching
Match scoring
Missing keywords
Missing skills
Keyword analysis
Experience-gap detection
Improvement suggestions
AI rewriting
Resume/JD comparison
Resume versioning
Analysis history
Interview preparation
Multiple AI providers
Dashboard functionality

The project is designed as a source-code foundation that developers can customize and extend, rather than as a hosted SaaS product.

What I'd Improve Next

There are several areas I'd like to explore further.

Better semantic matching

Moving beyond basic keyword matching toward deeper semantic comparison between resume experience and job requirements.

Better context selection

Determining which parts of a resume and job description actually need to be sent to the model.

Model evaluation

Creating a consistent way to compare different models and prompts for resume-analysis tasks.

More provider flexibility

Making it easier to switch between cloud-based and locally hosted models.

More career workflows

Expanding the system beyond resume analysis into additional parts of the job-search workflow.

Final Thoughts

Building ResumeIQ changed how I think about AI applications.

The interesting part isn't:

Resume → LLM → Score

It's the system around the model:

Structured Analysis
+
Matching
+
AI Reasoning
+
Actionable Recommendations
+
Resume Improvement

AI becomes much more useful when it is combined with application logic instead of being treated as the entire application.

For me, the combination of:

Java + Spring Boot + AI + document processing + matching + real-world automation

is what makes this project interesting from a backend-engineering perspective.

Source Code

If you're building a resume platform, career SaaS, ATS tool, or experimenting with AI-powered career applications, I made the complete ResumeIQ AI source code available as a customizable Spring Boot foundation.

ResumeIQ AI — AI Resume Analyzer & ATS SaaS Starter
https://javacoder716.gumroad.com/l/resumeiq-ai

How to Build a Self-Hosted AI Code Review Pipeline with Spring Boot and GitHub Webhooks

JavaCoder7 — Sat, 26 Sep 2026 10:53:48 +0000

How to Build a Self-Hosted AI Code Review Pipeline with Spring Boot and GitHub Webhooks

AI-assisted code review is becoming increasingly useful for catching issues before a Pull Request reaches a human reviewer.

But building an AI code-review workflow isn't simply a matter of sending source code to an LLM.

A useful system needs to handle several pieces:

GitHub Pull Requests
Webhooks
GitHub API integration
Diff extraction
AI provider integration
Structured AI responses
Finding categorization
Risk and quality assessment
Review history
Automated GitHub comments

In this article, I'll walk through a practical architecture for building such a system with Java, Spring Boot and GitHub webhooks.

The basic architecture

The overall workflow can look like this:

GitHub Pull Request
↓
GitHub Webhook
↓
Spring Boot Application
↓
Fetch PR Changes
↓
AI Analysis
↓
Structured Findings
↓
Quality / Risk Assessment
↓
GitHub Review Comment

The important idea is that the AI model isn't directly responsible for the entire workflow.

Spring Boot acts as the orchestration layer.

It receives the GitHub event, retrieves the relevant changes, prepares the AI request, processes the response, stores the review result and optionally sends the findings back to GitHub.

Receiving GitHub Pull Request events

GitHub webhooks allow an external application to receive events when something happens in a repository.

For example:

Pull Request opened
Pull Request updated
Pull Request synchronized

A Spring Boot endpoint can receive these events.

@RestController
@RequestMapping("/webhooks/github")
public class GitHubWebhookController {

@PostMapping
public ResponseEntity<Void> handleWebhook(
        @RequestBody String payload) {

    // Validate webhook
    // Parse event
    // Trigger review workflow

    return ResponseEntity.ok().build();
}

}

In a real implementation, the webhook should also validate the GitHub signature before processing the request.

This prevents arbitrary callers from pretending to be GitHub.

Don't send the entire repository to the AI

One of the most important design decisions is deciding what the model actually receives.

For a Pull Request review, sending the entire repository can be:

expensive
slow
unnecessary
difficult to fit into the model's context window

Instead, retrieve the Pull Request changes.

Conceptually:

Repository
↓
Pull Request
↓
Changed files
↓
Diff
↓
Relevant code
↓
AI

The GitHub API can be used to retrieve the files and changes associated with the Pull Request.

The review service can then construct an analysis request from those changes.

Separate GitHub integration from AI integration

This is where the architecture becomes important.

I would avoid putting GitHub API calls and AI provider calls inside the same service.

Instead:

GitHubWebhookController
↓
PullRequestReviewService
↙ ↘
GitHubService AIReviewService
↓
AI Provider

For example:

public interface AIReviewService {

ReviewResult review(String codeChanges);

}

The rest of the application doesn't need to know whether the request is going to OpenAI, Gemini or a locally running Ollama model.

That's particularly useful if you want the provider to be configurable.

Supporting multiple AI providers

A code-review tool shouldn't necessarily be locked to one AI provider.

A configuration-driven approach can look like:

ai.provider=openai
ai.model=gpt-model

And another environment could use:

ai.provider=gemini
ai.model=gemini-model

Or a local provider:

ai.provider=ollama
ai.model=local-model

The application logic should remain the same.

Conceptually:

            AIReviewService
                   |
          Provider Selection
          /       |       \
     OpenAI     Gemini    Ollama

This separation also makes it easier to test the review workflow independently from a particular provider.

Ask the AI for structured output

Another important part of an AI code-review system is the response format.

A free-form response such as:

"There might be a security problem here..."

is difficult for an application to process reliably.

Instead, define a structured review result.

For example:

{
"qualityScore": 8,
"riskLevel": "LOW",
"confidence": 0.90,
"findings": [
{
"category": "SECURITY",
"severity": "MEDIUM",
"title": "Potential credential handling issue",
"description": "Review how the credential is overridden.",
"recommendation": "Validate and restrict credential updates."
}
]
}

Now the application can use the response programmatically.

For example:

AI response
↓
Parse JSON
↓
Validate structure
↓
Store review
↓
Display dashboard
↓
Generate GitHub comment

This is much more useful than treating the model response as plain text.

Categorizing findings

The review can classify problems into different categories.

For example:

🐛 Bugs

Potential logical errors or unexpected behavior.

🔐 Security

Potential security weaknesses, credential handling problems, authentication issues or unsafe input handling.

⚡ Performance

Potential inefficient operations, unnecessary database calls or expensive processing.

✅ Best Practices

Maintainability, readability and implementation practices that could be improved.

A finding can also have a severity:

CRITICAL
HIGH
MEDIUM
LOW
INFO

This allows developers to focus on the most important findings first.

Adding a quality and risk assessment

Individual findings are useful, but a summary can make the review easier to understand.

For example:

Quality Score: 8/10

Risk: LOW

AI Confidence: 90%

Critical Issues: 0
Suggestions: 2

The important thing is to make these scores supporting signals, not replacements for human review.

An AI reviewer can help surface potential problems, but developers still need to inspect the actual code and decide whether a change should be merged.

Posting the review back to GitHub

Once the analysis is complete, the application can use the GitHub API to post the review.

The workflow becomes:

PR opened
↓
Webhook
↓
Fetch diff
↓
AI analysis
↓
Structured result
↓
Save review
↓
GitHub review/comment

This makes the AI reviewer part of the existing developer workflow instead of forcing developers to open another application every time.

Manual reviews are useful too

Webhooks are great for automation, but a dashboard can provide a manual review option.

For example:

Repository
Pull Request
↓
[ Review PR ]
↓
AI Analysis

This is useful when developers want to review a Pull Request on demand without waiting for another webhook event.

It also gives you a good place to expose review history.

Store review history

If reviews are persisted, the application can provide historical information such as:

PR #42
Quality: 8/10
Risk: LOW
Critical Issues: 0
Suggestions: 2
Reviewed: Sep 26

Over time, this can become more useful than a single AI response.

You can start identifying trends such as:

Review History

PR #38 → 6/10
PR #39 → 7/10
PR #40 → 7/10
PR #41 → 8/10
PR #42 → 8/10

This gives developers another way to understand how their code is evolving.

Security considerations

A self-hosted implementation still needs careful handling of credentials.

Typical sensitive values include:

GitHub Personal Access Token
GitHub Webhook Secret
AI Provider API Key
Database Credentials

These shouldn't be hardcoded in source code.

Use environment variables or an appropriate secret-management mechanism.

For example:

github.token=${GITHUB_TOKEN}
github.webhook-secret=${GITHUB_WEBHOOK_SECRET}

ai.api-key=${AI_API_KEY}

The application should also apply appropriate permissions to GitHub tokens rather than requesting more access than necessary.

Why self-host the reviewer?

There are situations where developers may want more control over the review infrastructure.

With a self-hosted architecture:

GitHub
↓
Your infrastructure
↓
Your AI provider

Instead of:

GitHub
↓
Third-party SaaS
↓
AI provider

The exact privacy and compliance benefits depend on how the system and AI provider are configured, but self-hosting gives the developer more control over where the application, credentials and review workflow operate.

It also makes customization much easier.

You can modify:

review rules
prompts
finding categories
scoring
dashboard
AI provider
GitHub workflow
storage
authentication

The complete workflow

Putting everything together:

             GitHub Pull Request
                     │
                     ▼
              GitHub Webhook
                     │
                     ▼
          Spring Boot Application
                     │
                     ▼
            Fetch PR Changes
                     │
                     ▼
              Prepare Prompt
                     │
                     ▼
             AI Provider Layer
              /      |       \
         OpenAI    Gemini    Ollama
              \      |       /
                     ▼
            Structured Review
                     │
          ┌──────────┼──────────┐
          ▼          ▼          ▼
        Bugs     Security   Performance
          │          │          │
          └──────────┼──────────┘
                     ▼
             Quality / Risk
                Assessment
                     │
          ┌──────────┴──────────┐
          ▼                     ▼
   Review Dashboard       GitHub Comment

The key architectural principle is separation of concerns.

GitHub integration shouldn't know how an AI provider works.

The AI layer shouldn't know how GitHub authentication works.

And the business layer shouldn't need to change simply because you switch from one AI provider to another.

Building CodeGuard AI

I built CodeGuard AI around this type of workflow.

It's a self-hosted GitHub AI code-review application built with:

Java 17+
Spring Boot
Spring Security
GitHub REST API
AI provider integrations
REST APIs
HTML/CSS/Vanilla JavaScript
Maven

It supports:

AI-powered Pull Request reviews
Bug detection
Security analysis
Performance analysis
Best-practice checks
Quality and risk assessment
AI confidence scoring
Automatic GitHub review comments
GitHub webhooks
Manual PR reviews
Review history
Review trends
Markdown/PDF export
OpenAI
Google Gemini
Ollama

The goal was to build a customizable source-code foundation rather than another closed review service.

Final thoughts

An AI code reviewer is more than an LLM prompt.

The interesting engineering work is around the LLM:

GitHub events → code extraction → provider abstraction → structured AI output → validation → persistence → developer-facing results → GitHub integration.

That's where Spring Boot fits particularly well.

If you're building an AI developer tool, keeping the AI layer modular and the surrounding application deterministic can make the system much easier to extend and maintain.

About the project

CodeGuard AI is available as a self-hosted Spring Boot source-code project for developers who want to build and customize their own AI-powered GitHub code-review workflow.

Build. Customize. Self-host.
Get CodeGuard AI → https://javacoder716.gumroad.com/l/codeguard-ai

Building a Multi-Provider AI Resume Analyzer in Spring Boot (and why I didn't lock it to one AI provider)

JavaCoder7 — Thu, 24 Sep 2026 05:58:00 +0000

I've been building AI-powered developer tools solo for the past few months, and I want to share some of the architecture decisions behind my latest one: ResumeIQ AI, a resume analyzer and interview prep tool.

The core problem I wanted to solve

Most AI resume tools are SaaS products tied to one AI provider, usually OpenAI. That means:

You're locked into their pricing
If you're privacy-conscious, your resume data goes through a service you don't control
You can't swap providers if a cheaper or better one comes along

I wanted something a developer could self-host and plug in their own choice of provider — OpenAI, Gemini, or a local Ollama instance.

Design decision: config-only provider switching

Instead of hardcoding model names anywhere in business logic, every model name lives in application.properties. Swapping from gpt-4 to gemini-1.5-pro to a local Ollama model is a config change, not a code change. This also made it trivial to add new providers later without touching the analysis logic.

A subtle bug this caught: forcing JSON mode where it doesn't belong

Some endpoints need structured JSON output (resume scoring breakdowns), others need free-text generation (interview prep questions, feedback). Early on I had JSON mode forced globally on the AI provider interface — which silently broke the free-text responses, since forcing JSON mode on a prompt that wants prose either truncates or garbles the output.

Fix was a jsonMode boolean on the provider interface itself, set per-call rather than globally. Small change, but it's the kind of thing that's invisible until you're staring at broken output wondering why your prompt is fine but the response isn't.

What's actually in it

Full auth system with user history and resume versioning
Side-by-side resume comparison across versions
AI-generated interview prep tied to the resume + target role
Freemium gating built in, so it's ready to sell as-is
Admin panel for managing users/tiers

Where it's at now

It's live and for sale as source code on Gumroad — self-hosted, one-time purchase, bring your own API key. https://javacoder716.gumroad.com/l/resumeiq-ai

Still very early — this is my first real push on distribution after building solo for a while. If you've built anything similar or have thoughts on the provider-switching approach, I'd love to hear it in the comments.

How to Handle External API Failures in Spring Boot: Retries, Timeouts and Resilience

JavaCoder7 — Fri, 18 Sep 2026 16:30:49 +0000

TL;DR: When a Spring Boot application depends on an external API, failures are inevitable. In this article, I'll walk through how to think about timeouts, retries, backoff, rate limits, and fallback handling when building a resilient backend.

When I was building an AI-powered GitHub Pull Request reviewer, one thing became very clear:

The AI API is not under my control.

My application can be perfectly healthy, but an external service can still:

Take too long to respond
Return a 500
Temporarily become unavailable
Reject requests because of rate limits
Return an unexpected response
Have a network failure

So this raises an important backend question:

What should my Spring Boot application do when an external API fails?

Simply calling the API and returning the exception to the user isn't enough.

Let's look at a better approach.

The Problem

Imagine this simple flow:

Client
|
v
Spring Boot
|
v
External API
|
X
Failure

If the external API fails, our application needs to decide:

Should we retry?

How many times?

How long should we wait?

What if the API is still unavailable?

What response should our client receive?

These are resilience questions.

Always Set a Timeout

One of the first mistakes that can happen with external API calls is forgetting about timeouts.

Imagine:

Spring Boot
|
| Request
v
External API
|
| .............
| .............
| .............

If the external service doesn't respond, you don't want your application waiting indefinitely.

A timeout gives your application a clear boundary.

Conceptually:

The exact timeout depends on the API and the operation.

A request that normally takes 200 ms shouldn't necessarily have a 5-minute timeout.

The important idea is:

Every external network call should have an intentional timeout strategy.

Should We Retry?

Not every failure should be retried.

For example, suppose the external API returns:

500 Internal Server Error

A retry might make sense because the failure could be temporary.

But imagine the API returns:

400 Bad Request

Retrying the exact same request probably won't fix anything.

The request itself is invalid.

So we need to distinguish between failures.

Potentially retryable
Connection failure
Timeout
Temporary 5xx response
429 Too Many Requests
Usually not retryable
400 Bad Request
401 Unauthorized
403 Forbidden
404 Not Found
Invalid request data

The exact retry policy depends on the API and the operation.

Don't Retry Immediately

Suppose an external API is temporarily unavailable.

A naive implementation might do:

Request
↓
Failure
↓
Retry immediately
↓
Failure
↓
Retry immediately
↓
Failure

This can make the situation worse.

Instead, we can introduce a delay between attempts.

This is called backoff.

For example:

Attempt 1 → Failure
↓
Wait 1 sec
↓
Attempt 2 → Failure
↓
Wait 2 sec
↓
Attempt 3 → Failure

A common approach is exponential backoff, where the delay increases after each failed attempt.

In production systems, adding some jitter to the delay can also help prevent many clients from retrying at exactly the same time.

Example Using Spring Retry

One way to implement retries in a Spring application is with Spring Retry.

For example:

@Retryable(
retryFor = ExternalApiException.class,
maxAttempts = 3,
backoff = @Backoff(delay = 1000)
)
public String callExternalApi() {

return externalApiClient.call();

}

The basic idea is:

Maximum attempts = 3
Initial delay = 1000 ms

So if the call fails with the configured exception, the application can attempt the operation again according to the retry configuration.

But there's an important question:

What happens after all retry attempts fail?

That's where fallback handling becomes useful.

Fallback Handling

Suppose all retry attempts fail:

Attempt 1 → Failure
Attempt 2 → Failure
Attempt 3 → Failure

At this point, continuing to retry isn't useful.

The application needs to fail gracefully.

Conceptually:

Depending on the application, the fallback could:

Return a meaningful error
Use cached data
Queue the request for later processing
Mark the operation as pending
Use an alternative service

The correct fallback depends heavily on the business requirement.

Handling Rate Limits

Another interesting failure scenario is:

429 Too Many Requests

This usually means the client has exceeded the API's allowed request rate.

Immediately sending more requests isn't a good strategy.

Instead, the application should respect the API's rate-limit behavior.

Some APIs provide information such as:

Retry-After

which can indicate when the client should try again.

This is particularly important when building applications that make frequent calls to third-party APIs.

What About the AI Code Reviewer?

This became particularly relevant to the AI code reviewer I was building.

The workflow looks roughly like:

What happens if the AI service doesn't respond?

I don't want the entire application to simply crash.

A better design would be something like:

This is where resilience becomes more than just adding a retry annotation.

It becomes an architectural decision.

Synchronous vs Asynchronous Processing

Suppose the GitHub webhook directly waits for the AI response:

GitHub
|
v
Webhook
|
v
Spring Boot
|
v
AI API
|
v
Response

The webhook request remains open while the AI request is being processed.

A more scalable approach could be:

Now the webhook can be acknowledged quickly while the actual review happens asynchronously.

This also makes it easier to implement:

Retries
Delayed processing
Failure tracking
Dead-letter queues
Multiple workers
Horizontal scaling

Don't Retry Everything

This is probably the most important lesson.

Adding:

retry = 5

doesn't automatically make an application resilient.

Imagine five application instances all calling the same unavailable API.

If every instance retries aggressively, we could end up with:

Application 1 → Retry
Application 2 → Retry
Application 3 → Retry
Application 4 → Retry
Application 5 → Retry

The external service is already struggling.

Our retries could make the situation worse.

This is sometimes called a retry storm.

That's why retry policies need to consider:

Which errors are retryable
Maximum attempts
Backoff
Jitter
Rate limits
Request volume
Idempotency
Overall system behavior

What Is Idempotency and Why Does It Matter?

This is another important consideration when implementing retries.

Suppose we have:

POST /payments

and the first request actually succeeds, but the response is lost because of a network problem.

Our application doesn't know whether the operation succeeded.

If we blindly retry:

POST /payments

we could potentially create the operation twice.

That's why retrying a request isn't simply a technical decision.

We also need to understand whether the operation is safe to repeat.

For operations that can have side effects, idempotency mechanisms may be necessary.

Circuit Breakers

Retries aren't always enough.

Imagine an external service has been unavailable for several minutes.

Our application keeps sending requests.

Each request waits for a timeout.

Then it retries.

Then another request does the same thing.

We're wasting resources while the dependency is clearly unhealthy.

This is where a circuit breaker can help.

Conceptually:

         Normal
           |
           v
    +--------------+
    |    CLOSED    |
    +--------------+
           |
    Too many failures
           |
           v
    +--------------+
    |     OPEN     |
    +--------------+
           |
    Wait / test
           |
           v
    +--------------+
    | HALF-OPEN    |
    +--------------+
      /          \
 Success        Failure
   |               |
   v               v
CLOSED            OPEN

The circuit breaker temporarily stops calls to an unhealthy dependency.

This prevents our application from continuously hammering an unavailable service.

Libraries such as Resilience4j can be used to implement patterns like:

Retry
Circuit breaker
Rate limiter
Bulkhead
Time limiter
A Resilient External API Flow

Putting the concepts together:

              Client
                |
                v
          Spring Boot
                |
                v
         External API
                |
      +---------+---------+
      |                   |
   Success              Failure
      |                   |
      v                   v
   Continue            Is it
                       retryable?
                       /      \
                     Yes       No
                      |         |
                      v         v
                   Backoff    Fail
                      |
                      v
                    Retry
                      |
                Still failing?
                   /      \
                 Yes       No
                  |         |
                  v         v
               Fallback   Success

This is the kind of flow I now think about whenever my backend depends on an external service.

What I Learned

Before working on projects involving external APIs, it was easy to think:

"I'll just call the API and handle the response."

But real backend systems aren't that simple.

External dependencies can fail.

Networks can fail.

Services can become slow.

Rate limits can be reached.

Responses can change.

And your application needs to behave predictably when those things happen.

The goal isn't to make failures impossible.

The goal is to make failures manageable.

My Spring Boot Resilience Checklist

When I integrate an external API now, these are some of the questions I ask:

✓ Do I have a connection timeout?
✓ Do I have a response timeout?
✓ Which failures are retryable?
✓ How many retries should I allow?
✓ Do I need exponential backoff?
✓ Should I add jitter?
✓ How do I handle 429 responses?
✓ Is the operation safe to retry?
✓ Do I need a circuit breaker?
✓ Should this operation be asynchronous?
✓ What happens after all retries fail?
✓ How will I monitor failures?

Thinking about these questions early can prevent a lot of problems later.

Final Thoughts

While building my AI-powered GitHub Pull Request reviewer, I initially focused mostly on the AI part.

But the more I thought about the architecture, the more I realized:

The AI call is just another external dependency.

The same principles apply whether you're calling:

An AI API
A payment gateway
A notification service
A database service
A third-party REST API

Your application needs to assume that external dependencies can fail.

That's one of the differences between a backend that works in a demo and one that is designed to handle real-world conditions.

What would you add?

If your Spring Boot application depends heavily on an external API, what resilience strategy do you usually use?

Retries? Circuit breakers? Async processing? Queues? Caching?

I'd love to hear how other developers approach this.