DEV Community: JavaCoder7

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.

How I Built an AI Code Reviewer for GitHub Pull Requests with Spring Boot

JavaCoder7 — Tue, 08 Sep 2026 17:04:07 +0000

How I Built an AI Code Reviewer for GitHub Pull Requests with Spring Boot

TL;DR: I built an AI-powered GitHub Pull Request reviewer with Spring Boot that receives GitHub webhooks, fetches code changes, sends relevant context to an AI model, and generates an automated first-pass code review.

Code reviews are one of those things every development team needs.

But they're also repetitive.

A developer opens a Pull Request.

Someone reviews it.

They look for bugs, security issues, code quality problems, performance concerns, and possible improvements.

So I started wondering:

What if AI could perform the first round of review before a human reviewer even looks at the PR?

That idea led me to build an AI-powered GitHub Pull Request Code Reviewer using Spring Boot, GitHub APIs, and an AI model.

The goal wasn't to replace human code reviews.

It was to automate the boring first pass and give developers useful feedback earlier.

The Architecture

The basic workflow looks like this:

The interesting part wasn't simply calling an AI API.

The real challenge was connecting multiple systems and making the workflow reliable as a backend service.

Why Spring Boot?

I chose Spring Boot because it provides a clean way to build REST APIs and integrate external services.

The backend is responsible for:

Receiving GitHub webhook events
Processing Pull Request information
Communicating with GitHub APIs
Extracting code changes
Communicating with the AI service
Handling failures and timeouts
Processing the generated review

A simplified architecture looks like this:

             GitHub
               |
               | Webhook
               v
    +-----------------------+
    |      Spring Boot      |
    |        Backend        |
    +-----------------------+
          |           |
          |           |
          v           v
    GitHub API       AI API
          |           |
          +-----+-----+
                |
                v
          Review Result

Step 1: Receiving the GitHub Webhook

Instead of continuously polling GitHub for new Pull Requests, I wanted GitHub to notify my application whenever something happened.

For example, when a Pull Request is opened or updated, GitHub can send a webhook request to the Spring Boot application.

A simplified controller looks like this:

@RestController
@RequestMapping("/webhook")
public class GithubWebhookController {

@PostMapping("/pull-request")
public ResponseEntity<String> handlePullRequest(
        @RequestBody String payload) {

    // Process GitHub webhook

    return ResponseEntity.ok("Webhook received");
}

}

Of course, a production implementation shouldn't simply accept any incoming request.

The webhook should be validated, the payload should be parsed properly, and the event type should be handled accordingly.

This gave me an important reminder when working with external integrations:

Never blindly trust incoming webhook requests.

Step 2: Getting Pull Request Details

Once the webhook is received, the application needs information about the Pull Request.

For example:

Repository
Pull Request number
Source branch
Target branch
Author
Changed files

The backend can then communicate with GitHub's API to retrieve the required information.

Conceptually:

Webhook
|
v
Repository + PR Number
|
v
GitHub API
|
v
Pull Request Details
|
v
Changed Files / Diff

This is where the project starts becoming more than a simple CRUD application.

We're integrating with an external system, transforming its data, and feeding it into another service.

Step 3: Extracting the Code Changes

One thing I didn't want to do was send an entire repository to the AI model.

That would introduce unnecessary context and potentially increase processing cost.

Instead, the application focuses primarily on the changes introduced by the Pull Request.

For example:

return user.getName();
return user.getName().trim();

The AI doesn't always need the entire application.

It needs enough relevant context to understand:

What changed?

and

Could this change introduce a problem?

This makes the review more focused.

Step 4: Building the AI Prompt

This turned out to be one of the most important parts.

Simply sending:

Review this code.

doesn't give the AI enough direction.

Instead, I give it a specific role and review criteria.

For example:

You are a senior Java code reviewer.

Review the following Pull Request changes.

Look for:

Bugs
Security vulnerabilities
Performance problems
Exception handling issues
Code quality problems
Maintainability issues

For every significant issue:

Explain the problem
Explain why it matters
Suggest a possible improvement

If there are no significant issues, say so clearly.

Focus only on meaningful issues.
Do not suggest unnecessary changes.

Pull Request diff:

[DIFF HERE]

The important lesson here was:

The quality of an AI response depends heavily on the quality of the context and instructions you provide.

Prompting isn't just about asking a question.

It's about giving the model the right context to reason about.

Step 5: Calling the AI Service

From Spring Boot, the application can communicate with an external AI API using an HTTP client.

Conceptually:

public String reviewCode(String codeDiff) {

String prompt = buildPrompt(codeDiff);

// Send prompt to AI service
// Receive generated review
// Return review

return review;

}

But the backend responsibility doesn't end with making the API call.

A real application also needs to think about:

API failures
Timeouts
Invalid responses
Rate limits
Authentication
Logging
Retry strategies

This is where the project became more interesting from a backend engineering perspective.

The Complete Flow

Putting everything together:

What started as an idea for an AI code reviewer became a backend workflow involving multiple systems.

The Biggest Thing I Learned

The most interesting part of this project wasn't actually the AI API.

It was everything around it.

AI is only one component of the system.

A production-style application still needs:

Clean API design
Authentication
Input validation
Error handling
External API integration
Logging
Security
Rate limiting
Observability
Good database design when persistence is required

You can have a powerful AI model, but if your backend fails when GitHub sends a webhook, the application isn't very useful.

AI doesn't remove backend engineering. It makes good backend engineering even more important.

What I'd Improve Next

There are several things I'd add if I continued developing this project.

Asynchronous Processing

AI requests can take time.

Instead of keeping the webhook request waiting, I'd move the review process into an asynchronous workflow.

This would make the webhook endpoint faster and provide a better foundation for scaling.

Review History

I'd store previous reviews so developers could see:

Previous issues
Repeated problems
Review history
Changes in code quality over time

Configurable Review Rules

Different teams care about different things.

For example:

Java
Spring Boot
Security
Performance
Clean Code
Architecture

The review criteria could be configurable depending on the project.

Better Context Management

This is one of the biggest challenges with AI-based developer tools.

Send too little context and the AI may misunderstand the change.

Send too much context and the response becomes less focused while increasing processing cost.

So the real engineering question becomes:

What is the minimum context the AI needs to produce a useful review?

I think that's a much more interesting problem than simply connecting an application to an AI API.

AI Doesn't Replace the Developer

I don't see AI code review as a replacement for human developers.

I see it as a first-pass reviewer.

AI can quickly identify potential problems.

But a human developer still needs to ask:

Is this actually a problem for our application?

That's particularly important for business logic and architectural decisions, where the AI may not have enough context.

Final Thoughts

Building this project changed the way I think about AI applications.

The interesting part isn't:

"I connected Spring Boot to an AI API."

The interesting part is building a reliable backend system around that AI capability.

For me, the combination of:

Java + Spring Boot + APIs + AI + real-world automation

is much more interesting than building another basic CRUD application.

And that's the kind of backend engineering I want to keep exploring.

What would you add?

If you were building an AI-powered Pull Request reviewer, what would you prioritize?

Security vulnerabilities? Performance issues? Architecture? Code quality?

I'd love to hear what other developers would add.

I Built 3 AI Products with Spring Boot — Here’s What I Learned

JavaCoder7 — Fri, 14 Aug 2026 15:32:45 +0000

I got tired of building the same CRUD applications.

So instead of creating another simple Employee Management System or To-Do application, I decided to build something that felt closer to a real product.

Over the last few weeks, I built three AI-powered applications using Spring Boot:

🤖 AI Code Reviewer for GitHub Pull Requests
📄 AI Resume Analyzer
💬 Self-Hosted AI Support Widget

Each project started with a simple idea:

Can I build something useful with the backend technologies I already know instead of just building projects for a tutorial?

The answer turned out to be yes.

But the most valuable part wasn't actually finishing the applications.

It was everything I learned while building them.

Why I Chose Spring Boot

I've been working with Java and Spring Boot, so I wanted to see how far I could take the stack when combined with AI.

When people talk about AI applications, the conversation often revolves around Python, machine learning models, notebooks, and data science.

But there is another side to AI:

The application layer.

You still need:

REST APIs
Authentication
Database integration
External API communication
Request validation
Error handling
File processing
Business logic
Logging
Configuration
Deployment

And that's where Spring Boot becomes extremely useful.

The AI model might generate the intelligence, but the backend is what turns that intelligence into an actual product.

Product 1: AI Code Reviewer for GitHub Pull Requests

The first product I built was an AI-powered code reviewer for GitHub Pull Requests.

The idea was simple:

Instead of manually going through every changed file in a Pull Request, why not let an AI analyze the changes and provide useful feedback?

The basic flow
GitHub Pull Request
↓
Fetch PR information
↓
Get changed code
↓
Prepare review prompt
↓
AI analysis
↓
Generate review
↓
Return useful feedback

The AI isn't just being asked:

"Is this code good?"

The goal is to make the review more useful by looking for things developers actually care about.

For example:

Potential bugs
Code quality problems
Security concerns
Performance issues
Maintainability
Bad practices
Possible improvements
What I Learned From This Project

The biggest lesson was:

AI output is only as good as the context you give it.

Initially, it is tempting to simply send a piece of code to an AI model and ask:

"Review this code."

But real code doesn't exist in isolation.

A method might depend on another class.

A variable might have a specific business meaning.

A change might only make sense when you look at the entire Pull Request.

So building an AI application isn't simply about calling an AI API.

It's about collecting the right context and presenting it in the right way.

That was one of my first major lessons.

Product 2: AI Resume Analyzer

The second product was an AI Resume Analyzer built with Spring Boot.

The idea came from something very familiar to anyone who has applied for jobs:

You spend hours creating a resume...

Then send it to a company...

And never know why it didn't get shortlisted.

So I wanted to build a tool that could analyze a resume and provide useful feedback.

The basic idea
Resume
↓
Upload
↓
Backend processing
↓
Extract resume content
↓
AI analysis
↓
Generate feedback
↓
Return analysis

The application can analyze areas such as:

Skills
Experience
Keywords
Resume structure
Job relevance
Missing information
Potential improvements

The interesting part was that this project introduced a completely different backend problem compared with the GitHub reviewer.

Now the application had to deal with documents and unstructured information.

What I Learned From This Project

This project taught me something important:

Building an AI application is often more about data preparation than the AI call itself.

You can't just throw a document at an AI model and expect perfect results.

The application needs to:

Receive the file
Process the content
Extract useful information
Organize that information
Send the right context to the AI
Process the response
Present the result in a useful format

The backend therefore becomes the bridge between the user's raw input and the AI model.

That made me appreciate Spring Boot even more.

Product 3: Self-Hosted AI Support Widget

This is the project I'm currently most excited about.

I built a self-hosted AI support widget using Spring Boot.

The idea was to create an AI-powered support experience without forcing someone to depend on an expensive monthly SaaS subscription.

The important word here is:

Self-hosted.

Instead of thinking:

"I need to subscribe to another SaaS product."

The idea becomes:

"I can run this myself."

The basic concept
User
↓
Support Widget
↓
Spring Boot Backend
↓
AI Service
↓
Response
↓
Support Widget

The backend handles the communication between the widget and the AI service.

That means the frontend doesn't need to contain all the business logic.

Spring Boot becomes the central layer responsible for the application's behavior.

Why I Like This Project

This project felt different from my previous applications because I wasn't just thinking about whether an API worked.

I started thinking about:

How would another developer use this?
How can the application be self-hosted?
What should the API look like?
How should errors be handled?
How should configuration work?
How can the application be extended later?
How can I make this feel like an actual product?

That's when I realized something:

There is a big difference between building an application and building a product.
What These 3 Projects Taught Me

After building all three, I noticed that the AI itself was not the hardest part.

Calling an AI API is relatively straightforward.

The difficult part is everything around it.

AI Doesn't Replace Backend Engineering

This was probably my biggest takeaway.

AI can generate an answer.

But someone still has to build the system around it.

You still need to think about:

Authentication
↓
API Design
↓
Validation
↓
Business Logic
↓
Database
↓
External Services
↓
AI Integration
↓
Error Handling
↓
Deployment

That's backend engineering.

And AI becomes another service that the backend integrates with.

Prompt Engineering Is Only One Piece

Before building these projects, I thought a lot about prompts.

After building them, I realized that prompt engineering is only one part of the problem.

A better mental model is:

Good Input
+
Good Context
+
Good Prompt
+
Good Backend Logic
=
Better AI Application

If the application sends poor or incomplete context, even a great model can produce a poor result.

Product Thinking Matters

When you're following a tutorial, the goal is usually:

Make the application work.

When you're building your own product, the questions change.

You start asking:

Who is going to use this?
What problem does it solve?
Why would someone use this instead of another tool?
What happens when something fails?
How can I make it easier to use?
What features should I add later?

Those questions changed the way I approach development.

Don't Build Features Just Because You Can

One of the easiest mistakes when building side projects is adding too many features.

You start with:

"I'll build an AI code reviewer."

Then suddenly you're planning:

Authentication
Teams
Billing
Analytics
Notifications
Dashboards
Admin panels
Multiple AI providers
Ten different integrations

And the original product never gets finished.

I've learned to ask:

Does this feature solve the core problem?

If the answer is no, it can wait.

A Working Product Is More Valuable Than a Huge Project

I would rather have:

3 small working products

than:

1 huge unfinished application.

These projects also taught me that a project doesn't need 50 features to demonstrate engineering ability.

A relatively small application can demonstrate:

API design
Backend architecture
External integrations
AI integration
File processing
Error handling
Business logic
Deployment
Product thinking

That's already a lot.

The Tech Stack

Across these projects, my focus was primarily on the backend ecosystem I'm comfortable with.

Backend
Java
Spring Boot
REST APIs
Spring-based backend architecture
AI
AI APIs / LLM integration
Prompt design
Context preparation
AI-generated responses
Integrations
GitHub APIs
File/document processing
External services
Development
Maven
Git/GitHub
API testing
Logging
Configuration management

The exact implementation differs between the projects, but the common idea is the same:

Use Spring Boot as the application layer that connects users, business logic, external services, and AI.

What I Would Do Differently Next Time

If I started these projects again, I would spend more time on architecture before writing the first line of code.

I'd ask:

What is the core problem?
↓
What is the minimum useful product?
↓
What APIs do I need?
↓
What data do I need?
↓
Where does AI actually add value?
↓
How should the components communicate?
↓
How will I deploy it?

This prevents a project from turning into a collection of random features.

What's Next?

I'm not planning to stop at these three.

The next step is to take what I learned from these projects and build more practical backend tools around Java, Spring Boot, AI, and databases.

I'm particularly interested in projects that solve problems developers actually face.

Because my goal isn't simply:

"Build another AI project."

My goal is:

Build useful software and learn the engineering behind it.

Final Takeaway

Building these three products changed the way I look at AI development.

I started with:

"How do I integrate AI into a Spring Boot application?"

And ended up thinking much more about:

"How do I build a useful product where AI is actually part of the solution?"

That's a much more interesting question.

The AI model is only one component.

The real engineering challenge is everything around it.

And that's exactly the part I want to keep exploring.

The 3 Products

🤖 AI Code Reviewer for GitHub Pull Requests
Analyze Pull Request changes and generate AI-powered code review feedback.

📄 AI Resume Analyzer
Analyze resumes and provide AI-powered feedback and improvement suggestions.

💬 Self-Hosted AI Support Widget
Build an AI-powered support experience that can be self-hosted without relying entirely on a monthly SaaS platform.

If you're also a Java/Spring Boot developer experimenting with AI, I'd love to hear what you're building.

What would you build with Spring Boot + AI?

Drop it in the comments 👇

🔗 Projects

GitHub: [https://github.com/Sweety717/]

Project 1 — AI Code Reviewer: [https://swarnalata25.gumroad.com/l/codeguard-ai]

Project 2 — AI Resume Analyzer: [https://swarnalata25.gumroad.com/l/resumeiq-ai]

Project 3 — Self-Hosted AI Support Widget: [https://swarnalata25.gumroad.com/l/supportai-springboot]

I Built My Own AI Code Reviewer for GitHub Pull Requests

JavaCoder7 — Tue, 11 Aug 2026 10:33:47 +0000

# I Built My Own AI Code Reviewer for GitHub Pull Requests

Code reviews are important.

But let's be honest — they can also become repetitive.

Someone opens a pull request.

A reviewer has to go through dozens of changed files.

Then comes the usual checklist:

Is there an obvious bug?
Is there a security issue?
Is this database query going to cause a performance problem?
Is there duplicated or unnecessary code?
Is there a better way to implement this?
Did we introduce something that will break later?

And when the PR is large, reviewing everything carefully becomes difficult.

So I decided to build something for this problem.

Meet CodeGuard AI — a self-hosted AI code reviewer for GitHub Pull Requests.

The idea is simple:

Give it a GitHub PR → let AI inspect the diff → get a structured code review directly on GitHub.

And because I wanted this to be a developer-owned tool, it is designed to run on your own infrastructure and use your own AI provider.

## What is CodeGuard AI?

CodeGuard AI is a Spring Boot application that automatically reviews GitHub Pull Requests using an AI model.

It can analyze a PR for things like:

🐛 Bugs
🔐 Security issues
⚡ Performance problems
📐 Best-practice violations
🗄️ Database-related issues
💡 Improvement suggestions

Instead of returning a huge block of AI-generated text, the review is structured around findings.

For example:

CRITICAL
SecurityConfig.java

Disabled CSRF on Session-Cookie Authentication

CSRF protection is disabled while the application
uses session cookies for authentication.

Suggested fix:
Enable CSRF protection using a CookieCsrfTokenRepository
or switch to stateless header-based authentication.
The goal isn't to replace human reviewers.

The goal is to give them a useful first pass before they spend time going through the PR themselves.

Why I built it

There are already many AI coding tools.

AI can write code.

AI can explain code.

AI can generate tests.

So I was interested in a slightly different question:

What happens if AI becomes the first reviewer instead of the programmer?

A pull request already contains something extremely valuable for an AI model:
the change itself.

You don't necessarily need to understand the entire application to start finding potential problems.

You can start with:
PR
↓
Changed files
↓
Diff
↓
AI analysis
↓
Structured findings
↓
Developer
That became the core idea behind CodeGuard AI.

How CodeGuard AI works
The architecture is intentionally simple.
GitHub
│
│ Pull Request
▼
┌─────────────────────┐
│ GitHub Webhook │
│ Receiver │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ PR / Diff Fetcher │
│ GitHub API │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Code Review Service │
└──────────┬──────────┘
│
▼
┌─────────────────────────┐
│ AI Provider Abstraction │
└──────┬──────┬──────┬───┘
│ │ │
OpenAI Gemini Ollama
│ │ │
└──────┴──────┘
│
▼
┌─────────────────────┐
│ Structured Review │
│ Findings │
└──────────┬──────────┘
│
┌──────┴───────┐
▼ ▼
Dashboard GitHub PR

The application is built with:

Java 17
Spring Boot
Spring Security
GitHub REST API
REST APIs
HTML/CSS/Vanilla JavaScript
OpenAI / Gemini / Ollama integrations
Maven

Step 1: GitHub sends the Pull Request
CodeGuard AI exposes a GitHub webhook endpoint.
For example:
POST /webhook/github
When a pull request is opened, reopened, or updated, GitHub sends an event to CodeGuard AI.
The webhook signature is verified using HMAC-SHA256 before processing the request.
This is important because you don't want arbitrary requests triggering your review pipeline.
Step 2: Fetch the Pull Request
Once the webhook is verified, CodeGuard AI uses the GitHub API to retrieve information about the PR.

This includes things such as:

Repository
Pull request number
Author
Changed files
Diff
Added lines
Deleted lines

The important part is the diff.

Instead of blindly sending an entire repository to an AI model, the reviewer focuses on the code that actually changed.

Step 3: Send the changes to the AI
The diff is then passed to the configured AI provider with a structured review prompt.
CodeGuard AI supports multiple providers:
OpenAI
Google Gemini
Ollama

The provider can be selected through configuration.
For example
ai.provider=openai
or:
ai.provider=gemini
or:
ai.provider=ollama
This provider abstraction was an important design decision.
I didn't want the entire application tightly coupled to a single AI vendor.

Step 4: Generate structured findings
The AI isn't simply asked:
"Review this code."
Instead, the review is structured around useful information.
A finding contains concepts such as:
Severity
Category
File
Location
Problem
Suggested Fix

For example:
Severity: HIGH

Category: SECURITY

File:
src/main/java/com/example/config/SecurityConfig.java
Problem:
CSRF protection is disabled while session cookies
are used for authentication.
Suggested Fix:
Enable CSRF protection or switch to stateless
authentication.
This makes the result much easier to consume in a dashboard or GitHub comment.
Step 5: Post the review back to GitHub
One of the things I wanted from the beginning was:
Don't make developers open another dashboard just to read the review.
So CodeGuard AI can post the generated review directly to the Pull Request.
The result looks something like:
🤖 CodeGuard AI Review

✅ SAFE TO MERGE

Quality score: 9/10
Risk: Low
Confidence: 95%

No issues found.

What's good:

Clean implementation
Backward-compatible configuration
Clear separation of concerns If problems are found, the review instead highlights them with severity and suggested fixes. The dashboard

The dashboard provides a second way to run and inspect reviews.

You can manually enter:

owner/repository
PR number

and run a review.

This is useful before setting up the webhook because you can test the entire pipeline manually:

GitHub
↓
Fetch PR
↓
Analyze diff
↓
AI
↓
Generate review
↓
Post comment

No webhook is required for the initial test.

Review history

I also wanted the application to remember previous reviews.

The dashboard therefore keeps review history containing information such as:

Repository
PR number
Review score
Risk
Number of findings
Files reviewed
Lines changed
Review timestamp

This makes it possible to see how a codebase is progressing over time.

For example:

Review #1 6/10 3 issues
Review #2 7/10 2 issues
Review #3 9/10 0 issues

The dashboard can also visualize review trends.

One interesting feature: merge recommendation

I added a simple high-level verdict to make the review easier to understand.

For example:

┌──────────────────────────────┐
│ ✅ SAFE TO MERGE │
└──────────────────────────────┘

Quality Score: 9/10
AI Confidence: 95%
Critical Issues: 0
Suggestions: 0

Or, when the PR has serious issues:

┌──────────────────────────────┐
│ ⚠️ REVIEW REQUIRED │
└──────────────────────────────┘

Quality Score: 6/10
Risk: Medium
Critical Issues: 1

This isn't intended to replace a team's merge policy.

It's simply a quick signal for the developer.

Why self-hosted?

This was probably the most important product decision.

There are already hosted AI code-review products.

So why build another one?

Because some developers and teams don't want their source code going through another hosted SaaS platform.

With a self-hosted architecture:

Your GitHub
↓
Your CodeGuard instance
↓
Your AI provider

You control the infrastructure and credentials.

You can use:

OpenAI
Google Gemini
Ollama

And with Ollama, you can even run a local model.

The application doesn't require a CodeGuard-managed AI subscription.

Private repositories

CodeGuard AI isn't limited to public repositories.

The GitHub Personal Access Token used by the application determines which repositories it can access.

For example, a fine-grained token can be configured with the required permissions for the repositories that need to be reviewed.

This makes the same architecture usable for private projects and internal repositories.

Handling large Pull Requests

There is an obvious problem with AI-based code review:

What happens when a PR contains hundreds of files?

Sending an enormous diff to an AI model isn't practical.

CodeGuard AI therefore truncates large per-file diffs to keep the review within a reasonable token budget.

That means extremely large PRs may receive a partial review rather than causing the entire review process to fail.

This is one area I want to improve further.

What I deliberately didn't build yet

One thing I intentionally kept out of the first version is inline GitHub review comments.

Currently, CodeGuard AI posts a structured summary comment to the Pull Request.

Inline comments are more complicated because GitHub's review API requires calculating the appropriate diff positions.

So a future version could potentially do this:

src/main/java/UserService.java:42

🔴 HIGH

Potential authorization bypass.

Suggested fix:
Verify that the authenticated user owns
the requested resource before updating it.

That would make the tool much closer to a traditional human code review.

What I learned building it

The interesting part of this project wasn't actually calling an AI API.

That part is relatively straightforward.

The harder part is building the system around it.

A useful AI developer tool needs:

Reliable input

The model is only as useful as the code context you provide.

Structured output

A giant paragraph isn't particularly useful during a code review.

Provider abstraction

AI providers change quickly, so coupling the application to one provider isn't ideal.

Security

GitHub tokens, webhook secrets and AI API keys need to be handled carefully.

Failure handling

GitHub API failures, AI timeouts, invalid model responses and huge diffs all need to be considered.

A useful UI

Developers shouldn't have to dig through logs to understand what happened.
**
Current feature set**

The current version includes:

✅ GitHub Pull Request integration
✅ GitHub webhook support
✅ HMAC webhook verification
✅ Manual PR review
✅ AI-powered bug detection
✅ Security analysis
✅ Performance analysis
✅ Best-practice analysis
✅ Risk assessment
✅ Quality scoring
✅ AI confidence score
✅ Structured findings
✅ Suggested fixes
✅ GitHub review comments
✅ Review history
✅ Review trend visualization
✅ Markdown export
✅ PDF export
✅ OpenAI support
✅ Google Gemini support
✅ Ollama support
✅ Light/dark mode
✅ Self-hosted deployment

What's next?
There are several things I want to explore next.

Inline review comments

Instead of one summary comment, report findings directly on changed lines.

GitHub App support

The current version uses a Personal Access Token because it keeps the self-hosted setup simple.

A GitHub App would be a better architecture for multi-repository and multi-organization deployments.

Better repository configuration

Allow teams to define their own review rules.

For example:

security:
enabled: true

performance:
enabled: true

tests:
required: true

style:
enabled: false
Custom review prompts

Different teams care about different things.

A Spring Boot backend team may care heavily about:

N+1 queries
transaction boundaries
authentication
authorization
database indexes
API design

A frontend team may care about completely different things.

CI/CD integration

Another direction is running CodeGuard AI directly inside CI pipelines.

Final thoughts

I started CodeGuard AI with a simple idea:

AI shouldn't only help us write code. It can also help us question the code we just wrote.

The goal isn't to replace experienced engineers.

A good human reviewer can understand business context, architecture and trade-offs that an AI model may completely miss.

But an AI reviewer can be a useful first layer.

It can catch obvious issues.

It can point out suspicious code.

It can identify things worth discussing.

And it can do that before the human reviewer spends 30 minutes reconstructing what changed.

That's what I'm trying to build with CodeGuard AI.

Try it / explore the project

CodeGuard AI is built as a self-hosted Spring Boot application with the complete source code included.

If you want to run your own instance, you can configure it with your own OpenAI, Gemini, or Ollama setup.

CodeGuard AI — Self-Hosted GitHub AI Code Reviewer

# CodeGuard AI### Self-hosted AI code review for GitHub Pull Requests — built with Spring Boot.CodeGuard AI automatically reviews your GitHub Pull Requests using AI and identifies potential bugs, security issues, performance problems, and best-practice violations.Instead of paying for another monthly SaaS subscription, run CodeGuard AI on your own infrastructure using your own AI provider credentials.## 🚀 What You Get- 🤖 AI-powered GitHub Pull Request reviews- 🐛 Bug and logic issue detection- 🔐 Security issue detection- ⚡ Performance analysis- ✅ Best-practice checks- 📊 Quality score and risk assessment- 🎯 AI confidence score- 💬 Automatic review comments posted directly to GitHub- 🔄 Automatic reviews through GitHub webhooks- 📝 Manual PR review from the dashboard- 📚 Review history- 📈 Review trend tracking- 📄 Export reviews to Markdown and PDF- 🌙 Light and dark mode- 🔌 Multiple AI providers## 🔌 Supported AI ProvidersChoose the provider that works best for you:- OpenAI- Google Gemini- Ollama (local AI)Your AI provider can be changed through configuration without changing the core review architecture.## 🛠️ Technology Stack- Java 17+- Spring Boot- Spring Security- GitHub REST API- AI provider integrations- REST APIs- HTML / CSS / Vanilla JavaScript- Maven## 🔐 Self-Hosted & PrivateCodeGuard AI is designed to run in your own environment.Your GitHub credentials and AI API keys stay under your control.It can be used with repositories your GitHub token has permission to access, including private repositories when the token has the required permissions.## 📦 What's IncludedThe download includes:- Complete Spring Boot source code- Installation Guide- User Manual- API Documentation- Architecture Diagram- Database Schema- SQL database script- Postman Collection- Environment Configuration Guide- Sample Repository Guide- Changelog- License## ⚡ How It WorksGitHub Pull Request↓GitHub Webhook↓CodeGuard AI↓Fetch PR Changes↓AI Analysis↓Security / Bug / Performance Review↓Quality & Risk Assessment↓GitHub Review Comment## 🎯 Who Is This For?CodeGuard AI is ideal for:- Java / Spring Boot developers- Backend developers- Solo developers- Small development teams- Freelancers- Developers building internal developer tools- Anyone who wants an AI-assisted code review system they can run themselves## 💡 Why Buy the Source Code?This isn't just a demo UI.You get the complete backend implementation and supporting documentation so you can:- Run it locally- Deploy it on your own server- Customize the review logic- Change the AI provider- Modify the dashboard- Extend the GitHub integration- Build additional features on top of it## ⚠️ Requirements- Java 17+- Maven 3.8+- GitHub Personal Access Token- OpenAI, Gemini, or Ollama- A GitHub repository/PR accessible by your configured tokenDetailed setup instructions are included in the download.---### Build on top of it. Customize it. Self-host it.One-time purchase. No CodeGuard AI subscription required.

<div class="color-secondary fs-s flex items-center"> <img alt="favicon" class="c-embed__favicon m-0 mr-2 radius-0" src="https://public-files.gumroad.com/v56byb8cpoecdju06otk8bb7y66g" loading="lazy" /> swarnalata25.gumroad.com </div> </div> </div>

I'd especially love feedback on:

What should an AI code reviewer detect?
Would you use a self-hosted reviewer?
Which AI provider would you prefer?
Are inline GitHub comments more useful than a single summary?
What would make this useful for your team?

Thanks for reading! 🚀

I Built an AI Resume Analyzer in Spring Boot Instead of Another CRUD Project

JavaCoder7 — Sat, 08 Aug 2026 05:17:44 +0000

I Built an AI Resume Analyzer in Spring Boot Instead of Another CRUD Project

After finishing my previous AI Support Widget project, I wanted to build something that solved a different real-world problem.

Most developers have built a Todo app, an Employee Management System, or another CRUD project.

I wanted to build something people could actually use.

So I spent the last few weeks building an AI-powered Resume Analyzer using Spring Boot.

## The idea

Whenever I apply for jobs, I usually wonder:

Is my resume ATS friendly?
Which keywords am I missing?
Which resume version is better?
How can I improve my chances before applying?

There are plenty of online tools, but I wanted a self-hosted application that I fully controlled.

## Tech Stack

Java 17
Spring Boot 3
Spring Security
Spring Data JPA
Thymeleaf
MySQL
OpenAI API

## What it does

Instead of simply uploading a resume and getting one score, the application provides multiple AI-powered features.

### ATS Resume Analysis

The application analyzes a resume against a job description and generates:

ATS score
Resume strengths
Weaknesses
Missing keywords
Resume improvement suggestions

### AI Resume Rewrite

Instead of manually editing bullet points, the application rewrites the resume while preserving the candidate's actual experience.

The goal isn't to invent achievements.

It's to improve clarity and ATS readability.

### Resume Comparison

One feature I personally found useful was comparing two versions of the same resume.

Sometimes changing only a few bullet points increased the ATS score significantly.

### Resume Versioning

Rather than replacing previous analyses, every analysis is saved.

This allows users to compare improvements over time.

### AI Interview Preparation

After analyzing the resume, the application can generate interview questions based on:

Resume
Skills
Experience
Job Description

This makes the tool useful even after the ATS analysis is complete.

### Dashboard

The application also includes a dashboard showing:

Previous analyses
Average ATS score
Highest score
Resume history
Trends over time

## Challenges

One interesting challenge was balancing AI output with predictable scoring.

Large Language Models are creative, but ATS scoring should feel consistent.

I ended up combining deterministic scoring with AI-generated explanations so that users receive both a measurable score and useful feedback.

## What I intentionally didn't build

One thing I deliberately left out was payment gateway integration.

The application already supports usage limits and user plans, but checkout integration (Stripe/Razorpay) is something I'd rather let developers integrate based on their own business needs.

## Lessons Learned

Building AI products isn't just about calling an LLM.

Most of the work is actually:

Prompt engineering
Designing good workflows
Managing user data
Producing useful outputs
Creating a smooth user experience

Those parts took far longer than integrating the OpenAI API itself.

## Final Thoughts

This project taught me much more than another CRUD application ever could.

I'm now building a collection of AI-powered Spring Boot applications focused on solving real business problems instead of tutorial-style examples.

If you're building AI products with Java or Spring Boot, I'd love to hear what you're working on.

### Source Code

I packaged this project as a complete Spring Boot source code product with documentation, database scripts, API collection, installation guide, and production-ready architecture.

If you'd like to build on top of it instead of starting from scratch, you can check it out here:

👉 https://swarnalata25.gumroad.com/l/resumeiq-ai

I'd also love your feedback on what features you'd add next.

I Built a Self-Hosted AI Support Widget with Spring Boot (No Monthly SaaS Fees)

JavaCoder7 — Fri, 07 Aug 2026 15:19:16 +0000

Every new SaaS seems to embed ChatGPT these days.

Most AI support solutions rely on third-party platforms, monthly subscriptions, and vendor lock-in. While they're great products, I wanted something different.

I wanted complete ownership.

I wanted to deploy everything on my own server, use my own OpenAI API key, customize every part of the experience, and embed the widget into any website with a single script tag.

So I built my own self-hosted AI support widget using Spring Boot and Vanilla JavaScript.

Why I Built It

When building small products and websites, I realized that customer support quickly becomes a problem.

Users have questions about pricing, features, returns, or simply get stuck.

Most developers solve this by integrating services like Intercom, Crisp, or Tidio.

Those platforms are excellent, but they also mean:

Monthly subscription costs
Vendor lock-in
Customer conversations stored on third-party platforms
Limited customization
Another external dependency

I wanted something that developers could completely own.

The Goal

The goal was simple.

Build an AI-powered customer support widget that developers can deploy on their own server and integrate into any website in less than a minute.

The widget should:

Answer customer questions using AI
Learn from a custom knowledge base
Match the company's branding
Store conversation history
Allow human handoff
Be easy to deploy
Require only one script tag to embed

Technology Stack
Java 17
Spring Boot 3
Spring Security
Spring Data JPA
Thymeleaf
Vanilla JavaScript
H2 Database (MySQL supported)
OpenAI API

Architecture

The overall architecture is intentionally simple.
Visitor
│
▼
AI Chat Widget
(Vanilla JavaScript)
│
▼
Spring Boot REST API
│
▼
OpenAI API
│
▼
Database
(H2 / MySQL)
Keeping the frontend framework-free makes the widget lightweight and easy to embed into virtually any website.

One-Line Integration

Adding the widget to a website only requires a single script.
<script src="/widget/widget.js" data-api-base=""></script>
No React.

No Vue.

No npm packages.

Just one script.

Features I Built

The project includes:

✅ AI-powered customer support

✅ Spring Boot backend

✅ Secure admin authentication

✅ Custom knowledge base

✅ Conversation history

✅ Brand customization

✅ Human handoff with email notification

✅ OpenAI API configuration

✅ H2 support with MySQL production configuration

✅ One-line website integration

The Admin Dashboard

Instead of hardcoding prompts inside the application, administrators can configure everything from the dashboard.

They can update:

Company name
Greeting message
Brand color
OpenAI API key
Knowledge base
Notification email

Changes take effect immediately without restarting the application.

Why I Didn't Use RAG

One interesting design decision was intentionally not implementing Retrieval-Augmented Generation (RAG).

Instead, administrators maintain a simple knowledge base that is included in the AI's system prompt.

For small and medium-sized businesses, this approach keeps deployment extremely simple while still delivering accurate responses.

If the project grows, adding vector search later is straightforward.

Sometimes simplicity is the better engineering decision.

Human Handoff

AI can't answer everything.

Whenever visitors need human assistance, they can submit their email.

The system:

Stores the lead in the database
Sends an email notification (if SMTP is configured)
Lets administrators continue the conversation manually

This ensures users never hit a dead end.

Lessons Learned

Building the OpenAI integration wasn't actually the hardest part.

The real engineering challenges were:

Designing a flexible architecture
Authentication and authorization
Conversation persistence
Prompt management
Making the widget framework-independent
Creating an admin experience that non-developers can use

Those pieces ended up being much more interesting than simply calling an AI API.

Things I Intentionally Left Out

Every project needs boundaries.

I intentionally skipped:

Multi-tenancy
Stripe subscriptions
Vector databases
Multiple AI providers
Complex AI orchestration

The goal was to build a clean, understandable codebase that developers can deploy quickly and extend however they like.

What's Next?

I'm considering adding:

Streaming AI responses
Multiple AI providers
RAG support
File uploads
Conversation analytics
Multi-tenant architecture

Final Thoughts

This project reminded me that building AI products isn't just about connecting to an LLM.

The real engineering happens around it:

authentication
configuration
deployment
usability
persistence
developer experience

Those are the parts that transform an API call into a real product.

I'd love to hear how you're building AI applications with Java or Spring Boot, and what features you would add to a self-hosted support widget.

Interested in the Full Project?

I built this as a complete, production-ready Spring Boot project. If you'd like the full source code, setup guide, and deployment instructions, you can find it here:

👉(https://swarnalata25.gumroad.com/l/supportai-springboot)

I'm also building more self-hosted Java & Spring Boot products, so feedback and suggestions are always welcome.