inflearn logo

[Part 1] AI Application Control Techniques Through Spring AI Case Studies: Managing Cost, Quality, Risk, and Flow

If you’ve implemented AI features with Spring AI, it’s time to think about how to observe how AI behaves and control its costs, quality, risks, and workflows. Simply calling an LLM, connecting RAG, and receiving structured responses isn’t enough to make an AI application reliable. In a real application, you also need to consider how each request was handled, how much context you’re providing to the model, how much you can trust the generated results, and how to limit risky recommendations. In this course, we use a Spring AI–based Incident Responder application as a consistent example. Starting from a baseline that works but isn’t yet sufficiently controlled, we observe actual execution results, identify problems, add control points to the code, and compare the results before and after the improvements. Along the way, you’ll learn more than just how to use another AI feature. You’ll develop a design perspective on how to observe, constrain, and validate probabilistic AI within Java/Spring applications.

3 learners are taking this course

Level Basic

Course period Unlimited

Java
Java
Spring Boot
Spring Boot
observability
observability
AI
AI
LLM
LLM
Java
Java
Spring Boot
Spring Boot
observability
observability
AI
AI
LLM
LLM

What you will gain after the course

  • Track AI request traces and spans to analyze the actual request flow, including model calls, prompts, context, token usage, and latency.

  • You can route requests to different AI processing paths based on their characteristics and control how the application uses models.

  • You can control context costs by directly limiting the size of runbooks, past incident records, and prompts passed to the LLM.

  • You can reliably handle structured AI responses by validating their basic contract and applying retries and fallbacks when they fail.

  • Beyond DTO mapping, you can evaluate and improve the evidential consistency, specificity, overconfidence, and appropriateness of actions in AI responses.

  • You can classify the risk level of AI-generated recommendations and apply policies to prevent dangerous results from being delivered as-is.

  • You can identify uncontrolled points in a working AI application and design appropriate control points across its workflows, costs, quality, and risks.

AI application, is it enough for it to simply work?

We called an LLM with Spring AI and got the response we wanted.

The application also works normally.

But can we say that the AI application is well controlled just because it returns a valid response?

It may be difficult to know exactly what path a request took, or more information than necessary may be passed to the LLM. Even if a response is generated in the correct format, whether its content is accurate and appropriate is a separate matter. It may also produce recommendations that are technically plausible but risky to pass on as-is.

When AI that operates probabilistically is introduced into existing Java/Spring applications, we need to consider not only "Is it working correctly?" but also "What should we monitor, what should we constrain, and which results should we validate?".

This lecture begins with precisely these questions.

An AI application calls an LLM while passing through multiple data sources and services to process a single request, then delivers the result back as the application’s response.

The problem is that the fact that this process completed successfully does not tell us whether the process and its results were appropriate.

We may not be able to see the actual path a request took, and the LLM may receive more runbooks and past incident history than necessary. Even if the response conforms to the required JSON structure, that does not guarantee the accuracy or quality of its content, and it may produce recommendations that sound plausible but are risky to pass along as-is.

In other words, the problem isn’t that the LLM doesn’t work.

The fact is that there are still points throughout the application that we have yet to observe, constrain, or validate.

Then how should we identify and control these points?

We called an LLM with Spring AI, connected the necessary information using RAG, and generated responses in the desired format.

The application is working normally.

But working correctly is not the same as being under control.

If you can’t see how the request actually flowed, it can be difficult to trace the cause when something goes wrong.

If more information than necessary is continually sent to the model, costs and processing time may increase unnecessarily.

Even if a response is generated in the desired format, that doesn’t guarantee its content is trustworthy.

Even a technically plausible recommendation may be too risky to pass along as-is.

This course starts right here.

Rather than adding another AI feature, we’ll identify what to observe, constrain, and validate within an AI application that’s already running.

We develop a single Incident Responder throughout the course.

This course does not create a new example for every concept.

The course uses a single Incident Responder as its case study, continually evolving the same application as the course progresses.

Incident Responder is a Spring AI application that takes in operational incident information, gathers relevant runbooks, historical incident records, and escalation policies, then uses AI to analyze the incident and potential causes and recommend priority response actions.

We don’t start by showing an application that’s perfectly controlled.

The baseline that serves as the starting point of the course is not badly written code, but an application that works normally yet is not sufficiently controlled.

We run real requests against this baseline, identify problems, and then add the necessary control points one by one from the perspectives of flow, cost, quality, and risk. Then we run the same requests again and see what has changed.

We follow, from start to finish, how a single application evolves into a more reliable system by repeatedly identifying and controlling problems.

This course does not proceed by listing Spring AI features one by one and teaching you how to use them.

First, run the working baseline and see what problems actually arise.

When a problem arises, find the point in the code that needs to be controlled, then observe the execution results to understand why it needs improvement.

Only then do the techniques and patterns needed to solve the problem come into play.

Techniques such as Routing, Observability, Context Budget, Validation, and Evaluator–Optimizer are not learning goals in themselves.

First, identify “What problem does this technology solve, and what part of the application is it needed to control?” before applying it to the code.

Then we run the same request again and compare the results before and after the improvement.

First identify the problem, choose the necessary technique, and verify the change through actual execution results.

This is how you’ll learn in this course.

Solve four control problems hands-on.

When something goes wrong in an AI application, it’s hard to find the cause by looking only at the final response.

In this course, we connect observability and use the trace · span · event structure to see which services and model calls a single incident request passed through.

In the actual Langfuse Trace screen, you’ll examine the request flow, the time taken at each step, model calls, token usage, latency, and errors firsthand. Then you’ll apply Routing so that the appropriate path is selected based on the request’s characteristics.

First make the flow visible, then control it.

To control LLM costs, you shouldn’t stop at checking how many tokens were used.

You need to decide how much information the application is allowed to pass to the LLM.

In this lesson, we control the final prompt size by limiting the number and length of runbooks and past incident histories, removing duplicates, and applying a context budget based on severity.

Then rerun the same request to observe token usage and compare the results before and after the improvements.

From observing costs to controlling the Context that generates them.

Just because an LLM response has been successfully mapped to a DTO doesn’t mean its contents can be trusted right away.

First, validate the basic contract, including required values, list sizes, duplicates, and priority ranges. If there’s a problem, respond with a retry or fallback.

However, even correctly formatted responses can contain claims that lack sufficient evidence or are overly confident. So we go one step further, evaluating alignment with evidence, specificity, overconfidence, and action appropriateness, and improving responses through the Evaluator–Optimizer.

From validating the structure to validating the quality of the content.

Even a technically plausible AI recommendation may be too risky to pass directly on to the user.

In this course, we identify the risk level of recommendations, assign riskLevel, approvalRequired, riskReason, and apply application policies such as minimumSeverity and escalation policy.

The key is to separate the AI’s role of generating recommendations from the application’s role of controlling them according to policy.

This course does not cover actual Tool execution or automated remediation. It covers controlling AI recommendations according to policy and safely delivering them externally.

From blindly trusting AI recommendations to controlling them through application policies.

This course progressively develops a single Incident Responder based on Java 21 and Spring Boot, Spring AI.

To observe request flows, we use Micrometer, OpenTelemetry, and Langfuse, run the actual code, call the API, and verify the results firsthand.

Rather than learning a separate, complex environment from scratch, you will focus on designing and validating control points for AI applications in a development environment familiar to Java/Spring developers.

🔗 Download course materials

The hands-on code, guide documents, and glossary for each lesson are available in the GitHub repository.

📦 Course Materials GitHub Repository

All course materials are available in the Repository below.

Go to the GitHub Repository

Before starting the exercises, be sure to read the README.md in the Repository root first.
It contains essential information on using the course materials, including how the code for each lesson is organized and used.


⚙️ Langfuse Setup Guide

For learners using Langfuse for the first time, we provide a separate guide covering everything they need to prepare for the exercises, from signing up to setting up an API key.

Guide to Signing Up for Langfuse and Setting Up an API Key


📖 Course Glossary

If key terms that appear in the course, such as AI application control, Prompt, Context, Observability, Quality, and Risk, are unfamiliar, you can refer to the glossary as well.

View the course glossary

If you come across an unfamiliar term while following the course, use this as a reference to quickly check what the term means, rather than as documentation explaining how to implement it.

👉 Please check before getting started.

Prerequisites

This course is for Java/Spring developers.

Basic application development experience with Java and Spring Boot is required, and a basic understanding of REST APIs and JSON data processing is recommended.

You’ll also find the course easier to follow if you’re familiar with basic generative AI concepts such as LLMs, prompts, and tokens, as well as how to make basic LLM calls using Spring AI.


Development Environment

The hands-on exercises are based on Java 21, Spring Boot, and Spring AI.

The code is written primarily in IntelliJ IDEA, and actual incident requests are run and their results checked using tools such as Postman.


Topics Covered in the Course

By developing a single Incident Responder, you’ll learn how to observe and control the flow, cost, quality, and risk of AI applications.

Rather than simply learning how to use features, we focus on identifying areas that lack control, adding the necessary controls to the code, and then comparing the actual execution results.


What This Course Does Not Cover

The Incident Responder in this course is responsible for generating AI recommendations, identifying risks, applying policies, and delivering them in a safe format.

Therefore, this course does not cover tool execution on real systems, such as restarting, rolling back, or scaling; automatic recovery; or processes for executing actions after administrator approval or resuming interrupted workflows.

Recommended for
these people

Who is this course right for?

  • A Java/Spring developer who, after learning the basics of Spring AI, is considering how to design a real-world AI application.

  • A developer who has implemented LLM calls but struggles to fully understand the request flow and how model calls work.

  • Developers concerned about managing tokens and costs as the context passed to RAG and prompts grows.

  • Developers who feel that structured output alone isn’t enough to trust the quality of AI responses

  • Developers who want to control AI-generated recommendations and decisions through application code and policies

  • Developers who want to learn how to design AI applications that are operationally viable and reliable, beyond simply implementing AI features.

Need to know before starting?

  • Basic understanding of Java and object-oriented programming

  • Experience developing applications using Spring Boot

  • Understanding Spring’s dependency injection (DI) and basic application structure

  • A basic understanding of REST APIs and JSON data processing.

  • Understanding of basic generative AI concepts such as large language models (LLMs), prompts, and tokens.

  • Experience implementing basic LLM calls, such as ChatClient, using Spring AI.

Hello
This is Kevin

Career Verified

6,936

Learners

311

Reviews

133

Answers

4.8

Rating

12

Courses

  • Main languages or technologies: Java, Spring Framework, RxJava, Reactor, Spring WebFlux

  • Worked as a Backend Developer at Penta Security Inc. (From 2015.07 To 2022.01)

  • Worked as a Senior Educational Software Engineer (Backend) at Code States Co., Ltd. (https://www.codestates.com)
    (From 2022.03 To 2024.01.31)

- Working as a freelance developer and instructor (Since 2024.02)

- Author of

Hello, I'm Kevin. ^^

I am very happy to meet you all as an instructor here on Inflearn.

As is the case in any field, I believe that for a software developer in particular, constantly honing one's skills to keep up with ever-changing trends is the only way to survive. I am one of those developers who enjoys developing software while maintaining a mindset of always learning.

I started my courses on Inflearn with the hope that my knowledge and experience could be of even a little help to others.

I will continue to reach out to students through various courses that provide practical help. Thank you.

 

Questions and feedback are always welcome, so please feel free to reach out via email (it.village.host@gmail.com).

 

More

Curriculum

All

16 lectures ∙ (6hr 23min)

Course Materials:

Lecture resources
Published: 
Last updated: 

Reviews

Not enough reviews.
Please write a valuable review that helps everyone!

Kevin's other courses

Check out other courses by the instructor!

Similar courses

Explore other courses in the same field!

Limited time deal

$28.60

33%

$42.90