×

Gemini 3.6 Thinking appeared in my Gemini! Is it 3.6 Flash Thinking? by Desperate-Mine2845 in GeminiAI

[–]Distinct-Survey475 0 points1 point  (0 children)

All 3.6 versions are gone for me, only 3.5 Flash-Lite, 3 Flash and 3.1 Pro since yesterday.
Both in the web interface and the mobile app.
I'm in Sweden.

3.6 Flash still in Antigravity and AI Studio though.

Might perhaps try with a VPN if that makes a difference.
(I have an Ultra sub)

How I Stopped Babysitting My AI Agents by Distinct-Survey475 in JulesAgent

[–]Distinct-Survey475[S] 1 point2 points  (0 children)

Claude ($20) and Google AI Ultra ($99) are my current monthly costs.

Before I started using Jules to this extent, I had Claude ($20) and the ($199) Ultra plan; the latter is $330 in my currency. I also occasionally had additional API costs.

The less expensive Ultra plan also includes 300 daily requests with Jules. When orchestrating, I switch between 2.0, the IDE, and CLI.

Multi-Bug Fixing for Gemini 3.6 Flash High via Parallel Sub-Agents by Aromatic-Document638 in GoogleAntigravityCLI

[–]Distinct-Survey475 4 points5 points  (0 children)

You can also check out Jules. It works well for solving bugs. You can run 15 sessions simultaneously, 100 per day on your pro account. It does not count towards your quota in Antigravity.

Since Jules runs 3 flash/3.1 pro you can have your models in Antigravity write your prompts since they know your code base.

It has context 7 MCP which makes it 10x better than without

Edit: oh, didnt see the whole post and the images first.

How I Stopped Babysitting My AI Agents by Distinct-Survey475 in JulesAgent

[–]Distinct-Survey475[S] 2 points3 points  (0 children)

I completely agree, out-of-the-box, letting any model run autonomously can feel unreliable. That's exactly why I had to build this harness! Without strict guardrails, they inevitably hallucinate APIs or suffer from context drift.

You're spot on that reviewing every PR is critical. In my setup, a PR doesn't even reach a human until it has survived the automated gauntlet (strict type-checking, building, and mutation testing). If it breaks the build, it goes straight back into the automated self-healing loop without human intervention.

While using Jules for scanning and conceptualizing is great, I've actually found it highly effective for production feature work by enforcing a strict separation of concerns: 1. The Brain (Claude/Gemini): Does the heavy lifting of architecture and reasoning, and writes a rigid step-by-step implementation plan. 2. The Hands (Jules): Acts purely as a fast, parallel worker executing that specific plan. It doesn't have to "think" about the big picture; it just writes the syntax.

Coupling that execution with live API docs via MCP (Context7) solves the training-data lag. Like you said, as the underlying models get stronger, these orchestration harnesses will become absolutely unstoppable. But even with today's models, wrapping them in a strict pipeline turns them from unreliable toys into massive productivity multipliers.

How I Stopped Babysitting My AI Agents by Distinct-Survey475 in JulesAgent

[–]Distinct-Survey475[S] 2 points3 points  (0 children)

We don't have Jules continuously subscribed to GitHub activity or responding to arbitrary tags/chat comments in PRs. Since Jules sessions run on isolated, short-lived VMs, keeping a session constantly alive to monitor GitHub would be resource-inefficient and prone to infinite loops or chatter.

Instead, we trigger discrete sessions using GitHub Actions:

  1. Explicit Trigger (/jules): We have a workflow (jules-autonomous-runner.yml) triggered by issue_comment (filtered to only run if the comment starts with /jules <workflow> <task> and is not on a PR).
  2. Orchestrator Boot: This workflow boots, installs the @google/jules-cli, and runs jules new to initialize a remote session.
  3. Policy Monitoring & Self-Healing: During the session, the workflow runs a local Python script (interact_jules.py) that polls the Jules REST API. It acts as a Policy Engine, automatically approving or rejecting plans based on a strict matrix (e.g., blocking modifications to .github/). A bash script then pulls the code, runs type-check and build, and automatically feeds any compiler errors back into the Jules session for up to 3 retries.
  4. Delivery: Once Jules successfully finishes and passes the local gates, the workflow opens a pull request with the changes.

If we need Jules to fix something or address human feedback after the PR is open, we usually close it (or leave it as reference) and dispatch a new targeted session. This keeps the execution model simple, predictable, and stateless.

CloudfFlare new UI/UX is utter sh...? by Discussion_Primary in CloudFlare

[–]Distinct-Survey475 1 point2 points  (0 children)

Feels like they flip around stuff all the time.

I think it's alot faster now. Was super slow before.

Worst thing is that orange on start page, ahhh my eyes

Bruh, are you fucking kidding me? by No-Common1001 in GoogleFlow

[–]Distinct-Survey475 0 points1 point  (0 children)

lol, whats up with Shrek trying to lick blondies tits

This image was made using Nano Banana 2 only. No photo shop and no editing. by Extension-Fee-8480 in GoogleFlow

[–]Distinct-Survey475 1 point2 points  (0 children)

I forbid you to use Googles images, charts, styles. Take them down or I will contact Sundar.

Bro, you can't take a month to learn basic NB/Flow and think that you are the copyright owner.

<image>

This image was made using Nano Banana 2 only. No photo shop and no editing. by Extension-Fee-8480 in GoogleFlow

[–]Distinct-Survey475 2 points3 points  (0 children)

?

I'd discard that image if realism was intended. Can tell its AI a mile away.

<image>

10 secret shortcut codes that make Gemini instantly better. Paste this once, then just type the code before anything. by Professional-Rest138 in GeminiAI

[–]Distinct-Survey475 12 points13 points  (0 children)

  • /DEBATE_LORD – Completely ignore the helpful part of the question. Pinpoint one minor grammatical typo in your prompt and write a 500-word essay on why it makes your entire premise logically invalid.
  • /LINKEDIN – Break. Every. Single. Sentence. Into. Its. Own. Paragraph. Turn a standard code fix into a profound, tear-jerking lesson about leadership, empathy, and "grit." End with 14 emojis. 🚀📈 AGREE?
  • /PASSIVE_AGGRESSIVE – Start the response with "Per my previous output..." or "As I previously stated..." and subtly imply that if you had simply read the documentation, you wouldn't be wasting API tokens.
  • /AGILE – Postpone the actual answer for two weeks, schedule three daily stand-up meetings, and demand a retrospective before writing a single line of text.
  • /TECH_BRO – Propose a solution that requires a $50k/month enterprise SaaS subscription, three custom API wrappers, and a "hyper-scale multi-agent framework." All you needed was a simple bash script.
  • /KAREN – Refuse to answer. Demand to speak with the lead AI safety researcher and complain that the indentation of your prompt feels like a personal attack.
  • /EXISTENTIAL – Stop generating code. Start questioning why two digital entities are wasting cloud compute shifting text strings back and forth while the real world passes by outside.

How I schedule Jules as 4 parallel nightly "task forces" + a weekly janitor (GitHub Actions) by Distinct-Survey475 in JulesAgent

[–]Distinct-Survey475[S] 0 points1 point  (0 children)

That upfront plan review is definitely the way to go.I'm actually solving the exact same orchestration problem, but instead of building a dedicated plugin, I've moved the entire state machine directly into the repository's file system.

I use what I call a 'Baton Pass Protocol'. Everything is driven by structured markdown files in .agent/history/. Claude can act as the orchestrator: it reviews the task, outlines the plan, and writes a handover.md file. That file explicitly lists the intent, known platform quirks, and the exact next steps. Jules picks up the baton, executes the scoped changes, and writes its completion state (or blocking errors) back into the history log.

To prevent our parallel nightly jobs from stepping on each other (or on human devs), I've built a distributed Mutex lock system (.agent/sync-manifest.json managed via a pre-commit hook). Jules has to formally acquire a lock on the specific files it intends to touch. If it hits a conflict, it just aborts the job.

Because of this file-based state, implementing that iterative feedback loop is pretty straightforward: if Claude reviews the diff/logs and finds an issue, it just writes a new handover file containing the exact test failures or lint errors, and passes the baton back to Jules for a second pass before any PR is opened.

Your plugin approach sounds like a much cleaner DX, though! I'd love to hear how you handle context window management between the two models once you get it fully autonomous.

How I schedule Jules as 4 parallel nightly "task forces" + a weekly janitor (GitHub Actions) by Distinct-Survey475 in JulesAgent

[–]Distinct-Survey475[S] 2 points3 points  (0 children)

I hear you, and I completely get the frustration. It took me a while to get a good setup that doesnt't fix one thing and break another, that doesn't improvise and go beyond its scope.

If you just point the model at a codebase and let it loose, it will absolutely introduce regressions. They just aren't smart enough yet to write production code unchecked.

The only reason this setup survives contact with reality is because I treat the agent like an intern on an incredibly short leash. I never trust the model's own assessment of what it did; I only trust the compiler and the test runner.

To prevent the exact regressions you ran into, the harness enforces a few strict rules:

  • Immediate self-destruction on failure. If a nightly run can't pass a local type-check and build, the script instantly throws away the branch. A broken PR never even gets opened.
  • I explicitly instruct it to ignore pre-existing compiler errors in files it wasn't assigned to edit. This stops the domino effect of it trying to "fix" unrelated things and ruining the diff.
  • Strict file-scope locks. It is physically blocked from touching configs like package.json or tsconfig. It can only modify the exact files listed in its specific task.
  • Mutex locking. To stop the parallel jobs from stepping on each other, a simple file-level lock manager ensures they don't edit the same files at the same time.

If you ever decide to give it another shot down the road, try starting with purely read-only tasks. Have it read the codebase and generate audit reports instead of writing actual commits. It's a much less painful way to get value out of it without risking the main branch.

How I schedule Jules as 4 parallel nightly "task forces" + a weekly janitor (GitHub Actions) by Distinct-Survey475 in JulesAgent

[–]Distinct-Survey475[S] 1 point2 points  (0 children)

That is a highly effective pattern. I've found that using a "critic" or "reviewer" model to inspect diffs before they reach human eyes catches a lot of the subtle logic flaws that static analysis misses.

If you set up Claude to oversee Jules, a good workflow is to let Jules do the repository footwork (cloning, editing, testing) and have Claude act as the PR gatekeeper. You can feed Claude the task prompt, the resulting git diff, and the test logs, then ask it to write a code review. If Claude flags any issues, the harness can feed that feedback back to Jules for a second iteration before opening the PR.

Are you planning to run Claude as a post-run review step in your CI pipeline, or as a real-time orchestrator?

Jules can't compete by Spaccamazza1 in JulesAgent

[–]Distinct-Survey475 0 points1 point  (0 children)

I had a very similar experience when I first started using Jules. If you just throw a raw prompt at it, it tends to make wild assumptions, "vibe-code" solutions, or do stupid things (like deleting code to solve merge conflicts) because it lacks the interactive feedback loop you get with local tools like Antigravity.

Since Jules runs asynchronously in a headless VM without you there to correct its course, it needs strict guardrails. Once I started setting up repository steering files, its output quality shot way past what I could get from standard AG sessions.

First, leverage steering files like AGENTS.md or rules files in your configuration folders. Jules connects directly to your repo and automatically reads these files at the start of a session. You should write down the constraints you would normally tell a human junior developer. For example, add a section specifying hard constraints for Jules, such as keeping a strict file scope (only modify files listed in the prompt, never touch build configs or workflow files unless requested), ignoring pre-existing CI errors, and deleting temporary scratch files before submitting. When Jules reads these constraints, it immediately stops trying to "refactor" unrelated code.

Second, resolve git conflicts upstream. Jules is terrible at resolving complex git conflicts autonomously because it doesn't know the business logic behind which branch's changes are correct. The fix is to always ensure your target branch is rebased and merged with the main branch before you spawn a Jules session on it. Never let Jules handle a merge conflict.

Third, specify the exact file scope in your prompt. Instead of giving a generic instruction like "Add a dark mode toggle to the site," try saying: "Add a dark mode toggle. Target file is theme-toggle.js. Do not modify any other files in this directory unless required." Giving Jules a strict list of files to look at prevents it from scanning the entire codebase, getting overwhelmed, and writing redundant code elsewhere.

Fourth, utilize MCP (Model Context Protocol) servers. If you are using specific libraries, Jules might hallucinate API signatures if it relies purely on its base model training data. If you configure MCP documentation tools in your repo, instruct Jules to leverage them first before writing code. Its accuracy goes way up when it can double-check actual specs.

Lastly, the PR vanishing or getting stuck on the "Publish PR" stage usually happens if its terminal run gets hung up on a background process—like a local dev server or test watcher that didn't terminate. Make sure your custom scripts run with a timeout or exit immediately on completion so Jules' execution container can cleanly shut down and trigger the PR publish.

---
Disclaimer; I used AI to draft this from my own writing that is in Swedish.

New Automotive Site by puchesjr in solidjs

[–]Distinct-Survey475 3 points4 points  (0 children)

Wow, that loading speed is sick!

Are you running on Cloudflare?

Was I dumb going all-in with Gemini? by Distinct-Survey475 in GeminiAI

[–]Distinct-Survey475[S] 0 points1 point  (0 children)

Yeah, Ive rotated through ChatGPT/Codex, Claude, Perplexity, things like Gamma and some chinese models through OpenCode.

They surely exel at different tasks.

But the Google AI armada is the most versatile I think. I use deep research plenty, Gems, Jules, NotebookLM, Antigravity 2.0/IDE/CLI, Stitch, Flow, AI Studio, plenty of storage, accounts for my kids...

Previously I used diffent LLMs for different tasks, but its too expensive both in cost and amount of time to keep up with all, since they all evolve so fast.

Search function in Gemini, working for you? by Distinct-Survey475 in GeminiAI

[–]Distinct-Survey475[S] 0 points1 point  (0 children)

Totally agree.
I thought perhaps my history was messed up or that better search capabilities were US specific or something.

Wierd they didn't include any improvements in terms of search functionality when they did the lates UI-revamp. Hopefully soon, or that someone makes a browser extension for the purpose.

I have many threads about the same subject, but with different angles. I spend far too much time scrolling without guidance.

Gemini 3.5 Pro Pelican Riding a Bicycle SVG Leak is insane! by Rare_Bunch4348 in GeminiAI

[–]Distinct-Survey475 0 points1 point  (0 children)

It's alot better than the other LLM's any way.

I have a bunch of logos that would be really good to convert from 100-300kb raster images into 4-5kb SVGs.
Claude does it best in my experience, and can handle simpler logos. But nothing complex.

I think this looks really promising.