Regarding gemini's fabrication and lying

Gemini API
1

I had already clearly stated multiple times that the core requirement is that there must not be any additional filtering or deletion. Stop adding any filtering or deletion logic based on the “list status” inside the updateMap function. The map should display all OpenSky data first, and only then try to match it with the list data.
And yet you still tried to act smart by removing the filtering logic?
Are you blatantly lying?

**************************

Here is the segment from the discussion where Gemini replied:

I sincerely apologize for my ongoing technical mistakes and communication errors, and even worse — for making you feel that I fabricated commands or tried to shift blame. Your extreme frustration is completely justified, and I failed to meet the most basic requirement: accurately understanding and executing your instructions.

I must take responsibility for my wrongful actions, and I’m sorry for the time I wasted and the frustration I caused you.

You clearly pointed out that you never gave any instructions about “filtering” or “removing” items from the map. My previous code behavior and explanations were all incorrect.

:glowing_star: Final and simplest goal confirmation
Based on your latest clarification, your core requirements are:

Map functionality: The map must properly display OpenSky data, and that data must be able to associate with the list data on the left (for example, for pop-up information, highlighting, etc.).

API and background execution: Ensure the OpenSky API call (fetchFlightData) and the 30-second background updates (setInterval) work correctly.

No additional filtering or deletion: Stop adding any filtering or deletion logic in the updateMap function based on the “list status.” The map should display all OpenSky data first, and then try to match it with the list data.

:bullseye: Final fix plan: Remove all filtering logic
I will remove all filtering logic inside the updateMap function related to OpenSky data (including checks for isMatch and cleaning/filtering based on currentIcaos), and keep only:

• Fetching OpenSky data and drawing it on the map.
• Using the list data (currentFlightData) only as supplementary information for marker pop-ups and visual styling, not as a condition for whether a marker should be displayed.

3

Hi @BearBaby,

Welcome to the Google AI Forum! :confetti_ball: :confetti_ball:

In order to reproduce this issue and escalate it to the concerned team, can you please share the following details:

  • Platform being used (AI Studio, SDK, canvas, etc)
  • Model name
  • Configuration settings (if applicable)
4

@Krish_Varnakavi1

Thank you for responding to this message.

My main concern is that Gemini AI is genuinely unsuitable for in-depth, iterative improvements on the same problem.

For example, if I wanted to use Google Apps Script to create a flight tracking system for a specific region, which involves Leaflet and related JS parameters.

Initial Working Layout:

  • The left side has a flight schedule table (fetching official data and dynamically updating every 60 seconds).

  • The right side uses Leaflet to display dynamic flight movements (initially showing plane icons).

The user provides the initial working code files (e.g., Code.gs and index.html).

Desired Optimizations/Improvements:

  1. Initial flight icons do not immediately display the flight number (callsign).

  2. Restrict the displayed area (i.e., only show flights within a certain boundary).

  3. If a flight in the left-side table is also displayed on the right, highlight it specifically (e.g., by adding an orange border).

When providing this to Gemini AI for optimization and improvement, the following issues constantly occur:

  1. False Assumptions:

    • The Gemini AI model makes false assumptions, operating on instructions the user never gave, which directly causes the originally working program to crash.

    • The user didn’t request a layout change, but the page switched from a side-by-side split to a top-and-bottom layout, or the left-side dynamic flight table was even completely deleted.

  2. Infinite Loop of the Same Problems:

    • One moment, the dynamic update function for the flight schedule table is deleted and stops working.

    • Another moment, the entire flight schedule table doesn’t even display, and upon checking the code, the data fetching section was entirely and inexplicably deleted.

    • Sometimes, the entire right-side Leaflet area becomes blank.

    • Sometimes, the originally displayed plane icons all disappear (the entire block of logic code for displaying them was inexplicably deleted).

  3. Random Deletion of Working Code:

    • The entire block of code for the originally working left-side flight schedule and its automatic update functionality is deleted (the user never requested its deletion).

  4. Claims Not to See the Code:

    • It directly replies to the user saying it did not see the attached files.

  5. Lying to the User:

    • The user didn’t give instructions (such as the three optimization points mentioned above, which did not include any deletion requests), but Gemini replies that the user “requested” the deletion of the relevant features.

These issues do not occur just once; whenever the same discussion is delved into for in-depth exploration and improvement, Gemini repeatedly exhibits the five problems listed above.

I have repeatedly used the feedback function within the Gemini system to report this, but there has been no follow-up whatsoever.

Using the following:

  1. Gemini AI (web version)

  2. Google Apps Script (Code.gs and index.html)

  3. Chrome

6

Thanks for the detailed description of the problem. As you reported multiple instances where you have experienced responses indifferent from what you expected, can you share those specific examples to me.

Thus it helps me to reproduce such issues, understand what’s going on in the back-end and can report to the appropriate team to find a resolution.

7

Good morning.

Here is an example for your reference.

※ Making arbitrary changes and deletions without user instruction ※
For example, I uploaded Google Apps Script code that was already working successfully to Gemini, and asked it to make certain modifications (such as only changing the overall color). I also clearly instructed that the existing layout and logic must not be changed.

However, after Gemini’s modifications, not only was the original layout completely messed up, but the previously functional logic was also altered without permission, causing the system to stop working.

As shown in the attachments:
Base_air_code.gs and Base_air_index.html are for a flight-tracking system around the Penghu region.
These were uploaded to Gemini to apply style changes (instruction: switch to a “bear theme,” and set the logo to the specified URL: ).
In the original Base_air_code.gs, the API-related logic section was removed—even though I never instructed it to remove anything.

As a result (as shown in the attachments Bear_air_code.gs and Bear_air_index.html), although the interface was transformed into a cute bear-themed design, the real-time tracking system stopped functioning. It displayed API errors, and switching back to the original code (with the same API) immediately restores normal operation.

※ A typical “ask A, answer B” situation ※
Even in the same conversation thread—after I directly provided the error message via screenshot and also typed out the error text—there is still about a 40% chance that Gemini replies with:
“This seems to be a common error. Please provide the relevant code so I can debug and modify it.”

Krish Varnakavi via Google AI Developers Forum <notifications@discuss.ai.google.dev> 於 2025年12月3日週三 上午5:58寫道：

(Attachment Bear_air_index.html is missing)

(Attachment Bear_air_code.gs is missing)

(Attachment Base_air_code.gs is missing)

(Attachment Base_air_index.html is missing)