←back to thread

Gemini CLI

(blog.google)
1336 points sync | 1 comments | 25 Jun 25 13:10 UTC | HN request time: 0.253s | source
Show context
wohoef ◴[25 Jun 25 14:51 UTC] No.44378022[source]▶
A few days ago I tested Claude Code by completely vibe coding a simple stock tracker web app in streamlit python. It worked incredibly well, until it didn't. Seems like there is a critical project size where it just can't fix bugs anymore. Just tried this with Gemini CLI and the critical project size it works well for seems to be quite a bit bigger. Where claude code started to get lost, I simply told Gemini CLI to "Analyze the codebase and fix all bugs". And after telling it to fix a few more bugs, the application simply works.

We really are living in the future

replies(8): >>44378198 #>>44378469 #>>44378677 #>>44378994 #>>44379068 #>>44379186 #>>44379685 #>>44384682 #
agotterer ◴[25 Jun 25 17:15 UTC] No.44379685[source]▶
I wonder how much of this had to do with the context window size? Gemini’s window is 5x larger than Cladue’s.

I’ve been using Claude for a side project for the past few weeks and I find that we really get into a groove planning or debugging something and then by the time we are ready to implement, we’ve run out of context window space. Despite my best efforts to write good /compact instructions, when it’s ready to roll again some of the nuance is lost and the implementation suffers.

I’m looking forward to testing if that’s solved by the larger Gemini context window.

replies(3): >>44382389 #>>44383702 #>>44386731 #
data-ottawa ◴[26 Jun 25 02:24 UTC] No.44383702[source]▶
Does /compact help with this? I ran out of context with claude code for the first time today, so looking for any tips.

I'm trying to get better at the /resume and memories to try and get more value out of the tool.

replies(2): >>44383913 #>>44385223 #
1. agotterer ◴[26 Jun 25 03:21 UTC] No.44383913[source]▶
I thought I read that best practice was to start a new session every time you work on a new feature / task. That’s what I’ve been doing. I also often ask Claude to update my readme and claude.md with details about architecture or how something works.

As for /compact, if I’m nearing the end of my context window (around 15%) and are still in the middle of something, I’ll give /compact very specific details about how and what to compact. Let’s say we are debugging an error - I might write something along the lines of “This session is about to close and we will continue debugging in next session. We will be debugging this error message [error message…]. Outline everything we’ve tried that didn’t work, make suggestions about what to try next, and outline any architecture or files that will be critical for this work. Everything else from earlier on in this session can be ignored.” I’ve had decent success with that. More so on debugging than trying to hand off all the details of a feature that’s being implemented.

Reminder: you need context space for compact, so leave a little head room.