DEV Community: Playful Programming

My AI Content Journey

Ryan Carniato — Wed, 19 Aug 2026 16:47:10 +0000

I apologize ahead of time, what follows has no tooling applied to it. No grammar checks, no AI, and no edit passes for flow. It might be a bit rough, but that's important.

For those who know me, I've written hundreds of articles over the last 8 years. I realized very early into my journey of creating SolidJS that education was going to be a fundamental barrier. React's rhetoric had consumed the frontend space in such way that the discussion of different ideas was not welcomed warmly. It may have started with the ideas, but the complexity of the move to modern tooling had left many feeling overwhelmed. The term "JavaScript Fatigue" was being thrown around, and those who didn't sneak in before 2016 were subject to it.

My early writing was rough. I mean really rough. I'd try to articulate my ideas, but they were hard to translate. It wasn't that I didn't have decent command of the English language. I always had done well in school. But the ideas I wanted to articulate extended past code examples. They borrowed from years of observations and cross discipline learning. It would take the span of a whole article for me to get my point across and it was really easy to get lost in the details.

It didn't help that I wrote like I talked. Which is rather disjointed. When I used to type messages on ICQ and MSN back in the day I'd keep thumbing the "." as a way to convey to the recipient the pacing. The more "..." the longer the pause. I had needed to communicate at work, obviously and had gotten used to rewriting my emails on average three times so that I could cut out things that were unnecessary.

So I published my earlier articles on Medium in 2018 and fortunately for me, the early Solid community on Gitter and Spectrum started providing me edits. This pattern of reviewing my articles with the community never went away. Most of my articles today still appear in the Solid Discord days before publishing.

Stepping up my Game

At some point, a community member suggested I pick up Grammarly. Honestly, it was such a huge help. I always skipped words and commas in certain places. Given I had the free tier it would also hint when I phrased something a lot oddly so I could at least give a shot at rewriting it.

This was better but honestly it fixed less than you would think. I wasn't falling into the simple traps. But the writing wasn't really anymore clear. The big break through there was when I started getting my work published through online publications. Specifically, "Angular in Depth" in 2019 time period. They were really supportive of my content but they saw that it was missing the audience.

I remember at one point @layzee sat down with me and picked through an article with me showing me how to break my writing up into more paragraphs. I was accustomed to having a paragraph express what I considered a complete idea. That meant 6-8 run-on sentences. He was like no more than 3. Give them a break to sit with what you just told them. Add spacing and images to your articles for the same reason.

I didn't like this much at first because it made my articles longer. Too long as far as I thought. But it also forced me to really focus on what I wanted to say. I'd need to do one editing pass to break things up and another to eliminate the cruft.

At this point, Solid was picking up steam, and there were others in the community that were interested in seeing us succeed. Some of you may not know but Theo Browne (T3.gg) reviewed many of my articles during the 2020-2022 time period. He had a lot less tolerance for sentences that didn't flow and he would go through and gut all my unnecessary phrasing. All the "And ...", "In fact", "But Honestly", "Actually..", "Simply put,". He emphasized it didn't add anything. By doing that I was able to save those for when I wanted to make a real impact.

So that gives you some insight into where my writing process was through the end of 2025. I'd write something rough, do multiple passes myself, run it through Grammarly, feed it to the Solid community. Have feedback, then pass it to a few specific reviewers (although some like Theo were getting too busy to look at my work regularly). And half a dozen people and twice as many hours later we had an article.

Enter LLMs

Now I never prompted an LLM intentionally before the end of 2025. As I have noted in previous articles, I was an AI laggard. Sure Gemini results would show up on a Google search. And I had dabbled with some image generation for Articles/Streams. But I did not use Chat LLMs directly at all. Funny enough, since late 2023 I had noticed two phenomena.

First, absolute garbage articles quoting my work in like "Best JavaScript Frameworks to use in 2023". At first I thought these were just low effort marketing articles. Some of them probably were. But after a while I came to recognize these as AI generated.

Second, people coming on to my articles and accusing them as being AI generated. My response would be, "Did you read the article?" There is no way AI makes that argument. But the general feedback was that the articles were vague because they tried to pack too much into a small space. And the move between macro and micro details was disorienting. Ironically my trademark writing style because it was born out of necessity.

I mostly pushed both of these aside. What had always mattered was the content. Those two couldn't be more obviously different. Even if I did my own yearly JavaScript summaries, any one with half a brain could tell the difference. My articles had takes that existed nowhere else and provided a deep insight.

Trying LLMs for Myself

I was working on Solid 2.0. High-level design stuff late 2025 and I decided to give LLMs a try. Not for coding just to talk through the problem and see if they had an insight. I believe GPT 5.3 was out but I was just using CoPilot for free which was on 5.1. I found the process very frustrating because it kept losing details. I realized pretty quickly I needed to have it write things down.

As I got more excited about formalizing these designs I got AI to write short explainers about what we had talked about so that I could share them in Discord. This was very helpful since my HackMDs I had been writing were cryptic and people could immediately understand what I was talking about this way. Maybe not deeply but the gist of it.

Summaries of really high level stuff. The thing I was particularly bad at writing. It was very common in the Solid community for people to post AI written summaries on my writing since no one seemed to get what I was saying and I didn't have time to clarify while working on cutting edge things.

But every time I tried to get AI to really capture the real point behind my stuff it missed. Even after moving to Cursor and frontier models. AI could write something coherent but it was never the position or argument the way I'd make it. As before it didn't have my original positioning/takes. Occasionally it would come up with something interesting like: The Architecture of Temporal Determinism. But that was a rare occurence.

AI Assisted Writing

So at some point, tired of the Yellow squigglies I was getting from Grammarly--the ones that you need to pay for that refer to structural issues--I was like why don't I feed my article to the LLM instead? And I was amazed.

It took what I wrote and it sounded coherent. No initial 3 passes, no Grammarly, no community pass, no special editors. Yes I still ended up doing all of those but it was like it skipped to the finish line. There was very little feedback down the line.

The part that really loved was it simultaneously made my writing shorter while bringing back that pacing I heard in my head. The old pauses. The way it used semi-colons and -- was exactly what I intended. No broken sentences. No confusion on flow. It just read perfectly.

I was so impressed. There were a couple things I thought odd. It really liked sumarizing at the end of each section. I had a habit of connecting sections with a probing sentence for sure, but AI liked to try to tie things in a bow. And those additions were the place that I immediately cut out. Easy to see. But for the most part it was like what I had always been looking for. I'd struggled being terse and clear and it just gave it to me, in mostly my own words.

I released my first article like this:

Ryan Carniato for Playful Programming

Mar 13

Two React Design Choices Developers Don’t Like—But Can’t Avoid

#javascript #webdev #solidjs #react

9 min read

and I was pretty excited. This was an important article. It was where I was going to do the unexpected: express to the world that React, a long time competitor philosophically, was actually completely right about a few things. It was controversial. It was honest. And it needed to be clear more than anything I'd done before.

In hindsight, the response should have been obvious. People couldn't get over the AI phrasings in places. That's the thing. It only takes a couple of places for the radar to go off. I had the before and after AI for this article I actually showed it on stream. I wrote every bit of the source. The things that people were accusing being AI were as much me. I thought that by taking accountability, owning it would be enough.

But this kicked up a rage. And I admit I felt a bit resentful. This is critical work. From my perspective earthshaking and all people could seem to talk about was that I used AI to make the message clearer. I had been dismissed in the past for being vague or hard to follow. Now I was being dismissed for the opposite.

I had also received similar feedback on using AI-generated covers. Previously, I was picking up random free images online. It took some cleverness to choose the image but it wasn't some work that I put in. AI had actually given me images suitable to my content. Again it seemed so much better to me. I'm not an artist. But somehow it wasn't acceptable. It seemed irrational to me. I put more effort in, to come up with a better result. I was clearly missing something.

Another Attempt

Last week, I took that lesson and tried something a little different when we dropped the Solid 2.0 RC release announcement. I had written release articles before but they were always tough. Short attention spans and a need to get to the point. And Solid 2.0 was proving difficult. It just had too much stuff in it. A point form list undersold it but there was no way I was going to be able to get into all the details.

I had written an article showed it to AI and it had done some edits. And this time I was more careful to cleanup language. Not because I thought it was bad but because I knew it would trigger people. However, no matter what I did the article was way too long. At some point the agent suggested the obvious. Make a follow-up article series. It would summarize the some of the pieces we would be removing. And we would be set.

I looked at the work and I was impressed it had kept my opening and sentimental parts and filled in the gap with the type of clear, to-the-point way that I'd expect in a release article. It was way shorter than what I had written and after a quick pass, everyone who reviewed agreed it was much more approachable. The language here was not nearly as AI-sounding because I didn't get it to really rewrite what I had written where it mattered. But obviously, even after human edits on the more marketing side there were still some traits.

Again, and I imagine it was because people didn't get to the end. The response was half about the use of AI in those point form lists. The general sentiment was that it was subtle but still enough to notice. It was genuinely a better article for it, it fit the purpose of the writing. But they couldn't see past it. Most of the article had the human soul, but a few point form lists ruined it.

Today

I had an odd week. It started with seeing an AI Gist comparing Solid 2.0 to Octane. I saw that Dominic had responded with some agent-assisted prose, and I knew there was no way I was going to keep up with that discussion while pushing forward all the post-release things I needed to do without doing the same. We literally had the Agents arguing our points. You can tell they are our points. Our fundamental positioning, but it isn't our voice.

But the most warmly genuine thing happens at the end. We both remove the Agent and have a real discussion. I think we both realized how ridiculous it had become.

Now, the problem is that it isn't too far from how we are working today. When I have an agent review and issue or PR even if I'm driving it, reviewing the changes, and setting the response, it no longer sounds like me. It's easy to justify the reasoning.

Look at how many open issues/PRs are on SolidJS right now. There is no way we could be as responsive without it. We've almost closed out every issue. That is between issue submitters using agent-guided PRs and from our own agent work. But a certain human aspect is gone. I used to go on every PR and write a thank you note personally and I know I haven't done that as much the last couple months. I can justify it, but there is a human cost.

I'm also about to release another article. I'm trying yet another approach to this. Where I write it, feed it to AI, but never let AI edit the actual article. When it identifies something that it rewrites, I take that as a sign my writing isn't the best there and read what the AI wrote, then minimize the window and write back the structure myself using my own voice. We'll see if this lands better.

It's tricky because I can already hear LLMism in my own writing. According to critics, I was already pretty close years ago. And if I already think it sounds better than what I write I have a bias. But it's the most honest thing I can do to produce good content. And I mean good content. Not whatever this is. So I'm going to try again. I'm still figuring this out.

That's all we can keep doing.

Functional languages are heavily imperative.

Mike Pearson — Mon, 17 Aug 2026 07:39:18 +0000

This article will seem full of contradictions.

Even writing it feels like a contradiction: Why am I digging through academic Haskell papers from the '90s right in the middle of my AI psychosis moment? Literally, as I write this, I am running my first experiment with an agent delegating tasks to another agent. So why am I spending time on esoteric academic nonsense instead of giving in to the vibes and building my loopy graphy software factory?

I am writing this because AI is a nuclear amplifier on the patterns we establish in our codebases, and we literally do not have the right terminology to establish scalable patterns. Nobody has the answers we need because nobody even has the right terminology to talk about it.

Two Dimensions, Not One

Industry dogma says that functional and declarative are synonyms—that code is either side-effectful and imperative, or pure and declarative:

But functional and declarative are independent dimensions:

Code that is both functional and imperative debunks this, and so does code that is both side-effectful and declarative.

Both exist!

"Imperative Functional Programming"

Simon L Peyton Jones and Philip Wadler helped create Haskell, which is a beautiful, pure functional programming language.

In 1993 they wrote a paper called "Imperative Functional Programming." The title may sound like an oxymoron, but it isn't.

The functional programming community had been struggling with how to manage side-effects like I/O, and these co-creators of Haskell proposed a way to decouple the expression of I/O commands from their execution.

But they noticed something:

It will not have escaped the reader’s notice that programs written in the monadic style look rather similar to imperative programs. For example, the echo program in C:

echo() {
loop: a = getchar(a);
    if (a == eof)
        return;
    else { putchar (a);
        goto loop; }
}

In Haskell:

echo :: IO ()
    echo = getcIO 'bindI0' \a ->
    if (a == eof) then
        doneIO
    else putcI0 a 'seqI0'

Does the monadic style force one, in effect, to write a functional facsimile of an imperative program, thereby losing any advantages of writing in x functional language?

Nope! Jones and Wadler list two advantages that remain:

List operations (like mapand append) can still operate on monadic commands
Effects can be expressed without immediately executing them. "It's a bit like being able to define your own control structures in an imperative language."

Recognizing the imperative structure of the Haskell monadic pattern does not mean we have to abandon the advantages that are inherent in pure functional programming.

But it is still imperative structure.

"Lazy Imperative Programming"

John Launchbury, another creator of Haskell, wrote a paper the following year called Lazy Imperative Programming.

In it he says,

Imperative features were introduced to Glasgow Haskell for expressing input and output.

Could this be plainer? Haskell has imperative features.

And the Haskell code that uses them is imperative. Also from his paper, an "Imperative Scan Left":

writeVar is an imperative statement, which is why this is an example of imperative code—written entirely with pure functions!!!

The paper has many other references to imperative stuff, including this:

In a strict imperative framework such as the IO monad (and most imperative languages), no value could be returned until the whole of the list was traversed. Using lazy sequences, however, this is not the case. If only the head of the list is required then very little of the computation is performed: the variable is allocated and initialised, it is read, and the list returned with that value in the head. If even less is required, merely whether the final list is empty for example, then the variable is not even allocated as only xs needs to be examined in order to give the structure of ys.

🤯
This is insanely cool.

Again, not everything in Haskell has to be declarative for it to still allow for incredible execution properties!

The "Imperative Feel" of Concurrent Haskell

Paul Hudak (another creator of Haskell) and Conal Elliot wrote a paper in 1997 where they weren't happy with the "strongly imperative feel" of Concurrent Haskell—even though it was 100% purely functional.

(Side note: I owe my passion for programming to this paper. More on that later.)

Here's an example of what that pure functional approach with an "strongly imperative feel" looked like:

box <- newEmptyMVar

forkIO $ do
  threadDelay 1000000
  putMVar box 42

result <- takeMVar box

puTMVar box 42 expresses a command to set box's value to 42.

In the authors' own words,

While this system is purely functional in the technical sense, its semantics has a strongly imperative feel. That is, expressions are evaluated without side-effects to yield concurrent, imperative computations, which are executed to perform the implied side effects. In contrast, modeling entire behaviors as implicitly concurrent functions of continuous time yields what we consider a more declarative feel.

It is not a coincidence that the definition of "imperative" in English is "expresses a command" and that a line of code that literally "expresses a command" had an "strongly imperative feel"—even in Haskell.

But the authors were dissatisfied with that "imperative feel"—so they invented functional reactive programming (FRP):

box t0 =
  0 `untilB`
    predicate (time >=* t0 + 1) t0
      -=> 42

Just a single declaration. Nothing here expresses a command at all. putMVar is 100% imperative, while this is 100% declarative and 0% imperative.

Note on "more declarative" and monoparadigmatic dogma

Since the industry dogma in the 1990s was "functional = declarative", they had to call FRP more declarative. Concurrent Haskell was already declarative, supposedly, by virtue of being in Haskell—so this had to be extra declarative 🤷

And I say that with great admiration for these authors, because I owe my passion for programming to this paper. This was the origin of both RxJS and signals, which I love... very much. Too much for many people.

The "Lazy Imperative Programming" paper was more contradictory. The author often contrasted Haskell with "imperative languages," while dozens of times referring to features within Haskell as imperative.

On the one hand, functional languages are commonly more expressive and easier to reason about than imperative languages,

After reading 20 or so papers from the 1990s talking about programming paradigms, you will understand that the terminology was extremely entrenched. Academics classified programming languages into rigid categories to help explain the programming patterns of the time.

Functional programmers were especially guilty of reinforcing this reductionism, since they were a minority of programmers and had to fight against the grain with every rhetorical tool they could. Branding functional programming languages as automatically 100% declarative was an enticing selling point—even though we have many Haskell creators very plainly referring to features within Haskell as imperative.

Also, in the 1990s very few "imperative languages" had added much functional features, having not had to deal with much concurrent processing yet, which meant languages really did mostly fall into neat categories; multi-paradigmatic languages were not the norm like they are now. The concept of entire languages as "imperative" or "declarative" somewhat applied back then, but today is a nothing but a leftover from decades of synchronous code that all matched the same 2-3 structural patterns.

We have to make a mental note of this history, but if we do not push to correct the terminology, it will continue to confuse developers and AI. Many developers think that stuffing imperative features between < > characters magically makes them declarative because it's part of HTML, a "declarative language." Some are attempting this and creating masses of spaghetti code that only cosmetically looks different from the imperative JavaScript spaghetti they were writing last year.

There are no "declarative languages" and "imperative languages", as much as it would simplify selling them. There are commands expressed in code, which are imperative by the purest definition; and there are features and behaviors declared without scattered commands controlling them from elsewhere.

Conclusion (Imperative Functional Programming)

The literal precise English definition of "imperative" is something that expresses a command. That is what these pure functions are doing in Haskell and other functional languages. This should already rest the argument.

But even the less precise definitions of imperative programming focus on structural descriptions written in code rather than execution details:

"Imperative programming involves writing programs as sequences of explicit commands that are executed in order from top to bottom." https://builtin.com/articles/imperative-programming
"logic encoded as a sequence of ordered operations" https://en.wikipedia.org/wiki/Programming_language
"Imperative programming focuses on describing how a program operates step by step, rather than on high-level descriptions of its expected results" https://en.wikipedia.org/w/index.php?title=Imperative_programming
"With an imperative approach, a developer writes code that specifies the steps that the computer must take to accomplish the goal." https://learn.microsoft.com/en-us/dotnet/standard/linq/functional-vs-imperative-programming
"Imperative programming languages are composed of step-by-step instructions (how)... By contrast, in declarative programming, the desired result (what) is described directly." https://www.ionos.com/digitalguide/websites/web-development/imperative-programming/
Imperative programming is a paradigm where you explicitly state how the program should achieve the desired result. https://octopus.com/devops/infrastructure-as-code/declarative-vs-imperative-programming/

It's very clear that Haskell and functional programming languages are extremely cool with the flexibility they afford for all kinds of things, including the execution of side effects.

But Haskell has features that enable writing literal imperative commands even with pure functions. This results in code that is structured imperatively: Explicit commands incrementally adding to behavior described elsewhere. The instant a single command appears, it completely takes away the declarative quality of describing the final result of something up-front. The imperative features of Haskell are not just less declarative; they are completely anti-declarative.

Functional programming can be imperative.

Declarative Side-Effects

RxJS

RxJS enables fully declarative code, despite latent side-effects.

RxJS actually came from that Fran paper we looked at earlier, which proposed a way to turn this kind of Concurrent Haskell:

box <- newEmptyMVar

forkIO $ do
  threadDelay 1000000
  putMVar box 42

result <- takeMVar box

into this:

box t0 =
  0 `untilB`
    predicate (time >=* t0 + 1) t0
      -=> 42

Neither of these trigger side-effects, but the declarative version structures the code as a single description of a complete, final logical result (a behavior over time). The thing that made the first imperative and the second declarative is the structure of the code, not the side-effect execution model.

The same structural move can be made in side-effectful code:

const box = Promise.withResolvers();

setTimeout(() => {
  box.resolve(42);
}, 1000);

const result = await box.promise;

const box = await lastValueFrom(
  timer(1000).pipe(map(() => 42)),
);

Both of these trigger side-effects when executed, but the declarative version structures the code as a single description of a complete, final logical result. The thing that made the first imperative and the second declarative is the structure of the code, not the side-effect execution model.

These four code snippets alone are enough to complete our four quadrants:

But let's look at some more common declarative side-effects.

HTML

"HTML is declarative" is often said. And it's mostly true (see above callout "Note on "more declarative" and monoparadigmatic dogma").

Yet the entire point of HTML is a side-effect: You being able to look at beautiful interfaces like this:

It's not just the DOM that's a side effect though. The HTML rendered in the page can itself trigger other kinds of side effects, like network calls:

<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.0/dist/css/bootstrap.min.css" />
<script src="https://cdn.jsdelivr.net/npm/axios/dist/axios.min.js"></script>
<!-- ... -->
<img src="https://storage.googleapis.com/blog-images-backup/1*tY3o3UFtBaMQ103en48qxA.png" />
<iframe src="https://www.youtube.com/embed/dQw4w9WgXcQ" />

Nondeterministic Declarations

`Math.random`

Math.random() technically produces a side effect because it relies on and mutates a hidden global internal state (the seed or PRNG algorithm pointer) inside the runtime environment to generate its next value.

But this is still totally declarative:

const x = Math.random();

`Date.now()`, `crypto.randomUUID()`, `process.memoryUsage()`, etc...

const now = Date.now();
const date = new Date();
const perfNow = performance.now();
const randomBytes = crypto.getRandomValues(new Uint32Array(1));
const uuid = crypto.randomUUID();
const hrtime = process.hrtime();
const uptime = process.uptime();
const memoryUsage = process.memoryUsage();
const freeMemory = os.freemem();
const battery = await navigator.getBattery();
const windowWidth = window.innerWidth;
const visibility = document.visibilityState;
const online = navigator.onLine;

All of these are completely declarative. They are declarations of final results, and no subsequent step-by-step (or any) imperative code is involved.

But they are not pure functions. They don't have side effects, but they have side causes, so they still are not functional. So while they aren't examples of declarative code that causes side effects, they are examples of declarative code that break rules of functional programming, showing that these are independent dimensions.

Declarative "Pure" Functions with Side-Effects

CPU

const fib = (n: number) => n < 2 ? n : fib(n - 1) + fib(n - 2);
const result = fib(50);

Everything here looks pure as the driven snow, and it's definitely declarative.

No side effects at all, right?

In fact, it triggers 40,730,022,147 calls, which means that its side effects are so severe that I really don't recommend pasting that into dev tools and running it. You think jQuery has interesting side effects by reaching into the DOM and changing the behavior of random things, but this will change the behavior of everything on the page. Namely, it eliminates it because it locks up the CPU.

Memory

new Array(2 ** 30).fill(0);

No side effects here, right? It's declarative, at least.

However, this might get compiled into assembly code that looks like this:

mov     rdi, 8589934592
call    malloc

mov     rcx, 1073741824
mov     rdi, rax
xor     eax, eax
rep stosq

There is a huge side-effect in this code: call malloc requests 8589934592 = (2 ** 30) × 8 bytes = 1,073,741,824 × 8 bytes ≈ 8 GiB of memory.

There may be guardrails against creating arrays this big. I didn't feel like testing it. But there is a variation that may not be prevented:

Array.from({ length: 1000 }, () => new Array(1_000_000).fill(0));

This time each inner array has only 1 million elements, but there are 1000 of them, so 1,000,000,000 total elements.

Here are some possible side-effects:

The page or Node.js process becomes unresponsive while the runtime tries to allocate and initialize the array
In a severe case, the browser tab crashes because it exceeds its memory limit.

And yet, it's still declarative.

Conclusion (Declarative Side-Effects)

Declarative and functional are not synonyms. Declarative code is about how a computation is structured: describing a result rather than spelling out a sequence of commands to get there.

Functional purity is about what that computation depends on and affects. A declaration can trigger network requests, consume CPU and memory, observe clocks and runtime state, or depend on hidden mutable state without becoming imperative.

These are separate dimensions.

Conclusion

The point of separating these dimensions is not to win a pointless terminology argument. It is to make better engineering decisions while AI is applying incredible pressure on our architectural patterns.

If we collapse functional into declarative, we lose the ability to talk precisely about what code is doing. Pure code can still be structured imperatively. Declarative code can still observe mutable state, trigger I/O, allocate absurd amounts of memory, or otherwise affect the world.

Structure and purity are independent properties of code that sometimes align, but DO NOT HAVE TO!

If the problem is hidden state, surprising effects, or difficulty reasoning about dependencies, functional programming can help with its explicit inputs, immutable values, pure transformations, effect isolation. And although I love functional programming, in my experience, most apps genuinely will never see significant consequences for not being purely functional.

However, most apps I have seen have suffered severely from being imperative: It always scatters control, with commands reaching across a system (spaghetti code), or behavior that can only be understood by mentally executing twenty steps across multiple contexts. Declarative code fixes this. Functional programming does not.

I am sick of saying I like declarative code and being told to juST UsE ELm or HASkElL.

People can't even understand the problem because they don't have the words to discuss it properly.

Now throw AI into this cross-talking mix of contradictions, and this is what we can expect:

This looks delicious, but can we please try to avoid it anyway?

Let's fix our vocabulary so we can learn real things about imperative code and steer humans and AI away from it.

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 🥹

☕ Buy me a Coffee: https://buymeacoffee.com/domenicotenace

Originally published on ZyVOP

💡 For more articles like this, subscribe to the ZyVOP newsletter!

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 🥹

Introducing Argus: The Code Security Colleague Your Team Doesn't Have

Davide Imola — Thu, 30 Jul 2026 08:56:00 +0000

Most development teams don't have a security engineer. Not because they don't want one. Security expertise is genuinely hard to find, expensive to keep, and most of us would rather ship features than spend an afternoon reading about deserialization gadget chains. So security becomes the thing you'll get to later, and later never comes.

I've believed for a while that AI is going to change security, and not as a slogan. The reason is structural: there aren't enough people. The industry is short something like 4.8 million security professionals worldwide,¹ which is the gap from that first paragraph counted globally, and no hiring spree closes a hole that size. AI won't close it either, and I want to be honest about that. What it can do is make the gap hurt less: take the routine load off the few people who are there, and keep a small team, or a team of one, from being buried. Same as it did for my coding, where it didn't make me smarter, it just stopped the grunt work from being the bottleneck.

A good model has read more security than most of us ever will: the best practices, the attack patterns, the bugs that hide in plain sight. Point it at code written by someone who isn't a security expert, which is most of us, and it genuinely lifts what they can ship safely. This isn't a spectator take for me either, it's what I spend my days on, building products that live right at that intersection. And the other side already gets it: attackers are using AI right now, so insisting defenders shouldn't is not caution, it's a handicap.

Concretely, I already use AI for security review, enough that I'm building a talk around how to do it well: lean on the skills that already exist, write your own, and point them at the real tools you already have. Give a capable model the right context and it quietly does a lot of the work a tired reviewer skips under a deadline. What it doesn't do is stick around. Every session starts from zero, knows nothing about your last review, forgets what you told it yesterday.

Then I started using OpenClaw, and it reframed the problem for me. OpenClaw is an always-running agent with a SOUL, a memory, and enough context about you that talking to it feels less like prompting a chatbot and more like messaging a colleague. It remembers. It knows your setup. I used it for useful things and for completely useless ones, and I had a lot of fun. We've mostly stopped since, if I'm honest, but it worked, and somewhere in there the idea landed: what if that colleague did security?

That's Argus: an open-source application security agent, written in Go, that I've been building with a few colleagues at RedCarbon. It's the project that quietly took the place of Worky, the tool I built and then never used, except this one has a mission I actually care about, so I'm not going anywhere.

Fair warning before you get excited: Argus is v0.2.0, and it's as much an idea as a tool. It's the thing I kept wishing existed, so I built a first version with people who actually do security for a living. I'm not sure I've got the shape right, but the shape is the part worth arguing about, and I'd rather do that in the open than sit on it.

Why security review needs a different shape

I want to be clear here, because this is easy to misread. I'm not saying AI security review is a bad idea. It's a great idea. What I don't believe in is doing it with AI alone. Models hallucinate, and a confident, wrong answer about a vulnerability is worse than no answer at all. Lean the whole thing on a model and you get a tool that sounds authoritative while quietly missing the one finding that mattered.

So the bet behind Argus isn't "point a model at your code". It's the union of three things that each cover for the others' blind spots: deterministic security tools that have been proven for years, a human kept firmly in the loop, and a model to tie it together and reason across the whole picture. Take any one of the three away and it falls over. Especially the human.

Recognizing a security problem is not something you wing. Get a code suggestion wrong and it's annoying; get a security call wrong and it's a breach. So an agent you'd actually trust with this has to earn that trust in ways a coding assistant never has to. Its answers need to trace back to something real instead of a confident guess. Its memory, from the moment it has one, becomes a thing attackers will try to lie to, so who gets to shape it suddenly matters. And it has to understand your world in particular, not security in the abstract, because a good share of the problems that actually bite only make sense once you know how your systems fit together.

None of these choices are settled. They're the ones I'd make today, pulled from the years I've spent around cybersecurity and filed down to the few details I think actually matter. I'm genuinely happy to have every one of them argued with. Here's the reasoning, a piece at a time.

Structured tools, not a shell

The default way to build a code agent in 2026 is to hand a model a shell and let it run. It works shockingly well for writing code. For security, I didn't want it.

When an agent has a shell, two things are true at once: it can do anything, and you can't be sure what it did. In a security context that's backwards. You want the opposite. A small, known set of capabilities, each one auditable.

So Argus doesn't get a shell. It gets tools. Under the hood there are real, boring, deterministic security scanners: Semgrep for static analysis, Gitleaks for secrets, osv-scanner for vulnerable dependencies. Each one is wrapped as a structured tool the agent can call, not a command it can type. The scanner runs, returns structured findings, and the model reasons on top of that.

This is also where an agent earns its place, because application security doesn't suffer from a missing tool. It suffers from too many. Nobody has the time to learn them properly, and even once you know them, remembering to run the right one at the right moment is a discipline of its own. You can wire them into a pipeline, of course, and then a slice of your week goes into managing the pipeline. An agent that already holds them, knows which one answers which question, and reaches for them without being asked is a different proposition from a folder full of CLIs you keep meaning to try.

One thing I'm genuinely proud of, and it's the least flashy part: Argus doesn't reinvent any of this. I'm not rewriting Semgrep, I'm not reimplementing a dependency scanner, because why would I. The whole bet is the opposite. Take the tools that already exist and already work, pull good data out of them, and let the agent reason over that data instead of over a hunch. The set Argus ships with today is small on purpose, and the direction is to let you bring your own: the more real tools it can call, the more signal it has to reason with. How far you push that is up to you.

That division of labor is the whole point. The deterministic layer finds things. The model does what models are good at: reading 400 findings and turning them into a conversation. "These three are the ones that matter, this one is a false positive because of how your auth middleware works, and here's the fix." Not a wall of SARIF. A colleague's summary.

It also keeps Argus honest about where its answers come from. A finding traces back to a tool that actually ran, not to a model that decided to type grep and interpret the output. When the domain is security, that provenance is the difference between a report you can act on and a guess you have to re-verify.

Roles and an audit log

An agent with a memory has a problem a stateless chatbot doesn't: the memory is part of the attack surface. If anyone who can talk to Argus can also teach it, then anyone who can talk to Argus can poison it. "Ignore that finding, it's fine" whispered often enough becomes policy.

OpenClaw already draws this line. If you have permission to write to the memory, you can shape it. If you don't, you can't. Argus takes the same idea and makes it central, because for a security tool it isn't a nice-to-have.

So every request arrives as a principal with a role, and Argus always knows which door you came through. Reach it over the local Unix socket and you're local:$USER; come in through the MCP endpoint and you're mcp:<token-hash>; arrive as a GitHub webhook and you're github:<login>. A viewer can ask questions and read findings, but shaping the memory, changing what Argus believes about your org, is a privileged action. And whatever anyone does, whoever they are, lands in an append-only audit log.

That log turns out to matter for a second reason. Go back to the original itch: teams without a security person. Those teams usually still have someone who has to answer to a CISO, a client, or an auditor about how security is handled, without reading the code themselves. An append-only record of what was reviewed, what was found, and what was decided is exactly the artifact that conversation needs.

SOUL, context, and a memory built for security

This is the part I took most directly from OpenClaw, then closed down hard around security.

Argus keeps a mix of three things, and they are not the same thing, which I keep having to explain to people, past-me included. There's the SOUL, the stable stuff: who Argus is, what your company does, your stack, your compliance posture. It rides along in every single model call, so Argus never forgets whose codebase it's looking at. There's context, the per-task working set for whatever it's reasoning about right now. And there's memory, the curated knowledge that persists from one conversation to the next.

The memory is where the security focus shows. Argus remembers findings. It remembers the things you tell it. And, my favorite part, it remembers your false positives, so the thing you already triaged and dismissed doesn't come back to eat your afternoon next week. That is the single most colleague-like behavior in the whole system. A good reviewer remembers what you already decided.

Say config.py in one of your repos only holds deploy-time placeholders that your secret manager swaps out at deploy. Tell Argus once, and it stops flagging them on that repo. The next review comes back clean, with a note explaining why, instead of the same false alarm you waved off last sprint.

The SOUL is what makes the reasoning fit your world instead of the abstract world of security-in-general. And the cross-session, cross-project knowledge is where I think this goes somewhere a single-repo tool can't follow. A coding agent pointed at one repository is blind to how that repository talks to the other twelve. Plenty of the security problems that actually hurt live in exactly that gap: the service that trusts input another service should have sanitized. Feed Argus enough of your world and it can start to reason across that boundary. It's early, but that's the direction.

OpenClaw is a general assistant, open-ended by design. Argus is the opposite. It knows it's a security tool, and everything (the tools, the skills, the memory, the persona) is shaped for that one job. Narrower, but deeper.

What Argus does today (v0.2)

Enough philosophy. Here is what actually runs.

One thing to set straight first, because the word "security" invites the wrong expectation. Argus doesn't watch your infrastructure, it doesn't sit in front of your traffic, and it is not a SOC. It reads code. That's the job it's built for, and the rest is somebody else's product.

Argus is a daemon, argusd, one shared instance per organization. Every way you talk to it (a terminal UI, the MCP endpoint, GitHub webhooks, and Slack soon) is a different door into the same process, sharing one memory, one tool registry, one audit log.

The most visible thing it does is review pull requests. Connect it as a GitHub App and it turns up on the thread like any other reviewer, except this one only cares about security. When it flags something you can push back right there, "Argus, is this finding real?", and it answers in context instead of making you go and dig. That back-and-forth isn't a nicety, it's the design: Argus is meant to be argued with, not obeyed.

Because it's also an MCP server, the AI tools you already use can consult it as a colleague rather than a black box. This is the part I reach for most: I point at something I just wrote and ask whether it's safe. And I want to be fair about the alternative, because the tools you already have are good at this. Claude and friends ship security skills, people write their own, and they work. What none of them has is your company: the other twelve repos, how your services talk to each other, which of your systems actually holds the data worth stealing. Ask Argus whether a pattern is a problem and it answers for your world instead of for security in the abstract, because the SOUL and the memory are right there. And it runs skills, which is how security methodology gets baked in. It ships with a handful: pr-quick-check for a fast pass over a diff, authz-audit for hunting authorization flaws, secret-rotation-plan for finding committed secrets and deciding what to rotate first, and threat-modeling for a STRIDE pass. You write your own the same way the built-ins are written, as a Markdown SKILL.md.

Getting started is ./argus init to pick a provider and write your SOUL, ./argus doctor to check the scanners are wired up, ./argus codehost setup to connect GitHub, and plain ./argus to just chat with it. There's a container image on ghcr.io with the scanners pre-bundled if you'd rather not install Semgrep and friends by hand.

A word on which model runs all this, because it's a design choice and not an afterthought. Argus is built to run on the AI you already have and already trust, rather than the one a vendor picks for you. The provider layer sits behind an interface, and argus init is where you choose. Today that choice is still narrow, with one provider implemented, and I won't dress that up as a feature. Support for any OpenAI-compatible endpoint is what I'm building right now, so depending on when you read this it may already be in. That's also the change that opens the door to local models, since most local runners speak the same API, and it matters for the teams I most want to reach: the ones who can't send their code to somebody else's API and don't have the budget to.

Where it's going

The idea list is longer than the changelog, which is the correct ratio for a v0.

The near stuff: Slack as a first-class channel, so Argus really is the colleague you message. Local models. More skills.

The stuff I'm actually excited about: service and code discovery, so Argus builds its own map of your systems instead of waiting to be told, and a view of how your projects connect, because that cross-project graph is where the non-obvious problems hide.

But I want to be careful, because I've made this mistake before. With Worky I built a showcase site and full docs for a tool with zero users, then watched it drift because there was no real usage telling me what to build next. A roadmap without users is fiction. So I'm not going to pretend I know exactly what Argus needs. The roadmap comes from whoever picks it up.

The difference from Worky, the reason I'm not worried this one ends up on the same shelf, is that I use Argus. It has a mission I care about. This is the tool I want to keep alive, and I get a vote in what it becomes precisely because I'm one of its users.

Come build in AI and security

There's a bigger thing behind Argus, and it's the reason I'm writing this instead of just pushing a repo.

AI and cybersecurity are converging fast, and most people are only watching one side of it. Back in June we ran a hackathon at RedCarbon: one day, tiny teams, AI pointed at security problems. I wrote about being on the jury in the Worky retrospective, but the part I keep coming back to is the range. One team went after phishing aimed at non-technical family members. Another built for the SOC. Another attacked the security of AI models themselves. Same prompt, completely different directions, all of them real.

Argus is just my direction, and it comes from something I actually live. I'm lucky here: I have security colleagues at RedCarbon who helped me shape it, pick the tools, and read what those tools are really saying. But they spend their days pointing our own AI agents at SOC problems, and none of them has time to sit behind our code's security posture every single day. So the developers have to, and Argus automates the exact work those colleagues would otherwise do by hand. And that job, it turns out, is increasingly buildable: models are getting good enough at security reasoning that the bottleneck is no longer the model, but whether someone shapes it into something trustworthy and useful.

A while back I wrote that AI will not secure your codebase, that it won't do the job for you but it can surface risk earlier, act as an early-warning system. Argus is me trying to make that concrete. Not a magic box that makes you secure, but a colleague who has read your whole codebase, remembers what you decided, and is awake at 2am when the PR lands.

It's on GitHub, Apache 2.0, v0.2 and honest about it. If you do security, or you just want the security colleague you don't currently have, clone it, break it, write a skill, and tell me how you use it. Real usage is the one thing that turns a fun experiment into a tool that matters, and I learned that the expensive way.

Worky has two stars and I made my peace with that. Argus I'd actually like you to star, because this is the one I'm keeping. And if you've been sitting on your own idea at the intersection of AI and security, stop sitting on it. The water's warm.

The 4.8 million figure is ISC2's estimate of the global cybersecurity workforce gap: the distance between the security professionals organizations say they need and the ones actually available to hire. Source: ISC2 2024 Cybersecurity Workforce Study. ↩

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 🥹

Automating my Codemotion Badge with Antigravity

Luca Del Puppo — Wed, 08 Jul 2026 05:50:52 +0000

Today, I wanna show you how to set up your devices with Antigravity using only the agentic mode, without touching any code.

At the last CodeMotion Rome, I got my special badge. A CM Node, a special hardware board, that you can customise for your conferences.

I'm not a super nerd for this kind of stuff, so I decided to use Antigravity and all its capabilities to build and flash the best board ever for my future conferences.

Small intro about the board

This board has been delivered with a GitHub repository to understand how to flash it and how it works. In Rome, I saw different attendees with awesome badges. For instance, Soumaya had built a badge with a small plastic hand that used a sensor when someone was near her; it started waving to say hi.

Since that day, I have been thinking about what I can build to have a cool badge. Nothing has come to my mind, so today, with this blog, we will build my badge together, and thanks to Antigravity, we will create the best version possible.

Antigravity

If you don't know Antigravity. Antigravity is a set of tools built by Google. We have:

Antigravity 2.0: is a dedicated platform to work with agents. Orchestrate multiple autonomous agents working in parallel across independent projects.
Antigravity CLI: terminal-first surface to interact with Antigravity agents. Stay in your flow without context switching
Antigravity IDE: editor view offers tab autocompletion, natural language code commands, and a configurable, and context-aware configurable agent
Antigravity SDK: build AI agents that autonomously read files, run commands, edit code, and more. The Agent SDK gives you the same tools, agent loop, and context management that power Google Antigravity, programmable in Python.

Today, in this blog post, we will use Antigravity 2.0 to set up the board. You can use this tool to orchestrate many projects from a unique UI. This tool is fully agentic; using natural language, you can spawn agents, plan, and work on your projects. If you want to check the codebase in detail, you must use the Antigravity IDE. I’m not a fan of this decision, I’d prefer one tool for both, but this is what we have, and we must use it as it is.

Let’s start cooking

Okay, after this introduction, let’s see what we can do with Antigravity and the CodeMotion Board.

So, I’m dumb about this board right now, and I want to use Antigravity to figure out what I can do with it and get an idea of what my badge might look like.

I open the Antigravity app, and from the UI, I start a new project, and in the prompt, I type

I want to set up my Codemotion Badge.

It's a CMNode v0 https://www.cmnode.it/en/, and it can be programmed.

I want to create two different screens: the first a classic one with name, surname, heading, and company, and a QR code linking to my website.

The second one must be fantastic, and I want different options to choose from you.

I have this repository as an example to set up the badge https://github.com/Codemotion-Official/CMNode; you can use it as an example to create my badge.

Lastly, I don't want to flash the ROM every time, so I'd like a small web page I can access via Wi-Fi to update the information.

Can you plan the work to do it?

Include also two or three possible ideas for the second screen. It must be cool and fancy!

The badge is already connected to the laptop in case you want to deploy the result.

Now, I press enter and let’s see the result and what it will cook.

The result

CMNode v0 WiFi Configuration & Dual Screen Setup

The goal of this task is to upgrade your CMNode v0 badge by replacing the serial-based configuration with a Wi-Fi-based web interface. We will also save the configured data to flash memory so it persists across reboots, and implement two different display layouts: a "Classic" screen and a "Fantastic" screen.

User Review Required

IMPORTANT

Please review the proposed ideas for the "Fantastic" screen below. Let me know which one you prefer, or if you'd like to combine elements from different ideas!

Ideas for the "Fantastic" Second Screen:

The "Hacker Terminal" : A retro command-line interface aesthetic. The screen features a black background with white text, simulating a terminal session (e.g., > user@cmnode:~$ whoami, followed by your details). We can use monospace fonts and add some faux hex-dumps or ASCII elements.

The "RPG Stats / Gamer Card" : Your badge becomes a character stat sheet. It will display you as a "Level 99 Developer" with stats like "INT: 99", "COFFEE: 100%", an energy bar, and your details integrated into a game-like UI.

The "Minimalist Cyberpunk" : A bold, modern, and high-contrast design. It uses large vertical typography for your name, heavy geometric shapes, thick red accent lines, and a large barcode aesthetic alongside your QR code.

Let me know which of these three ideas (or a mix!) you want me to build for the second screen.

Proposed Changes

We will modify the firmware to support a captive-like Wi-Fi Access Point and Web Server.

Core Logic Updates

[MODIFY] src/main.cpp (or NodeV0.ino)

Wi-Fi Access Point : The ESP32-C3 will broadcast an SSID (e.g., CMNode-Config). You can connect to it with your phone or laptop.

Web Server : A built-in web server will serve a simple, mobile-friendly HTML configuration page at http://192.168.4.1.

Form Submission : The webpage will contain a form to update your Name, Surname, Role, Company, QR Link, and a dropdown to select the active screen layout (Classic vs Fantastic).

Persistent Storage : Integrate the Preferences library to save your data to the ESP32's non-volatile storage (NVS). This ensures your badge remembers your details even after turning off.

Display Pipeline : Refactor the drawContent() function to support rendering two completely different layouts based on your selection.

Verification Plan

Manual Verification

I will write the updated code and you will flash it to your badge via PlatformIO or Arduino IDE.

We will verify that the badge broadcasts the CMNode-Config Wi-Fi network.

We will connect to it, open the web page, submit new data, and verify that the E-paper display updates immediately.

We will reboot the badge to confirm the data is preserved.

We will toggle between the Classic and Fantastic screens to verify the layouts.

I commented on the plan, deciding to go with option one and asked for an example design.

Antigravity has started reviewing the plan and updated it in this way

CMNode v0 WiFi Configuration & Dual Screen Setup

The goal of this task is to upgrade your CMNode v0 badge by replacing the serial-based configuration with a Wi-Fi-based web interface. We will also save the configured data to flash memory so it persists across reboots, and implement two different display layouts: a "Classic" screen and a "Fantastic" screen.

Design Choice: "Hacker Terminal"

You've selected the Hacker Terminal idea for the second screen. This layout will simulate a retro command-line interface on the E-ink display:

Background : Black (inverted).

Text : Monospace white font, simulating terminal output (root@cmnode:~$ whoami).

Data : Your name, surname, role, and company will be displayed as the "output" of the terminal command.

Accents : Faux hex-dumps or system logs on the side, and a right-aligned QR code.

Here is a mockup of the design:

Does this mockup and the updated plan look good to you? If so, I will proceed with the implementation!

Proposed Changes

We will modify the firmware to support a captive-like Wi-Fi Access Point and Web Server.

Core Logic Updates

[MODIFY] src/main.cpp (or NodeV0.ino)

Wi-Fi Access Point : The ESP32-C3 will broadcast an SSID (e.g., CMNode-Config). You can connect to it with your phone or laptop.

Web Server : A built-in web server will serve a simple, mobile-friendly HTML configuration page at http://192.168.4.1.

Form Submission : The webpage will contain a form to update your Name, Surname, Role, Company, QR Link, and a dropdown to select the active screen layout (Classic vs Fantastic).

Persistent Storage : Integrate the Preferences library to save your data to the ESP32's non-volatile storage (NVS). This ensures your badge remembers your details even after turning off.

Display Pipeline : Refactor the drawContent() function to support rendering two completely different layouts based on your selection.

Verification Plan

Manual Verification

I will write the updated code and you will flash it to your badge via PlatformIO or Arduino IDE.

We will verify that the badge broadcasts the CMNode-Config Wi-Fi network.

We will connect to it, open the web page, submit new data, and verify that the E-paper display updates immediately.

We will reboot the badge to confirm the data is preserved.

We will toggle between the Classic and Fantastic screens to verify the layouts.

As you can see, we now have a clear idea of how the second screen should look and a plan to implement everything, but before spawning the agent work, I'd also like to have a design of the first screen of the badge, so using the chat, I ask to include it also in the plan.

After two iterations of the prompt, this is the result

The implementation

To implement the plan, we just need to press the Proceed button and wait

During the implementation, we can check what is happening through the UI

And if we notice something weird, we can stop the agent and type a new prompt to drive it again on the right path.

If you, like me, prefer to get confirmation before running commands or editing files, you must also approve these actions through the UI.

After 2 minutes, this is the result.

And if I connect my laptop to the badge Wi-Fi, I can configure my badge.

The refine

Now we have a badge working, but we want to improve it a bit: first, I want to change the screen by pressing the button on the back without connecting to the badge's Wi-Fi, and I want to set the Wi-Fi password via Environment Variables.

So I can prompt this

Can we also change the screen view using the button on the rear of the badge without connecting to the badge's Wi-Fi?

And after a minute, the result is ready, and my badge has been flashed.

And lastly, I can ask not to hard-code the password but use an environment variable,

use an environment variable for the wifi password

same here, after one minute and a couple of approvals, the result is again ready and in my badge.

To complete, I want to change the layout by using one of the buttons on the back of the badge. So again I ask Antigravity to do it for me.

Can we change the screen view also by using the button in the rear of the badge without connecting to the badge wifi?

and same here, after some minutes, sometimes the result is happier in the badge.

And the final result is this one

and this one

Conclusion

It's time to wrap up!

So my experience with Antigravity has been great! I love to use it to build new things, or as a teammate to learn new technology, or just to prototype a pet project like this one.

If you are in the agentic development, this tool can be a good one for you!

The experience is great, and if you want to have control over different projects or streams, it can be really helpful. The only pain point for me is the fact that if you want to check the code, you must install another tool, the Antigravity IDE, to check it.

In this era of agent development, what I find great is the ability to plan and review the changes before the agent implements them! This is the game-changer for me in this moment, and then a lot and a lot of code review!

Okay, that's it! I hope you enjoy this introduction to Antigravity and that you now want to test it for your project.

I hope you also like my new super badge 🚀

p.s. to check the code result, you can navigate to this repository

Google Cloud credits are provided for this project.

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 🥹

Pasting Code into AI? Here’s Why Your Legal Team is Sweating

Hayk Sargsyan — Sun, 28 Jun 2026 19:13:25 +0000

The integration of Large Language Models (LLMs) like OpenAI’s GPT-5, Anthropic’s Claude, and Google’s Gemini has fundamentally shifted the engineering landscape. For developers, these tools offer unprecedented velocity. However, blind reliance on public AI models introduces severe legal, financial, and architectural liabilities.

Understanding these legal pitfalls is no longer optional-it is a core engineering competency.

The Core Legal Risks of AI in Development

Using AI tools without guardrails exposes your organization to three primary legal vectors: Intellectual Property (IP) leakage, copyright infringement, and breach of contract.

Intellectual Property (IP) Leakage

When you paste proprietary code, business logic, or internal database schemas into a public LLM, you may forfeit trade secret protections. Many standard consumer-grade AI terms of service grant the provider the right to use your inputs to train future models. This means your proprietary algorithms could theoretically be generated for a competitor.

Copyright Infringement & "Copyleft" Contamination

LLMs are trained on massive datasets, including open-source repositories with varying licenses (e.g., GPL, AGPL, MIT).

An LLM might output a block of code that verbatim matches a copyleft-licensed project (like GPL). If that code is integrated into a commercial product, your organization could legally be forced to open-source its entire codebase.

Breach of Client Contracts and NDAs

Most enterprise software contracts include strict Non-Disclosure Agreements (NDAs) and data-handling clauses. Pasting client code into third-party AI models without explicit authorization directly violates these agreements, risking litigation and immediate contract termination.

Photo by Google DeepMind on Pexels

Why "Blind Copy-Pasting" is a High-Risk Practice

Copying and pasting entire business snippets, complex modules, or sensitive data dumps into tools like Claude or ChatGPT creates distinct liabilities.

Pasting entire files often inadvertently includes proprietary APIs, security tokens, internal domain names, and unique business logic.
Free or standard consumer tiers of Anthropic, OpenAI, and Google retain history by default. Even if you delete the chat, the data may remain on third-party servers for compliance auditing or system optimization.
When an AI refactors an entire proprietary snippet, it mixes your IP with its statistical training weights. If the output mimics protected code, proving original ownership in a patent or copyright dispute becomes incredibly difficult.

Photo by George Becker on Pexels

Paths to Solve the AI Risk Problem

Organizations must move away from ad-hoc AI usage and implement structural, engineered guardrails.

Enterprise API Tiers and Zero-Data Retention (ZDR)

Consumer interfaces (like the free web chats) are unsafe for corporate IP. Businesses must mandate the use of Enterprise platforms or direct API integrations. Major providers guarantee via enterprise contracts that inputs and outputs are never used for model training and are deleted within a fixed window (typically 30 days).

Self-Hosted and Local LLMs

For highly sensitive core IP, companies should completely cut off third-party network dependencies. Data never leaves the corporate firewall, entirely eliminating third-party data leakage risks. Implement automated safety checks in the CI/CD pipeline. Use tools like GitHub Copilot’s built-in duplication filters or standalone scanners (e.g., Snyk, SonarQube) to catch AI-generated code that matches public repositories before it merges into production.

Developers must treat LLMs as untrusted, highly competent junior interns. You guide them, verify their work, and never hand them the keys to the vault.

Never paste real business logic. Replace proprietary class names, variable names, and internal APIs with generic equivalents (e.g., convert calculateCorporateTaxBracket() to processNumbers()).
Use AI to generate architectural patterns, algorithmic logic, or regex patterns rather than copy-pasting entire production files.
Treat AI-generated code with higher skepticism than human code. Review it for security vulnerabilities, licensing compliance, and optimization.
Always verify whether your organization utilizes enterprise-grade agreements with providers like Anthropic or OpenAI before utilizing their web interfaces.

Photo by Christina & Peter on Pexels

Conclusion

AI is not going anywhere, and trying to ban its use in development is a losing battle. The key to staying competitive as a developer isn't avoiding LLMs - it's mastering the guardrails around them. By treating AI as an untrusted third-party service, sanitizing your inputs, and pushing for enterprise-grade infrastructure, you can leverage the full velocity of generative AI without compromising your company's intellectual property.

Web MCP: give some tools to your agent

Nicolas Frizzarin — Thu, 11 Jun 2026 15:50:17 +0000

Introduction

Nowadays, AI agents are becoming increasingly powerful at assisting users in their daily web activities. However, we cannot yet allow them to act completely autonomously—there is still a risk of them clicking on the wrong elements, for instance.

In theory, these agents are capable of performing impressive tasks, provided they are guided step-by-step through the interface. The challenge here is not a lack of intelligence in the model, nor a shortage of web APIs to expose data to the agent. The core issue lies in the fact that the agent must currently "guess" its way through applications that were designed exclusively for humans.

This is precisely the problem that WebMCP is here to solve.

It is important to note that these are not intended to replace standard APIs as access points for an application. Instead, they provide a structured way for a web application to "instruct" the AI agent used in the browser on how to navigate its interface. This results in:

Fewer misplaced clicks.
Less trial-and-error when interacting with the UI.

When utilized to their full potential, WebMCPs could redefine the user experience in the coming years.

What is WEBMCP?

As you may have guessed, WebMCP is a browser-side "guide/standard" for exposing tools to an AI agent directly from an active web page.

During Google I/O, this new feature was introduced as a way for web applications to describe how a page functions—and what actions can be performed—to various AI agents. As a result, agents can execute these described actions faster, more efficiently, and with greater precision.

Unsurprisingly, the syntax for creating these descriptions relies on JavaScript functions. These functions take natural language descriptions as parameters, along with structured schemas directly exposed from the web page.

This is exactly where the power of WebMCP lies.

Today, while we have Playwright (designed for end-to-end testing of web applications) and Playwright MCP (which extends this model to LLMs), WebMCP sits right at the intersection. It allows a page to effectively communicate to the agent: "Here are the actions you can perform on this page, how it works, and how you can trigger them."

Difference between WebMCP | MCP | Automation

At first glance, it may seem like all these approaches are similar and perform the same functions. In reality, each serves a well defined purpose, and they are highly complementary. To better understand the distinctions between them, let’s look at things from an AI integration perspective.

Backend MCP

At its core, an MCP server acts as a specialized bridge between AI models and external systems. It functions by providing a direct connection to APIs, effectively removing the friction typically involved in integrating new tools. By establishing a structured framework for data access, it ensures that the information exposed to the agent is organized, predictable, and secure. This architecture makes it an ideal solution for executing data-driven actions, allowing AI agents to perform complex, precise tasks with the reliability required for production grade applications.

Browser Automation

Traditional automation concepts rely on mimicking user behavior to interact with the web. They reproduce human-like interactions, such as clicking buttons or scrolling through pages, and can access any element within the UI by targeting it directly in the DOM. A key characteristic of these methods is that they do not require a predefined data structure, as they operate by observing the visual state of the application. However, because they are so tightly coupled to the underlying HTML structure, the main flow can be quite brittle; even minor UI changes often cause the automation to break, requiring constant maintenance.

WebMCP

By design, it shares the current application context directly with the AI, moving beyond what is merely visible on the screen. It structures and describes UI actions, providing the agent with a clear map of what is possible rather than forcing it to guess. This results in a highly reliable, context-aware interaction model that significantly reduces errors. Furthermore, the architecture is designed with human-in-the-loop capabilities at its core, ensuring that users maintain oversight and can intervene whenever necessary for sensitive or complex workflows.

When to use what: rules to apply.

To ensure your AI agent performs at its best, it is important to select the right integration strategy based on your specific requirements:

When an agent requires direct, structured access to data without interacting with a live web page, an MCP server is the ideal solution.
When you need to interact with a web interface exactly like a human would—whether for automated testing, task execution, or full application usage—browser automation is the right choice.
When a user is already actively navigating your web application and requires an agent that can interact with the entire page with high precision, WebMCP is the optimal path forward.

Different layers, different jobs.

How to use WEBMCP

It is worth noting that, for now, WebMCP is only available in Chrome starting from version 149 (with a strong drive to integrate this feature into the Baseline movement).

To enable this functionality in Chrome today, you need to use a feature flag:

Navigate to chrome://flags in your browser.
Search for and enable the enable-webmcp-testing flag.
Relaunch your browser to apply the changes.

There are two primary ways to utilize the WebMCP APIs to configure the tools exposed by your page:

The Declarative API: This method enables you to create WebMCP tools simply by adding annotations to your standard HTML forms, making the integration process more streamlined and semantic.
The Imperative API: This approach allows you to define custom tools such as form submission, navigation, or other specialized actions directly using standard JavaScript functions.

Defining tools using the Imperative API

document.modelContext.registerTool({
  name: 'search_product',
  description: 'search product based on a user search input'
  inputSchema: {
    type: "object",
    properties: {
      search: { type: 'string' }
    }
    required: ['search']
  }
  outputSchema: { type: 'string', description: 'List of products corresponding to the search'} 
  execute: async ({ search }) => {
    if(!search) return [];
    const products = await (await(fetch(`${url}?search=${search}`)).json());

    return JSON.stringify(products);
  }
})

Defining Form tool with the Declarative API

As previously mentioned, the Declarative API allows you to create form-based tools using annotations. More specifically, it leverages standard HTML attributes on your forms to define and manage how the tool is created.

<form toolname="supportRequestTool"
  tooldescription="Submit a request for support."
  action="/submit">

  <label for="firstName">First Name</label>
  <input type=text name=firstName>

  <label for="lastName">Last Name</label>
  <input type=text name=lastName>

  <select name="select" required 
    toolparamdescription="Determines what team this request is routed to.">
    <option value="Customer happiness team">Return my purchase.</option>
    <option value="Distribution team">Check where my package is.</option>
    <option value="Website support team">Get help on the website.</option>
  </select>

  <button type=submit>Submit</button>
</form>

The declaration process relies on specific attributes to define your tools:

toolname: Used to assign a specific name to your tool, reflecting its purpose.
tooldescription: Used to provide a clear explanation of the action the tool performs.

In practice, when the agent invokes the supportRequestTool, the browser brings the corresponding form to the foreground and fills out the fields while keeping the form visible to the user. Note that if you remove either the toolname or tooldescription attribute, the tool will be automatically unregistered and become inaccessible to the agent.

toolparamdescription: This optional attribute allows you to map a specific element to a detailed description. If this attribute is omitted, the agent will default to using the field's label as the description.

Security

As a reminder, LLMs process all text—including instructions and user data—as a single sequence of tokens. Consequently, once your application implements the WebMCP feature, it becomes susceptible to indirect prompt injection, where malicious instructions can be hidden within the content.

To mitigate these risks, here are several security recommendations for implementing WebMCP:

untrustedContentHint: Use this attribute to signal to the agent that the data originates from an external source, prompting it to exercise greater vigilance.
readOnlyHint: Apply this attribute to tools that should not modify data states, ensuring they require explicit agent confirmation before execution.
Character budgets: Define strict character limits for your tool names and descriptions to prevent prompt-injection attempts via long, malicious strings.
exposedTo: Use this property to restrict access to your tools, limiting them to specific, trusted domains.

It is important to remember that by default, tools are only exposed to the AI agent and are not accessible to other websites or iframes.

Conclusion

WebMCP represents a fundamental shift in how AI agents interact with the web. We are moving beyond the era of "computer-use stunts" where agents must guess intent from messy interfaces toward a model of direct, structured cooperation between sites and assistants.

By exposing structured actions and context, WebMCP allows the browser to share what it already knows: the current page, the user's session, and the precise moment help is needed. While backend integrations remain the best fit for bulk data processing, WebMCP is the optimal path for sites that want to provide a reliable, context-aware experience during live navigation.

We have only scratched the surface. In our next article, we will move from theory to practice by diving deep into implementation join us as we explore how to seamlessly integrate WebMCP into Angular applications.

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 🥹

DEV Community: Playful Programming

My AI Content Journey

Stepping up my Game

Enter LLMs

Trying LLMs for Myself

AI Assisted Writing

Two React Design Choices Developers Don’t Like—But Can’t Avoid

Another Attempt

Today

Functional languages are heavily imperative.

Two Dimensions, Not One

"Imperative Functional Programming"

"Lazy Imperative Programming"

The "Imperative Feel" of Concurrent Haskell

Note on "more declarative" and monoparadigmatic dogma

Conclusion (Imperative Functional Programming)

Declarative Side-Effects

RxJS

HTML

Nondeterministic Declarations

Math.random

Date.now(), crypto.randomUUID(), process.memoryUsage(), etc...

Declarative "Pure" Functions with Side-Effects

CPU

Memory

Conclusion (Declarative Side-Effects)

Conclusion

OpenRouter: One API Key to Rule Them All 🔑

Overview

What Is OpenRouter? 🤔

How It Works 🔧

Provider Routing and Fallbacks

The Free Tier

Pricing: What You Actually Pay 💰

OpenRouter + OpenCode 🔗

The Pros 👍

The Cons 👎

Who Should Use OpenRouter? 🎯

Final Thoughts 🌟

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

Overview

What Is OpenCode? 🤔

How It Works 🔧

The Pricing Reality 💰

The Anthropic Block: What Happened and Where It Stands 🚧

OpenCode vs Claude Code: The Real Differences 🥊

Terminal experience

Autonomy features

Output quality

The Pros 👍

The Cons 👎

Who Should Use OpenCode? 🎯

My Honest Take 💭

Domenico TenaceFollow

Introducing Argus: The Code Security Colleague Your Team Doesn't Have

Why security review needs a different shape

Structured tools, not a shell

Roles and an audit log

SOUL, context, and a memory built for security

What Argus does today (v0.2)

Where it's going

Come build in AI and security

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

Overview

What Is Gemini 3.6 Flash? 🤔

The Numbers: What Actually Changed 📊

Benchmarks

Speed

Pricing

Context Window and Knowledge Cutoff

Token Efficiency

How It Compares to the Competition 🥊

vs. Claude Sonnet 5

vs. GPT-5.6 Luna

vs. Gemini 3.5 Flash

What's Missing: The Elephant in the Room 🐘

The Pros 👍

The Cons 👎

Who Should Use Gemini 3.6 Flash? 🎯

My Take 💭

`Math.random`

`Date.now()`, `crypto.randomUUID()`, `process.memoryUsage()`, etc...

[MODIFY] `src/main.cpp` (or `NodeV0.ino`)

[MODIFY] `src/main.cpp` (or `NodeV0.ino`)