How Scripting can enforce and improve code quality when vibe coding

In the following series of articles we have been going through how to improve the quality of code written by AI assisted development tools, and the next item on our list is Scripting.

Scripting:

If you search on Google for "Scripting", usually you get a bunch of web pages as result, from there you open up couple of pages at the same time and run through every one of them, just to get an understanding from a wider perspective, because some might add a little bit of additional use case which others thinks to be unnecessary.

However, If you Google "Scripting" today, you get the straight up answer, a summary of all the four to five pages' definition, and an example if necessary, I'm not sure how this is going to scale in a business perspective, anyhow.

Scripting - is defined as a small piece of code that you can use to perform a simple task, this is also a Program, written using well known, programming languages including but not limited to Python or JavaScript. The idea here is to complete a small task that are either repetitive or can be automated. 

A smallest example of scripting would be to rename every file in a folder with a prefix, or removing duplicate files based on file name, the second one is something that every one wish they had an app for that, in reality all you need is a simple script, that recursively open every folder in the system and create a map of the file names, with extension and size and compare each one against each other. 

This is a simple explanation and a use case that I can come up with when writing this article, I'm sure there are plenty of other use cases that you can find online with sample scripts and maybe a better application suitable for scripting, in the software front, like a server-side script, client-side script or system script.

How writing a script helps when vibe coding:

If you are following along, I have discussed a bit about Formatting and Linting in the previous article, if you missed it check out here: Formatting or Linting - Helps a lot in AI Assisted development . Technically, Linting is a also a script with predefined rules that can detect code smells, which would later impact the maintenance or might introduce  unexpected behavior. One example I can think of is the use of  "Magic Numbers" , this is something I always get tagged by my linter. 

A "Magic Number" in programming is nothing but a simple number, that has no meaning and defined at the callers site. For example, you want ask the user for a feedback, for that you will set up a trigger and define the constraint, that the user has to use the app for 2 days, here that 2 is the magic number, because if you define it in the caller site where you trigger the feedback function, without defining the number in a constant or a remote configuration, at a later point you might feel you should ask the user for feedback after 4 days, and on a different page the number of days that triggers the feedback, magically becomes 4 from 2.

This is something even us couldn't handle perfectly if not defined properly, even I remember in times, when I'm too lazy to search if a number is defined for a certain use case or not and just start inventing new number, And fix that once my linter tags it.

The same goes for LLMs, AI assisted development tools as well. The simplest trouble you can fall into is, you define a number as 2 at one point and 4 at another point in code, your agentic IDE will prefer the ones that it predicts, because that number is a magic itself in code.

Enforcing script to improve code quality:

This is where the real action begins. The Magic Number  example we just saw before can be mostly fixed with a little bit of better prompting, like saying, "use the same days interval for triggering the feedback, and make it a constant" now all you need this piece of line in your prompting to make a standard way of triggering the feedback.

Where as there are different use cases which you cannot just fix simply by putting in the prompt. On top of that it just introduces more token usages and a roundtrip to find the existing implementation, and there are project specific constraint as well. 

One example I can think of right now is the logging, I'm sure every project have a almost identical yet unique logging strategy, we define what to log and what not to log and how to log.

Since the LLM models used in the agentic IDEs are fixed, they don't know about your logging standard, so you might want to nudge them rightly in that direction, instead of the infamous conole.log or print statement, you want use a dedicated logger class.

Like our prompting before we can simple say "use the logging standard of the project and use the `UltimateLogger` class", again this introduces a bit of a stress for the token generation as the model has to predict the right way to implement the never seen on training logger class and the roundtrip - LLMs are pretty much capable of what I have mentioned earlier, yet they need to understand first on how the `UltimateLogger` class works.

So instead of completely relying on the prompt entirely for a simple correction, you can mention in the prompt like, "write code to delete duplicate files from a folder, add logs on each step of the execution. run the logging standard script after code generation" 

Here our prompt says, the Agentic IDE should write a simple code to delete duplicates, you may think this itself is a script isn't it, this is where things diverge, if the piece of code is run standalone it is a script, but when you hook it up onto a full fledged file explorer explanation, it because a program.

And at the end, we ask the Agentic IDE to run the logging standard script, which can be a simple python or a JavaScript code, which we can use to find the standard log statement and replace it with our desired logger class. If you want to make the most out of it, we can alter the prompt a little by saying, "include logs, and verify it meets the logging standard by running script `ultimatelogger.py`, here is the funny thing that will happen sometimes (if not most),  your Agentic IDE will first look at the `ultimatelogger.py` and see what it does, like replacing the print state with a logger class definition and will unprompted try to generate the code from scratch itself with the correct definition.

Because LLMs works in mysterious ways.

And that is it folks, see you  in the next article.