A premise. This article isn’t intended to address the ethical and moral issues associated with the use of LLM (Large Language Models), as (alleged) artificial intelligence systems are called, and other tools connected to these systems. Like it or not, these tools have already been adopted by many individuals and businesses, and it will be increasingly necessary to know how to use them in one’s work.

I already wrote a few comments some time ago regarding the rush to adopt these tools by some of the major search engines. Here, I simply intend to share my personal experience developing an app that uses such a system to perform processes that would otherwise be extremely complex. For this reason, I also used this system as a development assistant, as it was my first experience with this type of software development.

I had started testing the use of a few chatbots and creating a few images in 2024, and only occasionally found them useful. Over time, I saw the progress of these systems and started considering a more professional use. The idea of ​​developing universal apps that could run on PCs (Windows or Linux) and on Android, macOS, and ChromeOS devices using the Flutter and Dart languages started intriguing me.

Getting familiar with the syntax of these languages ​​isn’t difficult, but the philosophy behind developing a user interface in Flutter is different from that of the languages ​​I used in the past. I wasn’t familiar with the tools that allow me to easily perform certain complex operations, and I had to install and configure various development tools on my Linux desktop and my Windows miniPC, and configure the Flutter tools for testing on my Android tablet. These were further reasons to seek assistance from an LLM, and I must say it’s great to be able to get quick and precise answers to specific questions instead of searching through documentation that’s sometimes unclear.

Google offers a free quota for using its Gemini APIs, so it was almost a no-brainer for me to conduct my initial tests and offer anyone the ability to use apps that leverage those APIs without having to pay. Other companies chose to offer paid APIs only, so support for my apps may be added later for users who have their own access keys to use them, but that’s yet to be determined.

The experience of using Gemini is bittersweet. Prototyping an app is certainly quick because all you have to do is explain what you want to do, and Gemini starts blasting out blocks of code. The real problem is in the transition from prototype to working app. Anyone who works in software development knows that there are parts of a software program that reveal unexpected complexities, and it takes very careful evaluation and reflection to achieve what you want. Complexity is the enemy of LLMs! When Gemini has to manage blocks of code beyond a certain size, it starts hallucinating. It suggests a block of code and then immediately starts mentioning variables different from the ones it proposed.

Another crucial phase of software development is debugging. Finding errors is sometimes frustrating because the flow of events can be complex, among other reasons. Gemini is a great assistant when it comes to finding, for example, a syntax error in the code, but otherwise, it’s a disaster! It just tries to guess where the error might be, without any logic.

I learned quickly that Gemini is unreliable in certain cases: one morning, noon was near when I had a problem. I asked Gemini for assistance, received code that was supposed to fix the error, the code generated more errors, Gemini proposed more code that generated more errors, and so on until I realized that I got caught up in the rush to finish my morning’s work, but trusting Gemini was the wrong choice.

In other cases, Gemini showed a tendency to behave in ways where it claims to simplify or optimize the code or prioritize a certain phase in the event flow. In any case, the result is that it “forgets” pieces of code. For this reason, it’s crucial to be careful when inserting pieces of code proposed by Gemini into your app that replace working code! In these cases, you need to immediately revert to the previous version of the code; otherwise, it becomes complicated to restore the “lost” pieces. When developing software, I always save a backup copy at the end of each session, but when working with Gemini, I save one every time I complete a certain block of code.

Another “trick” I learned during this experience is that it’s useful to compare different approaches and solutions to a problem by asking the opinions of other LLMs and then choosing the best solution, or a hybrid. Both coPilot and Claude provided suggestions that, in some cases, were useful and better than Gemini’s. It should be noted that I occasionally asked Gemini for its opinion on solutions suggested by coPilot and Claude, and Gemini acknowledged their validity and incorporated them into its own suggestions. In other cases, the path was the opposite, in that coPilot or Claude provided solutions that improved on Gemini’s suggestions. I also happened to use and mix suggestions from two separate iterations of Gemini.

In essence, combining the use of different LLMs can improve the quality of software development. In all these cases, I’ve noticed that the winning strategy lies in being able to ask the various LLMs the right questions. It’s about trying out different LLMs, partly to understand the strengths and weaknesses of each one so we can make the most of them. It’s not easy, especially since these situations change over time as the various models evolve.

I’ve completed version 0.1 of the book cover analysis app, but it’s not yet ready for distribution. The main problem is that sometimes the original title of an Italian edition of a book is incorrect, so a verification chain is needed to fix these hallucinations. This requires thinking beyond the capabilities of an LLM, and in the meantime, I’ve started developing a food label analysis app. It’s an adventure that’s both stimulating and frustrating, and who knows how it will continue.