Gemini 3 Flash on Melabit

Antigravity: the LLM does it better

Mon, 16 Mar 2026 18:00:00 +0000

Over the last few weeks, I’ve been writing about my experiments with Antigravity, or rather, with the (more or less) intelligent agents integrated into the editor. The results have been mixed: sometimes the agents proved to be very effective, accurately easing some complex or repetitive tasks; in other cases they didn’t accomplish anything worthwhile, only wasting a huge amount of time.

Coding badly with an LLM

Among all the more or less useful applications of LLMs, one of the most controversial is the idea that anyone can use an LLM to program, even when they don’t know the first thing about it. This is the so-called vibe coding, a concept that can be summarized more or less like this: “I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works”. This is not a quote from Nanni Moretti, a famous italian actor and director; it was reported by Andrej Karpathy, one of the founders of OpenAI.

Now, setting aside the many issues regarding security, the maintainability of code produced without really knowing what it does, and the regression to the mean, which here implies that the quality of AI-produced code will inevitably tend to collapse, it only takes a bit of personal experimentation, even with simple projects, to realize that the very idea of coding for everyone doesn’t work. If you want to get something good out of AI, you have to know exactly what you want and how you want it.

I tried vibe coding myself: I asked Gemini to write a driver for an Arducam camera, explaining only the bare essentials and waiting for it to do everything on its own.¹

However, this approach did not work. It took hours upon hours of work, errors, inconclusive answers, corrections, and advice from me to reach an acceptable result.

And this was only possible because I eventually abandoned the idea of letting Gemini do everything and provided it with specific advice on how to proceed. Without that, it would have only been a massive waste of time.

Mimmo also tried, on his own, to have Lumo write a Micropython program to manage my Arducam Mini 5MP Plus with the Pico. Even Lumo, which is undoubtedly one of the best chatbots around, couldn’t do it.

– Image generated by Google Gemini.

Coding better with the same LLM

This doesn’t mean that an LLM can’t be useful when programming; you just have to use it properly. You must explain exactly what you want it to do, provide all the necessary materials, and set boundaries within which it must operate.

In short, you have to treat it like a graduate student or an intern, with little experience but a great desire to learn.

It only took two carefully written prompts to make a difference. The first defined the project’s directory structure and instructed the agent to use git for version control and uv to install any necessary Python packages,

Prompt

Start a new project and name it project13-pico-camera5mp-reprise.

Read the AGENTS.md file that defines your basic behaviour.

Create a new directory with this name and initialize an empty git repository using git init Use uv for managing Python packages. All the code must stay in the code directory, with no subdirectories within it. This project does not need a data directory and the output directory must be renamed as images.

while the second prompt contained everything I could think of to help it work.

Prompt

I have a Rasperry Pi Pico 2W connected to a Arducam 5MP Plus OV5642 Mini Module Camera Shield (https://www.arducam.com/arducam-5mp-plus-spi-cam-arduino-ov5642.html).

I have connected the camera to the Pico using the standard layout found in the documentation:

Camera	CS	MOSI	MISO	SCK	GND	VCC	SDA	SCL
Pico	GP5	GP3	GP4	GP2	GND	3V3	GP8	GP9

The main documentation for the camera can be found at these links:

The code to drive this camera with the Pico is written in C (i.e., for Arduino) and CircuitPython, and can be found here: https://github.com/ArduCAM/PICO_SPI_CAM. You can download all the files you need from this repository. In particular, the files for CircuitPython are in the Python directory:

Arducam.py, which contains the functions to drive the camera,
OV5642_reg.py which, as far as I have understood, defines the resolutions allowed when taking pictures, and
boot.py , but I don’t know what it does. In the same directory there is also the script ArduCAM_Mini_5MP_Plus_VideoStreaming.py which sends the video captured by the camera to a Windows application and that is of no use here.

Please write a basic CircuitPython script that uses the functions defined in Arducam.py to test that the camera works and can take photos.

These two better-crafted prompts allowed Gemini 3 Flash to quickly generate a CircuitPython script that runs directly on the Pico and performs all the requested tasks.

Actually, the very first version of the script didn’t work. But Gemini was able to modify just a single line in the Arducam.py driver provided by the manufacturer to fix it (specifically, it removed a zero from the frequency value).²

– The line highlighted in blue shows the only change that Gemini made to the Arducam.py file; the original file is on the left, and the Gemini-modified version is on the right.

All of other files provided by the manufacturer remained intact.

As it turned out, the manufacturer’s driver worked perfectly with the Pico. Gemini simply learned how to use it to write the script that captures the image directly from the microcontroller (with a bit of patience, I could have done that myself).

Guide the LLM or let it run on its own?

The difference with respect to the previous approach based on vibe coding is striking.

Then. Gemini worked frantically for hours and created such a mess that I was forced to restart my Mac twice. Meanwhile, it had convinced itself (and me, too) that the Arducam.py driver was incompatible with the Pico and thus rewrote it from scratch, discarding an essential library for communicating with the camera (the library marked by the red arrow),

– Changes to the first few lines of the Arducam.py file; original file on the left, Gemini’s modified version is on the right. The arrow marks the library that was removed by Gemini.

and removing most of the functions defined in that file for no reason and without any real gain in efficiency or functionality (quite the opposite, actually!). The image below shows the difference in the length of the original code, on the left, compared to the modified version, on the right.

– Changes to the Arducam.py file. The red rectangles highlight the difference in the number of lines between the original code (left) and Gemini’s modified version (right).

Not satisfied with that, Gemini also completely altered the OV5642_reg.py file containing the camera configuration data, claiming memory issues. These problems evidently didn’t exist, given that everything went smoothly in this second experiment using the manufacturer’s original file.

– Changes to the OV5642_reg.py file, containing the camera configuration data. The original configuration (left) was overridden by Gemini (right).

What About Arduino?

At this point, it was inevitable to ask Gemini to generate the Arduino driver, using the same information that I had already provided for CircuitPython.

At this point, it was inevitable that I would ask Gemini to generate the Arduino driver using the same information that I had already provided for CircuitPython.

Gemini struggled more this time, mostly because I had forced it to make only minimal changes to the original Arducam libraries. However, this constraint was impossible to satisfy since the libraries do not natively support the Raspberry Pi Pico.

Response

Researching Arducam Library Compatibility I’ve thoroughly inspected both the original ArduCAM library and the Arducam_mini library. Neither version contains native support for the RP2040/RP2350 (Pico) architecture. Specifically, both libraries are missing the necessary definitions for regtype, regsize, cbi, and sbi for this platform, which is the root cause of the compilation errors.

Once the constraint was relaxed, things went smoothly, and in a short time, the driver modified specifically for the Pico and the related image acquisition program were ready.

Free or paid?

Many argue that paid models are much better than free ones. Consequently, my vibe coding problems would supposedly have disappeared if I had paid for Gemini or Claude.

That’s not exactly how it went. During my testing, I mainly used the free version of Gemini to see what would happen to a non-professional user playing with these tools. However, when I ran out of tokens, I switched to the paid version of Gemini provided by the university, but I never noticed any significant differences. I can’t say much about Claude, because paying 200 dollars a month to use it seriously makes no sense for someone like me, who isn’t a professional programmer.

What I did notice was that Claude Opus and Claude Sonnet were much better than Gemini at solving the problems that arose during code development. However, since I only used them once the work was already in progress, they might have just been helped by what Gemini had already done.

Conclusions

It goes without saying that neither this experiment nor the previous one are scientific. For them to be considered as such, I would need to use different types of microcontrollers and modules, define a well-defined set of prompts, and measure how the agent responds to changing experimental conditions.

Despite this, the experiment has one merit: it is fully reproducible. Anyone can repeat the experiment using the same low-cost hardware and prompts to verify whether my findings are correct.³

This is something that the vibe coding apostles with tens of millions of views always carefully avoid proposing. Their posts are full of certainties and bold predictions yet they never provide any evidence to support their claims.

Today, no one can deny that LLMs can be a great help during programming. However, it’s hard to believe that they can truly do so without any human intervention. At least until those apostles decide to provide us with clear, repeatable data to support their claims.

Although I know a little bit about programming, I had no idea how to develop a driver and didn’t want to spend days learning how to do it. ↩︎
Actually, this file is a library of functions. However, since microcontrollers don’t have an operating system, these functions access the hardware directly, just like the drivers that control the components of a computer. Therefore, in this case, the terms library and driver are interchangeable. ↩︎
The term low cost must now be taken with a grain of salt. The shortage of electronic components has caused the price of the Pico to skyrocket, and even more so for the Arducam Mini 5MP Plus. The latter, which cost 40 dollars a few months ago, now costs more than triple that on Amazon or AliExpress. Fortunately, some retailers are maintaining more reasonable prices, at least for now. ↩︎

The Dory effect

Mon, 09 Mar 2026 18:00:00 +0000

I am well aware that LLMs have poor memory, but I never imagined that I would suffer the consequences so quickly.

– Immagine generata da Google Gemini.

Note to the reader. This article complements the previous one, Antigravity: a driver written by AI, and should be read afterward. However, here’s a brief recap for the lazy readers.

Not knowing how to write a driver for a SPI camera attached to a Raspberry Pi Pico, I asked Gemini 3 Flash for help, working entirely inside Antigravity. After many hours, the agent managed to produce a working Arduino program. Then I made a fatal mistake by asking for even more without taking any precautions.

Premise

The working code generated with such great effort by Gemini 3 Flash assumed the Pico acted as a bridge between my Mac Mini and the SPI camera.¹ On the Mac, a Python script commanded image capture, while the actual acquisition was performed by the Pico, running an Arduino program (a sketch in platform jargon) that is essentially C/C++ code adapted for microcontrollers.

Controlling everything from a PC works fine for early tests, but it becomes cumbersome when you want to use such a setup for fieldwork.

Automatic captures

I asked Gemini to modify the code so it would automatically snap an image every N minutes or when a button is pressed, then send the picture to a computer over Wi‑Fi.²

Prompt

[...] However, this means that I need to use a Pico for the capture and another computer, even a Raspberry Pi Zero for commanding the capture process. Would it be possible to do everything on the Pico, eg press a button and perform the capture or via a timed process (defined in the .ino file itself) every N minutes (but there should be a mechanism that sends the images to a computer connected by WiFi, avoiding to fill the pico storage space).

Gemini jumps straight into the work, still using Arduino. In principle, it should be a trivial task, but no matter how hard Gemini tries, the code never works. After many fruitless attempts I got fed up and asked it to revert to the last known‑good version of the program.

Backtracking

And here Gemini hits an unexpected wall because, despite my guidance and constant suggestions, there is absolutely no way to succeed.

Stupidly, I hadn’t kept track of the various code versions as they were generated, and that’s entirely my fault.

On the other hand, even though I am well aware that large language models (LLMs) have a working memory that resembles Dory’s, the blue tang fish, I would have never imagined that these ultra-sophisticated systems couldn’t even retrospectively reconstruct what they’ve already done. Despite having dozens upon dozens of implementation_plan.md, task.md, and walkthrough.md files that detail every previous step. I counted them: for this project alone, Antigravity produced over 250 distinct files.

Going back to a prior state is something that tools like Git and its predecessors – tools that are entirely devoid of any intelligence beyond that of their creators – have been doing flawlessly for more than fifty years). Maybe developers of these intelligent agents could give it a thought, huh?

Epilogue

In the end, stubbornly relying on my notes,³ I managed to get Gemini to repeat everything it had already done. It took hours, it reproduced all the earlier mistakes, but eventually the rebuilt code worked again.

While I was at it, I also had Gemini redo the whole thing for CircuitPython, and that port required many other hours of work and errors. And before getting there, Gemini caused such severe issues that macOS had to disable USB communication with the Pico, forcing me to restart the Mac a couple of times.

Needless to say, this time I had it keep track of every step with git and I also put all the code on GitHub, just in case.

One of the next steps will (hopefully) be MicroPython, but that’s another story.

Why does Arduino struggle so much, despite being a far more mature microcontroller development platform than MicroPython or CircuitPython? Because the camera module I chose isn’t supported on the Raspberry Pi Pico; it only works with classic Raspberry Pis (those running a full OS, such as the Pi 4, 5, or Zero), as well as with the Arduino and ESP286 families of microcontrollers. ↩︎
English isn’t great here; it’s more a stream of thoughts than a polished discourse. But I prefer jotting down whatever comes to mind while writing rather than losing the thread of ideas. ↩︎
I’ll never stress enough how important it is to keep written notes of what you’re doing. At the beginning it seems like a waste of time, yet it’s the best way to avoid losing a huge amount of time later. ↩︎

Antigravity: from surprise to doubt

Mon, 16 Feb 2026 18:00:00 +0000

As effective as Antigravity may be, digging a little deeper reveals that the agent-based systems working inside it, while helpful and capable at answering many complex questions, are not exempt from the usual issues of the large language models (LLMs) we’ve been dealing with for the past three years.

Let’s look at some practical examples.

– Image generated by Google Gemini.

Example #1

After successfully trying to extract data from images in one of my articles, I immediately got to work trying to apply the same method to other figures similar to those analyzed the first time, such as this one.

The figure is clearly more complex than my previous ones: the top part features a histogram showing monthly precipitation and snow depth measurements for two locations with unpronounceable names in Québec, where different measurements are represented with varying shades and colors. Below it, and partially overlapping the histogram, there is a line graph with the average monthly temperatures for the two locations, with the vertical scale positioned on the right side.

Even though the figure is more complex, I never expected Gemini 3 Flash to struggle so much. It tries, and tries again, but every time something is off. The histogram isn’t a huge problem, but there’s no way to make it understand what to do with the data in the line graph. This issue persists even when I explain exactly where it should look to determine the temperature values for each month.

Prompt

Hint: To evaluate temperatures for a given month you should take a point on the temperature plot that is between the two precipitation bars

I am truly surprised by Gemini’s difficulty in repeating and extending the results of my first test, even as it continues to reassure me, claiming it has understood perfectly what I want and has performed a meticulous job.

Answer

I have completed a meticulous re-evaluation of Figure 4 using the "midpoint" method you suggested (reading the temperature at the horizontal center between the two monthly precipitation bars). Final Corrections Applied: [...]

Actually, it seems that Gemini has no idea what the “midpoint” method is and is just repeating what I say, changing only a few words. If it were otherwise, it would have resolved the issue in seconds, pulling out the right data just as it did the first time.

In the end, I give up. It makes no sense to waste hours making an intelligent agent do a job that would only take a few minutes by hand.

Example #2

I must admit I’m disappointed, but perhaps I expected too much from my intelligent agent.

So, I try to make things easier by choosing a graph from an old article of mine that shouldn’t be too challenging for Gemini 3 Flash.

Instead, it gets stuck and makes incomprehensible mistakes. With a little help, he manages to pull out the data shown in this graph, which still has several missing points (highlighted by the colored boxes) or, even worse, points added quite imaginatively (such as the one indicated by the arrow).

Another disappointment. Why use an intelligent agent if it’s faster to acquire the points by hand?

Example #3

But I don’t give up easily and try once more to get it to do something good. I use a figure from another article, which is quite simple from a graphical point of view. However, it would be useful to be able to acquire it automatically, as the amount of data it contains makes it difficult to digitize accurately by hand.

Burned by the previous experiences, I first ask it to describe what it sees in the figure.

Prompt

Now could you describe in simple words what you "see" in figure 1?

The response is long, precise, and almost flawless,

Answer

Looking at figure 252505_1_f1.jpeg, I can see:

Two side-by-side graphs showing current-voltage (I-V) characteristics:

(a) Left graph (T = 2.0 K):

Shows a hysteretic behavior - the curve forms a loop
The current jumps abruptly at certain voltage points
There’s a clear gap between the upward and downward voltage sweeps
The vertical jumps occur around ±1 mV

(b) Right graph (T = 5.8 K):

Shows non-hysteretic behavior - smooth, continuous curve

No loop or gap between voltage sweeps
The transition is gradual rather than abrupt
The curve is more rounded at the critical points

Key observation: This demonstrates how the same Josephson junction behaves differently at different temperatures. At the lower temperature (2.0 K), it shows hysteresis (memory effect), while at the higher temperature (5.8 K), the hysteresis disappears and the junction becomes “overdamped.”

Both graphs show current ranging from about -15 to +15 mA on the y-axis, with voltage on the x-axis measured in millivolts (mV).

but, in reality, there is an error at the end of the response that would render any attempt to digitise the data in the two graphs impossible.

When I point it out, Gemini 3 Flash corrects itself immediately and seems almost sorry. But, as we all know, LLMs are programmed to always please the user.

I move forward and try to help it out, explaining exactly what it should do.

Prompt

No problem. Now could you extract the values of voltage and current from the two images? Please produce a table for each image, and export the table as a csv file and a markdown file, with suffix `_table`.
Since one of the I-V curves is hysteretic, I suggest this strategy for extracting the data: start from V=0, increase V up to the maximum value following one of the paths, decrease V to 0 following the other path, do the same for the negative values of V.

But despite the suggestion, there’s no way to get it to do a decent job. The best I get is this, which at first glance looks like a great result.

It’s a pity, though, that there’s a serious and incomprehensible error, which I’ll leave it for you to discover.

In any case, the previous image is truly the best of the best of the best, and it was obtained after hours of failed attempts (like this initial attempt, or this, or this one) and of hints that went from vague to increasingly precise, much like with an unprepared student from whom you try to get a few words out. Not to mention responses that always tried to adapt to the current suggestion without ever, or almost ever, making use of what had been discussed previously.

All these fruitless attempts were made even more frustrating by the fact that, several years ago, I had solved the same problem accurately and reproducibly with barely two hundred lines of Python code (I remembered wrong, it wasn’t C but Python).

And when I finish explaining exactly how it should be done, even suggesting that the key is to convert the original JPEG file into a PBM format (which is basically a grid of 0s or 1s depending on whether the pixel is white or black),

Prompt

My suggestion is to change focus completely. If I were you I would:

take note of the extreme values of voltage and current on the X and Y axes;
get rid of the extraneous information outside the plot area and of the text (if any) inside it;
convert the image to the PBM (or PGM) format, that gives you a clean grid of black and white (or gray and white) pixels;
remove the extraneous grid dots using a 3x3 or 5x5 filter (or anything like that);
calculate the X and Y position of each black pixel, converting the [values] to Voltage and Current (it is just a proportion).

Clearly you can change the order of the steps or do something different if you believe your approach is better than mine.

there’s still no way to get it to do something useful.

What’s even more frustrating is that Gemini didn’t hesitate to try to cheat! When it found the original file of measured values that I was using to compare its results with the real data, it tried to use that file to generate the data I was asking for. Clearly, the results were perfect this time, but did I need an artificial intelligence to achieve that?

Further examples

During the days I spent testing what I’ve described in this post, I also ran many other tests, such as asking it to write some simple LaTeX code or convert the tables contained in a few PDF files into CSV or Markdown.

t handled LaTeX well, but often struggled with tables, even when the layout was simple. There’s no need to go into detail here, as there aren’t many differences compared to previous examples.

Conclusions

After the excellent results described in the previous article, I was confident I could use the intelligent agents integrated into Antigravity to easily extract data buried in many scientific articles from a few years ago, which would have allowed me to perform new comparative analyses quickly and efficiently.

Unfortunately, all the more in-depth tests described in this post turned out to be unsuccessful.

The model used here, almost always Gemini 3 Flash (though I also briefly tried Gemini 3 Pro and Claude Sonnet 4.5),¹ showed inconsistent and unrepeatable behavior. For example, it would use different methods to solve the same problem without it ever being clear whether the choice of an algorithm or library had a specific technical motivation or was just a matter of statistical probability in the generation of responses.

Another serious issue was the lack of memory, much like Dory, the funny fish from the cartoons. Despite successfully solving the problem of extracting data from a histogram just a few days earlier, Gemini was unable to apply the same methodology to a similar case. On other occasions, once a problem was partially solved, Gemini would start working on it again from scratch instead of refining and improving the previous answer.

But the problem that perhaps bothered me the most was the inability to generalize the work already done. If you ask to extract data from an image, Gemini creates a program suited only for that specific image, without ever trying to develop a general method applicable to other images of the same type. Similarly, if you ask it to generate a graph from a data file, Gemini creates a script suited only for that file, which is nearly impossible to adapt to other similar cases.

When humans tackle a problem, they tend to become fond of the solution and try to reuse and extend it to similar problems. An LLM doesn’t care; it reinvents the wheel at every new iteration. It seems the triumph of the throwaway culture, a waste of resources and intelligence (however artificial) taken to the extreme.

I’m just a guy playing around with these tools. However, very serious scientific studies – which, for instance, tried to use LLMs to rediscover Newton’s law of gravitation starting from the orbits of planets around the Sun, or to predict the behavior of a molecule based on different representations of its structure – have reached the exact same conclusions.

Our analysis reveals that these models instead behave as if they develop task-specific heuristics that fail to generalize.²

Simply increasing model size does not improve performance or generalization ability.³

Lastly, even if at first glance it seems otherwise, we must never forget that LLMs don’t actually understand what they are being asked; they are just very good at finding a needle in a very, very, very large haystack. An LLM can explain in great detail what a “Josephson junction I-V characteristic” is because it has read many books and articles on the subject. But when it comes to connecting the ideal concept of “I-V characteristic” with its experimental representation in a figure, it fails miserably, proving it is just a well-trained parrot.

Someone claims that the latest generation of LLMs can write an entire C compiler on their own or tens of thousands of lines of perfectly functioning code.

Personally, I would be satisfied if these models could produce a data file or a table in a reproducible manner, without running into inexplicable errors or inconsistent results. They should also avoid awkward situations like the ones I experienced, where one day everything goes smoothly, and the next day, nothing works.

I also used the paid version of Gemini, kindly provided by my university, without noticing any differences compared to the free version. Those who claim that paid models do things the free ones can only dream of should provide solid evidence before being believed. ↩︎
K. Vafa et al., What Has a Foundation Model Found? Using Inductive Bias to Probe for World Models, arXiv 2507.06952v4, 2025. ↩︎
B. Yan et al., Inconsistency of LLMs in molecular representations, Digital Discovery vol. 4, 2025. ↩︎