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.

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.

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).

+1, read through what you have for enabling the agent and looks good

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.

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.

+1, read through this section and the benefits look good.