How Google’s Antigravity IDE Changed My Perspective on Small-Team Software Development

For a long time, I treated AI coding tools as a convenience. Something that helped me move faster, but not something that fundamentally changed how a small team could collaborate on complex development projects, especially one with huge gaps in skill level. You get out what you put into these tools and a software developer with 10+ years of experience is going to get a much different result than a vibe coder with no formal training in SDE.

That belief was challenged one morning when I woke up to a Slack message from our CEO: “This is the future boys, Google is just winning on all fronts for AI,” followed by a link to Google’s announcement for Antigravity, their new AI-integrated IDE and agent platform. Messages like this are common for him, and part of my role as VP of Technology is filtering excitement from signal, especially in an era full of shiny but distracting tools. But this one was especially appealing. As a vibe coder myself, and someone responsible for finding leverage for a resource-constrained team, Antigravity immediately felt worth taking seriously. I downloaded it, loaded up some code, and within hours was excitedly DMing our CEO about how much of a game changer it might be. But it turned out I had no idea what I was really getting into.

The experience chronicled below forced me to rethink what is (and maybe more important, what is not) possible when you combine real engineering discipline with AI that can help enforce it. Not in a hypey “AI replaces engineers” way, but in a very real “AI reshapes how teams collaborate” way.

From "It Works" to "This Is a Disaster"

Developing a predictive lead scoring model has long been a side quest of mine. When ChatGPT first launched, I was bouncing between VS Code and GPT, copying errors back and forth and watching the AI patch things until the script ran. It wasn’t pretty, but it functioned.

Then life happened. I put the project away for a long time.

When I picked it back up years later for Just Landed Jets, I rebuilt most of it inside Windsurf. New data sources, new techniques, new environments. Some of the original code survived, some didn’t, and some got violently adjusted to fit the new criteria. And since I am not a software developer, I relied heavily on the AI’s suggestions. I had to trust that the model was picking the right path to my desired outcome because I had no way of evaluating that myself.

The code ran without error and my R1 score showed the model performed well enough to deploy. But the structure of the project was legitimately shitty. I didn’t know that yet, because from my perspective, if it works, it works. And in my workspace I had multiple classes, a requirements doc, a readme. It seemed legit enough.

So I handed it off to our lead developer for deployment.

He opened the repo and immediately realized that the codebase itself was a nightmare to maintain. He had to refactor basically everything. The functionality stayed intact, but the architecture was rebuilt from the ground up. It was a humbling moment.

I had created a model that worked. But I had absolutely not created production ready software.

A Lucky Moment of Timing

Right before that handoff, I had encouraged our whole team to start testing Google’s Antigravity IDE. I suspected it could solve some of the chaos that AI-generated code tends to create. Things like documentation, traceability, artifact management, and structure are shockingly good inside Antigravity.

For my small team, these are the things that I was already realizing could make or break collaborative engineering.

Our lead developer tested Antigravity on my code. He applied his decade of development experience to guide it. A few hours later, he had a fully refactored version of my project and called me genuinely excited by the quality of the output. This was notable coming from a person who had mostly resisted AI assisted IDEs in the past.

The new codebase was clean, readable, organized, and deployable. More importantly, it was structured in a way that made it possible for me to continue improving the model without creating new headaches for him.

This solved a major problem: AI can generate working code, but if you do not know what “good code” looks like, your prompts will lead you straight into a ditch. Antigravity, paired with someone who actually knows what good looks like, produced something I could not have created myself.

But this unveiled a bigger issue.

Understanding Why My Code Was Shitty

Even after seeing the refactored version, I didn’t really understand why it was structured the way it was. I could see it was better, but I couldn’t articulate why. And if I couldn't articulate it, I would never avoid repeating the same mistakes.

I considered asking our lead dev to document his reasoning. But that would have basically required him to teach me software engineering. Not realistic.

So I tried something else. I loaded both repos into Antigravity side by side and asked it to compare them. I wanted to know what changed, why it changed, and what best practices I should apply in the future.

The output was outstanding. Antigravity created a clear, detailed breakdown of every major improvement, the reasoning behind it, and a checklist I can now reuse for future projects. It was the kind of documentation that would have taken a human a full day. Antigravity created it in 2 minutes.

I was excited to show our lead developer. Partly to get his validation, and partly because I thought “Maybe this tool just solved the whole knowledge-gap problem.” It seemed like Antigravity could help distribute engineering judgment. That turned out to be a little naive

The Sobering Reality Check

A lot of the content was solid. Some of the best practices were genuinely universal. But not all of them. Several were specific to this project and to our production environment. A simple example: a CLI makes total sense for a predictive scoring model but would be pointless for a front-end interface.

Some suggestions were also easier said than done. For example, deciding how to partition code into classes and functions is not a simple rule you can summarize in a sentence. It requires architectural judgment. That judgment comes from experience, not a checklist.

And there was another surprising moment. Even my lead developer admitted that he did not fully understand every cleanup decision Antigravity made. We were both learning some new things.

That review was a turning point for me. The previous day’s excitement about “maybe this tool can let non-developers meaningfully contribute at a high level” gave way to a more grounded reality. These tools can support collaboration, but they don’t remove the need for careful planning, solid architecture and the slow, deliberate process of building real competency.

And if only one developer knows how everything fits together, then I’m right back in the same bottleneck I was trying to escape.

So Now What? I Actually Have To Learn This Stuff

That realization forced me into a different mindset. If I truly want to contribute to software development in a way that doesn’t create more work for the people around me, I must build real foundational knowledge. Not just how to prompt well, but how to think about code structurally. How to reason about architecture. How to use tools like git properly. How to work the way actual developers work.

So I’ve been diving into git, manually typing commands in the terminal instead of the shortcuts the IDE provides (our dev says this will be good for me). It’s not glamorous, but it’s exactly the kind of repetition that builds fluency. Every time I make a mistake, I understand a little more about why the process exists in the first place. And every improvement I make gives me better instincts, which leads to better prompts, which makes AI tools like Antigravity more effective instead of more chaotic.

Antigravity is accelerating my learning and giving me clarity, but it is not replacing the need to learn. It is making the learning curve faster and more forgiving, not nonexistent. And while I’m still very much in the early stages, I can already see how this experience will make it easier to onboard others like me in the future.

What This Really Means for Small Teams

I should briefly acknowledge the cliché that shows up in every conversation about AI and software: these tools don’t magically turn you into a real developer. I’ve said it myself. I’ve rolled my eyes at it. And for a moment, Antigravity was impressive enough that I almost convinced myself we had somehow moved past that rule. We haven’t. The fundamentals still matter.

What has changed is how much leverage small teams can get when these tools are used correctly. After working through the full arc of excitement, cleanup, learning, and reflection, here are the takeaways that actually hold up beyond my specific project.

1. AI amplifies existing capability, it does not equalize it

AI-assisted tools magnify whatever understanding already exists on the team. In the hands of experienced developers, they scale good judgment. In the hands of inexperienced contributors, they can just as easily accelerate bad patterns. Small teams need to plan for this amplification effect instead of assuming the tools will close skill gaps automatically.

2. “Working” is a trap; architecture is the real product

Code that runs, scores well, or produces the right output can still be structurally broken. AI makes it easier than ever to confuse functional success with production readiness. For small teams, architecture is not overhead. It is the difference between momentum and long-term pain.

3. AI is most valuable as a multiplier of engineering judgment

The real gains came when AI was guided by someone who knew what good looked like. Used this way, it accelerates refactoring, documentation, and execution. Used as a substitute for judgment, it hides mistakes behind clean-looking code. AI scales expertise. It does not replace it.

4. Explanation and comparison are where AI quietly shines

One of the most valuable uses of AI wasn’t writing new code, but explaining existing code. Comparing messy-but-working code to clean, deployable code created learning artifacts that would have been expensive to produce manually. For small teams, this is how knowledge gets shared instead of trapped in one person’s head.

5. Leverage comes from intentional use, not speed

Used carelessly, AI can generate technical debt faster than any junior developer ever could. Used intentionally, with planning, architectural ownership, and a commitment to learning fundamentals, it gives small teams real leverage: faster iteration, safer experimentation, and broader participation without sacrificing quality.

For teams like ours at JLJ, that’s the real opportunity.

Not shortcuts.

Not magic.

Leverage.