I recently spent 1.5 hours debugging what should've been a simple Postgres connection issue while using Google's Gemini CLI. The task? Connect a FastAPI backend to a Dockerized Postgres instance using credentials stored in a .env file.

It wasn't a hard problem.

But Gemini CLI made it hard.

The Problem

I had spun up a Docker container with:

docker run --name ai-paper-digest-app-db \
  -e POSTGRES_USER=postgres \
  -e POSTGRES_PASSWORD=myrootpassword \
  -e POSTGRES_DB=appdb \
  -p 5432:5432 -d postgres

My .env looked like:

DATABASE_URL=postgresql://appuser:apppassword@127.0.0.1:5432/appdb

The result?
fe_sendauth: no password supplied or FATAL: role "appuser" does not exist

Gemini's response: restart the container, reset the password, change the host, try no password, change the user, try trust, prune Docker, run diagnostic Python scripts. Again. And again. And again.

The Real Issue

Claude solved it in under 5 minutes:

"You're using appuser in your connection string, but your Docker container initializes with postgres as the only user. Update your .env file to use postgres:myrootpassword, or create appuser manually inside the DB."

Done. Fixed. No loops, no guesswork, no overengineering.

What Gemini Got Wrong

Gemini CLI felt like pair programming with a junior engineer who knows the playbook but hasn't learned when to break from it.

  1. Overfocus on mechanics, not causality
    It kept suggesting fixes without validating if the assumptions were even correct.
    It never asked: "Does the user you're trying to connect with even exist?"

  2. Checklists over critical thinking
    Gemini defaulted to docker cleanup scripts, recreations, and password resets instead of debugging like a human:

    • Who's the user?
    • What's the password?
    • Does the .env reflect that?
    • Is the user in the DB?

  3. No observability
    It didn't run docker logs, psql \du, or SELECT 1; until much later. These are basic sanity checks any dev would run within minutes.

What Claude Did Differently

Claude debugged like a senior engineer:

  • Pattern recognition: Instantly noticed the user mismatch.
  • Hypothesis-first: Didn't guess wildly — validated key assumptions first.
  • Minimal steps: Reset once, cleanly, with a corrected POSTGRES_USER and .env alignment.
  • Clear feedback loop: Used psql, Docker logs, and connection tests quickly to validate assumptions.

What This Taught Me

Using LLMs in dev workflows isn't just about code generation. It's about debugging support, problem-solving style, and how they think.

Gemini CLI felt like a flowchart. Claude felt like a mentor.

As LLMs get embedded deeper into our tools (IDEs, CLIs, terminals), this distinction will matter more than benchmarks or model size.

My Ask to the Gemini Team

If you're building tools for developers:

  • Teach your models how to debug.
  • Prioritize observability and inference over verbose explanation.
  • Build hypothesis-first agents that can test and adapt instead of relying on rigid playbooks.

Until then, I'll keep Claude nearby when I need to get unstuck fast.