Skip to content

MTA-5378 Developer Lightspeed Introduction #172

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
+111 −0
Open

MTA-5378 Developer Lightspeed Introduction #172

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
de83b5f
MTA-5378 - Developer Lightspeed Introduction
Jul 31, 2025
8e20d4d
Modified the introduction based on feedback
Sep 2, 2025
dc8124a
Modified the introduction
Sep 3, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions docs/developer-lightspeed-guide/master-docinfo.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,11 @@
<title>Developer Lightspeed Guide</title>
<productname>{DocInfoProductName}</productname>
<productnumber>{DocInfoProductNumber}</productnumber>
<subtitle>Using the {ProductName} Developer Lightspeed to modernize your applications</subtitle>
<abstract>
<para>you can use {ProductFullName} Developer Lightspeed for application modernization in your organization by running Artificial Intelligence-driven static code analysis for Java applications.</para>
</abstract>
<authorgroup>
<orgname>Red Hat Customer Content Services</orgname>
</authorgroup>
<xi:include href="Common_Content/Legal_Notice.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
20 changes: 20 additions & 0 deletions docs/developer-lightspeed-guide/master.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,20 @@
:mta:
include::topics/templates/document-attributes.adoc[]
:_mod-docs-content-type: ASSEMBLY
[id="mta-developer-lightspeed"]
= MTA Developer Lightspeed Guide

:toc:
:toclevels: 4
:numbered:
:imagesdir: topics/images
:context: mta-developer-lightspeed
:mta-developer-lightspeed:

//Inclusive language statement
include::topics/making-open-source-more-inclusive.adoc[]


include::topics/developer-lightspeed/con_intro-to-developer-lightspeed.adoc[leveloffset=+1]

:!mta-developer-lightspeed:
1 change: 1 addition & 0 deletions docs/developer-lightspeed-guide/topics
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
../topics/
44 changes: 44 additions & 0 deletions docs/topics/developer-lightspeed/con_intro-to-developer-lightspeed.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,44 @@
// Module included in the following assemblies:
//
// * docs/cli-guide/master.adoc

:_content-type: CONCEPT
[id="intro-to-the-developer-lightspeed_{context}"]
= Introduction to the {ProductShortName} Developer Lightspeed

Starting from 8.0.0, you can use {ProductFullName} Developer Lightspeed for application modernization in your organization by running Artificial Intelligence-driven static code analysis for Java applications. Developer Lightspeed gains context for an analysis from historical changes to source code through previous analysis (called solved examples) and the description of issues available in both default and custom rule sets. Thus, when you deploy Developer Lightspeed for analyzing your entire application portfolio, it enables you to be consistent with the common fixes you need to make in the source code of any Java application. It also enables you to control the analysis through manual reviews of the suggested AI fixes by accepting or rejecting the changes while reducing the overall time and effort required to prepare your application for migration.
Copy link
Member

@jwmatthews jwmatthews Aug 29, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It may be worth to reword this a little, I'll share more info for you to decide what is best path to take. Please don't feel compelled to use all I share below, I'm just trying to help to give a bit more info so you ultimately can decide what you think is best to include.

Developer Lightspeed gains context for an analysis from historical changes to source code through previous analysis (called solved examples) and the description of issues available in both default and custom rule sets.

It may help if I provide a bit more info of what the "solved example" is.

The "solved examples", are not so much previous analysis info, that is related, but there is more.

The solved example contains how a previous analysis issue was "solved" it includes:

  • Before Code
  • Updated Code (what fixed the issue and was ultimately accepted by the Migrator)
  • Hint ... this hint is the big piece of what is so helpful. This hint is calculated from a LLM by working with the LLM to tell them 1) the analysis problem, 2) the before code 3) the modified code, then asking the LLM to extract out the pattern/instructions of how to fix this in the future, we call that the "hint".

The key pieces I would emphasize are:

  • We provide 2400+ analysis rules with the product for various Java technologies AND this is extensible for custom frameworks or new technologies via custom rules

  • Each analysis rule allows capturing additional contextual information, such as guidance to the LLM of how to resolve the specific problem, we call this a "hint". This is an extensible/easy mechanism for Migrators to complement the migration information by quickly adding guidance to the LLM of how to address any analysis issue they identify. (This is a RAG pattern implemented via Analysis issues as the similiarity search opposed to the more popular vector search).

  • The Solution Server, augments the above "hint" which a rules author can associate to an Analysis Rule. As Migrators use MTA for migrations and solve difficult problems, (the value comes in when the Migrator uses MTA for a fix, the fix was not ideal, Migrator manually modifies the fix to correct it, then accepts it), this info is recorded and processed. MTA works with a LLM to produce a Hint based on what the Migrator corrected, that then improves the contextual information with an improved Hint.


[id="how-developerlightspped-works_{context}"]
== How does Developer Lightspeed work

The main components of Developer Lightspeed are the large language model (LLM), a Visual Studio Code (VS Code) extension, and the solution server.

When you initiate an analysis, Developer Lightspeed creates a context to generate a hint or a prompt that is shared with your LLM. The context is drawn from profile configuration that contains the target technology or the source technology that you configure for migration. Based on the source or target configuration, Developer Lightspeed checks the associated rule set containing rules that describe what needs to be fixed as the first input for the LLM prompt. As the second input, Developer Lightspeed uses the solved examples that are stored in the solution server from previous analyses in which the source code changed after applying the fixes.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When you initiate an analysis, Developer Lightspeed creates a context to generate a hint or a prompt that is shared with your LLM.

May want to rephrase this, we do create context and a prompt and work with a LLM, but we do that only when a code suggestion is requested, we do not do that at time of analysis. Analysis info is an input to this context and passed into the prompt.

Will share some more info to help clarify the technical pieces.

Analysis is purely static code analysis, there is no LLM interaction for Analysis.

Think of the analysis as the first step that scans the code to "understand" what the potential concerns are, then it produces a list of potential concerns. We call each of those concerns a "violation".

The user will view those concerns and may elect to "fix" one, if they decide to ask MTA to fix it, then we move to next step of collecting "context" related to the concern and working with a LLM to request a code suggestion.

The context we pass includes several things...

  • The target technology the analysis ran against, serves as an "aim" of what the LLM will try to move our code to
  • Description of the Analysis Issue seen
  • [Optional] Extra information included in the Rule associated with the Analysis Issue, this often serves as extra guidance, or a hint to the LLM of how to fix the problem. This is info the Rules Author may or may not include for each Rule
  • [Optional] Hint produced from the solution server, potential if this is a problem that has been in past and solved, the solution server may have been able to work with a solved version of the code and extract a pattern (or a hint) to help future examples be solved in a similar way by the LLM
  • [Optional] Additional data from "tools" integrated into the IDE, i.e. "vscode diagnostic" information. The agentic workflows have the capability to use a few additional tools to detect problems and attempt to fix.


The Solution Server uses Model Context Protocol (MCP) to act as an institutional memory that stores changes to source codes from analyzing all the applications in your organization. This helps you to leverage the recurring patterns of solutions for issues that are repeated in many applications. Solution Server reuses these past solutions through fix suggestions in later migrations, leading to faster, more reliable code changes as you migrate applications in different migration waves. At the organizational level, the solution server can also help Developer Lightspeed tackle a new issue given how a similar issue was resolved in a previous analysis.

The hint or the prompt generated by Developer Lightspeed is the well-defined context for identifying issues that allows the LLM to "reason" and generate the fix suggestions. This mechanism helps to overcome the limited context size in LLMs that prevents them from analyzing the entire source code of an application. You can review the suggested change and accept or reject the update to the code per issue or for all the issues.

Developer Lightspeed supports different goals of analysis through the three modes: the Agentic AI, the Retrieval Augmented Geeneration (RAG) solution delivered by the solution server, and the demo mode.
Copy link
Member

@jwmatthews jwmatthews Aug 29, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: "Geeneration" near end in Retrieval Augmented Geeneration

I wouldn't think of this as different goals of analysis through three modes, I don't think that is accurate.

I would not document anything of the "demo mode" that is not something an end user would be expected to use.

I would consider that MTA DLS is built on the fundamental concept of Static Analysis and RAG. The RAG pattern is implemented relying on static analysis to identify similar problems and provide relevant additional info per identified issue. After we obtain an initial code suggestion from the LLM, there is an optional behavior where we can detect "follow on" problems that occur after the suggestion is applied, this uses the agentic workflows and additional tools to attempt to "understand" and "fix" potential problems.

In terms of goals, I would think of the goal tied to the end users desire for moving to a "new target technology", for example Java EE to Quarkus, Spring Boot 2 to Spring Boot 3... this is the "big need" the end user has and why they use MTA, they want to move a legacy application to a newer piece of technology.

To accomplish what they want to do they can use MTA to perform an analysis to undercover potential areas of concern a Migrator should consider. This allows an engineer who knows say Spring Boot 2 and 3 to quickly get an understanding of an application they haven't worked with before and quickly see the big areas they need to look at to accomplish their goal, (maybe for example to upgrade the app from Spring Boot 2 to 3).

Copy link
Collaborator Author

@Pkylas007 Pkylas007 Sep 2, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi John,

I'm sorry to say that if the demo mode is presented in the configuration of Developer Lightspeed, it has to be explained in the documentation according to doc practices. Please let us discuss this further.


If you enable the agentic AI mode, Developer Lightspeed streams an automated analysis of the code in a loop until all issues are resolved and changes the code with the updates. In the initial run, the AI agent:

* Plans the context to define the issues.
* Chooses a suitable sub agent for the analysis task.
Works with the LLM to generate fix suggestions. The reasoning transcript and files to be changed are displayed to the user.
* Applies the changes to the code once the user approves the updates.

If you accept that the agentic AI must continue to make changes, it compiles the code and runs a partial analysis. In this phase, the agentic AI can detect diagnostic issues (if any) generated by tools that you installed in the VS Code IDE. You can accept the agentic AI's suggestion to address these diagnostic issues too. After every phase of applying changes to the code, the agentic AI runs another round of automated analysis depending on your acceptance, until it has run through all the files in your project and resolved the issues in the code. Agentic AI generates a new file in each round when it applies the suggestions in the code. The time taken by the agentic AI to complete several rounds of analysis depends on the size of the application, the number of issues, and the complexity of the code.

The RAG solution, delivered by the Solution Server, is based on solved examples or past analysis to fresolve new issues or similar issues that are found while analyzing the source code. This type of analysis is not iterative. The Solution Server analysis generates a diff of the updated portions of the code and the original source code for a manual review. In such an analysis, the user has more control over the changes that must be applied to the code.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: "fresolve"

Note that we use RAG for more than just solution server.
The basic concept of RAG is fundamental to all we are doing with MTA DLS.

The Solution Server uses past analysis AND accepted/modified migration problems from prior completed migrations. Just analysis would be incomplete.

I think this paragraph would benefit from rewording, it's not quite capturing what the solution server is.

The solution server is not really performing "analysis", its more the solution server is forming a big "memory pool" for the entire organization. As Migrators use MTA to migrate legacy applications they will be faced with analysis issues that MTA struggles to solve automatically. A Migrator will need to manually modify the suggested code changes to "correct" them, this interaction is recorded and saved in the Solution Server... it's updating the "memory" of how a given issue was fixed. Later, there is a post processing stage where the Solution Server will look at the data it's collected and it will work with a LLM to ask it for this given problem we struggled on, how would I improve the Hint so next time we see it we have better contextual info so MTA is more likely to be able to fix the problem in future.


You can consider using the demo mode for running Developer Lightspeed when you need to perform analysis but have a limited network connection for Developer Lightspeed to sync with the LLM. The demo mode stores the input data as a hash and past LLM calls in a cache. The cache is stored in a chosen location in the your file system for later use. The hash of the inputs is used to determine which LLM call must be used in the demo mode. After you enable the demo mode and configure the path to your cached LLM calls in the Developer Lightspeed settings, you can rerun an analysis for the same set of files using the responses to a previous LLM call.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be removed. Demo mode is only intended to aid folks running a demo that was previously recorded to limit LLM communication issues in a conference setting or similar, limited network connectivity.

I wouldn't document this setting for downstream.

Copy link
Collaborator Author

@Pkylas007 Pkylas007 Sep 2, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shall we please discuss the demo mode? If it's hidden in the UI, then I'll be able to remove it in the documentation. The doc best practices require us to document what is visible and usable to the user.


[id="benefits-using-developer-lightspeed_{context}"]
== Benefits of using Developer Lightspeed

* *Model agnostic* - Developer Lightspeed follows a "Bring Your Own Model" approach, allowing your organization to use a preferred LLM.
* *Iterative refinement* - Developer Lightspeed can include an agent that iterates through the source code to run a series of automated analyses that resolves both the code base and diagnostic issues.
* *Contextual code generation* - By leveraging AI for static code analysis, Developer Lightspeed breaks down complex problems into more manageable ones, providing the LLM with focused context to generate meaningful results. This helps overcome the limited context size of LLMs when dealing with large codebases.
* *No fine tuning* - You also do not need to fine tune your model with a suitable data set for analysis which leaves you free to use and switch LLM models to respond to your requirements.
* *Learning and Improvement* - As more parts of a codebase are migrated with Developer Lightspeed, it can use RAG to learn from the available data and provide better recommendations in subsequent application analysis.