Generating Code: Roslyn or AI?

In this article, I continue exploring the automation of code generation as part of my effort to migrate this blog's editor, a Windows desktop application I developed myself, to my new universal platform, AIDBDeveloper, which brings together advanced application services, database management and artificial intelligence.

In the previous article, I managed to generate around 11,000 lines of code entirely through deterministic processes. The task was to create a repository class and a set of classes representing each table in the database schema where I store the blog's configuration.

I also generated several interfaces, since my platform makes extensive use of them to represent the many abstractions required by its architecture. After all, the idea is to build a universal infrastructure: one capable of supporting practically any kind of application.

I only used artificial intelligence to generate texts in English and Spanish for the name, category and description attributes applied to interfaces, classes and their properties. I also rely heavily on .NET attributes to attach metadata, allowing me to document not only the code itself, but also the user interface and its controls at runtime.

I've been gradually increasing the complexity.

In the first article in this series, I was only modifying resource files, adding English and Spanish versions of the literal strings assigned to control properties such as AccessibleName, AccessibleDescription and ToolTipText.

The automation also modified the form and control designer files, replacing those literal strings with references to the corresponding resources.

In the second article, I moved on to generating new code from templates. A little more complicated, but still relatively straightforward. In addition to C# code, I added MySQL code generation for the stored procedures used to update the data.

In this article, once again accompanied by a video, I take another step towards more complex automation: creating a component that integrates into my platform and allows users to manage repository objects through the user interface.

That means implementing several existing interfaces and overriding some methods and properties of a predefined base class. Once again, with the help of the runtime automation services already available in my platform, I've managed to do it deterministically. Remember that we're dealing with a generic, but standardised, database repository.

But I've also realised that, from this point onwards, I'll definitely need some form of analysis of the existing code.

I'll need to present code generation options and models to either the user or the AI, based on the classes and interfaces already developed, so that decisions can be made when they cannot simply be derived deterministically from the available information.

The fact that a step isn't deterministic doesn't mean we can't minimise the amount of information needed to perform it. I should stress that I'm not trying to prove that everything can be done without AI. What I'm trying to achieve is profitable automation, without paying unnecessary overheads, not only in tokens, but also in the human hours spent supervising and validating the results.

But before handing all the analysis over to AI, and since we're working with .NET, there's a particularly interesting option worth exploring: Roslyn.

Roslyn is Microsoft's open-source compiler platform for C# and Visual Basic .NET. It provides tools for analysing, interpreting and transforming source code by accessing its syntactic and semantic structure.

Any work we can do before AI comes into play saves tokens and reduces the time required to review the results.

Add automation tailored to our own architecture, especially when that architecture already provides automation services at runtime, and I think we have a very solid foundation for making the whole process worthwhile.

In the video, I demonstrate a first automation using Roslyn to locate the source files containing the declarations of any types we've obtained through reflection.

It's a fairly basic use of Roslyn, but one that can save a great deal of work. Not every source file has the same name as the type it contains, and not every file contains just one type.

I use this capability to automate the documentation of my platform's interfaces, combining Roslyn's code analysis with AI-generated texts. I also explain how I use interfaces and attributes to automate the definition of functions and their parameters for Function Calling.

Without further ado, I invite you to watch the video:

I hope you find it interesting and inspiring. Thanks for reading, and see you next time!