chapter two

2 Building a legacy modernization framework powered by Vibe Engineering

 

This chapter covers

  • Avoiding time-consuming manual habits and mistakes
  • Using prompts for understanding a huge legacy codebase
  • Trade-off between LLM-generated code size and humans’ ability to understand it.
  • Creating a migration framework using the Vibe Engineering techniques

Oftentimes, when approaching a legacy or any unknown codebase, we don’t know where to start looking. What is more challenging, such a codebase may require migration to a new technology stack to reduce the technical debt, improve the performance, or ease the future maintainability.

Before the LLM era, migrating codebases to other technology stacks was a considerable effort requiring many people with knowledge of the older technology in which the application is written, the new technology that we are targeting, domain experts, and many more people besides. And, in reality, many people who authored legacy applications may no longer be at our company, so their knowledge is lost or buried deep in the codebase.

How do we approach migration under such circumstances?

To start, LLMs are great for analyzing text (thus code), making it easier to extract implicit knowledge from code. From that point, as we get more insights into the application, we will be able to migrate the application in small incremental steps, making sure that we are heading in the right direction, all by using LLMs only (with some code reading).

2.1 Context and application

2.2 Pre-analysis of the application

2.2.1 Extracting the bigger picture

2.2.2 Deployment models

2.2.3 Decisions and assumptions

2.3 Trade-offs: copying the code in place vs a new repo

2.3.1 A hybrid approach

2.3.2 Procedure for code increments

2.4 Testing

2.4.1 Generate missing tests

2.4.2 Migrate tightly coupled tests from the old framework

2.4.3 Mistake of missing steps in the process

2.5 Production code migration trade-offs

2.5.1 Applying a minimal set of changes

2.6 Cleanup stage

2.7 UI layer migration

2.7.1 Taking a step back when AI tools did too much

2.7.2 Trade-off between LLM inferring too much vs too little

2.7.3 Fixing bugs with AI tools

2.8 Cleanup - the 2nd stage

2.8.1 Mistake of overusing LLMs over static code refactoring tools

2.9 Adding documentation

2.10 Migrating the persistence layer

2.10.1 Adding Mongo support

2.10.2 Improving tests not to require a manual step

2.11 Conclude with merge pull requests

2.12 Summary