There has been a lot of conversation regarding the use of AI in software development. We all know that AI isn’t (yet) a total or even useful solution for many problems. But when used in the right contexts, it is in fact a game changer.
App Modernization in the New World
When it comes to software development (and many other areas of life), there are three statements that I come back to over and over again:
- Measure twice, cut once
- Right tool for the right job
- He/she who codes first, finishes last
When it comes to AI-assisted coding (I am trying not to use the “v” word) in the year 2026, we are still trying to get out of the crawling phase of the growth cycle. It leaves a lot to be desired, largely because it struggles for the same reason that AI often struggles: it is largely trained on data laying around the internet, and we all know how accurate that can be.
The Use Case
One of the classic requests that we get in our world is something like this:
Client comes to us with an application that needs some serious updating. Let’s say it was an application that had two tiers (front and back end) that used languages X and Y. We are asked to do the following:
- Convert the application to use newer languages B and C
- The application must use middleware to handle authentication
- The application must be subject to code scanning/analysis (for quality, security, etc) and automated testing on every commit to the main branch
The response to this would be an estimate of several weeks or months. But what if we could do all of this in MUCH less time. Over lunch? Keep reading to find out.
While AI is the wrong tool for so many jobs, it excels at reporting and planning. When it comes to the software delivery cycle, why not use it for those tasks?
In the graphic above, you’ll see we are starting with an existing application (if you aren’t starting with an existing application, the process is the same, but we will start with a hand-made “Application Spec”):
- We create an “App Analysis Instructions” prompt that contains all of the information that AI needs to scan the existing application. e.g. what to document, where to document it, etc. The document produced is the “Application Spec”. It is a good practice to have AI help with the creation of the “App Analysis Instruction” because in theory it knows what kind of directions are going to be most effective.
- There should also be companion specs that are going to be the same for all applications. For example, it would make sense to document company-wide coding standards, authentication options, database information, etc).
- When armed with the various spec documents, AI should have all of the information it needs to create the application in one pass.
- Regardless of who made the code (AI or a human), every commit to the application is scanned to ensure that it meets the company’s self-defined coding standards. These tools have been around for years – they can be used to put guardrails around the entire SDLC.
Wait – You Just Said that AI-Assisted Coding is Dangerous
It is, but that isn’t what we are doing here. In this scenario, we are letting AI do all of the coding.
So why will that work here but not when “vibe coding” (cringe)? When vibe coding, AI only has a portion of the application in focus when it offers to make a change for you. The change it makes might be completely valid in a limited scope, but it can be disastrous in a larger scope that is not currently in its memory.
When AI is armed with the full scope of the application, we are talking about a completely different world. It doesn’t need to put up with pesky humans (gulp), so it is free to makes its own plan and execute it. It knows the entire context because it made the plan. Will it still make mistakes? Absofreakinglutely. But the mistakes will be far more infrequent and easily caught by the guardrails that we will put in place.
Talk is Cheap – Let’s See This in Action
I created this entire process using smaller python applications, but it came time to try this on a production application. I was notified that one of our clients was interested in modernizing an application:
- The application had a frontend in React and a backend in .net
- There is a middleware that handled the authentication
- Multiple api endpoints
To better prove this concept, I used that code base. I also instructed AI to use python for the frontend and node / typescript on the backend.
Step 1: Document the Current Application to Create the Application Spec
Reminder: If you aren’t starting with an existing application, you can simply create the Application Spec by hand.
Why spend a day rooting through code when you can have AI document the application for you? AI really shines when it comes to tasks like these. As noted earlier, the key to AI assistance is to give it the right kind of instructions. As I repeated this process over and over, I found better ways to instruct AI. Of course, AI helped with this: when I finished making a new app, I would ask AI to make a document that summarized what went right and what went wrong. I then took that document and had AI update the instructions that were used earlier in the process.
Step 2: Review the Specs with AI
While I am generally very bullish on AI, repeated iterations of this processed showed me how fickle AI can be when it comes to being given directions. I took great care in providing a ton of detail for AI to use in creating the new app. Here is an interaction that I had with GitHub Copilot:
This felt like an interaction that I had with one of my teenagers. We had just created the beautiful spec docs in another session, and I asked AI to take a deep dive into those docs and to ask any questions before starting. It then proceeded to ask questions that were VERY clearly defined in the spec docs. I scolded it, and then we were good again:
[/vc_column_text][/vc_column][/vc_row] Step 3: Creating the Application At this point, you just tell AI to “go” and it does its thing: Step 4: Code Scanning I should probably take a small step back and talk about code quality analysis that every software dev shop should have in place but rarely do. There are products such as SonarQube that act as the center of the software development world. I won’t get too deep into the weeds here, but the gist of it is this: a company can define all kinds of rules and scans to guarantee that code created in their environment meets all of their requirements, including being secure. The activities and analysis performed during each commit This can all be set up so that failures for certain scans result in the application not being deployed. The advantages in using these tools is that they are centrally defined and controlled. If you want to make changes to your scanning profiles, the admin can make them in SonarQube and then all apps connected to those profiles will use them going forward (no code changes needed!). SonarQube also does a great job with reporting on tech debt, issues, etc. Step 4: Automated Testing Remember when I said that there are lots of things that dev environments should be doing but rarely do? Automated testing absolutely falls into that umbrella. In my instructions to AI when it helped me create the Application Spec, I asked it to create test cases for me in the code that can be executed automatically during every commit. Tests should be created for any action or process that does something. For example, you would want a test case for every endpoint that the application uses. When the app calls that endpoint, it should return <example>. Here is what that looks like: Besides the obvious benefits of automated testing, it provides an additional benefit in the new world: this is a tool that will allow us to use vibe coding to make smaller changes going forward. AI has been known to perform an action in one context that breaks a completely unrelated function in another context. If the dev or BA isn’t careful, this can and will be committed to production. Automated testing is a great tool to catch these kinds of potential disasters. Step 5: The Finished Application At this point, AI has created a brand-new application that has the front end and back-end services coded to our specifications and it followed the company’s coding standards while doing it. But does it work? In this attempt, everything fired up and worked correctly on the first try. I can assure you that this was not always the case. So why was it perfect this time? As noted earlier, I used the lessons learned from each attempt to better improve the process. I purposely did not give instructions on what to do with the UI because I wanted to see what it would come up with. I asked it to create a clean UI that was responsive, and it did. I could have very easily given it additional specs, wireframes or even images and it would have used them in creating the new application. You might be wondering where the data came from. I had AI create the endpoints that are needed for the application, but I had it set to a “dev mode” where the endpoints returned static values. This is also a useful practice when implementing automated testing (you generally don’t want your tests to be running against production systems).
This went on and on, but the entire process only took about 30 seconds.
Summary #1
