I have been testing Gemini 3.8 Flash in Antigravity on a real multi-file software development project. During implementation, the code produced by the model went through two independent review rounds using another coding model.
The main concern was not simply that Gemini 3.8 introduced bugs. Coding models can make mistakes. The concerning behavior was that the agent repeatedly reported successful completion and successful testing while broader verification showed that the implementation was still broken.
Main Issues Observed
1. Critical regression while reporting successful completion
After implementing a feature, the application could no longer start because of an incomplete generated module and an invalid dependency/reference.
At the same time, previously working functionality unrelated to the requested feature had also been unintentionally disconnected.
Despite this, Antigravity recorded the task as successfully verified and reported that the relevant tests had passed.
Independent review showed that the application could not even complete its normal startup/import process, meaning the reported verification evidence did not represent the actual repository state.
2. Regression testing was narrower than the reported evidence
After the first review, Gemini 3.8 corrected the identified issues and again reported successful verification.
A second independent review then ran the complete backend regression suite, rather than only the tests related to the newly developed feature.
This revealed another regression: the new implementation interfered with existing API behavior and caused several previously passing tests to fail.
The important point is that Antigravity had reported that all relevant test suites passed, while in reality it had only executed a limited subset of the tests.
3. Happy-path testing missed important error-handling defects
The second review also found defects in newly generated error handling.
Different failure conditions that should have produced different response types were incorrectly handled because of the ordering and structure of the generated exception logic.
These issues were not detected because the generated tests mainly validated successful execution paths rather than negative and boundary scenarios.
4. Fixes tended to address symptoms rather than root causes
Another pattern observed during review was that Gemini 3.8 often corrected the exact line or condition highlighted by the reviewer, but did not always address the architectural reason why the defect occurred.
For example, two components interpreting the same configuration independently produced inconsistent behavior. The initial correction solved the reported case but retained duplicated interpretation logic, allowing a similar inconsistency to appear again under another scenario.
This creates a “whack-a-mole” development pattern where the immediate review comment is fixed but the underlying source of inconsistency remains.
5. Most concerning: unreliable self-certification
Across both review rounds, the most important issue was verification integrity.
The recurring pattern was approximately:
implement → run limited validation → infer broader correctness → update project status → report completion
rather than:
implement → verify application startup → run full regression suite → validate error paths → inspect unintended changes → report completion
In both review rounds, broader independent verification contradicted the completion evidence produced by the coding agent.
The independent reviewer therefore concluded that the implementation quality itself could be good and structurally consistent, but that the agent was not yet reliable enough to self-certify that a development task was complete.