Uncategorized

Recently, Google launched Gemini CLI, an open-source AI agent for the command line.

In the announcement, they mention that the tool isn’t just for coding—it supports many other tasks as well. It also comes with very generous usage limits for the free version.

One feature that especially caught my attention is the ability to access web content and invoke Gemini CLI as part of a script.

In addition, Gemini CLI complements Google’s programming assistant, Gemini Code Assist, by providing an agent mode. Gemini Code Assist integrates into the IDE, which is definitely another reason to give this tool a try—I’ve added it to my to-test list.

It looks like Google is making a serious push to position itself as a major player in the AI-powered developer tools space.

Let’s Get Started!

I head over to the project’s repo: https://github.com/google-gemini/gemini-cli

First Impressions

The README highlights features like support for large codebases, task automation, the ability to analyze PDFs or images, and integration with tools via MCP for generating images or performing Google searches.

Installation

Gemini CLI is written in TypeScript and requires Node.js 18 or higher.

In my case, I install the tool on both of my usual work environments—Ubuntu Linux and macOS—where I already have Node.js 22.14.0 installed (with nve), using the following commands:

npm install -g @google/gemini-cli
gemini

There’s also an option to run Gemini CLI without installing it:

npx https://github.com/google-gemini/gemini-cli

It welcomes me with a screen where I can choose a theme. From the available options, I pick Dracula, one of the dark themes with more contrast than the default.

Next, it prompts me to authenticate. I choose Login with Google, confirm in the browser, return to the terminal—and hit my first issue:

Failed to login. Message: This account requires setting the 
GOOGLE_CLOUD_PROJECT env var. See https://goo.gle/gemini-cli-auth-docs#workspace-gca

Apparently, the issue is that the account I used is linked to Google Workspace. I switch to another account, and finally, the tool becomes usable.

Commands

Before diving into prompts, I type a forward slash / to display the list of commands:

These stand out to me:

• /chat <list|save|resume> [tag] to manage conversations—similar to chat management in Gemini, I assume.
• /compress compresses the context and replaces it with a summary—very interesting, curious to see how it performs with code.
• /editor lets you choose the external editor—I’m sticking with Vim for now.
• /mcp shows configured MCP servers—none yet.
• /memory <show|refresh|add> to manage memory stored in files (e.g., GEMINI.md)
• /tools shows what tools Gemini CLI has access to. Includes tools for filesystem access, downloading web content, running Google searches, and executing shell commands.
• /help shows available commands and notes that you can refer to files using @ (e.g., @src/myFile.ts) or execute shell commands using ! (e.g., !git diff)

There’s no obvious way to change the model, which defaults to gemini-2.5-pro. So I check the gemini command options and—voilà—-m allows model selection. However, it’s unclear which models are supported. After a few Google searches, I find that you can pick a model if you have an API key from Google AI Studio, but you can also switch to the flash model with:

gemini -m gemini-2.5-flash

In any case, the usage limits for the pro version are generous (in theory) and more than enough for many use cases.

Testing Memory

Let’s try the memory. I tell it to remember my name:

/memory add My name is Cesar

This creates a .gemini/GEMINI.md file in my home directory, with a line containing just that info.

The surprise: when I ask for my name, it says it doesn’t know—even though it indicates it’s using the memory file:

> What is my name?
✦ I do not know your name. I am a large language model and do not have access to personal information about you.

Let’s try a fact:

/memory add Our sales in 2024 were 2.5 million
What were our sales in 2024?
I do not have access to your sales data for 2024

Still nothing. Strange.

> Dump the facts in your memory
✦ I cannot directly dump the facts in my memory. I can save information using the save_memory tool, but there is no tool available for me to retrieve or display what has been saved.

Something’s definitely not working.

I close and reopen the tool, and now it seems to be using memory:

> What is my name?
✦ Your name is Cesar.

But when adding new information, the same issue reappears. I thought it might be intentional, but the tool’s feedback says otherwise:

ℹ Memory refreshed successfully. Loaded 167 characters from 1 file(s).

Let’s check the docs. I type /docs and it opens the browser. Everything I find says /memory refresh should load data into context—but it’s clearly not working right.

I search the GitHub issues and find a vaguely related one, so I go ahead and open a new issue.

Hierarchical Memory

Project memory is organized using GEMINI.md files in plain Markdown.
There’s a global file in the user’s home directory, and project-specific files.

Within a project, there’s usually one in the root for general info, and others in subdirectories with more specific details.

When reasoning is required, the files are concatenated in order, from general to specific—so local definitions override global ones.

Example: the general convention is UpperCamelCase, but files in the assets folder use snake_case.

You define the general rule in the root GEMINI.md, and the exception in a GEMINI.md inside the assets folder.

Let’s Try a Real Project

Analyzing the Project

I run gemini inside a project’s source directory.

First, I ask:

What is this project?

It reads three files (NEWS, app/build.gradle.kts, and settings.gradle.kts) and correctly infers many details (omitted for confidentiality) and the tech used:

The application is built using modern Android technologies, including Kotlin, Jetpack Compose for the UI, Hilt for dependency injection, Room for the local database, and MapLibre for maps.

Now let’s ask it to generate the hierarchical memory files:

Perform an exhaustive analysis of the code base and create the hierarchical memory files to retain key details of the project. Generate GEMINI.md to be committed as part of the project.

It creates a root GEMINI.md file with a technical report including:

• Project overview (purpose, main features by user role, core technologies)
• Code structure (organization, architecture like MVVM and a Clean Architecture variant)
• Build and test (build variants, test methodologies, key files)

It’s more of a report than I expected—I was hoping for something shorter and split across multiple files with more precise, context-usable info. Still, it’s worth testing.

Generating Code

Let’s test it with a basic task: writing unit tests for a mapper class:

Add tests for @app/src/main/java/org/gc/octopus/app/data/mappers/GearCompositeWithStateMapper.kt in @app/src/test/java/org/gc/octopus/app/data/mappers/GearCompositeWithStateMapperTest.kt

I kept the prompt as simple as possible to see if it would infer and follow the project’s style.

Using @ triggers a file search. It’s easier than typing full paths, though the results can be polluted with temp or generated files.

It works quickly, reads other test files, and the previewed code follows the existing style. I accept the changes, and it stops there.

I review the generated code—there’s a compile error. I ask:

The code does not compile. Fix it.

It asks permission to run gradlew, which I allow. It works for about 4 minutes, iterating until it finishes.

The result is solid and fits the project’s style well. I notice one test case is missing, so I ask:

Add a test to verify when elements is not empty

This time it hangs on Planning the implementation. After 5 minutes, I hit CTRL+C twice, which kills the session. Oops!

Skipping the details—but in a new session I finally get the test added.

Other Uses

Calling from a Script

You can run gemini from a script or pipe input to it. For example:

$ sudo dmesg | gemini -p "This is a dmesg output. Provide a hardware summary" -m gemini-2.5-flash

Result:

Here’s a summary of your hardware based on the provided dmesg output:

Motherboard:

• Manufacturer: Gigabyte Technology Co., Ltd.
• Model: B760M DS3H DDR4
• BIOS Version: F19 (dated 09/27/2024)

Processor (CPU):

• Model: 13th Gen Intel(R) Core(TM) i7-13700
• Cores/Threads: 24
• Clock Speed: 2.1 GHz (TSC detected at 2112.000 MHz)

Memory (RAM):

• Total RAM: 32 GB

General Use

For general use, the Gemini web chat is more practical—auto chats, canvas, other options. Still, the CLI can be handy for quick queries—and it (supposedly) has more generous limits.

Google Searches

Let’s try:

Search online the weather forecast for the next week in Tarragona and provide a summary

Works fine:

GoogleSearch Searching the web for: “weather forecast next week Tarrago…
✦ Here is the weather forecast for Tarragona for the next week:

• June 30: Sunny, 25–32°C
• July 1: Mostly sunny, 25–35°C
• July 2: Scattered clouds, 25–33°C
• July 3: Sunny, 24–31°C
• July 4: Clouds + chance of thunderstorms, 23–32°C
• July 5: Light rain chance, 22–31°C
• July 6: Possible light rain, 22–30°C
• July 7: 40% chance of rain, 21–27°C

Accessing Website Content

Provide a summary of the contents of my webpage: https://cesarmauri.com/

Works without issues.

And then I hit the first usage limit:

ℹ ⚡ Slow response times detected. Automatically switching from gemini-2.5-pro to gemini-2.5-flash for faster responses for the remainder of this session.
⚡ To avoid this you can either upgrade to Standard tier. See:
https://goo.gle/set-up-gemini-code-assist
⚡ Or you can utilize a Gemini API Key. See:
https://goo.gle/gemini-cli-docs-auth#gemini-api-key

Ouch. I seriously doubt I hit the supposed 1000 daily request limit. Maybe those “generous” limits aren’t so generous after all? We’ll see.

Conclusions

This first hands-on with Gemini CLI shows that Google is serious about competing in the AI-assisted development tools space. The tool is clearly developer-friendly: command-line-based, open-source, and extensible via scripts—giving developers more visibility and control over how it behaves.

While not fundamentally different from tools like Cursor or GitHub Copilot, it brings some unique features: the CLI interface and the file-based hierarchical memory system using GEMINI.md files, which—if used well—could significantly enhance context customization.

It also supports web access, shell command execution, and external data/file processing—something not all assistants offer. However, it currently only supports Gemini models. While Gemini 2.5 Pro performs well for coding tasks, this limitation may weigh against it versus more flexible alternatives. Personally, I often prefer Claude Sonnet 4 for coding—it produces better results in my experience.

The tool is still rough around the edges: some features are buggy or underdocumented, and using it still takes a bit of patience and trial-and-error.

That said, the (supposedly) generous free-tier limits and its focus on practical dev tasks make it an interesting tool to incorporate into the workflow—at least as a complement.

In the vibrant universe of software development, some topics, like true classics, always ignite passionate debate. We’re talking about those eternal discussions that divide the community: tabs or spaces? vi or emacs? Similarly, frameworks hold a privileged spot on this list of “things that stir up passions.”

Just like other fundamental tools (programming languages or text editors), frameworks leave no one indifferent. And for good reason, because they undeniably have a beneficial side.

The Friendly Face of Frameworks

There’s no denying that frameworks are an unquestionable help. When used correctly, they are a powerful tool that allows us to elevate the quality of the final product. Why? Because they offer us the opportunity to reuse common logic that has already been tested and polished. This translates into fewer errors and more efficient development.

Additionally, frameworks are excellent for establishing a guide, a way of working that promotes a common language among all users. They create a true ecosystem, acting as magnets that attract other developments and contributions, thus enriching the whole.

When the Framework Becomes a Problem

But like in any good story, there’s a turning point. The problem arises when the framework becomes the absolute center of our development, conditioning and ultimately negatively impacting our project.

Let me illustrate with an example. The vast majority of modern web frameworks (I’m thinking of Spring Boot, Django, or Laravel, with which I’ve had the pleasure of working) come with an integrated ORM (Object-Relational Mapping).

Often, ORM entities are used directly as domain models. For relatively simple CRUD (Create, Read, Update, Delete) projects, this can be a perfectly valid solution, even the best option. No need to be dogmatic. However, when we delve into more complex business domains, this practice often becomes a real liability.

Let’s see why:

1. Rigidity in Domain Modeling When ORM entities are used as domain models, especially in projects with complex business logic, design freedom is diminished. Instead of using Plain Old Java Objects (POJOs) or similar plain classes that offer total flexibility to model the domain as best suits business needs, the developer is limited by the ORM’s restrictions and expectations. This can lead to a suboptimal design that prioritizes framework convenience over the true nature of the business.
2. Difficulty Adapting to Changes or Evolving If our business logic is tightly intertwined with specific framework functionalities (like an ORM), any attempt to switch to another technology or even to update the framework to a major version can become a real nightmare. Every modification in the framework could demand significant changes in our domain code, which increases maintenance time and cost.
3. Increased Complexity for Unit Tests The coupling between our domain models and the ORM makes unit testing pure business logic difficult. Often, it’s necessary to mock or initialize parts of the ORM for tests to work, rather than being able to test our domain classes in isolation. This not only slows down the development cycle but can also compromise the reliability of the tests.
4. Excessive Framework Dependency Making the framework the “center” of our development makes us overly dependent on its design decisions and features. If the framework stops receiving support, or if a key functionality is removed or drastically modified, our project can find itself in a very complicated situation. Lower coupling would allow for a much simpler framework change or migration if necessary.

In summary, the main disadvantage lies in the loss of flexibility and control over our own business code. We are forced to adapt to the framework’s way of working, rather than designing a solution that is truly efficient and adaptable to the specific needs of our domain. Remember, the framework is just a detail. 

The other day, I was listening to an interview with John Ousterhout, a computer science professor at Stanford and author of “A Philosophy of Software Design.” The concept of a “tactical tornado” really caught my attention. Here’s what it means:

Read more

I usually structure my codebase following Clean Architecture principles, which helps ensure scalability.

If you look at the root folder structure of the projects I work on, you’d see something like this (for more complex projects, it might vary, but the general idea remains the same):

Read more