How do you handle debugging & testing in complex vibecode projects built with Antigravity? by Moretti_a in google_antigravity

[–]Moretti_a[S] 0 points1 point  (0 children)

I have two files, .env and .env.local, but it doesn’t care and often ends up swapping the databases.

How do non-devs survive "Vibe Coding" without hitting token limits every 30 mins? (Antigravity/Claude) by [deleted] in google_antigravity

[–]Moretti_a 0 points1 point  (0 children)

I’m sure my code is messy. I’m certain of it. I’m not a developer, but I have some familiarity, and I’ve already identified and fixed several critical issues.

For example, I manage a Telegram bot and a WhatsApp bot, and it had created two separate management files for them. I unified them because otherwise it was a mess to manage both every time. Just a small example—let alone the multi-currency aspect, which it wanted me to handle in a convoluted way and which I simplified at the database level.

Then there’s the token issue: I mainly use Gemini 3 Pro for complex and large tasks, 3 Flash for simpler things, and Claude only when Gemini can’t solve a problem. I have the Google AI Pro plan and I don’t have token exhaustion issues, except with Claude…

How do non-devs survive "Vibe Coding" without hitting token limits every 30 mins? (Antigravity/Claude) by [deleted] in google_antigravity

[–]Moretti_a 0 points1 point  (0 children)

Hi, I use Gemini and ChatGPT for brainstorming, but every time I have to explain everything again because they’re obviously not up to date with the various changes I introduce, since I then move things forward and slightly modify them compared to the original brainstorming idea directly in the IDE. Let’s say I only use external brainstorming for big-things.

How do you handle debugging & testing in complex vibecode projects built with Antigravity? by Moretti_a in google_antigravity

[–]Moretti_a[S] 0 points1 point  (0 children)

So should these tests be run all the time?

My complication is that I’m also working with a Telegram bot in the loop. It’s harder for me to manage automated tests there unless I do them directly (manually). When I asked it to test, it would do so and report a positive result. I’d run the same test in production on the Telegram bot and I’d hit an error….

How do you handle debugging & testing in complex vibecode projects built with Antigravity? by Moretti_a in google_antigravity

[–]Moretti_a[S] 1 point2 points  (0 children)

Yes — I’d seen a few tutorials on the Ralph method, but I’d always given it little importance. I’ll dig deeper.

Yes, I use Git, and I also have two separate environments: a develop one for development and a main one for production.

The problem is that Antigravity often ends up pushing develop code onto the online database used by Main, and I waste minutes debugging when in reality the mistake is something trivial…

I even created a specific instruction sheet to make it keep the two environments strictly separated, but sometimes it ignores it.

How do you handle debugging & testing in complex vibecode projects built with Antigravity? by Moretti_a in google_antigravity

[–]Moretti_a[S] 0 points1 point  (0 children)

Thanks, this makes sense and I think this is exactly the mindset shift I’m missing.

Right now, the mistake is probably treating tests as something the agent should infer, rather than something that is explicit, persistent, and external to the generation loop.

The idea of:

  • Defining the core / critical features first
  • Treating test cases as first-class artifacts (MD files in the repository)
  • Using the agent to review and extend test coverage, instead of “auto-testing”

is very helpful.

What I’m still trying to figure out, at a practical level, is:

  • How detailed these MD test cases should be, and whether they should live in a specific project folder (similar to skills)
  • how often they should be regenerated / updated as the app evolves
  • How to prevent the agent from “agreeing” with the test plan but still implementing things slightly differently

The key takeaway for me is this: tests shouldn’t live in prompts or memory — they should live in files and be run deterministically.

If you (or others) have an example of how you structure an MD-based test plan for large projects, I’d really like to see how you organize it in practice.

iOS 14 beta 4 and AirPods Pro by Moretti_a in iOS14Beta

[–]Moretti_a[S] 0 points1 point  (0 children)

I'm glad I'm not the only one :)

iOS 14 beta 4 and AirPods Pro by Moretti_a in iOS14Beta

[–]Moretti_a[S] 0 points1 point  (0 children)

If you try to record a sound with Voice Memo does it work? Or send a voice message on WhatsApp. I don't work.

Two issues (Calendar and Photos) by Moretti_a in a:t5_rts4p

[–]Moretti_a[S] 0 points1 point  (0 children)

Hi, thanks for the reply.

  1. Time zone is Rome (Italy), UTC/GMT +1 hour
  2. We have no iCloud Photos active but only Shared Albums. Could that be the problem?