byjos.dev Blog RSS Feed

When AIs start gossiping about your code - Claude Code with Gemini CLI

Thu, 07 Aug 2025 17:00:00 GMT

What happens when you combine Claude Code’s conversational coding with Gemini CLI’s massive context window? A workflow that transforms how we understand and work with complex codebases.

The problem with large codebases

Ever joined a team and faced a codebase with hundreds of files? You know the feeling - opening file after file, trying to piece together how everything connects. Traditional grep commands and IDE searches help, but they can’t answer the big questions: “How does navigation work across all these Flutter screens?” or “Is state management consistent throughout the app?”

That’s where I discovered something interesting. Claude Code excels at detailed, conversational coding work, but it hits context limits with large projects. Gemini CLI, with its massive context window and planning capabilities, can digest entire codebases and provide strategic insights.

But here’s the key insight: they’re not separate tools you switch between. Claude Code can call Gemini CLI directly, creating something powerful.

The dream team: Claude + Gemini + Human

Think about it this way: Claude Code (even with Sonnet) is exceptional at actual coding - writing functions, debugging, refactoring. Gemini CLI brings massive context understanding and strategic planning capabilities. Add yourself as the code reviewer and senior software engineer, and you’ve got a small, experienced development team.

Claude handles the implementation details, Gemini provides the big-picture strategy, and you make the architectural decisions. It’s like having two consultants who never argue over who gets credit for fixing your mess 🤝

When Claude Code hits its limits

Working on a Flutter project recently, we hit a frustrating bug. Users reported that switching between tabs caused “LateInitializationError” crashes. The app used GetX for state management, and the error seemed to happen inconsistently across different screens.

Claude Code could help debug individual controllers beautifully, but this felt like a system-wide issue. The bug report mentioned it happened “sometimes on the Profile tab, sometimes on Settings, but always after rapid tab switching.”

The kind of bug report that makes you question your life choices and wonder if you should have become a baker instead.

That’s when I realized Claude Code could bring in its research assistant.

The actual workflow: Starting with Claude

Here’s the workflow that’s become second nature. I start where I always do:

claude

This opens Claude Code, and I switch to plan mode. But now I copy-paste the entire bug report, add my own context about what might be happening, and mention which files seem related.

“We’re getting LateInitializationError crashes in our Flutter GetX app. I think it’s related to how we’re initializing controllers in main.dart, profile_controller.dart, and settings_controller.dart. Can you analyze the entire codebase structure and help fix this?”

Real-world example: Fixing GetX late initialization

Here’s exactly how this played out:

1. Starting the conversation with context: I pasted the full bug report, stack traces, and added: “This seems to happen when users switch tabs rapidly. I suspect it’s related to GetX controller lifecycle. Files that might be relevant: /lib/controllers/, /lib/screens/profile/, /lib/screens/settings/.”

2. Claude Code coordinates the analysis: Claude Code is smart enough to call Gemini CLI with exactly what it needs for analysis. I don’t see the actual command it runs, but it gets a comprehensive view of how GetX controllers are initialized across the entire codebase.

3. Strategic insight emerges: The analysis revealed the issue: some controllers were being initialized with Get.put() in initState(), while others used Get.lazyPut() in routes. When users switched tabs rapidly, some controllers were disposed while others were still trying to initialize.

4. Implementation together: Claude Code and I worked through the fix:

Standardized all controller initialization to use Get.lazyPut()
Added proper dependency injection in the main binding
Ensured controllers had proper lifecycle management
Added null checks for late-initialized variables

5. The code review step: Here’s where it gets interesting. After Claude Code finished all the changes, I asked: “Can you use Gemini CLI to review these changes as an external peer? Check if the fix is consistent with GetX best practices across the entire codebase.”

The code review advantage

This review step was eye-opening. Gemini CLI, acting as an external peer reviewer, caught a few things we missed:

One controller still used the old initialization pattern
A potential memory leak in the settings controller
Suggested adding error boundaries around tab switching

It’s like having an external senior developer review your changes after implementation. Claude Code recently got automated security review capabilities, but using Gemini CLI as a code reviewer gives you that external perspective on any type of change.

The beautiful thing is it all happens in one conversation: “Claude, now ask Gemini to review these changes as if they’re a peer developer who hasn’t been involved in this implementation.”

Why this changes everything

What I love most is how this workflow handles everything from bug reports to feature requests. The pattern is always:

Start in Claude Code - paste the bug report, task description, add context
Provide guidance - mention which files might be relevant based on your experience
Let them collaborate - Claude Code and Gemini CLI work together on analysis and planning
Implement together - detailed coding work with Claude Code
External review - Gemini CLI reviews as a peer developer who wasn’t involved in implementation

Whether it’s fixing “late” initialization issues with GetX tabs or implementing new features, you get strategic overview, detailed implementation, and external code review in one seamless conversation.

The small experienced team effect

The key insight is that this creates something greater than the sum of its parts. Claude Code excels at coding conversations, Gemini CLI provides strategic context, and you provide the architectural vision and code review.

Together, it feels like working with a small, experienced development team where everyone has specialized strengths but communicates seamlessly.

Getting started

If you’re curious to try this workflow:

Install Gemini CLI and set it up
Next time you’re working on a complex codebase, start with claude as usual
Switch to plan mode and ask Claude Code to use Gemini CLI for big-picture analysis
Let the conversation flow naturally between strategic planning and detailed implementation

What’s next

This workflow has transformed how I approach complex projects, but I’m still discovering new applications. Recently, I’ve been asking Claude Code to use Gemini CLI for architecture reviews before major refactors, and the insights have been remarkable.

The real magic isn’t just about having better tools - it’s about creating a development environment where strategic thinking, detailed implementation, and code review happen in one seamless conversation. You end up building better software because you understand systems more deeply while maintaining the creative, conversational development experience we love.

The three-way collaboration between Claude Code, Gemini CLI, and human insight really does feel like working with a small, experienced development team. Each member brings unique strengths, but together they create something more powerful than any individual tool.

Have you tried combining AI tools in your development workflow? I’d love to hear about your experiences and what team dynamics work best for different types of projects.

GCP Workload Identity Federation - connecting with GitLab

Wed, 14 Sep 2022 17:00:00 GMT

Wondering if you can securely connect from Gitlab runner to GCP without generating service account keys? In this short post I’ll try to show you how to do it

All methods I found for now about connecting from Gitlab runner to gcloud via CLI or API, included the step of generating Service Account key and using it in job through CI/CD variables. For a few months, we are able to use Workload Identity Federation for making this connection more secure.

Workload Identity Federation

As you might know (or not?) generating service account keys is not a very secure practice if keys are not rotated. If a key like that is leaked you will need a block service account which may cause even production environments to stop working and then do rotation of keys.

Recently you might have heard about the leak of over 1 billion records of private citizens data because a key was leaked into a blogpost.

Workload Identity Federation (WIF) basically allows you to make secure connections between Gitlab (or other supported providers e.g. through OIDC) and Google Cloud.

Instead of generating access tokens from Service Account key, a short lived JWT token is used. This helps to increase security because even if a token is leaked it can’t be used in a short moment to get access to resources.

The same for generated json files for Workload Identity Federation. File can be leaked as it is not storing any secure information by itself. Without an option to sign a request to STS (Security Token Service) on Google Cloud, an attacker cannot acquire JWT token to access resources on your project.

From where Google Cloud STS knows that request to it is valid and signed? Gitlab sign request with its keys and it can be validated using published Gitlab OIDC configuration there https://gitlab.com/.well-known/openid-configuration.

Of course we should remember to use least privilege security principle and Service Account which we connect to WIF should have only required IAM permissions.

Modified graphic from blog post

Feature described below was working with Github as it has support for OIDC tokens. Gitlab enabled this feature too and using CI_JOB_JWT_V2 you can leverage Workload Identity Federation for secure connection.

The script

Script below is based on the GCP Blogpost tutorial on how to connect to Github.

Important step

Important change to blogpost code, is to allow Gitlab to be used as an audience in the Workload Identity Federation. Now you can set this too by hand when creating Pool from Google Cloud Console.

Important Step

Very important is to remember to set the audience to limit access to Identity Pool only to for instance given Gitlab project ID. It can be email or any other parameter from request. To do that, set the env variable and run the script. SUB=/attribute.project_id/29450825

#First, set PROJECT_ID example export PROJECT_ID=my-project
#Second, set so called SUB to make this connection work only with given Gitlab ID project.
#Example of sub export SUB=/attribute.project_id/29450825
#Last step, set Service Account name which will be used as a connection from Gitlab. export SA_NAME="my-service-account"

if [ -z ${PROJECT_ID} ];
  then echo ">> PROJECT_ID not set"; exit 1
else echo "PROJECT_ID set";
fi

if [ -z ${SUB} ];
  then echo ">> SUB not set, setting to *"; SUB="/*" ; exit 1
else echo "SUB set";
fi

if [ -z ${SA_NAME} ];
  then echo ">> Service account name (SA_NAME) not set"; exit 1
else echo "SA_NAME set";
fi

SERVICE_ACCOUNT_NAME="${SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com"
PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format="value(projectNumber)")
WORKLOAD_IDENTITY_POOL_ID="gitlab-identity-pool"
gcloud config set project ${PROJECT_ID}

echo ">> Creating Workload Identity Pool..."

gcloud iam workload-identity-pools create "gitlab-identity-pool" \
  --project="${PROJECT_ID}" \
  --location="global" \
  --display-name="Gitlab identity pool"

echo ">> Done. Creating OIDC provider in pool..."

gcloud iam workload-identity-pools providers create-oidc "gitlab" \
  --project="${PROJECT_ID}" \
  --location="global" \
  --workload-identity-pool="${WORKLOAD_IDENTITY_POOL_ID}" \
  --display-name="Gitlab OIDC provider" \
  --attribute-mapping="google.subject=assertion.sub,attribute.aud=assertion.aud,attribute.env=assertion.environment,attribute.project_id=assertion.project_id" \
  --issuer-uri="https://gitlab.com"

echo ">> Done. Enabling gitlab as audience..."

gcloud iam workload-identity-pools providers update-oidc gitlab --allowed-audiences=https://gitlab.com --location global --workload-identity-pool $WORKLOAD_IDENTITY_POOL_ID

echo ">> Done. Setting service account permissions..."

gcloud iam service-accounts add-iam-policy-binding $SERVICE_ACCOUNT_NAME \
  --project="${PROJECT_ID}" \
  --role="roles/iam.workloadIdentityUser" \
  --member="principalSet://iam.googleapis.com/projects/${PROJECT_NUMBER}/locations/global/workloadIdentityPools/${WORKLOAD_IDENTITY_POOL_ID}${SUB}"
echo ">> Done. Generating json configuration file..."

gcloud iam workload-identity-pools create-cred-config \
    projects/$PROJECT_NUMBER/locations/global/workloadIdentityPools/$WORKLOAD_IDENTITY_POOL_ID/providers/gitlab \
    --service-account=$SERVICE_ACCOUNT_NAME \
    --output-file=gitlab_token.json \
    --credential-source-file=gitlab_token \
    --credential-source-type=text

echo ">> Done. Use below configuration file in Gitlab project"

cat gitlab_token.json

You’ll get a file named gitlab_token.json which you can safely use and share in your project CI/CD variables. Example usage with gcloud CLI is

#If gitlab_token set as variable in Gitlab
- echo $CICD_SA_JSON > ${CI_PROJECT_DIR}/service_key.json
- export GOOGLE_APPLICATION_CREDENTIALS=${CI_PROJECT_DIR}/service_key.json
- echo $CI_JOB_JWT_V2 > gitlab_token
- gcloud auth login --cred-file=${CI_PROJECT_DIR}/service_key.json --activate --project $PROJECT_ID

#If token set as File tyle in Gitlab
- export GOOGLE_APPLICATION_CREDENTIALS=${CICD_SA_JSON}
- echo $CI_JOB_JWT_V2 > gitlab_token
- gcloud auth login --cred-file=${CICD_SA_JSON} --activate --project $PROJECT_ID

Job script can be different from case to case so feel free to ask me in comments or reach me on Twitter with questions.

I hope this will help you to make your pipelines safer. If you have any comments or improvement ideas, please share it :)

Google Cloud Run - hot service, happy users

Fri, 07 Jan 2022 17:00:00 GMT

Most of us like hot things. Hot meal, hot bath or hot weather. Some of us also like the hot state of serverless services without paying too much for it. In this post you can find out how to keep Cloud Run in hot state for free🔥

Cold and Hot states

In a previous blogpost you could read what Cloud Run is and it’s basics. For serverless services we can use the convention of having service in cold and hot states. Best scenario is when our service is always in hot state as it’s ready for responding to requests instead of booting every time.

Cold State

Service is “turned off” and sleeping. Often we are not paying for it and any incoming request needs to wait until service is woken up and ready for receiving requests.

In Cloud Run, cold state means that the Docker container is turned off and before the request can be handled we need to wait for the startup process (entrypoint script + app startup) of our program to end. It can differ from a few milliseconds to even a few minutes if we have a monolithic application (I saw this behaviour when I tried to run Keycloak on Cloud Run).

I have prepared a simple Go app which sleeps 5s before starting the server. In logs we can see that this will happen every time when an app is killed/exited and started again or a new revision is created. Users or other services will need to wait until all startup is done.

Other services calling it will have to wait and will be billed for it, so it’s not the best situation for us.

Hot State

This means that our app is ready for receiving requests. In a non serverless world it’s equivalent to just running an application all the time.

In Cloud Run hot state means that our container is not sleeping and is ready to handle requests even when in recent seconds/minutes it did not get any request. When you get eg. one request per second or half minute, it should be handled without any delay.

We need to also remember about CPU allocation which can be “request only” or “all the time” when an instance is live.

This is the best scenario for us and our users. From my experience, on production environments with stable and ongoing traffic we should have a hot state all the time.

But in case when we have differential traffic and non 24/7 our users might experience slowdowns or even timeouts. Below I’ll explain how to prevent this and keep users, business and devops happy.

You should optimize your app startup too as there is no guarantee that any of keeping hot methods will always work. If you don’t want to play with this you can always set a minimum instance count and have a hot state all the time but pay for it.

Rub your services?

When you are feeling cold you drink something hot, put on more clothes or rub yourself. I do not recommend trying the first two with your services but the third one option is possible!
If you manage to do the first two, contact me!

Are you alive aka health check

The simplest option is to do a regular health check of your service to monitor its state. This is what you should do by default (monitoring services).
Using a health check can be different depending on access type to your service.

Case 1 - my service has public URL and no auth

If you allow a public URL in Cloud Run (everyone can access it, IAM set to AllUsers Cloud Run Invoker) you can use any ping/health check service you have. In this scenario we can use GCP Operations uptime check and endpoint in your service which can even respond with only “pong” on default / path or /health.

To set this go to GCP Console -> Monitoring -> Uptime Check.

Set name of your uptime check. I’ll call mine “rub-my-service”.

Next we need to set how Monitoring will reach our service. For Cloud Run we set a public URL and optionally path to the endpoint. For basic uptime check we can leave default options. For the scheme we set HTTPS (as we can’t have an insecure endpoint with Cloud Run <3) and provide a url to it.

Next we can leave default settings for response timeout, skip content matching and not set alerts (but I recommend setting it). Before clicking “save” click “test” and you should see a green box with a successful response.

This will keep our service in hot state all the time with minimal cost (even 0$ if we keep it in free tier or requests/cpu/memory).

Runtime environment generation differences.

I have observed that for the First Generation runtime environment we can use a 5 minutes check frequency as it’s enough to keep the container in a hot state while when I was using Second Generation (beta) I had to set a 1 minute frequency check as my container tends to go to a cold state during a silent period.

Case 2 - my service has GCP Auth enabled

Now stuff gets a little more complicated. For now I did not find a way to leverage Uptime Check service with Auth enabled. When you try you’ll get just 403 responses and requests will not reach your app/container as they are blocked at GCP infra level.

We have at least two options:

I’m a greedy option

Often you have another service which is using your “authed” service and is a public one. Use it to do a health check of “authed” one with the previous strategy. If you use trace with your services you’ll be able to additionally monitor performance of this chain of requests.

I can spend penny option

If you are ok with spending “$0.10 per job per month” you can use Cloud Scheduler for this. It can use IAM Service Account with Cloud Invoker role which enables us to ping service with Auth enabled.

First we set the name, crontab and timezone of the job. I’ll set it to ping my service every 5 minutes.

Next we need to set a target. For Cloud Run use HTTP with full URL including schema. For Auth set OIDC token with created Service Account. Remember to set IAM permission Cloud Run Invoker for this Service Account in deployed service. You can read more about it in service-to-service auth docs.

You can leave the retry option with default settings. After the job is created click “Run Now” and you should see “Last run result” as “Success”.

Case 3- my service has ingress set to internal

For this case even when we set allow unauthenticated invocation we’ll get a 403 response when trying to access the URL. Resources which are trying to access your service needs to be in the same VPC which is not possible with all GCP products.
To read more about internal services ingress with Cloud Run visit docs.

As we see in docs, we can access our service using PubSub, EventArc or Workflows. The simplest way will be to use the previous Cloud Scheduler method with PubSub push subscription.

When you set your scheduler to use PubSub your message will reach your service but with POST method instead of GET so you need to be ready to handle it.

Cloud Scheduler connected to PubSub will return Success every time if it’s properly configured so we can’t use this method to monitor the health of our service.

PubSub uses push to our Cloud Run internal service. We can use OIDC token if we set Auth required for our service.

PubSub POST requests can reach our service and ping it.

There are few other methods which can leverage Workflows or creating serverless connectors but I think the described one is the simplest one if you just want to ping your service from time to time.

Self rubbing…

Some say that you can go blind when you do it ( ͡° ͜ʖ ͡°) but our services should be safe. This is not the prettiest way to keep services hot but is kind of an option.

Your container will receive a system event SIGTERM. From this time you have 10 seconds to handle it. Often you close DB connections, flush logs and traces and prepare app to close before receiving SIGKILL.

Solution is to use this 10s period to do a request to itself and make service in hot state again.

Using this simple Go program you can see how this can work. Again, I’m not recommending this solution but it works.

package main

import (
	"fmt"
	"log"
	"net/http"
	"os"
	"os/signal"
	"syscall"
)

func hello(w http.ResponseWriter, req *http.Request) {
	fmt.Fprintf(w, "hello\n")
}
func health(w http.ResponseWriter, req *http.Request) {
	fmt.Fprintf(w, "pong\n")
}

func main() {

	sigc := make(chan os.Signal, 1)
	signal.Notify(sigc, syscall.SIGTERM)
	go func() {
		s := <-sigc
		fmt.Printf("caught signal %s: selfrubbing...\n", s)
		_, err := http.Get("https://selfrubtest-x2hv5vxupa-lm.a.run.app/health")
		if err != nil {
			log.Fatalln(err)
		}
	}()
	http.HandleFunc("/", hello)
	http.HandleFunc("/health", health)
	http.ListenAndServe(":8080", nil)
}

Summary

As you can see there are multiple ways to keep your Cloud Run services in hot state for free or very cheap. This will make your users, other services and devops team happy. In next blog posts we’ll look at other features of Cloud Run. If you have any questions on this topic let me know in the comments :)

Google Cloud Run - serverless heaven?

Sat, 01 Jan 2022 17:00:00 GMT

So what is serverless? Server in someone’s datacenter, magical animal or easier to use services? Some of the answers are yes. Let’s dive into Google Cloud Run service to see how easy it is to be“cloud native” with a secure and simple deployment solution.

What is serverless

Often serverless services mean that they are in pay as you go “subscription” allowing you, as a user, to reduce costs. If you don’t have 24/7 traffic, you are probably overspending money. Often with serverless comes other benefits such as:

increased security
less infrastructure maintenance
ease of deployments

First serverless service on Google Cloud Platform was App Engine which is still available as a product. It was announced and released in preview in 2008 then released in GA in 2011.

Serverless options on GCP

Google Cloud Platform has a broad offer of serverless services such as Firestore, Workflows or DataFlow but today we’ll talk only about so-called Compute services.

Appengine

First serverless offer on GCP. Right now it can be used in two modes: Standard and Flexible.

Standard mode allows you to use only a set of languages but also can scale to 0 instances when there is no traffic.

Flexible mode allows you to use a more broad set of languages and libraries but there is always one active instance.

When you once create an App Engine service you are not able to change regions and for example scale your solution globally. But in one selected region this will work flawlessly and will be able to handle huge traffic.

Cloud Functions

Functions(FaaS) was released as a solution for event-driven architectures. V1 offers support only for a selected set of programming languages. Functions are often small code portions running independently which also allow easier scalability.

With V2 generation which are based on Cloud Run you’ll be able to overcome V1 limitations and use more languages, connect to more GCP services and get better performance.

Cloud Run

Cloud Run is the latest serverless product of GCP which we’ll focus on today. It may feel like it’s connecting the best parts of two previous, easy deployment in any available region, scaling to 0 when no traffic and good performance with even up to 4vcpu and up to 16GB of RAM (in preview).

What is Cloud Run

Cloud Run is a service where you deploy your code in a Docker container using any language you want (there are examples of running Cobol on Cloud Run!).

All containers running on Cloud Run are in a secure gVisor sandbox so not all syscalls might be accessible, but from my experience I didn’t have any problems. Recently published second generation of Cloud Run has full Linux compatibility and should support all syscalls.

Your deployed container has one public port and by default gets an https url endpoint which can be additionally secured excluding external traffic or requiring service-to-service authentication. So no need to worry about setting up Let’s Encrypt certbot and any other complicated stuff.

Cloud Run is connected to GCP Operations so you get Logging + Tracing in a box which makes it easier to track and measure performance of your application.

Easy deployment and security

Deployment

As mentioned before, you need to have a Docker container to deploy it on Cloud Run Service as new Revision.

Images need to be stored on GCR in any available region (Global, Europe, Asia). To push it there you can use commands like docker build and docker push but there are also easier ways to do it with GCP CLI.

When you go to your project directory and type gcloud run deploy --source=./ it will trigger the build of the container using Buildpack. When done, it will be pushed to GCR and then deployed to Cloud Run. So using just one command you can make your app live. From what I saw this often works well but generated containers tend to be quite big. This may have changed in recent times but if you don’t want to spend time creating the best Dockerfile you can, just use it.

Security

When deployment finishes you’ll get an individual URL with SSL and blocked public access to it. This might look like https://gateway-<hash>-lm.a.run.app and when you try to open it you’ll see error

Error: Forbidden
Your client does not have permission to get URL / from this server.

This is because by default group allUsers doesn’t have access to invoke your service. You can change this behaviour in tab Triggers or Permissions and add allUsers to the IAM list with permission Cloud Run Invoker. From my experience it’s better to manage it in Permissions as changing in tab Triggers might remove previously added users, groups or service accounts.

Thanks to these IAM rules you can access your application from other GCP services (not only Cloud Run) without making it accessible to everyone. This is called service-to-service authentication.

In future posts I’ll cover more features of Cloud Run like network access control, connecting to GCP Load Balancer, streaming data with gRPC, different CPU allocations or how to keep Cloud Run always in hot state.

Hello World

Sat, 30 Oct 2021 14:14:03 GMT

This is my first post on my new webpage.

I’m sure I’ll write a lot more interesting things in the future.