Automating Code with AI: Multilingual Controls

In this article, I’m presenting the first video in a new series about automating code generation with artificial intelligence. The idea is not to find the best agent capable of generating an entire application, or to work out how many agents we need to chain together to get better results. In fact, the approach is almost the opposite.

When we work with well-defined patterns, code automation is nothing new. We have been generating code, modifying files, creating repetitive structures and applying fully formalised rules for decades.

The problem has always been those particular points in the process where a decision has to be made that is difficult to turn into an algorithm.

Traditionally, we dealt with those points by leaving unfinished work for a programmer. We generated part of the code automatically and added comments indicating where someone needed to intervene and what had to be done.

Now we can replace those interventions with calls to a model, but that does not mean we should hand the entire process over to it. If a task can be performed by the application using a conventional algorithm, I would rather let the application do it. It will be faster, cheaper and, above all, more predictable.

AI only steps in where it is actually needed, and that is precisely the idea behind this series.

To introduce the approach, I have deliberately chosen a very simple example: converting literal text in a Windows Forms designer or UserControl into localisable resources. The interesting part is that the code generation is performed by the same application the changes are being applied to: my R&D platform, AIDBDeveloper. The long-term goal is to turn it into a self-extending platform.

This is a task I perform regularly. I first write the texts in English, which is the default language of my application, and then I have to replace them with resource references, create the corresponding resource names, modify the .resx files, add the translations and update the generated resource designer as well.

It is not difficult work, but it is tedious and time-consuming because several different files have to be modified.

Most of the process is entirely mechanical: the application can locate the texts, generate resource names according to a convention, modify the designer, update the resource files and collect all the modified files so that I can review the changes before accepting them.

I do not need AI for any of that.

Where it can add value is in the translations. I do not simply want words translated. I want the model to understand the context, adapt the text properly to the target language, and recognise that certain class names and control names belong to the code and should not be translated.

So the model only steps in at that point: it does its job, leaves the process again, and the application carries on with everything else.

This is what I mean when I say that the application is both the assembly line and the robots performing the mechanical work: AI takes the place of the specialist we call in when something appears that cannot easily be formalised.

In this first example, its involvement is minimal, which is exactly why I think it makes a good starting point.

In the next videos, I will gradually increase the complexity until we reach much more substantial development automations, while trying to maintain the same principle throughout: the application should do everything it can do by itself.

Here is the video.

The question that remains open for the rest of the series is quite simple:

How much of a code automation task actually needs AI?

Thanks for reading, and see you next time.