Starting and iterating on a Kaggle competition in Google Antigravity – Andrey Lukyanenko

Skip to main content

Starting and iterating on a Kaggle competition in Google Antigravity

09 July 2026

Starting and iterating on a Kaggle competition in Google Antigravity

I spent a couple of days on a Kaggle Playground Series competition (S6E7, predicting a three-class health_condition from tabular health data), mostly as an excuse to try Google Antigravity 2.0 with Gemini 3.1 Pro, as part of my Google Developer Expert activity. I wanted to see if an agentic IDE can take a competition from a cold start to a good leaderboard submission.

Google Antigravity 2.0 is Google’s agentic development platform, launched a couple of months ago. Unlike a normal IDE, it is built around AI agents that plan tasks, write and run code, and operate the editor, terminal, and browser on their own, then present the work as reviewable artifacts. The agent runs on Gemini 3.1 Pro , Google’s model for complex reasoning and coding.

I did not start from scratch. Before opening Antigravity, I used Claude Code to build a starter kit for tabular competitions based on my previous experience: a general playbook, two prompts (one to run the pipeline end-to-end, one to drive an improvement loop), and a set of agent prompts/commands. Then I added the competition data and ran the initial prompt in Antigravity. The full code is available on GitHub.

This post is about the experience of running a Kaggle competition in an agentic environment and about the importance of setting correct constraints and validation checks.

The starting direction

A multi-agent pipeline only works if all models agree on the rules. If different model scripts create their own cross-validation splits, they can’t be compared and their out-of-fold predictions can’t be blended. That’s why I defined the rules beforehand: a fixed fold split that every model reads, a pre-defined out-of-fold and test-prediction schema that every model writes, and a “memory” (EXPERIMENTS_LOG.md) that every run appends to.

My initial prompt included a standard approach to tabular competitions: EDA, feature engineering, three models trained in parallel (LightGBM , CatBoost , and a PyTorch MLP), a hill-climbing blend, and a submission to Kaggle. The most important rule was to spend considerable time setting up cross-validation and then using it for all subsequent runs. The second prompt was a loop that read the scoreboard, picked the highest-value ideas, implemented them, judged on CV, and logged the result. The loop repeated until the goal was met or ideas were exhausted.

Running the loop in Antigravity

I pasted the first prompt, and Gemini set up the folds, ran the EDA, built about 140 features (missing indicators, frequency encodings, numeric ratios, out-of-fold target encoding without leaks), and trained the three models. Antigravity runs long jobs as background tasks, so the three models trained concurrently, and Gemini could set a wake-up timer and check the results instead of monitoring a running process. Given the second prompt, the loop mostly ran itself: read the scoreboard, pick the highest-value ideas, implement them, evaluate on CV, log the result.

I used high reasoning to ensure the best quality, but it was at a cost. On the high reasoning setting, trivial edits took minutes and anything substantial took hours. Switching Gemini to low reasoning for implementation sped up the iterations significantly, and I kept high reasoning only for the few steps that actually needed it.

The wall

The first pipeline produced a CV of 0.967 accuracy. I submitted it and saw that something went wrong - the public leaderboard score was 0.874. A Kaggler who sees such a gap usually assumes the CV is wrong. However, the agent’s instinct was to get more data. It proposed downloading a Kaggle dataset of pseudo-labels and “known noisy IDs” for this competition, and it made the case with real confidence: this, it said, was “the only way to break past the 0.874 wall.”

The problem was that the dataset was just a user-uploaded file. Its pseudo-labels are one competitor’s model output and its “noisy ID” list is that model’s guesses, so training on them would have meant fitting our models to someone else’s solution, with no guarantee the labels were right. I told the agent it was unofficial and to stop. It stopped, reverted the change, and then did something more plausible: it dug up a public dataset the synthetic competition data had been inspired by and used that to augment instead.

That was the better hunch, but it was wrong again: the original competition stated that the second dataset was an inspiration, but the feature distributions were different. As expected, this external data didn’t improve CV and was dropped. Another attempt was confident-learning label cleaning - it was worse too, scoring 0.866 on the leaderboard, lower than the previous score.

The wall was two bugs

Both real causes were simple,...