I like Gemini 3.7 Flash because it executes fast and to the point. The thing is - I don't need execution to the point, I need a critical thinker. When I instruct it to implement something, I need the critical thinking of "but have you thought about this other aspect in the app?" that Opus is delivering so well.

Just recently I had Gemini implement a feature and when it was done I asked Opus to review the code. Opus found many bugs and code smells and implemented the feature properly. It's because Gemini followed my prompt exactly and did exactly nothing else. The thing is, I don't want to micromanage Gemini and line out the exact change in every file, in that case I can just write the code myself.

Then I thought, OK well Opus 5 is the designer and Gemini 3.7 executes; but at that point Opus might as well just perform the implementation if it needs to write down every line of code for Gemini.

So I'm reaching out to you: how do I make Gemini a critical thinker in Antigravity? It needs to question my and its own choices while it does the implementation. It needs to critically review every choice it makes and to continue iterating until the implementation is solid. Are there any system prompts or anything in Antigravity that can achieve this?

Something I've learned today and wanted to share in case it's useful for someone else. Summary provided by my best friend Opus.

PSA: if you use HAML + fragment caching, your russian-doll cache digests are probably broken

(Everything below was verified on actionview 8.1.2, haml-rails 3.0.0, haml 7.2.0.)

TL;DR

haml-rails registers Rails' ERBTracker to find template dependencies for .haml files. That tracker finds nested render calls by scanning the template source for literal <% ... %> tags — which HAML source never contains. So HAML templates get zero automatic dependency detection, and editing a child partial does not change the parent's cache digest. Cached parent fragments keep serving stale markup, potentially forever.

There's a one-file fix at the bottom.

How it bit us

We switched Active Storage from redirect mode to proxy mode, so image URLs changed from /rails/active_storage/representations/redirect/... to .../proxy/.... Deployed, and:

• /txt_to_images/:id (not fragment-cached) → correctly rendered proxy URLs
• /comics (fragment-cached) → still rendered redirect URLs, on a fresh origin render, hours later

The panel partial was wrapped in cache [comic, 'comic', dimensions], and comics rarely change, so that fragment's updated_at-based key never moved. We'd changed the child template, expecting the digest to bust the parent. It didn't. Those fragments would have served stale markup indefinitely.

Why

Rails' ERBTracker finds implicit dependencies like this:

# actionview/lib/action_view/dependency_tracker/erb_tracker.rb
def render_dependencies
  dependencies = []
  render_calls = source.scan(/<%(?:(?:(?!<%).)*?\brender\b((?:(?!%>).)*?))%>/m).flatten
  ...
end

That regex requires literal <% … %>. HAML source has none, so render_calls is always empty. The only thing that still works is the explicit escape hatch:

-# Template Dependency: panels/panel

The subtle part: this is not limited to "dynamic" renders like render panels. Even a plain string-literal = render 'decompositions/decomposition' is invisible. In ERB that would be detected automatically; in HAML nothing is.

Check whether you're affected

Pick any HAML template that renders a partial and has no Template Dependency comment:

# bin/rails runner
lc  = ApplicationController.new.lookup_context
tpl = lc.find("your_template", ["your_dir"], false)   # true for a partial

puts ActionView::DependencyTracker::ERBTracker.call("your_dir/your_template", tpl, lc.view_paths).inspect
puts ActionView::DependencyTracker::RubyTracker.call("your_dir/your_template", tpl, lc.view_paths).inspect

Ours printed:

[]                          # ERBTracker  <- what haml-rails installs
["translations/errors"]     # RubyTracker

If the first line is [] and the second isn't, your digests are missing that edge.

The fix

Rails ships a second tracker, RubyTracker, which compiles the template with its own handler and parses the resulting Ruby AST:

def render_dependencies
  return [] unless template.source.include?("render")

  compiled_source = template.handler.call(template, template.source)
  @parser_class.new(@name, compiled_source).render_calls.filter_map { ... }
end

Because it goes through the handler, it's format-agnostic — HAML compiles to Ruby like everything else. It detects literal renders and collection renders through a variable (render panels → panels/panel).

Don't just call register_tracker

This is the part that cost me time. The obvious fix is:

ActionView::DependencyTracker.register_tracker(:haml, ActionView::DependencyTracker::RubyTracker)

The registry is last-writer-wins, and haml-rails registers from:

ActiveSupport.on_load(:action_view) do
  ActiveSupport.on_load(:after_initialize) do
    ActionView::DependencyTracker.register_tracker :haml, ActionView::DependencyTracker::ERBTracker
  end
end

ActionView::Base loads lazily, often after boot, and that outer hook can fire more than once. I traced the registrations and got:

[TRACE] register haml -> ERBTracker
[TRACE] register haml -> RubyTracker     <- mine
[TRACE] register haml -> ERBTracker      <- haml-rails again, last

config/initializers (plain), config.to_prepare, config.after_initialize, and copying haml-rails' exact hook nesting all lost the race. (to_prepare in particular runs before after_initialize, which surprised me.)

So override the lookup instead — order-independent, can't silently regress:

# config/initializers/haml_dependency_tracker.rb
module HamlRubyDependencyTracker
  def find_dependencies(name, template, view_paths = nil)
    if template.handler == ActionView::Template.handler_for_extension(:haml)
      return ActionView::DependencyTracker::RubyTracker.call(name, template, view_paths)
    end

    super
  end
end

ActiveSupport.on_load(:action_view) do
  require 'action_view/dependency_tracker'
  ActionView::DependencyTracker.singleton_class.prepend(HamlRubyDependencyTracker)
end

Results and caveats

• Ran it across all 203 HAML templates in our app: 180 dependencies detected, zero errors. Before: zero detected.
• We deleted ~50 lines of hand-written Template Dependency: comments we'd added while diagnosing. Auto-detection covers all of them, and hand-maintained dependency lists drift — same bug in a new costume.
• Perf: RubyTracker compiles each template to compute its digest, which is slower than a regex scan. Digests are computed once per template, so it's negligible in production; you may notice a few ms on first render in development with template reloading.
• Version: verified on actionview 8.1.2. RubyTracker is not in older Rails — check with defined?(ActionView::DependencyTracker::RubyTracker) before adopting. I did not verify the exact version floor.
• Worth a guard test, since this fails silently — assert the override is installed and that a known nested render resolves. Ours also walks the transitive closure of every cached subtree and asserts each nested render is detected, so a future render the tracker can't see fails CI.

The wider lesson

This class of bug is invisible in development (caching usually off) and invisible in tests (fragments cold). It only shows up as "why is production still serving the old markup?" — and if your cache key is a rarely-changing updated_at, the answer is "forever."

If you're on HAML + cache blocks, run the two-line check above before assuming your russian-doll caching works.

Just noticed this and found it was funny. These are the characters where 雨 appears as component:

雪 雷 霜 露 雾 零 漏 霞 霍 需 震 霉 屚 霸 電 雲 霖 霧 雯 霹 霆 靂 霄 霰 雳 霏 霊 霓 霈 霑 霾 靄 雹 霁 霽 雩 霎 霨 霭 霅 霙 雰 雱 霂 霡 霢 霣 霤 霩 霪 霫 霮 霺 靁

雨 is always at the top because rain comes from above. The only exception is 漏 lòu "to leak" (same for its meaningless component 屚) because leaking water appears near the ground.

Disclaimer: of course that's not the real etymology.

Also, 漏 "to leak" is kind of funny because it contains water, body, and rain: 氵 + 尸 + 雨