DEV Community: Domenico Tenace

OpenRouter: One API Key to Rule Them All 🔑

Domenico Tenace — Wed, 12 Aug 2026 07:20:51 +0000

Overview

Hey everyone 👋

Managing AI models in 2026 has gotten ridiculous. Anthropic key here, OpenAI key there, a separate billing account for Google, another for Mistral, and if you want to try DeepSeek you're adding yet another dashboard to the pile. It's chaos.

OpenRouter fixes this. One API key, one credit balance, 300+ models. I've been using it as the backbone of my AI setup for a while now, and recently I wired it directly into OpenCode, which made the whole workflow click into place.

Let me explain how it all works. Let's dive in! 🤙

What Is OpenRouter? 🤔

OpenRouter is a unified API gateway that sits between your application and the underlying LLM providers. You send a request to OpenRouter, it forwards it to the model you specified, and returns the response in a normalized OpenAI-compatible format.

The catalog currently covers 300+ models from every major provider: Anthropic, OpenAI, Google, Meta, Mistral, xAI, DeepSeek, Qwen, NVIDIA, and dozens of smaller ones. You switch models by changing a single parameter in your request. No code changes, no new integrations, no new billing accounts.

It's also OpenAI SDK-compatible, which means if you're already using the OpenAI client in your code, you change the base URL and the API key, and everything else works unchanged.

How It Works 🔧

The setup is three steps:

Create a free account at openrouter.ai
Add credits via credit card or crypto (no minimum purchase, no expiration)
Generate an API key and use it across all your tools

From that point on, switching models is just changing a string. If you were calling Claude Sonnet directly through Anthropic and want to test Gemini Flash or DeepSeek for the same task, you change one line. That's it.

Provider Routing and Fallbacks

One of OpenRouter's strongest practical features is automatic provider fallback. Many popular models are served by multiple infrastructure providers. If one returns an error or hits capacity, OpenRouter silently routes to an alternative and your request succeeds. You don't write retry logic for this, it just works.

There's also an auto-router mode: set the model to openrouter/free and OpenRouter selects the best available free model for your request based on what it needs, structured output, tool calling, image understanding, and so on.

The Free Tier

OpenRouter offers around 29 free models at any given time, including Llama 3, Gemma 4, DeepSeek Flash, Qwen3, and others. Free accounts get 50 requests per day without adding credits, and 1,000 per day after a first top-up.

The free model lineup shifts as providers change their policies, so treat it as a useful resource for prototyping, not a guaranteed production tier.

Pricing: What You Actually Pay 💰

This changed significantly in 2025. OpenRouter used to add per-token markups on top of provider pricing. That model is gone.

The current structure is straightforward: a flat 5.5% fee on credit purchases, and provider token prices passed through at cost. So if Claude Sonnet 4.6 is $3/$15 per million tokens at Anthropic, you pay $3/$15 on OpenRouter. The only overhead is the 5.5% you paid when you loaded credits.

The one additional charge: if you bring your own provider API keys (BYOK) and exceed 1 million requests per month, there's a 5% fee on usage beyond that threshold. Below 1M requests it's free to route through your own keys.

To put it concretely: loading $100 in credits costs $105.50. Everything you buy with those credits is at direct provider rates.

For hobbyists and developers running multiple models, this is genuinely competitive. For enterprises burning millions of tokens per day, negotiated direct rates might beat it, but you'd have to be at serious scale.

OpenRouter + OpenCode 🔗

This is the combination I've been running, and it's become my default setup.

OpenCode supports any OpenAI-compatible endpoint, which OpenRouter is. You point OpenCode at OpenRouter, set your API key, and from that moment you can use any model in OpenCode's model selector without managing separate credentials for each provider.

The practical benefit is flexibility without friction. When I want to try Qwen3 Coder for a refactoring task, I switch the model in OpenCode. When I need Claude Opus for something that requires stronger reasoning, I switch back. One balance covers everything.

It also means I'm not locked into any single provider's availability. If Anthropic has downtime, I route through Gemini or DeepSeek without touching my workflow. OpenRouter's provider fallback does the heavy lifting.

The Pros 👍

One API key and one billing account replace every separate provider integration you'd otherwise manage. For teams or individual developers using more than two models regularly, that alone justifies the overhead.

The OpenAI-compatible API means zero migration cost if you're already using the OpenAI SDK. Change the base URL, change the key, done.

Provider fallback is genuinely useful in production. You stop worrying about individual provider outages because OpenRouter handles the retry layer for you.

The free model catalog gives you a real prototyping environment at zero cost. Qwen3 Coder Free and DeepSeek Flash Free are capable enough for a lot of development tasks.

Transparent pricing with no hidden per-token markups. The 5.5% credit fee is upfront and easy to account for.

The Cons 👎

The 5.5% credit fee is real money at scale. If you're running high-volume production workloads, that overhead adds up. Direct provider APIs will be cheaper once you're large enough to negotiate rates.

Credits don't expire, but they also aren't refundable. You're committing capital upfront even if your usage patterns shift.

Free model availability is unstable. Providers can remove free-tier access at any time and OpenRouter has no control over it. Don't build a production workflow that depends on a specific free model being there next month.

Enterprise teams needing RBAC, per-team budgets, audit logs, and VPC-native routing will hit a ceiling. OpenRouter is primarily a routing and billing layer, not a governance platform. For stricter compliance needs, something like LiteLLM self-hosted or Portkey might be more appropriate.

The auto-router mode (openrouter/free) is convenient, but the model selection varies between requests. If you need consistent output style across sessions, pin a specific model ID instead.

Who Should Use OpenRouter? 🎯

OpenRouter is the obvious choice if you're using more than one or two AI models regularly and don't want to manage the overhead of multiple accounts and billing setups. For individual developers, it removes a real operational annoyance.

It's also the right call for tools like OpenCode that support BYOK or custom endpoints but don't manage multi-provider routing themselves. OpenRouter becomes the infrastructure layer your tool sits on top of.

Where it makes less sense: pure Anthropic shops that only need Claude, or enterprises with compliance requirements that need on-premise routing and audit trails. For those cases, the flexibility isn't worth the trade-offs.

Final Thoughts 🌟

OpenRouter started as a scrappy model aggregator with 30 models. In 2026 it's become the most important middleware layer in the independent developer's AI stack, and the pricing reform that eliminated per-token markups made it significantly more honest to use.

The combination with OpenCode is what made it click for me. Instead of managing Anthropic and Google credentials separately, I load credits into OpenRouter once and switch models from OpenCode's interface as needed. It's the kind of setup that removes decisions you don't want to be making mid-task.

One key, one balance, hundreds of models. For how messy the provider landscape has gotten, that's a genuinely useful simplification.

Happy coding! ✨

Hi 👋🏻

My name is Domenico, software developer passionate of Open Source, I write article about it for share my knowledge and experience.

Don't forget to visit my social links to discover my links and to check out Domenico Tenace Open Labs for my open-source projects! 🫰🏻

🌲 Links: https://links.domenicotenace.dev/

🐙 Domenico Tenace Open Labs: https://github.com/Domenico-Tenace-Open-Labs

If you like my content or want to support my work, you can support me with a small donation. I would be grateful 🥹

OpenCode: The Open Source Coding Agent That Doesn't Lock You In 🔓

Domenico Tenace — Wed, 05 Aug 2026 08:00:00 +0000

Overview

Hey everyone 👋

If you've ever hit your Claude Code token limits mid-task, wondered what's happening under the hood of a closed-source agent, or just wanted to plug in a different model without switching tools entirely, OpenCode might be exactly what you were looking for.

It's the open source alternative that took the terminal agent concept and made it model-agnostic, and by mid-2026 it had already surpassed Claude Code on GitHub stars. That's not a coincidence.

Let me break it down. Let's dive in! 🤙

What Is OpenCode? 🤔

OpenCode is an open source AI coding agent built in Go that runs in the terminal, desktop, and IDE. Its thesis is simple: you bring the model, OpenCode brings the agent. It supports 75+ LLM providers, from Claude and GPT to local models via Ollama, doesn't store your code, doesn't charge a subscription, and over 7.5 million developers use it monthly.

It was built by the SST team, the same people behind the popular serverless framework. The design is a client/server architecture, not a single CLI binary, so one backend drives a terminal TUI, a desktop app, and IDE extensions for VS Code and Cursor.

OpenCode surpassed Claude Code on GitHub stars (160K+ vs 122K+) and is now the most starred open source coding agent. It does what Claude Code does, but lets you plug in any model from 75+ providers, including local models at zero API cost.

How It Works 🔧

Installing OpenCode takes about 30 seconds:

curl -fsSL https://opencode.ai/install | bash

You land in a polished TUI with two modes, Build and Plan. Build mode executes tasks directly. Plan mode is read-only, it lets the agent analyze your codebase and propose an approach before touching a single file. This is the separation of intent and execution that Claude Code doesn't make as explicit.

The design choice that matters most is the one in the name. OpenCode separates the agent harness from the model. Claude Code is tuned end to end around Anthropic's models and talks to them and only them. OpenCode connects to 75+ providers through Models.dev, including Anthropic, OpenAI, Google, Moonshot, Z.ai, local runtimes through Ollama, and any OpenAI-compatible endpoint you hand it.

You can switch models mid-session without restarting. That alone is a feature Claude Code doesn't have.

The Pricing Reality 💰

This is where OpenCode makes its strongest argument. There's no subscription for the software itself, you pay for model access directly.

The options as of mid-2026:

Bring your own key: pay the provider directly at their posted rates. Full flexibility, full cost visibility.

OpenCode Zen: a pay-as-you-go hosted gateway with access to many models.

OpenCode Go: $5 for the first month, then $10/month. Includes access to capable open models like GLM, Kimi K2, Qwen, DeepSeek, and MiniMax with generous per-session request limits.

Compare that to Claude Code's $20/month Pro, $100/month Max 5x, or $200/month Max 20x plans. For individual developers or small teams watching their AI spend, the math is clear.

The caveat: cost visibility helps when you are counting. Once you settle onto a flat Max plan, the math changes. If you're a power user who hits their limits constantly, Claude Code's flat rate might actually be cheaper per task.

The Anthropic Block: What Happened and Where It Stands 🚧

This is the part of the story that redefined what OpenCode actually is.

On January 9, 2026, Anthropic changed its OAuth policy to block third-party applications from authenticating users through Claude.ai accounts. OpenCode was the primary casualty: users who relied on their Claude Pro login lost access overnight. The official reason was "security and ToS compliance."

The January block made that choice less about saving money and more about philosophy. You are no longer choosing a cheaper way to run Claude. You are choosing whether you want a managed product or an open one.

Where it stands today: you can still use Claude models in OpenCode, but only through an Anthropic API key, not your Claude.ai subscription credentials. The more lasting impact was reputational: it accelerated many users migrating to Gemini as their default backend.

OpenCode vs Claude Code: The Real Differences 🥊

Terminal experience

OpenCode tends to win here, and it wins on feel. The TUI is the repeated favorite in nearly every comparison thread. The terminal does not flicker on each update, sections scroll independently, and planning prompts are easy to answer. OpenCode also ships a standalone Tauri desktop app for macOS, Windows, and Linux, something Claude Code doesn't have.

Autonomy features

Claude Code has a wider toolset: Agent View for fleet management, /goal for fire-and-forget autonomous runs, instant rewind via double-Esc, and background monitoring. OpenCode has background subagents and sessions that survive a terminal close, but lacks the orchestration depth.

Output quality

A controlled benchmark found Claude Code faster and OpenCode more thorough using the same model. The summary: "Claude Code is built for speed. OpenCode is built for thoroughness."

One practical issue to know about: multiple testers reported that OpenCode, across all tested models, reformats existing code without authorization. On mature codebases with established style guides, this is a trust issue. There's an open GitHub issue tracking this, and it's the most common complaint in real-world use.

The Pros 👍

True model freedom. No other terminal agent lets you swap between Claude, Gemini, DeepSeek, Qwen, or a local Ollama model mid-session. This is OpenCode's defining advantage.

Open source and inspectable. You can read the codebase, fork it, self-host it, and know exactly what the agent is doing with your code. Claude Code is closed source.

Better terminal UX. The TUI is genuinely nicer. Non-flickering updates, scrollable sections, a dedicated desktop app.

Cost control. Bring your own key, use local models at zero cost, or pay $10/month for the Go tier. The ceiling is much lower than Claude Code's $200/month Max plan.

Data compliance. Teams with strict data requirements can point OpenCode at a local or self-hosted model so code never leaves their network.

The Cons 👎

The code reformatting issue. OpenCode has a known tendency to reformat existing code without being asked. On mature codebases this creates noisy diffs and erodes trust in the agent's edits. Not a dealbreaker, but worth knowing.

Thinner plugin ecosystem. Claude Code has a more mature skills, hooks, and plugin marketplace. OpenCode's extension catalog is catching up, but it's not there yet.

No subscription path for Claude. If you're paying for Claude Pro or Max, you can't use that credit in OpenCode. You need a separate API key, which means paying again.

Fewer autonomous orchestration features. /goal mode, Agent View, instant rewind, and worktree isolation are Claude Code exclusives. For complex multi-agent workflows, Claude Code is still ahead.

Broad permissions by default. Several developers flag that OpenCode's agent permissions are broad by default. Check opencode.json before you point it at anything sensitive.

Who Should Use OpenCode? 🎯

OpenCode is the right choice if:

You want model flexibility and don't want to be locked into Anthropic's roadmap
Budget control matters and you want to use cheaper or local models
You prefer an open source tool you can inspect, fork, and trust
Your team has compliance requirements that require on-premise model inference
You find Claude Code's terminal UX annoying and want something nicer

Stay with Claude Code if:

You need the strongest possible instruction-following on hard tasks
You use Agent View, /goal, or other orchestration features heavily
You want a managed product that "just works" without configuration
You're already paying for Max and want to get full value from it

And honestly, plenty of people run both. OpenCode for day-to-day work with flexible models, Claude Code for the heavy debugging sessions where Opus is worth it.

My Honest Take 💭

OpenCode is a serious tool, not a hobby alternative. 178,000 GitHub stars and 7.5 million monthly users don't lie. The model-agnostic design is genuinely useful, and the terminal UX is objectively better than Claude Code's.

But the January block revealed something important: the moment you depend on Claude's quality and want to pay less, you're in Anthropic's crosshairs. OpenCode solved the tooling problem, not the model dependency problem. If you're using it with Claude via API key, you're still paying Anthropic rates.

The real freedom comes when you combine OpenCode's harness with open or local models. That's the combination that makes the cost argument actually land, and that's where the project's future clearly points.

Managed product or open tool? The answer depends on who you want to be as a developer.

Happy coding! ✨

Hi 👋🏻
My name is Domenico, software developer passionate of Open Source, I write article about it for share my knowledge and experience.
Don't forget to visit my Linktree to discover my links and to check out Domenico Tenace Open Labs for my open-source projects! 🫰🏻

🌲 Linktree: https://linktr.ee/domenicotenace
🐙 Domenico Tenace Open Labs: https://github.com/Domenico-Tenace-Open-Labs

Follow me on dev.to for more articles 👇

Domenico TenaceFollow

Passionate about the IT world and everything related to it ✌🏻 Open Source enthusiastic 🦠

If you like my content or want to support my work, you can support me with a small donation. I would be grateful 🥹

Gemini 3.6 Flash: Google's Fastest Bet in a Crowded Race 🚀

Domenico Tenace — Wed, 29 Jul 2026 08:33:15 +0000

Overview

Hey everyone 👋

Google dropped Gemini 3.6 Flash on July 21, 2026, and it's worth talking about. Not because it's a revolution, but because it quietly improves on almost everything from 3.5 Flash while getting cheaper and faster at the same time. That's a combination you don't see often.

Let me break down what actually changed, how it stacks up against the competition, and whether you should care.

Let's dive in! 🤙

What Is Gemini 3.6 Flash? 🤔

Gemini 3.6 Flash is Google's workhorse model for developers, the go-to for agentic workflows, coding tasks, long-document reasoning, and multimodal work. It's not Google's most capable model (that's still the upcoming 3.5 Pro and eventually Gemini 4), but it's the one most developers will actually use day to day.

It was released alongside two companion models: Gemini 3.5 Flash-Lite, designed for high-throughput and low-latency tasks like agentic search and document processing, and the limited-pilot Gemini 3.5 Flash Cyber for governments and trusted partners.

The model is available in Google AI Studio, the Gemini API (model ID gemini-3.6-flash), the Gemini app, Antigravity, Android Studio, and Vertex AI.

The Numbers: What Actually Changed 📊

Benchmarks

Gemini 3.6 Flash improves on Gemini 3.5 Flash across the board: coding went from 55.1% to 58.7% on SWE-Bench Pro, long-context retrieval went from roughly 27% to 54.0%, and computer use went from 78.4% to 83% on OSWorld Verified.

Average task time fell from 2.7 minutes to 1.3 minutes, while estimated task cost declined about 18 percent. That's not a minor tweak. That's a meaningfully faster agent in practice.

Speed

It runs at about 280 tokens per second, which makes it one of the faster models in its class for interactive use. For agentic workflows where you're chaining multiple LLM calls, this compounds fast.

Pricing

Gemini 3.6 Flash costs $1.50 per million input tokens and $7.50 per million output tokens. Input pricing is unchanged from Gemini 3.5 Flash, but output dropped from $9.00 to $7.50 per million tokens.

Context Window and Knowledge Cutoff

The model runs a 1 million-token context window with a 64,000-token output cap, and its knowledge cutoff is March 2026, up from January 2025 on Gemini 3.5 Flash. That's a 14-month jump, which matters more than it sounds. A model that knows about recent framework releases, pricing changes, and API updates needs less web retrieval to stay useful.

Token Efficiency

The model takes fewer reasoning steps and tool calls to complete multi-step workflows, which is a large part of why it uses roughly 17 percent fewer output tokens than its predecessor. You're paying for less and getting more done. That's the ideal direction.

How It Compares to the Competition 🥊

vs. Claude Sonnet 5

Claude Sonnet 5 outperforms on 3 benchmarks including SWE-Bench Pro and GDPval-AA, while Gemini 3.6 Flash wins on OSWorld-Verified and CharXiv-R. Claude Sonnet 5 has a slight edge in raw benchmark performance.

But the cost story is different. Gemini 3.6 Flash is 25% cheaper on both input and output compared to Claude Sonnet 5. At 100,000 tasks per month with 5,000 input and 10,000 output tokens each, that's $2,750/month in savings. For cost-sensitive workloads, Gemini is the clear winner.

Gemini 3.6 Flash also runs at 304 tokens per second compared to roughly 180 for Claude Sonnet 5. For agent workflows where latency matters, the speed difference is noticeable.

My take: if code quality at any cost is the priority, Claude Sonnet 5 still wins on most coding benchmarks. If you're building high-volume agent pipelines or cost is a real constraint, Gemini 3.6 Flash makes a strong argument.

vs. GPT-5.6 Luna

GPT-5.6 Luna remains cheaper than Gemini 3.6 Flash at public API rates, but Artificial Analysis measured Gemini at 304 output tokens per second compared to 190 for Luna. This creates a practical trade-off: Luna offers lower token rates, while Gemini produces output faster.

Independent testers report Gemini 3.6 Flash loses most coding benchmarks and GDPVal to Grok 4.5 and GPT-5.6 Luna. So if pure coding benchmark numbers are what you're optimizing for, Google isn't at the top of that list right now.

vs. Gemini 3.5 Flash

Both Gemini 3.6 Flash and Gemini 3.5 Flash currently score 50 on the Artificial Analysis Intelligence Index. Existing Gemini 3.5 Flash users have the clearest migration case, especially when latency and output volume drive costs.

In other words: same intelligence, faster, cheaper, fresher knowledge cutoff. The upgrade is a no-brainer if you're already on 3.5 Flash.

What's Missing: The Elephant in the Room 🐘

The most notable absence in this announcement is Gemini 3.5 Pro. Google originally said at I/O in May that 3.5 Pro would launch the following month. That deadline passed without a public release. Bloomberg reported on July 16 that the model was running months behind schedule, with Google spending extra time on its coding capabilities.

Google did not release Gemini 3.5 Pro in this announcement. The company said the Pro model fell short of internal expectations on coding and complex reasoning, so its broader release was delayed.

This is the real story. A delayed Pro model means that right now, Google's top available offering in the Flash tier competes on price and speed but not on raw reasoning against Claude Opus or GPT-5.6. Google also confirmed that pre-training has begun on Gemini 4, which the team described as its most ambitious pre-training run yet. So the roadmap is clearly ambitious, but the present gap is real.

The Pros 👍

Cost efficiency is excellent. Roughly half the output price of Claude Sonnet 5 at production scale is meaningful money. For startups or anyone watching API bills closely, this matters.

Speed is genuinely impressive. At 304 tokens per second, it's 1.7x faster than Claude Sonnet 5 for agent workflows where latency matters.

Multimodal support is broad. Gemini 3.6 Flash supports voice, video processing, images, PDFs, and audio as input. Claude Sonnet 5 doesn't support voice or video. For multimodal applications, Gemini is the stronger choice.

The knowledge cutoff jump is significant. Going from January 2025 to March 2026 in one model generation means you're working with a model that actually knows about tools and frameworks released in the past year and a half.

Token efficiency means lower costs in practice. Fewer output tokens for the same quality work, combined with a lower output price, compounds into real savings at volume.

The Cons 👎

The Pro model is still missing. For developers who need the strongest possible reasoning and coding quality today, Google's delays leave a gap that Claude Opus and GPT-5.6 are filling.

Raw coding benchmark scores lag behind top competitors. On the benchmarks that matter most to developers, Grok 4.5, GPT-5.6 Luna, and Claude Opus 4.8 still outperform Gemini 3.6 Flash. Speed and cost don't compensate for quality when you're debugging something complex.

Intelligence Index hasn't moved. Gemini 3.6 Flash and Gemini 3.5 Flash both score 50 on the Artificial Analysis Intelligence Index. Faster and cheaper is great, but it's not smarter. If you were hoping for a reasoning leap, this isn't it.

Gemini 4 uncertainty. Google teasing their next major model while 3.5 Pro is still delayed creates uncertainty for teams planning their model strategy. Do you build on 3.6 Flash now, or wait?

Who Should Use Gemini 3.6 Flash? 🎯

Existing Gemini 3.5 Flash users. The migration is a pure upgrade: same intelligence, faster, cheaper, better knowledge cutoff. No reason not to switch.

Cost-sensitive teams building agents. If you're running thousands or millions of API calls, the pricing advantage compounds fast. At scale, Gemini 3.6 Flash is the most efficient option in its class.

Multimodal applications. Voice, video, images, audio all in one model with a 1M token context window. If your use case touches multiple modalities, this is the most capable option at this price point.

Developers already in the Google ecosystem. Antigravity, AI Studio, Vertex AI, Android Studio. If you're already in these tools, the integration is seamless.

Who should look elsewhere: if you need the strongest possible code generation today and budget is secondary, Claude Opus 4.8 or GPT-5.6 Luna are stronger choices on raw coding benchmarks.

My Take 💭

Gemini 3.6 Flash is a solid, honest upgrade. Google didn't promise a revolution and didn't deliver one. What they delivered is a faster, cheaper, more efficient model with a dramatically improved knowledge cutoff. For most agentic workloads, that's exactly what you need.

The absence of 3.5 Pro is frustrating, and the coding benchmark gap against the top tier is real. But if you're building cost-sensitive pipelines, working with multimodal content, or already deep in Google's ecosystem, 3.6 Flash makes a compelling case.

The question isn't "is this the best model?" It's "is this the best model for what I'm building?" For a lot of teams, the answer is yes.

Happy coding! ✨

🌲 Linktree: https://linktr.ee/domenicotenace
🐙 Domenico Tenace Open Labs: https://github.com/Domenico-Tenace-Open-Labs

Follow me on dev.to for more articles 👇

Domenico TenaceFollow

Passionate about the IT world and everything related to it ✌🏻 Open Source enthusiastic 🦠

If you like my content or want to support my work, you can support me with a small donation. I would be grateful 🥹

Daily Prompt Is Out. Long Live Spellbook of Prompt 🧙🏻‍♂️

Domenico Tenace — Mon, 06 Jul 2026 07:00:00 +0000

Overview

Hey everyone 👋

Some projects start as a quick idea and slowly grow into something you actually want to take seriously. That's exactly what happened with Daily Prompt, a small collection of prompts I put together for personal use that at some point became messy, inconsistent, and honestly a bit embarrassing to share.

So I restarted from scratch. New name, new structure, new look. Meet Spellbook of Prompt.

Let's dive in! 🤙

What Was Daily Prompt? 🤔

Daily Prompt was exactly what the name suggests: a daily collection of prompts. The idea was fine, a place to gather useful prompt templates to use with ChatGPT, Claude, Gemini, and whatever else was around. But the execution had problems.

The prompts were scattered with no real organization. There was no clear logic behind the categories. The visual side was the default Starlight theme with zero customization. It felt like a dumping ground more than an actual project.

And the name itself was limiting. "Daily" implied a frequency I couldn't keep up with. It set the wrong expectations.

At some point I looked at it and thought: this doesn't represent what I actually want it to be.

Why Rebrand? 💡

Renaming a project isn't something I do lightly. It breaks URLs, confuses people who already know it, and requires updating everything.

But sometimes a fresh start is the right call.

The rebrand to Spellbook of Prompt came from a simple realization: a spellbook is a perfect metaphor for what this is. It's a collection of incantations, each one carefully crafted, tested, and documented. You open it, find what you need, cast the spell (run the prompt), and get a result.

It fits. And more importantly, it gives the project an identity worth building around.

What Changed: The Structure 🏗️

The biggest improvement is the organization. Daily Prompt was a flat list of prompts with loose labels. Spellbook of Prompt organizes everything by use case, so you can actually find what you need without scrolling forever.

The categories cover the most common real-world scenarios:

Content Creation: scripts, posts, articles, newsletters
Code Generation and Debugging: boilerplate, reviews, refactoring
Data Analysis and Reporting: summaries, structured output, comparisons
Writing and Copywriting: tone adjustments, persuasive copy, editing
Design and Creative Direction: briefs, feedback loops, mood boards
Learning and Education: explanations, quizzes, study guides

Each prompt comes with a clear description, at least one input and output example, and notes on edge cases. The goal was to make every entry actually usable, not just a template you have to figure out yourself.

The documentation is built with Astro and Starlight, which makes browsing fast and the content easy to read. MDX gives us enough flexibility to add interactive examples down the line without switching tools.

What Changed: The Look 🎨

This is where I spent more time than I expected.

The old project was visually generic. Default colors, default fonts, nothing that connected it to anything else I build. It could have belonged to anyone.

For Spellbook of Prompt I brought in my brand colors and made it feel like part of the same ecosystem as my personal site and other projects under Domenico Tenace Open Labs. It's a small thing, but it matters. When you open the docs, you immediately get a sense that someone cared about this, not just about the content but about how it looks.

Consistency across projects builds trust. And building trust was part of the point.

Model-Agnostic by Design 🌍

One thing I wanted to be clear about from the start: Spellbook of Prompt is not tied to any specific AI model.

Most prompts here work across ChatGPT, Claude, Gemini, and any other LLM you're using. Where there are differences in behavior across models, the documentation mentions it. The collection is validated across at least two different models before anything gets merged.

This matters because the AI landscape changes fast. Tying a prompt collection to a specific model would make half of it obsolete every few months.

It's Open Source and You Can Contribute 🤝

Spellbook of Prompt is fully open source under MIT, and contributions are very welcome.

If you have a prompt that works well and you've tested it properly, opening a PR is straightforward. The guidelines are in CONTRIBUTING.md and they're simple: keep prompts concise, include at least one example, validate across multiple models, and don't include sensitive data.

The bar isn't high. The point is quality over quantity. I'd rather have 50 excellent prompts than 500 mediocre ones.

What's Next 🚀

There's still a lot to add. The categories are in place but some of them are thin. The live documentation site is up and running at spellbook-of-prompt.netlify.app, and I'll keep adding prompts regularly.

A few things on the roadmap:

Interactive prompt examples directly in the docs
A tagging system for filtering by LLM compatibility
More prompts for developer workflows (CI/CD explanations, commit messages, PR descriptions)
Better search across the full collection

Final Thoughts 🌟

Sometimes a project needs to die to become something better. Daily Prompt served its purpose, but it had hit a ceiling. Spellbook of Prompt is what it should have been from the beginning, cleaner, more organized, and actually worth sharing.

If you work with AI tools regularly and you keep writing the same prompts from scratch every time, this might save you some time. Go browse the collection, grab what's useful, and if you have something good to add, open a PR.

The spellbook is open. 🔥

Happy coding! ✨

🌲 Linktree: https://linktr.ee/domenicotenace
🐙 Domenico Tenace Open Labs: https://github.com/Domenico-Tenace-Open-Labs

Follow me on dev.to for more articles 👇

Domenico TenaceFollow

Passionate about the IT world and everything related to it ✌🏻 Open Source enthusiastic 🦠

If you like my content or want to support my work, you can support me with a small donation. I would be grateful 🥹

Google AI Studio: The Playground Every Developer Should Know About 🎮

Domenico Tenace — Fri, 05 Jun 2026 07:00:00 +0000

Overview

Hey everyone 👋

If you've ever wanted to experiment with Gemini models, build AI-powered features, or grab an API key without going through a complex setup, Google AI Studio is the tool you're looking for.

It's free, it's browser-based, and it's probably the fastest way to go from "I have an idea" to "I have working code." Today I'll walk you through what it is, what you can actually do with it, and why it belongs in every developer's toolkit.

Let's dive in! 🤙

What Is Google AI Studio? 🤔

Google AI Studio is a web-based platform where you can interact with Google's AI models, prototype ideas, fine-tune behavior, and export working code, all without writing a single line of infrastructure.

Think of it as a sandbox. You can test prompts, switch between Gemini models, tweak parameters, and when something works, click "Get Code" to get a ready-to-use snippet in Python, JavaScript, or REST. No cloud setup, no billing configuration, no long onboarding. Just go to aistudio.google.com, sign in with your Google account, and you're in.

It sits at the intersection of playground and development tool. Researchers use it to experiment. Developers use it to prototype. Teams use it to validate ideas before committing to a full integration.

What You Actually Need It For 💡

There are a few scenarios where Google AI Studio becomes indispensable:

Getting a Gemini API Key:
This is often the first reason developers land on AI Studio. It's the official way to get a Gemini API key for free, which you then use in your own applications, in tools like Gemini CLI, Antigravity, or any custom integration. No credit card required for the free tier.

Testing Prompts Before Hardcoding Them:
Prompt engineering is trial and error. AI Studio gives you a fast feedback loop where you can iterate on prompts interactively, see the output, adjust, and repeat, before embedding anything in your codebase.

Exploring Model Capabilities:
Not sure if Gemini can handle your specific use case? Test it directly. Upload images, audio, documents, or code and see how different models respond. The multimodal support is all accessible through the UI.

Prototyping Features Quickly:
Even a small team can use it to create prototypes in days instead of weeks. The combination of interactive prompting and instant code export makes it genuinely fast to go from idea to proof of concept.

How It Works 🔧

The interface is organized around a few core concepts:

Prompts and Conversations

When you open AI Studio, you can start a new prompt immediately. You choose between three modes:

Chat Prompts:
Multi-turn conversations where you can test how the model handles back-and-forth dialogue. Perfect for chatbots, assistants, or any conversational feature.

Stream Mode:
Designed for real-time interactivity, it includes webcam integration, screen sharing, and live guidance. This is the mode for live, low-latency applications.

Structured Output:
Force the model to respond in JSON format with a schema you define. Essential when you need predictable, parseable output to feed into your app.

Model Selection

The platform features a multi-model playground allowing you to switch between models seamlessly while working. You can compare responses between Gemini 2.5 Pro, Gemini 2.5 Flash, and other variants side by side. Each model has different trade-offs between speed, cost, and reasoning depth, and AI Studio is the best place to understand those differences before committing to one.

System Instructions

This is where it gets interesting for developers. You can set a system prompt that shapes the model's behavior, persona, and constraints for the entire session. This is exactly how you'd configure an AI assistant for your product, and you can refine it here until it behaves exactly how you want.

Parameters and Controls

On every prompt, you have direct control over:

Temperature: How creative or deterministic the output is
Max output tokens: Limit the response length
Top-P and Top-K: Fine-grained sampling controls
Safety settings: Adjust content filtering thresholds

Changing these and seeing how responses shift in real time is one of the most educational things you can do as someone building with AI.

Get Code

Once you have a prompt and configuration that works, you can click "Get Code" to instantly generate a working code snippet in Python, Node.js, or REST that you can use to integrate that functionality into your own application via the Gemini API.

This is the feature that saves the most time. You iterate in the UI, then export the exact configuration as runnable code. No manual translation needed.

Multimodal: More Than Just Text 🌈

One of AI Studio's strongest points is how naturally it handles multiple input types. You can drag and drop into a prompt:

Images (for visual analysis, OCR, layout understanding)
PDFs and documents (for summarization, Q&A, data extraction)
Audio files (for transcription or analysis)
Videos (for content understanding with timestamps)
URLs (for web content analysis directly)
Code files (for explanation, review, or refactoring)

The Generative Media Kit unlocks creative potential with tools for generating images, speech, music, and videos. This makes AI Studio useful well beyond pure text use cases.

Free vs. Paid: What's the Difference? 💰

AI Studio has a generous free tier, but there are real differences worth knowing:

Free Tier:

Access to most Gemini models
Rate-limited API calls (enough for prototyping and personal projects)
Your prompts and data may be used to improve Google's models
No charge, just a Google account

Paid Tier (via Gemini API billing):

Higher rate limits and quotas
Your data is not used for model training, which is a necessity for most commercial or sensitive applications
Access to advanced features like caching and batch processing
Suitable for production applications

For individual exploration, side projects, and prototyping, the free tier is more than enough. For anything you're shipping to users with sensitive data, upgrade before going live.

AI Studio vs. Vertex AI: Which One? 🤷

A common question for developers already in the Google Cloud ecosystem. The short answer:

Google AI Studio is for individuals, developers, and fast prototyping. Browser-based, simple setup, no infrastructure knowledge required.

Vertex AI is for teams, enterprises, and production-scale deployments. More powerful, more complex, integrates with the full Google Cloud stack, and requires GCP setup and billing configuration.

If you're just getting started or working on a side project, AI Studio is the right choice. If you're building a production system that needs autoscaling, monitoring, and enterprise compliance, you'll eventually migrate to Vertex AI, but start in AI Studio first.

Practical Use Cases 🛠️

Here's how I actually use Google AI Studio in my workflow:

Validating prompt ideas for Gemini CLI Skills:
Before writing a SKILL.md, I test the core instructions in AI Studio to see how the model responds. If it doesn't behave as expected there, it won't behave as expected in the terminal either.

Grabbing API keys for new projects:
Every time I start a new project that needs Gemini integration, AI Studio is where I go first to create a key.

Understanding model differences:
When deciding between Gemini 2.5 Pro and Flash for a specific task, I run the same prompt against both in AI Studio and compare speed vs. quality trade-offs.

Exporting prompt configurations:
When a prompt works well in AI Studio, I click "Get Code" and drop the exported snippet directly into my project as a starting point.

Final Thoughts 🌟

Google AI Studio is the kind of tool that sounds simple until you realize how much time it saves. It's not trying to replace your IDE or your production infrastructure. It's the place you go to think, experiment, and validate before committing to anything.

If you're building with Gemini, it's effectively mandatory. And even if you're just AI-curious and want to understand what these models can actually do, spending an hour in AI Studio will teach you more than reading documentation for days.

Free, browser-based, no setup. There's really no reason not to try it.

Happy coding! ✨

🌲 Linktree: https://linktr.ee/domenicotenace
🐙 Domenico Tenace Open Labs: https://github.com/Domenico-Tenace-Open-Labs

Follow me on dev.to for more articles 👇

Domenico TenaceFollow

Passionate about the IT world and everything related to it ✌🏻 Open Source enthusiastic 🦠

If you like my content or want to support my work, you can support me with a small donation. I would be grateful 🥹

Gemini CLI Skills: Teaching Your Terminal Agent How to Think 🧠

Domenico Tenace — Tue, 26 May 2026 06:00:00 +0000

Overview

Hey everyone 👋

If you've been using Gemini CLI for a while, you've probably noticed that the agent is great at general tasks but sometimes needs guidance for specific workflows. That's exactly what Skills are for.

Skills are one of the most underrated features of Gemini CLI, and once you start using them, you'll wonder how you ever managed without. Today I'll walk you through what they are, how to create them, and a real-world example you can steal immediately.

Let's start! 🤙

Quick Note Before We Start 📢

Google has announced that Gemini CLI will transition to Antigravity CLI on June 18th for free tier and Google One users. The good news? Skills work the same way in both tools, so everything you learn here applies directly to Antigravity CLI. If you're already in the migration window, just replace "Gemini CLI" with "Antigravity CLI" in your head.

What Are Skills? 🤔

Think about the difference between a generalist and a specialist. A generalist knows a bit of everything but lacks deep expertise in any one area. A specialist has deep knowledge in their domain and knows exactly how to approach problems in that field.

By default, Gemini CLI is a generalist. It knows a lot, but it doesn't know your specific project, your team's conventions, or the exact steps your deployment pipeline requires.

Skills turn the generalist into a specialist.

A Skill is a self-contained directory that packages specialized instructions and context into a discoverable capability. Unlike GEMINI.md files that are always loaded into context, Skills are loaded on demand, only when the agent determines they're relevant to your current task.

This distinction matters a lot. If you put everything into GEMINI.md, you quickly saturate the model's context window with information that's irrelevant to most tasks. Skills solve this with Progressive Disclosure, the agent sees a brief description of every skill, and only loads the full instructions when the skill is actually needed.

The result: the right knowledge, at the right time, without cluttering the context.

The Anatomy of a Skill 🏗️

A Skill is just a folder with a specific structure:

.gemini/skills/
└── my-skill/
    ├── SKILL.md          # The main definition file (required)
    ├── examples/         # Reference implementations (optional)
    ├── resources/        # Templates and assets (optional)
    └── scripts/          # Helper scripts (optional)

The only required file is SKILL.md. Everything else is supporting material that the agent can reference when the skill is activated.

The SKILL.md File

This is the heart of every skill. It has two parts: a frontmatter header and a body with instructions.

---
name: your-skill-name
description: What this skill does. Use when you need to...
---

# Skill Title

Your instructions here.

The frontmatter is crucial. The description field is what the agent reads at the start of every session to decide whether to load this skill. Write it clearly and specifically, a vague description will cause the skill to be activated at the wrong times (or never).

Good description:

"Reviews code changes for security vulnerabilities, performance issues, and adherence to project conventions. Use when reviewing PRs or checking code before merging."

Bad description:

"Code review stuff."

Where to Put Your Skills 📁

Gemini CLI discovers skills from two locations, and which one you use depends on scope:

Project Skills (.gemini/skills/ in your repo):
These are tied to a specific project. Commit them to version control and your whole team gets the same specialized behavior. Perfect for project-specific workflows like deployment steps, framework conventions, or codebase-specific review guidelines.

Global Skills (~/.gemini/skills/ in your home directory):
These work across all your projects. Perfect for personal workflows, general coding standards, or tools you use everywhere.

The mental model: if a skill is useful for your team and the project, put it in the repo. If it's personal productivity, put it globally.

Creating Your First Skill: Step by Step 🔧

Let's create a practical skill for code review. Here's the full process:

Step 1: Create the Directory

For a project skill:

mkdir -p .gemini/skills/code-review

For a global skill:

mkdir -p ~/.gemini/skills/code-review

Step 2: Write the SKILL.md

Create .gemini/skills/code-review/SKILL.md:

---
name: code-review
description: Reviews code changes for bugs, security issues, performance problems, and style consistency. Use when reviewing PRs, checking diffs, or auditing code quality before merging.
---

# Code Review Skill

You are an expert code reviewer. When reviewing code, follow this checklist systematically.

## Review Checklist

### Correctness
- Does the code do what it's supposed to do?
- Are there logic errors or off-by-one mistakes?
- Are all edge cases handled?

### Security
- Are inputs validated and sanitized?
- Are there potential injection vulnerabilities?
- Is sensitive data handled securely?

### Performance
- Are there unnecessary loops or redundant operations?
- Are database queries optimized?
- Are there memory leaks or heavy resource usage?

### Style and Conventions
- Does the code follow the project's naming conventions?
- Is the code readable and well-structured?
- Are functions small and single-responsibility?

## How to Provide Feedback

For each issue found:
1. Specify the exact location (file and line number)
2. Explain what the problem is and why it matters
3. Suggest a concrete fix with a code example when possible

End the review with a summary: overall assessment (Approve / Request Changes / Needs Discussion) and a brief explanation.

Step 3: Verify the Skill Is Discovered

Start Gemini CLI in your project directory and run:

/skills

You should see your code-review skill listed. If it's not there, double-check the directory structure and file naming.

Step 4: Use It

Just work normally. When you ask for a code review:

Review the changes in auth.js before I merge this PR

Gemini CLI sees the request, matches it against the skill description, loads the full SKILL.md, and follows your checklist systematically. You don't need to explicitly invoke the skill, it happens automatically.

A Practical Example: Conventional Commits Skill 📝

Let me share another skill I use constantly, one that enforces Conventional Commits format across all my projects.

Create .gemini/skills/conventional-commits/SKILL.md:

---
name: conventional-commits
description: Generates commit messages following the Conventional Commits specification. Use when creating, reviewing, or suggesting git commit messages.
---

# Conventional Commits Skill

You are an expert at writing clear, structured commit messages following the Conventional Commits 1.0.0 specification.

## Format

<type>(<scope>): <description>

[optional body]

[optional footer(s)] 

## Types

- **feat**: A new feature
- **fix**: A bug fix
- **docs**: Documentation changes only
- **style**: Formatting changes (no code logic change)
- **refactor**: Code change that neither fixes a bug nor adds a feature
- **perf**: Performance improvement
- **test**: Adding or updating tests
- **chore**: Build process or auxiliary tool changes

## Rules

1. Use the imperative mood in the description ("add feature" not "added feature")
2. Lowercase the entire first line
3. No period at the end of the description
4. Keep the description under 72 characters
5. The body explains "what" and "why", not "how"
6. Reference issue numbers in the footer: `Closes #123`

## Examples

- feat(auth): add JWT token refresh logic
- fix(api): handle null response from payment provider
- docs: update README with pnpm installation steps
- refactor(utils): extract string validation to dedicated module 

When suggesting a commit message, always explain your reasoning for the chosen type and scope.

Now whenever you ask Gemini CLI to help with a commit:

Write a commit message for the changes I just made to the authentication module

The agent loads the skill, understands the full convention, and generates a properly formatted message with the right type, scope, and description style.

Skills vs. GEMINI.md: When to Use What 🔄

A common question: when should you put something in a Skill vs. in GEMINI.md?

Use GEMINI.md for:

Information the agent always needs (project name, tech stack, folder structure)
General coding standards that apply to every task
Critical context that should never be missing

Use a Skill for:

Specialized workflows that only run sometimes (deployments, code review, testing)
Deep expertise for a specific domain (security auditing, accessibility checking)
Complex checklists that would waste context when not needed
Anything you only need occasionally but need deeply when you do

The rule of thumb: if you'd be annoyed by the agent using this knowledge on unrelated tasks, it's a skill. If you'd be annoyed if the agent ever lacked this knowledge, it belongs in GEMINI.md.

Tips for Writing Good Skills 💡

After creating several skills, here's what actually works:

Write narrow descriptions. The description is how the agent decides whether to activate the skill. Narrow is better than broad. "Use when reviewing PRs or checking code quality" is better than "Use for coding tasks."

Add explicit "do not use" hints when needed. If your skill might be over-activated, add clarity: "Do not use for general coding questions or feature implementation."

Keep SKILL.md focused. Put detailed examples and templates in the examples/ or resources/ subdirectories. The core SKILL.md should be scannable and concise.

One skill, one responsibility. Don't create a "general development" mega-skill. Create separate skills for deployment, testing, code review, etc.

Test activation. After creating a skill, try prompts that should and shouldn't activate it. If it activates when it shouldn't, tighten the description.

Final Thoughts 🌟

Skills are a small investment with a big return. You spend 10-15 minutes writing a SKILL.md once, and the agent follows your exact workflow consistently from that point on.

The bigger picture: Skills are how you transform Gemini CLI (or Antigravity CLI) from a generic AI assistant into a tool that understands your team, your conventions, and your processes. The more skills you build, the more the agent feels like a teammate rather than a tool.

Start small, maybe with a code review skill or a commit message skill, and build from there. You'll quickly start noticing the moments where the agent "just knows" what you need, and that's when it clicks.

Happy coding! ✨

🌲 Linktree: https://linktr.ee/domenicotenace
🐙 Domenico Tenace Open Labs: https://github.com/Domenico-Tenace-Open-Labs

Follow me on dev.to for more articles 👇

Domenico TenaceFollow

Passionate about the IT world and everything related to it ✌🏻 Open Source enthusiastic 🦠

If you like my content or want to support my work, you can support me with a small donation. I would be grateful 🥹

Gemini CLI: Google's Free AI Agent for Your Terminal 🚀

Domenico Tenace — Tue, 12 May 2026 06:00:00 +0000

Overview

Hey everyone 👋

Google recently dropped something that's been flying under the radar: Gemini CLI, a free, open source AI agent that brings the power of Gemini directly into your terminal. While everyone's been debating Cursor vs Claude Code, Google quietly built a terminal AI that's actually free and surprisingly capable.

I've been using it for a few weeks, and I wanted to share what it is, how it works, where it shines, and where it falls short compared to the competition.

Let's dive in! 🤙

What Is Gemini CLI? 🤔

Gemini CLI is an open source AI agent that runs entirely in your terminal. Think of it as having Gemini 2.5 sitting at your command line, able to read your code, write files, run commands, and help you build software through conversation.

It's not just a chatbot with access to your terminal, it's an agentic tool that uses a ReAct (Reason and Act) loop to complete complex tasks autonomously. You give it a goal, it makes a plan, executes steps, validates results, and iterates until the task is complete.

The Core Philosophy

Google built Gemini CLI with a terminal-first philosophy. It's designed for developers who live in the command line and don't want to context-switch to a GUI. Everything happens in a single terminal pane: the conversation, file edits, command execution, and results.

This is different from tools like Cursor, which give you a full IDE experience. Gemini CLI embraces minimalism, the terminal is your interface, and that's it.

How It Actually Works 💻

Installing Gemini CLI is dead simple:

npm install -g @google/gemini-cli

Or use it without installing:

npx @google/gemini-cli

Once installed, just type gemini in your project directory, authenticate with your Google account, and you're in.

The Authentication Options

Gemini CLI offers several auth methods:

Personal Google Account (Free):
60 requests per minute, 1,000 requests per day. This is the generous free tier that makes Gemini CLI attractive.

Google AI Studio API Key:
Pay-as-you-go with usage-based billing. For heavy users who exceed the free quota.

Vertex AI:
For enterprise users who need Gemini Code Assist integration and higher limits.

Most individual developers will be perfectly happy with the free tier. 60 requests per minute is generous for typical development workflows.

The Agent Experience

When you start Gemini CLI, you get an interactive prompt. You can:

Ask questions about your codebase
Request file edits or new features
Run terminal commands through the agent
Search the web for documentation
Work with images and documents
Execute multi-step workflows

The agent reads your entire project context (up to 1M tokens with Gemini 2.5 Pro), understands your code structure, and makes changes that respect your existing patterns.

Example conversation:

You: Add user authentication to this Express app with JWT tokens
Agent: [reads codebase, creates plan]
Agent: I'll create:
  1. auth middleware (auth.js)
  2. login/signup routes (routes/auth.js)
  3. JWT token utilities (utils/jwt.js)
  4. update existing routes to use auth middleware

Proceed? (y/n)

You approve, and the agent executes the plan, creating files, writing code, and updating your project.

The Built-in Tools 🛠️

Gemini CLI comes with several built-in tools that the agent uses automatically:

Google Search Integration:
The agent can search the web and ground its responses in current information, perfect for finding documentation or recent API changes.

File Operations:
Read, write, create, delete files across your project.

Shell Command Execution:
Run terminal commands, install dependencies, run tests, commit changes, etc.

Web Fetching:
Retrieve web pages and documentation directly into the conversation context.

MCP Server Support:
Integrate custom tools via Model Context Protocol. Want to connect Slack, GitHub, databases, or custom APIs? MCP makes it possible.

The Competitors 🥊

Gemini CLI isn't alone in the terminal AI space. Let's see how it stacks up against the main players.

Claude Code

Claude Code is a terminal-based AI coding assistant built on Anthropic's Claude models. It enables developers to generate, refactor, and reason about code through conversational prompts directly in the command line.

Similarities:
Both are terminal-first agents, both support MCP, both handle multi-step tasks autonomously.

Key Differences:
Claude Code uses Claude models exclusively (Opus, Sonnet) while Gemini CLI uses Gemini 2.5 Pro/Flash. Claude Code delivers the full 200K token context reliably, with a 1M token beta on Opus 4.6, while Gemini CLI offers up to 1M tokens with Gemini 2.5 Pro from the start.

Pricing:
Claude Code is pay-per-token (typically $100-200/month for heavy users). Gemini CLI's free tier is genuinely generous at 60 requests/min.

My take: Claude Code is more mature and polished, but Gemini CLI's free tier is hard to beat for individuals.

Aider

Aider is a Git-native, terminal-based AI coding assistant built to support collaborative, open source workflows.

Similarities:
Both are terminal tools, both are open source, both support multiple LLM providers.

Key Differences:
Aider's strength is that it thinks in git. Every edit is a commit. Every session is a branch you can review, revert, or cherry-pick. Gemini CLI is less git-centric, it's more general-purpose.

My take: If you care deeply about git-native workflows, Aider wins. If you want Google Search integration and broader capabilities, Gemini CLI is better.

Cursor

Cursor isn't really a competitor, it's a different category. Cursor operates as a full-featured IDE with AI capabilities embedded throughout the interface, while Gemini CLI is terminal-only.

The Difference:
Cursor is IDE-first. You drive, the AI assists with completions, suggestions, and edits you approve inline. Gemini CLI is agent-first, you delegate tasks and review results.

My take: Many developers use both. Cursor for active coding sessions, Gemini CLI for delegated tasks or automation.

Where Gemini CLI Excels ✨

After using Gemini CLI alongside other tools, here's where it genuinely shines:

The Free Tier Is Real

60 requests per minute and 1,000 requests per day is generous. Most developers won't hit these limits in normal usage. This makes Gemini CLI the most accessible terminal AI for individuals and students.

Claude Code costs money from day one. Gemini CLI is actually free for most use cases.

Large Context Window

1M tokens with Gemini 2.5 Pro means you can load massive codebases into context. For large refactoring tasks or understanding complex systems, this is powerful.

I've successfully used it to analyze entire monorepos that would have required chunking with smaller context windows.

Google Search Integration

The built-in Google Search tool is surprisingly useful. When the agent encounters something it doesn't know (a new API, a recent framework update, etc.), it can search the web and incorporate current information.

This beats having to manually look things up and paste documentation into the conversation.

MCP Server Support

Configure MCP servers in ~/.gemini/settings.json to extend Gemini CLI with custom tools. Want to integrate GitHub, Slack, databases, or custom APIs? MCP makes it straightforward.

This extensibility means Gemini CLI can grow with your needs.

Multimodal Capabilities

Gemini's vision capabilities are available in the CLI. You can include images in your prompts, perfect for "implement this UI mockup" or "what's wrong with this screenshot" tasks.

Not many terminal AIs support this out of the box.

Low Barrier to Entry

Install with npm, authenticate with Google, done. No API keys to manage (unless you want to), no credit card required, no complex setup.

This makes it perfect for trying out terminal AI without commitment.

Where Gemini CLI Falls Short 😬

Nothing's perfect, and Gemini CLI has real weaknesses:

The UX Needs Polish

Compared to Claude Code's refined interface, Gemini CLI feels rougher around the edges. Error messages aren't always clear, the terminal UI can get cluttered, and occasionally the agent loses track of context mid-task.

It's usable, but it's not as smooth as more mature tools.

Model Quality Varies

Gemini 2.5 Pro is powerful, but it's not Claude Opus. Claude Code for reasoning depth (80.9% SWE-bench). Gemini scores lower on code-specific benchmarks.

For complex reasoning or nuanced refactoring, Claude Code often produces better results.

Limited Community Resources

Claude Code and Aider have large, active communities. Gemini CLI is newer, so there are fewer tutorials, examples, and community-built extensions.

When you hit an issue, you're more likely to be on your own.

Terminal-Only Limitation

Some developers prefer having a visual IDE experience with file trees, side-by-side diffs, and graphical interfaces. Gemini CLI offers none of that, it's terminal or nothing.

If you're not comfortable working purely in the command line, this is a dealbreaker.

Quota Limits for Free Tier

While 60 req/min is generous, heavy users will hit the 1,000 req/day limit. If you're doing intensive work, you'll need to either slow down or pay for API access.

Claude Code's pay-per-token model might actually be cheaper for very heavy usage.

Real-World Use Cases 💼

Here's what I've actually used Gemini CLI for:

Refactoring Legacy Code:
I pointed it at an old project with inconsistent patterns and asked it to modernize the code. The 1M token context meant it could understand the entire codebase and make consistent changes.

Documentation Generation:
"Read this codebase and create comprehensive README documentation." It analyzed the code, understood the architecture, and wrote decent docs.

Debugging:
When I hit errors I couldn't figure out, I'd paste them into Gemini CLI. The Google Search integration meant it could find relevant Stack Overflow answers or GitHub issues.

Prototyping:
"Create a simple Express API with user authentication and a todo list." Quick prototypes are where Gemini CLI excels, fast iteration without worrying about costs.

Learning New Tech:
"Explain how this React codebase implements authentication." The agent would analyze the code and explain patterns, great for onboarding to unfamiliar codebases.

Who Should Use Gemini CLI? 🎯

Gemini CLI isn't for everyone. Here's who will benefit most:

Students and Learners:
The free tier makes it perfect for learning. No financial barrier to experimenting with AI-assisted development.

Individual Developers:
If you don't need enterprise features and want a free terminal AI, Gemini CLI is excellent.

Open Source Maintainers:
For working on community projects where you don't want to pay out of pocket, the free tier is generous enough for regular use.

Developers Trying Terminal AI:
If you're curious about terminal-based AI agents but don't want to commit to paid tools, start here.

Budget-Conscious Teams:
Small teams or startups that can't afford $20-40/month per developer for Claude Code or Cursor.

Who Should Look Elsewhere? 🤷

Gemini CLI isn't ideal if:

You Need the Best Code Quality:
Claude Opus produces higher-quality code for complex tasks. If quality matters more than cost, pay for Claude Code.

You Prefer Visual IDEs:
If terminal-only feels limiting, use Cursor, Windsurf, or another IDE-based tool.

You're a Power User:
If you'll exceed 1,000 requests/day regularly, the free tier won't cut it, and paying for Gemini API might cost more than a Claude Code subscription.

You Need Enterprise Features:
For teams requiring compliance, audit logs, and enterprise support, look at Gemini Code Assist or Claude Code Enterprise.

My Honest Take 💭

Gemini CLI is a solid terminal AI that punches above its weight thanks to the generous free tier. It's not the most polished, and it's not the highest quality, but it's free and good enough for most tasks.

If you're an individual developer who lives in the terminal and wants to try AI-assisted development without paying, Gemini CLI is the obvious choice. The 60 req/min and 1,000 req/day limits are genuinely usable.

That said, if you're doing professional work where code quality matters and you can afford $20-40/month, Claude Code is still better. The reasoning quality, the polish, and the maturity are worth paying for.

But for learning, side projects, open source work, and experimentation? Gemini CLI is fantastic. Google's strategy of making it free is smart, it gets developers hooked on terminal AI without financial friction.

Try It Yourself 🚀

If you're curious, just run:

npx @google/gemini-cli

No commitment, no credit card, no setup beyond Node.js. Try a few tasks and see how it feels.

The worst that happens is you waste 10 minutes. The best that happens is you discover a free tool that transforms how you work.

Happy coding! ✨

🌲 Linktree: https://linktr.ee/domenicotenace
🐙 Domenico Tenace Open Labs: https://github.com/Domenico-Tenace-Open-Labs

Follow me on dev.to for more articles 👇

Domenico TenaceFollow

Passionate about the IT world and everything related to it ✌🏻 Open Source enthusiastic 🦠

If you like my content or want to support my work, you can support me with a small donation. I would be grateful 🥹

Why I Switched to pnpm and Never Looked Back 🚀

Domenico Tenace — Thu, 19 Mar 2026 09:03:03 +0000

Overview

Hey everyone 👋

For years, I used npm without questioning it. It's the default, it comes with Node.js, everyone uses it, why change? But after switching to pnpm a few months ago, I genuinely can't imagine going back.

This isn't about being trendy or jumping on the latest bandwagon. pnpm solves real problems I didn't even realize I had with npm. Let me explain why making the switch was one of the best development decisions I've made this year.

Let's start! 🤙

What's the Actual Difference? 🤔

Before we get into why pnpm is better, let's understand what makes it fundamentally different from npm.

npm's Approach: Flat and Duplicated

When you run npm install, npm creates a flat node_modules structure. This means all your dependencies and their dependencies end up in the same folder, flattened out. While this solved some earlier problems with nested dependencies, it created new ones:

Phantom Dependencies:
You can import packages that aren't listed in your package.json because they happen to be installed as someone else's dependency. This works until that dependency changes, and suddenly your code breaks.

Disk Space Waste:
If you have 10 projects on your machine and they all use Express, npm downloads and stores Express 10 times. Same for React, Lodash, or any other common package.

Slow Installations:
Every project needs its own copy of everything, which means longer install times and more network usage.

pnpm's Approach: Smart and Efficient

pnpm takes a completely different approach using something called a content-addressable storage system. Here's how it works:

Single Global Store:
pnpm keeps one copy of each package version in a global store (usually ~/.pnpm-store). When you install a package, pnpm creates hard links from this store to your project's node_modules.

Strict Dependency Tree:
Instead of flattening everything, pnpm maintains a proper nested structure using symlinks. You can only import packages that are explicitly listed in your package.json or their dependencies.

Shared Across Projects:
If 10 projects use Express version 4.18.0, pnpm stores it once and creates 10 hard links. No duplication, massive disk space savings.

This isn't just a minor optimization, it's a fundamentally better architecture.

Why pnpm Wins: The Real Benefits 🏆

Let me share the concrete improvements I've experienced since switching.

Speed That Actually Matters

pnpm is noticeably faster than npm. We're not talking marginal gains, we're talking "wait, it's already done?" levels of speed.

Cold Installs:
When installing a package for the first time, pnpm downloads it once to the global store. Every subsequent project that uses it just creates a hard link, which is nearly instantaneous.

Warm Installs:
If you've already got the packages in your global store (which you probably do if you work on multiple projects), installations are blazingly fast. What took npm 2-3 minutes might take pnpm 10-20 seconds.

In Practice:
Running pnpm install on a fresh clone of a project feels almost magical. The speed difference is real and noticeable every single day.

Disk Space Savings Are Huge

This one surprised me the most. After switching my entire workspace to pnpm, I freed up over 15GB of disk space. That's not a typo, 15 gigabytes.

Here's why: with npm, if you have 20 projects and 15 of them use React, you have 15 copies of React sitting on your disk. With pnpm, you have one copy with 15 hard links pointing to it.

For common dependencies like:

React and React DOM
Lodash
TypeScript
ESLint and Prettier
Testing libraries

The savings add up fast. And this isn't just about disk space, it's about principle. Why should my machine store the same exact files hundreds of times?

Strict Dependencies Prevent Bugs

This is the feature I didn't know I needed until I had it.

With npm, you can accidentally import packages that aren't in your package.json because they're installed as transitive dependencies. This creates hidden coupling that breaks when those dependencies update.

pnpm's strict mode prevents this entirely. If it's not in your package.json, you can't import it. Period.

Real Example:
I had a project using a utility function from Lodash, but Lodash wasn't in my package.json. It worked because another package happened to depend on Lodash. When that package updated and removed Lodash, my build broke.

With pnpm, this would have failed immediately, forcing me to add Lodash explicitly. The error is caught early instead of in production.

Monorepo Support Is First-Class

If you work with monorepos (and increasingly, who doesn't?), pnpm's workspace support is excellent.

Built-in Workspaces:
Define your workspace structure in pnpm-workspace.yaml, and pnpm handles linking between packages automatically.

Efficient Sharing:
Shared dependencies across workspace packages are stored once and linked everywhere they're needed.

Better Than Alternatives:
I've used npm workspaces and Yarn workspaces. pnpm's implementation feels cleaner and more efficient in practice.

The Lock File Is Better

pnpm's pnpm-lock.yaml is more deterministic than npm's package-lock.json. It stores more information about dependency relationships and produces more consistent results across different environments.

I've had fewer "works on my machine" issues since switching to pnpm. The lock file format just seems more robust.

The Migration: Easier Than You Think 🔄

I was worried about migrating, but it turned out to be trivial.

How to Switch

For an existing project:

# Install pnpm globally
npm install -g pnpm

# Navigate to your project
cd my-project

# Import your package-lock.json
pnpm import

# Install dependencies
pnpm install

That's it. pnpm even converts your package-lock.json to pnpm-lock.yaml automatically.

Commands Are Nearly Identical

If you know npm, you already know pnpm:

# npm commands
npm install package-name
npm uninstall package-name
npm run build
npm test

# pnpm equivalents
pnpm add package-name
pnpm remove package-name
pnpm run build
pnpm test

The only real difference is add instead of install and remove instead of uninstall. Everything else is identical.

Create Aliases If Needed

If you want even less friction:

alias npm=pnpm

Though honestly, once you start using pnpm, you'll appreciate the distinct commands.

The Gotchas (Yes, There Are Some) 😬

Let's be honest, pnpm isn't perfect. Here are the issues I've encountered:

Some Packages Don't Play Nice

Occasionally, you'll find a package that assumes npm's flat structure and breaks with pnpm's strict linking. This is rare, but it happens.

The Fix:
pnpm has a .pnpmfile.cjs where you can configure workarounds. Or you can use the shamefully-hoist flag to flatten dependencies like npm does (though this defeats some of pnpm's benefits).

In practice, I've only hit this issue twice in several months, and both times the package maintainers fixed it quickly.

Smaller Community

While pnpm's adoption is growing rapidly (Vue, Vite, Astro, and other major projects use it), it's still smaller than npm's massive ecosystem.

This means:

Fewer Stack Overflow answers
Less extensive documentation for edge cases
Occasional confusion when following tutorials that assume npm

That said, the community is active and helpful, and most npm knowledge transfers directly.

Initial Learning Curve

Understanding hard links, symlinks, and the global store takes a minute. The first time you look at node_modules in a pnpm project, it looks weird.

But once you understand the model, it makes perfect sense and you appreciate the elegance.

When npm Still Makes Sense 🎯

To be fair, there are scenarios where sticking with npm is reasonable:

You're Brand New to JavaScript:
If you're just learning, start with npm. It's the default, and you'll find more beginner-friendly resources. Switch to pnpm once you're comfortable.

Company Policy:
Some organizations have standardized on npm, and switching requires buy-in. Don't fight that battle unless the benefits are worth it for your specific situation.

Compatibility Concerns:
If you're working on legacy projects with lots of old dependencies that have quirks, npm's more permissive structure might save headaches.

You Don't Care About Disk Space or Speed:
If you have unlimited disk space and don't mind waiting for installations, npm works fine. Some people genuinely don't care about these optimizations.

But for most modern development, pnpm is simply better.

Real-World Impact 💪

Let me share some concrete numbers from my own experience:

Before pnpm (npm):

npm install on a typical Next.js project: ~90 seconds
Disk space for 20 active projects: ~42GB in node_modules
Frequent phantom dependency issues
Occasional lock file conflicts between team members

After pnpm:

pnpm install on the same projects: ~15-20 seconds
Disk space for the same 20 projects: ~27GB total
Zero phantom dependency issues
More consistent installations across the team

The time savings alone add up. If you run install 20 times a day (between switching branches, pulling updates, etc.), pnpm saves you about 20-25 minutes daily. That's over 2 hours per week.

The Broader Ecosystem Is Adopting It 🌍

pnpm isn't just a niche tool anymore. Major projects have switched:

Projects Using pnpm:

Vue 3 and the entire Vue ecosystem
Vite (one of the fastest build tools)
Astro (my personal site's framework)

When tools and frameworks this significant adopt pnpm, it's a strong signal that it's production-ready and worth considering.

My Recommendation 💡

If you're still using npm and any of these apply to you:

You work on multiple projects
You care about build speed
Disk space is a concern
You work with monorepos
You want stricter dependency management

Switch to pnpm. The migration takes 5 minutes, and the benefits are immediate and ongoing.

Will you encounter the occasional quirk? Probably. Is it worth it? Absolutely.

The JavaScript ecosystem moves fast, and package managers are evolving. npm was great for its time, but pnpm represents a better approach to dependency management. It's faster, more efficient, and more correct.

Conclusion 🚀

Here's my challenge: pick one project and try pnpm for a week. Just one week.

npm install -g pnpm
cd your-project
pnpm import
pnpm install

Use it like you'd use npm. Notice the speed. Check your disk space savings. Experience the strict dependency resolution.

After a week, if you genuinely prefer npm, switch back. But I'd bet that like me, you won't want to.

Sometimes the best tools are the ones that just work better in ways you didn't realize you needed. For me, pnpm is one of those tools.

Happy coding! ✨

🌲 Linktree: https://linktr.ee/domenicotenace
🐙 Domenico Tenace Open Labs: https://github.com/Domenico-Tenace-Open-Labs

Follow me on dev.to for more articles 👇

Domenico TenaceFollow

Passionate about the IT world and everything related to it ✌🏻 Open Source enthusiastic 🦠

If you like my content or want to support my work, you can support me with a small donation. I would be grateful 🥹

Rebuilding domenicotenace.dev: How Pure Astro and CSS Reminded Me That Simple Is Better 🌟

Domenico Tenace — Thu, 12 Mar 2026 16:52:57 +0000

Overview

Hey everyone 👋

I recently did something that felt almost rebellious in today's web development landscape: I completely refactored my personal website using only Astro and vanilla CSS. No React, no Vue, no Tailwind, no animation libraries, no component frameworks. Just HTML, CSS, and a bit of JavaScript where absolutely necessary.

And you know what? It was the most refreshing development experience I've had in years.

Let's start! 🤙

The Decision: Back to Basics ✨

The turning point came when I was helping a friend debug their website. They'd built it with pure HTML and CSS, no build step, no dependencies. When they made a change, they just refreshed the browser. No waiting for compilation, no hot module replacement issues, no dependency conflicts.

It was fast. Not just the website itself, but the entire development experience.

That's when I decided: my personal website doesn't need all this complexity. It's time to simplify.

Why Astro? 🚀

I chose Astro for one simple reason: it lets you write components and modern syntax while outputting pure static HTML. No JavaScript runtime, no virtual DOM, no hydration overhead. Just good old HTML, CSS, and minimal JS where needed.

Astro's philosophy aligned perfectly with what I wanted:

Zero JavaScript by default: Pages are pure HTML unless you explicitly opt-in
Component-based: I can still organize my code cleanly without shipping React
Fast builds: Seriously fast, we're talking seconds
No lock-in: If I want to switch frameworks later, I can easily migrate

The best part? Astro doesn't force you into any particular way of doing things. Want to use vanilla CSS? Great. Want to sprinkle in some JavaScript? Cool. Want to stay 100% static? Perfect.

The Refactoring Process 🔧

The migration was surprisingly straightforward. Here's what I did:

Step 1: Stripped Everything Down

First, I removed all the dependencies. Every single one. The package.json went from 40+ dependencies to just Astro itself. It felt liberating, like decluttering a messy room.

Step 2: Rebuilt the Structure

I created a simple Astro project structure:

src/
├── components/
│   ├── Header.astro
│   ├── Footer.astro
│   └── ProjectCard.astro
├── layouts/
│   └── BaseLayout.astro
└── pages/
    ├── index.astro
    ├── blog/
    └── projects/

Clean, minimal, easy to understand.

Step 3: Pure CSS, No Frameworks

This is where it got interesting. Instead of reaching for Tailwind, I wrote vanilla CSS. And honestly? It was fun.

I created a simple global.css file for handle all CSS.

No build tools, no purging, no configuration. Just CSS that works.

Step 4: Animations in Pure CSS

Here's where I had the most fun. Instead of importing animation libraries, I wrote CSS animations from scratch:

@keyframes fadeIn {
  from { opacity: 0; }
  to { opacity: 1;  }
}

.fade-in {
  animation: fadeIn 0.6s ease-out forwards;
}

Simple, performant, and I have complete control over every detail.

Step 5: JavaScript Only Where Needed

I added minimal JavaScript for interactive features:

Theme toggle (dark/light mode)
Mobile menu toggle
Smooth scroll behavior

Total JavaScript: less than 100 lines. No frameworks, no bundlers, just plain vanilla JS.

What I Rediscovered 💡

This process taught me (or reminded me) of several important lessons:

CSS Is Actually Powerful

Modern CSS is incredibly powerful. Grid, flexbox, custom properties, container queries, scroll-driven animations, we have everything we need to build beautiful, responsive websites without frameworks.

I'd forgotten that. Years of using Bulma, Tailwind, ecc made me think I needed utility classes for everything, but honestly? Writing semantic CSS felt more natural and resulted in cleaner markup.

Less Is Genuinely More

The final bundle size? Tiny. We're talking kilobytes, not megabytes. The Lighthouse score? 100 across the board. The build time? Under 3 seconds.

None of this would be possible with my previous stack. All that complexity was weighing the site down, literally and metaphorically.

Development Can Be Simple

There's something deeply satisfying about opening a file, changing some CSS, refreshing the browser, and seeing the change instantly. No build process, no hot module replacement quirks, no "hmm, why isn't this updating?"

The tight feedback loop made development enjoyable again.

You Don't Need a Framework for Everything

This is the big one. I'd internalized the idea that "professional" websites require modern frameworks. But that's not true. Frameworks solve specific problems, and if you don't have those problems, you don't need the framework.

My personal website doesn't need client-side routing, state management, or component reactivity. It's content, presented nicely. HTML and CSS do that perfectly well on their own.

The Results 📊

Let me share some concrete improvements:

Performance:

Initial load time: 0.3s (down from 1.8s)
Total bundle size: 45KB (down from 380KB)
Lighthouse score: 100 across all metrics
Time to Interactive: instant

Developer Experience:

Build time: 2.4s (down from 28s)
Hot reload: instant
Dependency updates: basically none
Mental overhead: significantly reduced

Maintenance:

Breaking changes: none (it's just HTML/CSS)
Security vulnerabilities: none (no dependencies to patch)
Complexity: minimal

What About the Trade-offs? 🤔

Let's be honest, there are some trade-offs:

No Component Reactivity:
Astro components are static by default. If I need interactivity, I have to add it manually. But for a content site, this is rarely an issue.

Less Tooling:
No automatic CSS optimization, no tree-shaking, no hot module replacement for styles. But honestly? I don't miss it. The simplicity makes up for the lack of bells and whistles.

Manual Responsive Design:
Without Tailwind's responsive utilities, I write media queries by hand. It takes slightly longer, but the CSS is more maintainable and semantic.

More CSS to Write:
No utility classes means writing more CSS. But the total amount of CSS is actually less than my Tailwind config generated, and it's more readable.

These trade-offs are worth it for me. Your mileage may vary.

Who Should Consider This Approach? 🎯

Pure Astro and CSS isn't for everyone, but it's perfect if:

You're building content sites:
Blogs, portfolios, documentation, marketing pages, anything that's primarily content benefits from this approach.

You value simplicity:
If you're tired of complex build processes and dependency management, going minimal is refreshing.

You want to learn the fundamentals:
Writing vanilla CSS makes you a better developer. You understand what your tools are doing under the hood.

Performance matters:
If you need the absolute fastest site possible, less code wins every time.

You don't need heavy interactivity:
If your site is mostly static content with occasional interactive elements, you don't need a full framework.

When You Still Need Frameworks 🔄

To be clear, I'm not saying frameworks are bad. They're excellent tools for the right jobs:

Complex web apps:
If you're building a dashboard, SaaS platform, or interactive application, React/Vue/etc. make total sense.

Teams with existing expertise:
If your team knows React and you're building something quickly, use React. Don't reinvent the wheel.

Lots of client-side state:
When you need to manage complex client-side state, frameworks provide the structure to do it well.

Rapid prototyping:
Component libraries and frameworks can speed up initial development significantly.

The key is choosing the right tool for the job, not defaulting to the most popular stack.

The Bigger Picture 🌍

This refactoring taught me something important about modern web development: we've collectively become a bit obsessed with complexity.

We reach for frameworks by default, even when they're overkill. We add dependencies without thinking. We over-engineer simple problems because that's what "professional" developers do.

But sometimes, the best solution is the simplest one.

HTML and CSS have been around for decades because they're good. They're stable, they're fast, they're simple. Modern CSS is powerful enough to build beautiful interfaces without frameworks.

Astro lets us use modern development practices (components, TypeScript, etc.) while outputting pure, simple code. It's the best of both worlds.

My Challenge to You 💪

If you're reading this and thinking "hmm, maybe I've over-engineered my site too," I challenge you:

Try building something with pure HTML and CSS. No frameworks, no libraries, just the fundamentals. See how it feels.

You might be surprised at how freeing it is.

And if you need a static site generator, give Astro a shot. It's genuinely excellent at letting you write simple code that performs beautifully.

Conclusion 🌟

Rebuilding domenicotenace.dev with pure Astro and CSS reminded me why I fell in love with web development in the first place: the joy of creating something that works, that's fast, that's simple.

We don't always need the latest framework or the trendiest library. Sometimes, the best code is the code we don't write.

If you take one thing from this article, let it be this: question your stack. Ask yourself if you really need all those dependencies. Challenge the assumption that complexity equals professionalism.

Often, the simplest solution is the best one.

Happy coding! ✨

🌲 Linktree: https://linktr.ee/domenicotenace
🐙 Domenico Tenace Open Labs: https://github.com/Domenico-Tenace-Open-Labs

Follow me on dev.to for more articles 👇

Domenico TenaceFollow

Passionate about the IT world and everything related to it ✌🏻 Open Source enthusiastic 🦠

If you like my content or want to support my work, you can support me with a small donation. I would be grateful 🥹

Adding Capacitor to Glif with Antigravity: The Good, The Bad, and The Reality Check 📱

Domenico Tenace — Thu, 26 Feb 2026 17:46:28 +0000

Overview

Hey everyone 👋

I recently decided to take Glif, my minimalist QR code generator web app, and turn it into a proper mobile app using Capacitor. For those who don't know, Glif is a simple Nuxt app that lets you create and download customizable QR codes, nothing fancy, just clean and functional.

Since I've been using Google Antigravity for various projects, I figured: why not let it handle the Capacitor integration? It's supposed to be great for frontend work, and mobile development is definitely frontend territory, right?

Well... let me tell you about that experience. Spoiler alert: Antigravity helped, but it wasn't the smooth ride I expected.

Let's start! 🤙

What Is Capacitor and Why Add It to Glif? 🤔

First, a quick explainer for anyone unfamiliar. Capacitor is Ionic's cross-platform runtime that lets you turn web apps into native mobile apps for iOS and Android. Think of it as a bridge: your web code (HTML, CSS, JavaScript) runs inside a native container, and Capacitor provides APIs to access device features like the camera, filesystem, notifications, etc.

For a tool like Glif, going mobile made perfect sense:

Why Glif Needs Mobile:

QR codes are inherently mobile-first (people scan them with phones)
Users might want to generate QR codes on the go
Having a native app feels more legitimate than "just a website"
Access to device features like sharing, saving to photos, etc.
Potential for offline functionality

The web version works fine, but a native mobile app would be the natural evolution. Capacitor seemed like the obvious choice, it's well-maintained, works great with Vue/Nuxt, and doesn't require rewriting the entire app.

The Plan: Let Antigravity Handle It ⚡

I've had good experiences using Antigravity for frontend work (I literally built an entire Material Design CSS library with it), so I was optimistic. My thinking was:

Capacitor integration is well-documented
It's mostly configuration and boilerplate
Antigravity should be able to follow the Capacitor docs
The agent can test the mobile build in the browser
This should be straightforward

So I fired up Antigravity in Planning mode and gave it the task:

"Integrate Capacitor into this Nuxt 4 project to create iOS and Android builds. Configure all necessary plugins for a QR code app including Filesystem."

The agent created a plan, I reviewed it, and we were off to the races.

What Went Well ✅

Let me start with the positives, because Antigravity did help in several areas:

Initial Setup Was Smooth

The agent handled the initial Capacitor installation perfectly:

Installed @capacitor/core and @capacitor/cli
Ran npx cap init with correct project details
Added Android platforms
Created the capacitor.config.ts file with proper configuration

All the boilerplate stuff that's tedious but straightforward worked flawlessly. This is exactly what AI assistants should excel at.

Plugin Installation

Antigravity correctly identified and installed the necessary plugins:

@capacitor/filesystem for saving QR codes
@capacitor/splash-screen for native app experience
@capacitor/status-bar for handle status bar
@capacitor-community/media for handle media files (like images)

It even configured them properly in the Capacitor config, which saved me from reading documentation.

Build Configuration

The agent modified the Nuxt config to work with Capacitor:

Set up the correct output directory
Configured SSR settings (disabled, since Capacitor needs SPA)
Adjusted router settings for mobile
Created proper build scripts in package.json

This was actually helpful because the Nuxt + Capacitor combo has some quirks that the agent navigated correctly.

Where Antigravity Struggled 😬

Now for the part where things got messy. Antigravity wasn't terrible, but it definitely wasn't at 100% performance:

Native Platform Specifics

The agent struggled with Android-specific configurations. For example:

AndroidManifest.xml permissions were incomplete
Didn't configure proper app theming
Missed some required Gradle configuration
Icons and splash screens needed manual adjustment

Again, the agent knew what needed to be done but couldn't execute it properly.

Build Errors and Debugging

This is where Antigravity really fell short. When builds failed, the agent struggled to:

Diagnose Real Errors:
The first Android build threw a Gradle error. I asked Antigravity to fix it, and it suggested changes that didn't address the actual issue. After three attempts, I just Googled the error myself and fixed it in 5 minutes.

Understand Native Tooling:
Antigravity doesn't actually run Android Studio, so when I pasted error messages from those tools, its suggestions were hit-or-miss. It could recognize common errors but anything specific required me to debug manually.

Handle Version Conflicts:
Dependency conflicts between Capacitor plugins and Nuxt modules were a pain. The agent suggested version combinations that didn't work, and I ended up trial-and-error fixing them myself.

Performance Optimization

The agent successfully integrated Capacitor, but the resulting app wasn't optimized:

Bundle size was larger than necessary
Some Nuxt modules loaded unnecessarily in mobile context
Animation performance on lower-end devices was choppy
Initial load time was slower than it should be

When I asked Antigravity to optimize, it made generic suggestions (tree-shaking, lazy loading, etc.) but couldn't implement them effectively for the Capacitor + Nuxt combo.

Mobile-Specific UI Issues

The web version of Glif looked fine, but mobile had problems:

Touch targets were too small in some places
Bottom navigation issues with Android gesture navigation
Keyboard behavior wasn't optimized for mobile

Antigravity suggested CSS fixes, but many required understanding native mobile behavior that it just didn't grasp well enough.

The Reality: Manual Work Was Necessary 🔧

Here's what I ended up doing manually:

Fix AndroidManifest.xml completely
Configure proper app theming and colors
Set up icons and splash screens correctly
Adjust Gradle dependencies to resolve conflicts

Code Optimization:

Manually remove unnecessary Nuxt modules for mobile
Optimize bundle size by tree-shaking unused code
Improve touch interactions with mobile-specific CSS
Fix status bar and safe area issues with custom code

Testing:

Test on actual devices (simulator isn't enough)
Fix device-specific bugs Antigravity couldn't predict
Optimize performance on lower-end hardware

Honestly, I'd estimate Antigravity handled about 60% of the work. The other 40% required manual intervention, native tooling knowledge, and debugging skills.

Why Antigravity Wasn't at 100% 🧠

After reflecting on the experience, I think I understand why Antigravity underperformed:

It Can't Actually Run Native Tooling

Antigravity's browser integration is great for web testing, but it can't Android Studio. This means:

It can't validate native builds
It can't see build errors in native IDEs
It can't test on actual devices or simulators

For truly mobile-native work, this is a significant limitation.

Capacitor Is a Bridging Technology

Capacitor sits at the intersection of web and native, which means you need knowledge of both worlds. Antigravity is strong on the web side but weak on the native side. When problems arise in the native layer, the agent struggles.

Documentation Isn't Enough

The agent can read Capacitor docs, but implementing best practices requires experience. Things like:

Proper safe area handling
Performance optimization for mobile devices
Platform-specific UI patterns
Native permission flows

These require knowing mobile development, not just reading about it.

Nuxt + Capacitor Is a Niche Combo

Most Capacitor tutorials focus on React, Angular, or vanilla JS. The Nuxt integration has specific quirks and gotchas that aren't as well-documented. Antigravity didn't have enough training data on this specific stack.

What I Learned 💡

This experience taught me some valuable lessons:

Antigravity Is Still Best for Pure Web:
When the work is 100% web-based (HTML, CSS, JavaScript, Vue components), Antigravity excels. The moment you cross into native territory, its effectiveness drops significantly.

Hybrid Frameworks Need Hybrid Knowledge:
Using Capacitor effectively requires understanding both web and native development. An AI that's strong in one but weak in the other will struggle with the integration layer.

Boilerplate vs. Implementation:
Antigravity is excellent at boilerplate and initial setup. But when things go wrong or need optimization, you still need traditional debugging skills.

Testing Matters:
The agent can't test on actual devices, which is critical for mobile development. Until AI can actually run apps on phones and see visual/performance issues, it'll miss important problems.

Documentation Has Limits:
Reading docs doesn't replace experience. Mobile development has countless edge cases and platform quirks that you only learn by doing.

The Current State of Glif Mobile 📱

Despite the struggles, Glif now has working Android builds! The apps:

Generate QR codes with custom colors and sizes
Save QR codes to the device photo library
Work offline (since it's all client-side)
Have proper icons, splash screens, and native feel

It's not perfect, there are still optimizations I want to make, but it's functional and feels like a real mobile app.

Antigravity got me maybe 60-70% of the way there, which isn't nothing. But the final 30-40% required rolling up my sleeves and getting my hands dirty with Android Studio.

Should You Use Antigravity for Capacitor Integration? 🎯

Based on my experience, here's my take:

Use Antigravity if:

You need help with initial setup and boilerplate
You're already comfortable with mobile development and just want to speed up configuration
You're okay handling native tooling yourself when things go wrong
Your app is relatively simple without complex native integrations

Don't rely solely on Antigravity if:

This is your first time with Capacitor or mobile development
Your app needs complex native features or optimizations
You need production-ready, fully optimized mobile apps without manual work

The Reality:
Antigravity is a helpful assistant for Capacitor integration, but it's not a replacement for mobile development knowledge. Think of it as a junior developer who can handle setup tasks but needs supervision for the complex stuff.

What I'd Do Differently Next Time 🔄

If I were to integrate Capacitor into another project with Antigravity, I'd:

Set Realistic Expectations:
Go in knowing I'll need to manually handle native configuration and optimization. Don't expect the agent to deliver a production-ready mobile app.

Use It for What It's Good At:
Let Antigravity handle installation, basic config, and documentation. Handle native-specific work myself from the start.

Test Earlier:
Don't wait for the agent to "finish" before testing on actual devices. Test incrementally and catch issues early.

Have Native Tools Ready:
Have Android Studio open from the beginning. Don't expect to complete mobile development purely through the Antigravity interface.

Combine with Traditional Resources:
Use Antigravity alongside Stack Overflow, Capacitor docs, and community forums. Don't rely on it exclusively.

Conclusion 🌟

Adding Capacitor to Glif was a learning experience. Antigravity helped significantly with setup and boilerplate, but mobile development's native aspects required traditional hands-on work.

The 60-70% of work the agent handled was genuinely useful and saved me time. But that final 30-40% reminded me that AI coding tools, as impressive as they are, still have clear limitations when you cross platform boundaries.

Mobile development is complex, spanning web tech and Android. Until AI tools can truly understand and test across all these layers, they'll remain helpful assistants rather than complete solutions.

That said, would I use Antigravity again for Capacitor integration? Probably yes, but with realistic expectations and my native IDEs ready to go from day one.

Have you tried using AI coding tools for mobile development? Drop a comment with your experiences, I'm curious if others have hit similar roadblocks or found better workflows!

Check out:

🌲 Linktree: https://linktr.ee/domenicotenace
🐙 Domenico Tenace Open Labs: https://github.com/Domenico-Tenace-Open-Labs

Follow me on dev.to for more articles 👇

Domenico TenaceFollow

Passionate about the IT world and everything related to it ✌🏻 Open Source enthusiastic 🦠

If you like my content or want to support my work, you can support me with a small donation. I would be grateful 🥹

Building Plus Ultra: How Antigravity Helped Me Bring Material Design to Bulma CSS 🎨

Domenico Tenace — Thu, 12 Feb 2026 11:32:17 +0000

Overview

Hey everyone 👋

Today I want to share something I've been working on that combines two things I love: clean CSS frameworks and Material Design aesthetics. I just launched Plus Ultra, an open-source CSS library that brings Material Design components to Bulma CSS while keeping all the flexbox goodness that makes Bulma so powerful.

And here's the kicker: I built most of it using Google Antigravity, which turned out to be an absolute beast for frontend work. If you're wondering whether Antigravity is any good for UI development, let me tell you, it's incredible.

Let's start! 🤙

What Is Plus Ultra? 🚀

First, let me explain what Plus Ultra actually is and why I built it.

The Concept

Bulma is one of my favorite CSS frameworks. It's lightweight, pure CSS (no JavaScript), based on flexbox, and incredibly easy to use. The problem? Its default aesthetic is pretty basic. The components work great, but they look... well, vanilla.

Material Design, on the other hand, is gorgeous. Google's design system is polished, modern, and has that clean "premium" feel. But most Material Design implementations (like Material-UI) are tied to specific JavaScript frameworks, which defeats the purpose of Bulma's simplicity.

So I thought: what if we could have the best of both worlds? Bulma's flexbox power and simplicity, but with Material Design's visual polish?

That's Plus Ultra.

What It Does

Plus Ultra takes Bulma's components and transforms them into Material Design equivalents using pure CSS/Sass:

Material buttons with proper elevation, ripple effects (CSS-only), and Material color schemes
Material cards with the signature shadow system and hover states
Material form inputs with floating labels and Material-style validation
Material navigation components following Material guidelines
Material modals and dialogs with proper transitions and backdrops

The key is that it's built on top of Bulma, not instead of it. You still get all of Bulma's flexbox utilities, grid system, and helper classes. Plus Ultra just makes everything look like Material Design.

Why "Plus Ultra"?

The name comes from one of my all-time favorite anime series: My Hero Academia 😄
"Plus Ultra" is actually a Latin Phrase. It translates to "Further Beyond." In My Hero Academia, it has been adopted as the school motto of U.A. High.

The Tech Stack 💻

Let me break down what Plus Ultra is built with:

Core:

Bulma CSS as the foundation (obviously)
Sass/SCSS for all the Material Design styling
Pure CSS for animations and transitions
No JavaScript dependencies (keeping Bulma's philosophy)

Build Tools:

pnpm for package management
Sass compiler for building the final CSS

Material Design System:

Following Google's Material Design 3 guidelines
Custom color system matching Material palettes
Elevation system with proper shadows
Material motion and transitions

The beauty is that it's just CSS. No complicated build process, no JavaScript runtime, no framework lock-in. Install it, import it, and your Bulma components instantly look like Material Design.

How Antigravity Changed Everything ⚡

Now here's where it gets interesting. I could have built Plus Ultra the old-fashioned way, manually writing Sass, testing in the browser, iterating on designs. But I decided to use Google Antigravity, and honestly, it transformed the entire development process.

Frontend Is Antigravity's Sweet Spot

I've used Antigravity for various projects, but it absolutely shines for frontend work. Here's why:

Visual Feedback Loop:
Antigravity's integrated browser means the agent can actually see the components it's building. It's not just writing CSS blindly, it's rendering the results, evaluating the visual output, and iterating based on what it sees.

When I asked the agent to create a Material Design button, it would:

Write the initial Sass
Compile and render it in the browser
Visually compare it to Material Design specs
Adjust colors, shadows, and spacing until it matched
Show me the final result

This visual validation is huge for UI work. The agent isn't guessing, it's verifying.

Material Design Knowledge:
Gemini (which powers Antigravity) has deep knowledge of Material Design principles. When I asked for "Material Design elevation level 2," it knew exactly what shadow values to use. When I requested "Material ripple effect," it understood the animation timing and easing functions.

This saved me countless hours of referencing Material Design documentation.

Rapid Iteration:
Frontend work is all about iteration. Try a color, see how it looks, adjust. Try a shadow, see if it feels right, tweak. Antigravity excels at this:

Me: "Make the button shadow more subtle"
Agent: adjusts shadow values, shows result
Me: "Actually, go back to the original but reduce opacity"
Agent: reverts and modifies, shows result

This back-and-forth happened in seconds, not minutes.

Specific Examples from Building Plus Ultra

Let me share some concrete examples of how Antigravity helped:

Example 1: Material Cards

Task: "Create a Material Design card component that works with Bulma's .card class"

What Antigravity did:

Analyzed Bulma's existing card structure
Added Material Design elevation (box-shadow) with proper values
Implemented hover state with elevation increase
Added proper border-radius matching Material specs
Created transition animations for smooth hover effects
Ensured responsive behavior on mobile

The agent created the entire component in one go, tested it visually, and the result was production-ready. I made minor tweaks to spacing, but 95% was perfect on first attempt.

Example 2: Floating Label Inputs

Task: "Implement Material Design floating labels for Bulma form inputs"

This is actually complex because floating labels require specific CSS logic:

Label starts inside the input
When focused or filled, label floats up and shrinks
Smooth transitions between states
Proper color changes
Accessible implementation

Antigravity not only wrote the CSS but also created test cases showing:

Empty input (label inside)
Focused input (label floating)
Filled input (label stays floating)
Error state (red accent)
Success state (green accent)

The agent validated each state visually before showing me the final component.

Example 3: Material Color System

Task: "Implement Material Design color palette with Sass variables compatible with Bulma's color system"

Antigravity:

Created Sass maps for Material color palettes (primary, secondary, error, etc.)
Integrated them with Bulma's existing color variables
Generated utility classes (.has-background-primary, .has-text-secondary, etc.)
Ensured proper contrast ratios for accessibility
Created documentation showing all available colors

This would have taken me hours manually. The agent did it in minutes.

Planning Mode Was Perfect for This

I used Planning mode extensively for Plus Ultra, and it was ideal for a project like this.

Before implementing each component, the agent would create a plan showing:

Which Material Design specs it would follow
How it would integrate with existing Bulma classes
What Sass variables and mixins it would create
What the final output would look like

I could review the plan, suggest adjustments (like "use Bulma's existing spacing variables instead of creating new ones"), and then approve. This ensured consistency across all components.

What I Learned About Antigravity for Frontend 🧠

After building Plus Ultra with Antigravity, here are my takeaways:

Antigravity is exceptionally strong for:

Component-based UI development
Design system implementation
CSS/Sass architecture
Responsive design work
Visual consistency across components
Rapid prototyping and iteration

The visual feedback loop is critical.
For UI work, being able to see results immediately and iterate visually makes Antigravity far more effective than text-based coding assistants.

Material Design knowledge is built-in.
Having an AI that deeply understands design systems means less time reading specs and more time building.

Planning mode prevents inconsistency.
For a library like Plus Ultra where consistency is crucial, Planning mode's upfront architecture decisions were invaluable.

The Current State and What's Next 🌟

Plus Ultra is currently in early development. The foundation is there, core Material components working on top of Bulma, but there's still work to do.

What's working now:

Material buttons with elevation and states
Material cards with proper shadows
Basic floating label inputs
Material color palette integration
Foundation Sass architecture

What's coming:

Complete form component library
Material navigation components
Modal and dialog components
Material tables and lists
Comprehensive documentation
Live demo site
npm package for easy installation

I'm building this in the open under Domenico Tenace Open Labs, so anyone can follow along, contribute, or use what's already there.

And yes, I'll be continuing to use Antigravity for development. It's been too effective not to.

Why Open Source? 🌍

You might wonder why I'm building this as an open-source project instead of keeping it proprietary.

Simple: the best tools I use every day are open source. Bulma is open source. Material Design specs are open. The entire web is built on open technologies.

Plus Ultra stands on the shoulders of giants. The least I can do is contribute back to the ecosystem that's given me so much.

If other developers find it useful, awesome. If someone wants to contribute improvements, even better. And if it helps people build better-looking websites with Bulma, that's the whole point.

What I Want to Hear From You 💬

Alright, your turn! I have questions for the community:

If you use Bulma:

Would a Material Design version interest you?
What components would be most valuable?
What design systems would you like to see integrated with Bulma?

If you use Material Design:

Do you prefer React-based Material UI or pure CSS solutions?
What features are non-negotiable in a Material Design implementation?

If you've used Antigravity for frontend:

How has your experience been with UI development?
Did you find the browser integration as useful as I did?
What tricks or workflows have you discovered?

If you're considering trying Antigravity:

What questions do you have about using it for frontend work?
What kinds of projects are you thinking about building?

Drop a comment below! I'm genuinely curious to hear if others are using Antigravity for frontend work and what your experiences have been. The tool is still new, and community knowledge sharing helps everyone.

Conclusion 🎯

Building Plus Ultra has been a blast, and Antigravity made the process significantly faster and more enjoyable than traditional development would have been.

The combination of Bulma's simplicity and Material Design's aesthetics feels like a natural fit, and having an AI assistant that understands both design systems, can write clean Sass, and can visually validate the results is incredibly powerful.

If you're doing frontend work and haven't tried Antigravity yet, I highly recommend giving it a shot. The browser integration alone makes it worth exploring. And if you're a Bulma user looking for a Material Design aesthetic, keep an eye on Plus Ultra, we're just getting started.

Check out the repo, star it if you're interested, and feel free to contribute or provide feedback. This is a community project, and the more input we get, the better it becomes.

Happy coding! ✨

🌲 Linktree: https://linktr.ee/domenicotenace
🐙 Domenico Tenace Open Labs: https://github.com/Domenico-Tenace-Open-Labs

Follow me on dev.to for more articles 👇

Domenico TenaceFollow

Passionate about the IT world and everything related to it ✌🏻 Open Source enthusiastic 🦠

If you like my content or want to support my work, you can support me with a small donation. I would be grateful 🥹

Planning vs Fast Mode in Google Antigravity: When and How to Use Each ⚡

Domenico Tenace — Tue, 03 Feb 2026 09:09:36 +0000

Overview

Hey everyone 👋

If you've started exploring Google Antigravity, you've probably noticed those two options sitting right there in the agent panel: Planning and Fast modes. At first glance, they might seem like just different speeds for getting stuff done, but trust me understanding when to use each one is the difference between feeling like a productivity wizard and wondering why the agent just did something completely unexpected.

After spending significant time with Antigravity across various projects (from quick bug fixes to complex refactoring), I've learned that these modes represent fundamentally different approaches to problem solving. Choosing the right one can make or break your workflow.

Today I want to dive deep into both modes: what makes them different, when to use each, how to get the most out of them, and the gotchas you need to watch out for. By the end, you'll know exactly which mode to reach for in any situation.

Let's start! 🤙

The Core Philosophy: Two Ways to Think 🤔

Before we get into the technical details, let's understand the philosophical difference between these modes, because it affects everything about how they work.

Planning Mode: The Architect's Approach

Planning mode is all about thinking before doing. When you give the agent a task in Planning mode, it doesn't immediately start writing code. Instead, it takes a step back and asks itself:

What exactly are we trying to achieve?
What are the different components involved?
What's the best approach to solve this?
What files will need to be created or modified?
What dependencies or technologies should we use?
What are the potential challenges or edge cases?

Only after answering these questions does it create a detailed implementation plan. This plan is a tangible artifact a document you can read, review, comment on, and approve before any code is written.

Think of it like an architect creating blueprints before construction begins. You get to see the entire vision, suggest changes, and ensure everyone's on the same page before the first line of code is touched.

Fast Mode: The Builder's Approach

Fast mode is the opposite philosophy: just do it. When you give the agent a task in Fast mode, it immediately starts executing. No plans, no artifacts, no waiting for approval. It interprets your request and takes action right away.

This isn't carelessness, it's confidence. Fast mode assumes the task is straightforward enough that the agent can handle it without needing to draft a comprehensive plan first. It's like asking a skilled carpenter to fix a wobbly table leg, they don't need to draw blueprints; they just grab their tools and fix it.

The key insight: Planning mode prioritizes clarity and control. Fast mode prioritizes speed and efficiency. Neither is "better", they solve different problems.

Planning Mode Deep Dive 📋

Let's start with Planning mode since it's the more complex (and often more powerful) of the two.

How Planning Mode Works

When you initiate a task in Planning mode, here's what happens behind the scenes:

Step 1: Initial Analysis

The agent reads your prompt and analyzes the scope. It examines your current workspace, identifies relevant files, and understands the context of what you're asking for.

Step 2: Plan Creation

The agent generates an Implementation Plan artifact. This document typically includes:

Goal: A clear statement of what the task aims to achieve
Tech Stack: The technologies, frameworks, and libraries it plans to use
High-Level Approach: The overall strategy for solving the problem
Detailed Steps: A breakdown of specific actions it will take
File Changes: Which files will be created, modified, or deleted
Testing Strategy: How it will verify the implementation works

This plan appears as an artifact in your workspace that you can read, comment on, and interact with.

Step 3: Your Review and Feedback

Here's where the magic happens: you can provide feedback directly on the plan. You can:

Highlight specific sections and add comments
Suggest alternative approaches
Ask clarifying questions
Request changes before any code is written
Approve the plan as-is

The agent reads your feedback and incorporates it into its understanding before proceeding.

Step 4: Execution

Once you approve (explicitly or implicitly by letting it proceed), the agent executes the plan step by step. It follows the roadmap it created, implementing each component methodically.

Step 5: Walkthrough Generation

After completing the task, the agent generates a Walkthrough artifact documenting what it did, what files changed, what features were added, and recommended next steps.

When to Use Planning Mode

Planning mode shines in specific scenarios. Here's when you should reach for it:

Complex, Multi-Step Tasks

If the task requires multiple components working together, Planning mode is your friend. Examples:

"Build a todo list app with user authentication, database storage, and responsive design"
"Refactor the entire authentication system to use OAuth 2.0"
"Create a CI/CD pipeline with automated testing and deployment"

These tasks have many moving parts. The planning phase ensures everything is coordinated correctly.

When You Need Oversight

If you want to understand the agent's approach before it starts making changes, Planning mode gives you that visibility. This is crucial when:

Working on production code
Making changes to critical systems
Learning how the agent solves problems
Ensuring the solution aligns with your architecture

Unfamiliar Domains

When you're asking the agent to work with technologies or frameworks you're less familiar with, Planning mode lets you review the approach and learn from the plan before implementation.

For example, if you're new to React and ask the agent to build a component, the plan will show you the React patterns and best practices it intends to use. You can learn from this before any code is written.

Large-Scale Refactoring

Refactoring across many files is risky without a plan. Planning mode ensures the agent has thought through all the implications and will make consistent changes throughout the codebase.

I used this extensively when refactoring Easy Kit Utils, the planning phase showed exactly which files would be touched and how the changes would maintain consistency.

Collaborative Development

If you're working on a team project or pair programming with the agent, Planning mode enables better collaboration. Your teammates can review the plan, provide input, and ensure the implementation aligns with team standards.

When You're Not Sure What You Want

Sometimes you have a vague idea but haven't fully crystallized the requirements. Planning mode can help you think through the problem by generating a plan you can then refine.

For example: "I need some kind of data visualization for user analytics" → the agent creates a plan proposing a specific approach → you review and say "actually, I want interactive charts, not static ones" → the plan updates before any coding happens.

How to Use Planning Mode Effectively

To get the most out of Planning mode, follow these practices:

Be Clear About the Goal, Not the Implementation

Good prompt:

"Create a user authentication system with email/password login, password reset functionality, and session management."

Less effective prompt:

"Use bcrypt to hash passwords in the users table and create a sessions table with JWT tokens and..."

Planning mode works best when you describe WHAT you want, not HOW to build it. Let the agent figure out the implementation details—that's what the planning phase is for.

Read the Plan Thoroughly

Don't just skim and approve. Actually read the implementation plan. Look for:

Does the tech stack make sense?
Are there parts of the problem the agent missed?
Are there simpler approaches?
Does this align with your project's architecture?

Use Inline Comments

Antigravity supports Google Docs-style commenting directly on plan artifacts. Highlight a section of the plan and add a comment like:

"Instead of using PostgreSQL, can we use SQLite for this prototype?"

"Don't forget to handle the edge case where the user's email isn't verified."

The agent reads these comments and adjusts its approach accordingly.

Iterate on the Plan

Don't feel pressured to approve immediately. It's okay to go back and forth:

Agent creates initial plan
You comment with changes
Agent updates the plan
You review again
Approve when satisfied

This iteration happens before any code is written, which is much more efficient than fixing issues after implementation.

Approve Explicitly

When you're satisfied with the plan, explicitly approve it by saying something like:

"Looks good, proceed with implementation"

"Approved, let's build this"

This signals to the agent that it should move from planning to execution.

Common Planning Mode Pitfalls

Even with the best intentions, there are traps to avoid:

Over-Planning Small Tasks

Planning mode has overhead. For tiny tasks like "fix the typo in line 42," the planning phase is overkill. Use Fast mode instead.

Analysis Paralysis

Don't get stuck endlessly iterating on the plan. At some point, you need to commit and see the implementation. Perfect plans rarely survive contact with reality anyway.

Ignoring the Plan

Some developers approve plans without reading them, defeating the whole purpose of Planning mode. If you're going to skip the plan review, just use Fast mode.

Assuming the Plan Is Perfect

The plan is a guide, not gospel. As the agent executes, it might discover issues or better approaches. Be flexible and let it adapt if needed.

Fast Mode Deep Dive ⚡

Now let's talk about Fast mode—the quick-and-dirty, get-it-done-now approach.

How Fast Mode Works

Fast mode is beautifully simple:

Step 1: Interpret the Request

The agent reads your prompt and immediately understands what action to take.

Step 2: Execute

It performs the task right away. No plans, no artifacts, no waiting. It makes the changes or writes the code directly.

Step 3: Report Back

The agent confirms what it did and shows you the results.

That's it. Three steps, minimal overhead, maximum speed.

When to Use Fast Mode

Fast mode is perfect for specific scenarios:

Quick Edits and Fixes

Simple, localized changes are Fast mode's bread and butter:

"Fix the typo on line 23"
"Rename this variable to be more descriptive"
"Add a console.log statement to debug this function"
"Change the button color to blue"
"Update the heading text to 'Welcome to Our App'"

These tasks are so straightforward that planning would just slow things down.

Obvious Solutions

When there's only one reasonable way to solve a problem, Fast mode is efficient:

"Center this div horizontally"
"Add error handling to this API call"
"Convert this callback to async/await"
"Sort this array alphabetically"

The implementation is obvious, so just do it.

Iterative Development

When you're rapidly prototyping and trying things out, Fast mode keeps you in flow:

"Try making the sidebar wider"
"Add another field to this form"
"Change the API endpoint to /v2/users"

You can make quick changes, see the results, and iterate without the overhead of planning each tiny adjustment.

Familiar Patterns

If you're working with code patterns you know well and you're confident in the approach, Fast mode gets you there faster:

"Add a new route for /profile"
"Create a simple React component for displaying user info"
"Write a unit test for this function"

You know what good looks like, so you don't need to review a plan first.

Following Up on Existing Work

When the agent has already done the heavy lifting and you just need small adjustments:

"Make the font slightly larger"
"Add a bit more padding"
"Fix that bug we just discovered"

These follow-up tasks build on existing context and don't need new plans.

Exploratory Tasks

When you're just trying something to see if it works:

"Can you add syntax highlighting to this code block?"
"Try implementing this feature and let's see how it looks"

If it doesn't work, you'll ask for something different. No need for upfront planning.

How to Use Fast Mode Effectively

Fast mode is simple, but there are still best practices:

Be Specific and Clear

Since there's no planning phase to clarify ambiguity, your prompt needs to be precise:

Good:

"Change the primary button background color from blue to green"

Less effective:

"Make the button look better"

The second prompt might work, but you're leaving too much to interpretation.

One Task at a Time

Fast mode works best with single, focused requests:

Good:

"Add input validation for the email field"

Less effective:

"Add input validation, fix the layout issues, and update the error messages"

If you have multiple tasks, either make separate requests in Fast mode or switch to Planning mode.

Stay Engaged

Since Fast mode executes immediately, watch what the agent does. If it goes in the wrong direction, you can course-correct quickly:

"Wait, I meant center it vertically, not horizontally"

The fast feedback loop is part of Fast mode's advantage.

Use It for Learning the Codebase

Fast mode is great for quick explorations:

"Show me all the places where this function is called"

"Add comments explaining what this code does"

These quick tasks help you understand the code without major changes.

Common Fast Mode Pitfalls

Fast mode's simplicity can also create problems:

Using It for Complex Tasks

The biggest mistake is using Fast mode for tasks that actually need planning:

Bad idea:

"Rebuild the entire user authentication system to use OAuth"

The agent will try to do it, but without planning, it might make inconsistent changes, miss edge cases, or choose a suboptimal approach.

If the task touches multiple files or has significant complexity, use Planning mode.

Vague Instructions

In Planning mode, vague instructions get clarified during the planning phase. In Fast mode, vague instructions lead to unexpected results:

"Make this component better"

Better is subjective. The agent might optimize for performance when you wanted visual improvements, or vice versa.

Chaining Too Many Fast Requests

Making dozens of sequential Fast mode requests can lead to inconsistency:

"Add field A"
"Add field B"

"Add field C"
"Now style them all"
"Actually, use a different layout"

At this point, you've essentially created a complex task piecemeal. Would've been better to use Planning mode from the start.

Assuming It'll Get Everything Right

Fast mode trades thoroughness for speed. Always review the results, especially for code that'll go to production.

The Practical Comparison: Side by Side 🔄

Let's look at how the same task would play out in each mode.

Example Task: "Create a Contact Form"

Planning Mode Approach:

You submit: "Create a contact form with name, email, message fields, and submit functionality"
Agent creates an implementation plan:

   Goal: Build a functional contact form

   Tech Stack:
   - HTML5 for structure
   - CSS3 for styling
   - Vanilla JavaScript for validation
   - FormSubmit.co for backend handling

   Steps:
   1. Create contact.html with semantic form structure
   2. Implement validation for required fields and email format
   3. Add CSS for responsive design
   4. Include client-side validation with clear error messages
   5. Set up form submission handling
   6. Test across different screen sizes

   Files to create:
   - contact.html
   - contact.css
   - contact.js

You review the plan, notice it's using an external service, comment: "Actually, let's handle the form submission ourselves with a simple PHP backend"
Agent updates the plan to include a PHP handler
You approve
Agent implements everything according to the revised plan
Agent generates a walkthrough showing what was built and how to test it

Total time: ~5-10 minutes, most of which is execution
Your involvement: Reading plan, commenting, approving

Fast Mode Approach:

You submit: "Create a contact form with name, email, message fields, and submit functionality"
Agent immediately creates the form with sensible defaults
You see the result, realize you wanted it styled differently
You request: "Make it look more modern with better spacing"
Agent updates the CSS
You notice validation is missing
You request: "Add form validation"
Agent adds validation
You realize you need a backend
You request: "Add a PHP handler for form submission"
Agent creates the handler

Total time: Similar overall, but broken into many small requests
Your involvement: Constant back-and-forth adjustments

The Difference:

Planning mode gave you visibility and control upfront, leading to a more coherent result in one go. Fast mode required iteration to arrive at the same place.

For a task like this, Planning mode is better. But if you just wanted to add one field to an existing form? Fast mode wins every time.

Switching Between Modes: When to Change Your Approach 🔀

Here's something important: you're not locked into one mode for your entire session. You can (and should) switch based on the task at hand.

How to Switch Modes

It's simple. In the agent panel, you'll see a toggle between "Planning" and "Fast" modes. Click the one you want, or use the keyboard shortcut Cmd/Ctrl + .

The current mode is always displayed in the chat interface, usually in the lower left of the input box.

Strategic Mode Switching

Here's how experienced Antigravity users flow between modes:

Start Big, Then Get Small

Use Planning mode to build the initial feature or system, then switch to Fast mode for tweaks and refinements:

Planning: "Build a blog system with posts, comments, and user authentication"
[Implementation happens]
Fast: "Make the comment form slightly wider"
Fast: "Add a character count to the comment field"
Fast: "Change the submit button text to 'Post Comment'"

Use Planning for Unknowns, Fast for Knowns

When you're unsure of the best approach, use Planning to get the agent's thoughts. Once the pattern is established, use Fast for similar tasks:

Planning: "Create a reusable card component with image, title, and description"
[Review plan, approve, implementation happens]
Fast: "Create another card component for product listings using the same pattern"

Complex Then Simple

After completing a complex task in Planning mode, use Fast mode to handle the inevitable small issues:

Planning: "Refactor the API layer to use async/await throughout"
[Implementation happens]
Fast: "Fix the error handling in the /users endpoint we just refactored"
Fast: "Add a TODO comment about the deprecated method we're still using"

When Work in Progress, Mode Sticks

Important note: if you switch modes while a task is running, the current task continues in its original mode. The mode switch only affects new tasks.

So if you start a complex task in Planning mode, then realize you want to make a quick fix and switch to Fast mode, the Planning task will continue with its plan-based approach while new requests use Fast mode.

Advanced Tips: Getting More from Both Modes 🚀

Now that you understand the basics, here are some advanced techniques:

For Planning Mode:

Use Sub-Plans for Massive Projects

For truly large projects, break them into phases and use Planning mode for each phase:

Phase 1 Planning: "Plan the database schema and authentication system"
Phase 2 Planning: "Plan the API endpoints based on the schema we just created"
Phase 3 Planning: "Plan the frontend components consuming the API"

This keeps plans focused and manageable.

Combine with Knowledge Items

Antigravity's Knowledge Items system captures important patterns and decisions. In Planning mode, reference these:

"Create a new API endpoint following the patterns in Knowledge Item #12"

The plan will incorporate your established patterns automatically.

Ask for Multiple Approaches

You can request the agent to propose different strategies:

"Create a plan for the image upload feature, but give me two different approaches: one optimized for performance, one optimized for simplicity"

Then pick the approach you prefer.

Use Plans as Documentation

Save the implementation plans as project documentation. They serve as a record of architectural decisions and can help future contributors understand why things were built a certain way.

For Fast Mode:

Chain Simple Tasks

While I said not to chain too many, you can chain a few simple, related tasks efficiently:

"Add a loading spinner" → [done] → "Make it blue" → [done] → "Position it in the center"

Three Fast mode requests in quick succession can be faster than one Planning mode task for these micro-adjustments.

Use It for Code Exploration

Fast mode excels at helping you understand code:

"Add console.log statements showing the data flow through this function"

"Add comments explaining each regex group in this pattern"

These exploratory tasks don't need planning.

Rapid Prototyping Loop

When experimenting with UI/UX:

"Try a card-based layout" → [see result] → "Actually, try a list layout" → [see result] → "Go back to cards but make them smaller"

Fast mode's immediacy supports this exploratory workflow.

The Mental Model: Choosing Between Modes 🧠

After all this information, you might still wonder: "How do I actually decide in the moment?"

Here's the mental model I use:

Ask yourself:

"If this goes wrong, how bad is it?"
- High stakes → Planning mode
- Low stakes → Fast mode
"Do I know exactly what I want?"
- Yes → Fast mode
- No, I need to see options → Planning mode
"How many files will this touch?"
- 1-2 files → Fast mode
- 3+ files → Planning mode
"Will I learn something from seeing the plan?"
- Yes → Planning mode
- No → Fast mode
"Is this part of a bigger workflow?"
- Yes, it's the foundation → Planning mode
- No, it's a quick fix → Fast mode

If you answer "Planning mode" to 2 or more of these questions, use Planning mode. Otherwise, Fast mode is probably fine.

Real-World Examples from My Experience 💼

Let me share some concrete examples from my own Antigravity usage:

Example 1: Refactoring Easy Kit Utils (Planning Mode)

Task: Modernize the entire utility library

Why Planning: Multi-file changes, needed consistency, wanted to review approach first

Result: The agent created a comprehensive plan showing how it would refactor each utility category, update tests, and maintain backward compatibility. I reviewed it, suggested using specific ES6 features, and the execution was smooth.

Example 2: Fixing a Typo in Documentation (Fast Mode)

Task: Correct a misspelling in README

Why Fast: Trivial change, obvious solution, not worth planning

Result: Done in 5 seconds. No overhead needed.

Example 3: Adding a New Feature (Planning Mode → Fast Mode)

Task: Add user profile functionality

Why Planning first: Complex feature with multiple components

Result: Used Planning for the initial implementation (profile page, data storage, API endpoints). Then used Fast mode for tweaks like "add a character limit to the bio field" and "make the avatar circular instead of square."

Example 4: Debugging (Fast Mode)

Task: Figure out why a function isn't working

Why Fast: Exploratory, trying different things quickly

Result: "Add logging to this function" → "Add error handling" → "Try calling it with different parameters", Fast mode's immediacy helped iterate quickly.

Example 5: Learning a New Framework (Planning Mode)

Task: Build a component in a framework I'm not familiar with

Why Planning: Wanted to see best practices before code was written

Result: The plan showed me the framework patterns and conventions. I learned from the plan, made suggestions to align with project structure, then approved and watched the implementation to learn more.

Common Questions and Misconceptions 🤷

Let me address some frequent confusion I've seen:

Q: "Is Planning mode slower?"

A: Yes and no. The planning phase adds time upfront, but often saves time overall by avoiding missteps and rework. For complex tasks, Planning mode can be faster end-to-end.

Q: "Can I edit the plan before execution?"

A: Yes! Use inline comments to request changes. The agent will update the plan based on your feedback.

Q: "Does Fast mode mean lower quality?"

A: Not necessarily. It means less deliberation, but for simple tasks, the quality is identical. For complex tasks, yes, Planning mode tends to produce better results.

Q: "What if I start in the wrong mode?"

A: You can cancel the current task and restart in a different mode, or just let it finish and switch modes for the next task.

Q: "Does the agent 'remember' between modes?"

A: Yes, the conversation context persists. You can use Planning for one task, Fast for the next, and the agent knows what happened previously.

Q: "Why would I ever use Planning mode if Fast is quicker?"

A: Because "quick" isn't always "best." Complex tasks need deliberation, oversight, and structured thinking, exactly what Planning provides.

What I Want to Hear From You 💬

Alright, now it's your turn! I've shared my experiences and understanding of Planning vs Fast modes, but I know I'm not the only one experimenting with Antigravity.

If you've used either or both modes, I want to hear from you:

Which mode do you find yourself using more often?
Have you discovered use cases where one mode clearly outperforms the other?
What's your decision-making process for choosing between modes?
Have you found any gotchas or unexpected behaviors?
Do you have tips or workflows that leverage both modes effectively?
How do these modes compare to other AI IDEs you've used?

If you're new to Antigravity and considering trying it:

What questions do you have about these modes?
What kinds of tasks are you hoping to use it for?
Does the Planning vs Fast distinction make sense, or is it confusing?

Drop a comment below! Your experiences help everyone learn faster. Plus, I'm genuinely curious if my mental models align with how others use these tools, or if I'm missing something.

The community's collective wisdom is how we all get better at this new paradigm of development.

Conclusion 🌟

Google Antigravity's dual-mode approach, Planning and Fast, represents a thoughtful design decision. Rather than forcing everyone into a single workflow, it acknowledges that different tasks require different levels of deliberation.

Planning mode is for when you want to understand the plan before execution, when complexity demands structure, when you're learning, or when stakes are high. It's the architect mode.

Fast mode is for when you know what you want, when the solution is obvious, when you're iterating rapidly, or when overhead would be counterproductive. It's the builder mode.

Neither mode is inherently superior. The skill is knowing which to use when.

As I've worked with Antigravity, I've found that my mode selection has become more intuitive. I don't consciously run through a checklist anymore, I just feel which mode fits the task. That comes with practice.

My advice? Start with Planning mode for most things as you learn Antigravity. The plans teach you how the agent thinks. As you get comfortable, you'll naturally start using Fast mode more for the simple stuff.

And remember: you can always switch modes mid-session. If you realize you chose wrong, just switch and move on. It's a tool, not a commitment.

The future of development is agentic, and interfaces like Planning vs Fast modes are how we'll navigate this new paradigm. Learning to use them effectively is an investment in your future productivity.

So experiment, break things, try both modes extensively, and find the workflow that fits your style.

Happy coding! ✨

🌲 Linktree: https://linktr.ee/domenicotenace
🐙 Domenico Tenace Open Labs: https://github.com/Domenico-Tenace-Open-Labs

Follow me on dev.to for more articles 👇

Domenico TenaceFollow

Passionate about the IT world and everything related to it ✌🏻 Open Source enthusiastic 🦠

If you like my content or want to support my work, you can support me with a small donation. I would be grateful 🥹