Forem: Zenika

Agent Development Kit 2.0, ADK-java 1,1 et Go 1.0 🚀

Jean-Phi Baconnais — Wed, 15 Apr 2026 07:30:32 +0000

La grosse nouvelle de la fin mars dans le monde du développement d’agent IA vient de Google avec les releases de la version 2.0 Alpha d’ADK Python et la 1.0 des versions java et Go !

✨ ADK

Agent Development Kit est un framework créé par Google permettant de facilement créer et déployer des agents IA. L’interface fournie permet de les débugger et de suivre l’orchestration des applications multi agents.

ADK a été conçu au départ pour les applications Python, c’est pour cela que la version 2.0 est uniquement présente pour ce langage.

👉 https://adk.dev/

🙌 Les apports de la v2

La version 2.0 arrive pour le moment en mode “Alpha”, il est donc (fortement) recommandé de ne pas utiliser cette version en production. Cette version est compatible avec les agents créés avec ADK 1.0 mais attention, il est impératif de ne pas partager les stockages entre vos projets ADK 1.0 et 2.0.

Cette release apporte 3 principales fonctionnalités :

les Graph-based workflows
la coordination de sous agents
les workflow dynamiques

Les Graph-based workflows permettent de chainer des actions ou requêtes Le root_agent est un agent qui exécute le workflow qui est défini par un nom, et un tableau de noeuds avec la possibilité de diriger des traitement en fonction d’un résultat précédent.

Cela permet par exemple de chaîner un ensemble de traitements ou bien de définir un ensemble d’actions exécutées en parallèle. Et quand je dis traitement, ce sont des appels à des LLM ou bien du code.

Image provenant de https://adk.dev/workflows/

La seconde nouveauté intervient au niveau des agents et de leur mode d'interaction. Des sous-agents peuvent désormais être créés et orchestrés par un agent “coordinateur”. Ces sous agents disposent de trois modes de fonctionnement :

Chat, le comportement actuel où le retour est fait à l’agent parent de manière manuelle
Task, permet une interaction avec l’utilisateur pour avoir des compléments d’informations
Simple échange (Single turn), l’agent travaille et renvoie son résultat. Peut-être exécuté en parallèle.

Les workflow dynamiques d’ADK sont la dernière nouveauté de cette release et permettent de s’affranchir de la structure rigide du graph-based vu précédemment. Avec l’annotation @node **ou le wrapper **FunctionNode, les workflow dynamiques permettent de supporter les exécutions parallèles, les boucles itératives et les compléments d’information de la part des utilisateurs (Human-in-the-loop) à l’aide de lignes de code.

👉 https://adk.dev/2.0/

🎉 Versions 1.0 des SDK Java et Go

Dans le même temps que la nouvelle version majeure d’ADK Python, les SDK Java et Go voient arriver leur première version majeure, le signe d’une maturité et stabilité validée.

La version 1.0 du SDK Go inclut l’arrivée native d’OpenTelemetry via le TraceProvider. De plus, un nouveau système de plugin va permettre d’inclure des fonctionnalités transverses (logs, sécurité, etc.). Un plugin intéressant, “Retry and Reflect”, permet d’intercepter les erreurs et de les renvoyer au modèle pour les corriger et les prendre en compte.

Cette version supporte aussi la définition d’agent directement via des fichiers YAML. \

👉 https://developers.googleblog.com/adk-go-10-arrives/

Du côté de Java, les releases 1.0 et 1.1 créées quelques jours plus tard incluent l’arrivée de nouveaux outils comme :

GoogleMapsTool pour récupérer des informations sur Google Maps.
UrlContextTool pour de récupérer les urls fournies. Cela vous permet par exemple de faire un résumé d’une page web.
ContainerCodeExecutor et VertexAiCodeExecutor pour exécuter du code locallement dans des containeurs Docker ou sur Vertex AI.
ComputerUseTool pour piloter un navigateur web.

App est la nouvelle classe de plus haut niveau pour créer une application agentique. Elle va pouvoir recevoir une liste de plugins qui sont appliqués à tous les sous-agents. Pratique pour harmoniser les logs par exemple avec LoggingPlugin ou bien donner des instructions globales à l’application avec le plugin GlobalInstructionPlugin.

Une stratégie de compression est également applicable sur la classe App et réduit notamment la taille de votre contexte et donc la taille de vos tokens.

L’outil ToolConfirmation permet de mettre en pause le traitement le temps d’avoir un complément d’information pour l’utilisateur·trice.

De nouveaux services permettent de sauvegarder le cycle de vie d’une conversation, en fonction de votre besoin, vos données en mémoire, dans VertexAI ou bien dans une collection Firestore (avec InMemorySessionService, VertexAiSessionService et FirestoreSessionService).

Pour conserver vos informations à travers plusieurs sessions, cela peut se faire localement ou bien dans Firestore (avec InMemoryMemoryService et FirestoreMemoryService).

👉 https://developers.googleblog.com/announcing-adk-for-java-100-building-the-future-of-ai-agents-in-java/

🚀 Démo

Je me suis prêté l’exercice de migrer ce projet me servant de démo avec les nouvelles fonctionnalités :

public static final App APP = App.builder()
    .name("trip-planner-app")
    .rootAgent(ROOT_AGENT)
    .plugins(
        new LoggingPlugin(),
        new GlobalInstructionPlugin(
            "Please add related emojis to your responses to make them more engaging."))
    .eventsCompactionConfig(EventsCompactionConfig.builder()
        .compactionInterval(10)
        .overlapSize(2)
        .build())
    .build();

Conclusion

L'effet "Wow 🤩, une version majeure arrive" est bien là, et je me rends compte que les évolutions apportées sont importantes et vont permettre d'accroître les possibilités de nos agents.

J’avais mis à jour quelques uns de mes projets utilisant la version d'ADK 1.1 sans avoir d'impact dans le code. En lisant les release notes, il y a bien des ajustements à faire dans la conception des agents pour notamment se poser des questions sur la gestion de la mémoire, la compression des informations et l’utilisation des plugins amène un gros plus pour optimiser les traitements et le code.

A suivre 🚀

🦊 GitLab CI: Automated Testing of Job Rules

Benoit COUETIL 💫 — Fri, 20 Mar 2026 16:52:47 +0000

Initial thoughts
1. The problem: CI rules complexity
2. The solution: automated job list validation
- gitlab-ci-local: the cornerstone
- How it works
3. Setting up the test infrastructure
- Directory structure
- Test case definition
- Reference CSV files
4. The validation script
5. The CI job
6. Workflow: adding or modifying jobs
7. Testing with rules:changes
- The problem with rules:changes and gitlab-ci-local
- The force-build label workaround
- Per-module test cases
8. Documentation that writes itself
Wrapping up
Further reading

Initial thoughts

As a CICD engineer, you've likely experienced this frustrating scenario: you modify a job's rules: to optimize pipeline execution, only to discover later that some jobs no longer trigger in specific situations. Or worse, jobs that should be mutually exclusive now run together, wasting resources and causing confusion.

GitLab CI's rules: syntax is powerful but complex. With workflow:rules, job-level rules:, extends:, !reference, and changes: all interacting, predicting which jobs will run for a given pipeline type becomes increasingly difficult as your CI configuration grows.

What if we could automatically test that the right jobs appear for each pipeline type? This article presents a practical solution: using gitlab-ci-local to validate job presence across all your pipeline variants, with reference files that serve as both tests and documentation.

1. The problem: CI rules complexity

In a mature GitLab CI setup, you typically have multiple pipeline types — especially in mono-repos with complex workflow:rules and module-based builds. Here, we focus on testing that your rules produce the expected jobs.

Type	Trigger	Example
A	Merge Request	Developer pushes to a feature branch with an open MR
B	Protected Branch	Push to `main`, `develop`, or release branches
C	Manual Pipeline	Triggered from GitLab UI with variables
D	Tag (auto)	Tag push triggering preprod deployment
E	Tag (manual)	Tag pipeline for production deployment
F	Scheduled	Nightly builds, cache warmup, full test suites

Each pipeline type should have a specific set of jobs. For example:

MR pipelines should run tests related to changed modules only
Protected branch pipelines should run all tests and prepare deployable artifacts
Scheduled pipelines might run expensive security scans or full regression tests

When you have 50+ jobs with complex rules:, maintaining this becomes a nightmare. Change one rule, break three jobs, sometimes in further pipeline types — the butterfly effect, CI edition. And if you've ever endured the slow feedback loop of CI YAML modifications, you know that discovering these regressions through push-and-pray is not sustainable.

2. The solution: automated job list validation

The solution is surprisingly simple and will be detailed step by step in this article:

Define test cases as variable files simulating each pipeline type
Use gitlab-ci-local --list-csv to get the jobs that would run
Compare with reference CSV files committed to the repository
Fail the CI if the job list differs from the expected reference

gitlab-ci-local: the cornerstone

gitlab-ci-local is an open-source tool that parses GitLab CI YAML locally. Among its many features, --list-csv outputs the jobs that would run given a set of variables, without actually executing anything.

This is perfect for our use case: we simulate pipeline conditions and check the resulting job list. Think of it as a flight simulator for your CI — all the turbulence, none of the crashes.

# Install globally
npm install -g gitlab-ci-local

# List jobs as CSV with custom variables
gitlab-ci-local --list-csv --variables-file ci/test/D-tag-preprod.variables.yml

How it works

Load the test case
Run gitlab-ci-local
Capture the CSV output listing all jobs that would run:

   name;stage;when;allowFailure;needs
   📦🌐api-build;📦 Package;on_success;false;[]
   🗄️✅back-unit-tests;✅ Test;on_success;false;[]
   ...

Compare with the reference file ci/test/D-tag-preprod.csv:
- ✅ Match → Test passes
- ❌ Diff → Show diff, fail test

When job name / stage / when condition / allowFailure flag / needed jobs change, the CI will let you know, and you will commit the change or fix the CI regression.

3. Setting up the test infrastructure

Directory structure

Create a ci/test/ directory to store test definitions and reference files:

ci/
└── test/
    [...]
    ├── D-tag-preprod.variables.yml      # Tag triggering preprod deployment
    ├── D-tag-preprod.csv                 # Expected jobs (reference)
    ├── F-scheduled.variables.yml         # Scheduled nightly pipeline
    └── F-scheduled.csv                   # Expected jobs (reference)

The naming convention {Type}-{Description}.variables.yml makes it easy to identify test scenarios.

Test case definition

Each .variables.yml file contains the GitLab CI predefined variables that simulate a specific pipeline context:

D-tag-preprod.variables.yml - Tag triggering preprod deployment:

CI_COMMIT_TAG: "v1.2.3"

F-scheduled.variables.yml - Scheduled nightly pipeline:

CI_PIPELINE_SOURCE: "schedule"
CI_COMMIT_BRANCH: "main"

The key is to set the variables that your workflow:rules and job rules: check to determine pipeline behavior.

Reference CSV files

The reference CSV files contain the expected job list. They're auto-generated on first run and then committed. Here's an example:

F-scheduled.csv:

name;description;stage;when;allowFailure;needs
🔎🖥️front-lint;"";🔎 Check;on_success;false;[]
✅🖥️front-unit-tests;"";🔎 Check;on_success;false;[]
📦🖥️front-build;"";📦 Package;on_success;false;[]
📦🌐api-build;"";📦 Package;on_success;false;[]
🗄️✅back-unit-tests;"";✅ Test;on_success;false;[]
🗄️🧩✅back-integration-tests;"";✅ Test;on_success;false;[]
🕵️💯security-scan;"";🕵 Quality;on_success;false;[]
🕵ᯤ🌐api-sonar;"";🕵 Quality;on_success;false;[📦🌐api-build]

This file serves as documentation and test oracle simultaneously:

Developers can quickly see which jobs run for scheduled pipelines
CI validates that reality matches expectations

4. The validation script

Here's a Bash script that automates the validation. It discovers test cases, runs gitlab-ci-local, and compares with reference files:

#!/bin/bash
# ci/test-ci-jobs-list.sh
#
# Tests CI non-regression by comparing gitlab-ci-local --list-csv
# output with committed reference files.
# Creates/updates reference files when differences are detected.
#
# Usage: ./ci/test-ci-jobs-list.sh [test-case-name]

set -e
FAILED=0
TOTAL=0

# Optional: run a single test case
if [ -n "$1" ]; then
    FILES="ci/test/$1.variables.yml"
else
    FILES="ci/test/*.variables.yml"
fi

for varsFile in $FILES; do
    [ -f "$varsFile" ] || continue

    baseName=$(basename "$varsFile" .variables.yml)
    referenceFile="ci/test/$baseName.csv"

    echo "🔍 Testing $baseName..."
    ((TOTAL++))

    # Generate current job list (filter out logs, keep only CSV)
    gitlab-ci-local --list-csv --variables-file "$varsFile" 2>/dev/null | \
        grep -E '^[^[]' | grep -v '^$' > "$referenceFile.tmp" || true

    # Ensure header is present
    if ! head -1 "$referenceFile.tmp" | grep -q "^name;"; then
        gitlab-ci-local --list-csv --variables-file "$varsFile" 2>&1 | \
            grep -E "^name;" > "$referenceFile.header"
        cat "$referenceFile.header" "$referenceFile.tmp" > "$referenceFile.new"
        mv "$referenceFile.new" "$referenceFile.tmp"
        rm -f "$referenceFile.header"
    fi

    mv "$referenceFile.tmp" "$referenceFile"

    # Check for git differences
    if ! git diff --exit-code -- "$referenceFile"; then
        echo "❌ FAILED: $baseName - jobs list has changed"
        ((FAILED++)) || true
    else
        echo "✅ PASSED: $baseName"
    fi
done

echo ""
echo "=========================================="
echo "Results: $((TOTAL - FAILED))/$TOTAL passed"
echo "=========================================="

if [ $FAILED -gt 0 ]; then
    echo "Review the diffs above and commit updated reference files."
    exit 1
fi

💡 Note: A PowerShell version is available on request for Windows-based runners.

5. The CI job

Add a job resembling this to your .gitlab-ci.yml:

✅🦊validate-ci-jobs-list:
  stage: ✅ Test
  resource_group: avoid-gcl-concurrency  # gitlab-ci-local may not be thread-safe
  tags: [your-runner-tag]
  image: node:20-alpine
  before_script:
    - npm install -g gitlab-ci-local
  script:
    - ./ci/test-ci-jobs-list.sh

Key points:

resource_group: Prevent concurrent executions that might conflict
rules:: you may want to run this on merge request when CI has changed, and on long-lived branches

6. Workflow: adding or modifying jobs

When you modify CI rules, follow this workflow:

Make your changes to .gitlab-ci.yml or included files
Run locally (optional but recommended):

   ./ci/test-ci-jobs-list.sh

Review the diffs - the script shows exactly what changed:

  🗄️✅back-unit-tests;"";✅ Test;on_success;false;[]
  🗄️🧩✅back-integration-tests;"";✅ Test;on_success;false;[]
− 🕵ᯤsonar;"";✅ Test;manual;true;[]
+ 🕵ᯤsonar;"";✅ Test;on_success;false;[]
  🕵ᯤ🌐api-sonar;"";🕵 Quality;on_success;false;[📦🌐api-build]

If intentional, commit the updated CSV files along with your CI changes
If unintentional, fix your rules before committing

This creates a self-documenting system: the git history of CSV files shows exactly when and why job behavior changed.

7. Testing with rules:changes

The examples above cover pipeline types where all jobs of a category run (protected branches, tags, scheduled). But on a real project with module-based rules: using changes:, MR pipelines only trigger jobs for modules whose files were modified. This is where things get spicy — and where regressions love to hide.

The problem with rules:changes and gitlab-ci-local

gitlab-ci-local does evaluate rules:changes — it has access to the git diff. But since our test job runs inside the MR pipeline, the diff contains whatever files happen to be modified in the current MR. A test for "backend-only pipeline" would suddenly include frontend jobs if someone touched a frontend file in the same branch. The results depend on the MR content, not on CI configuration — the opposite of a reliable test.

The solution is to guard changes: rules with $GITLAB_CI == "true":

.api-mr-rules:
  rules:
    - if: $CI_MERGE_REQUEST_ID && $GITLAB_CI == "true"
      changes:
        - src/Api/**/*
        - src/Commons/**/*

In real GitLab CI, $GITLAB_CI is always "true", so the rule works normally — changes: is evaluated against the MR diff. But gitlab-ci-local sets $GITLAB_CI to "false", which makes the if: condition fail before changes: is even evaluated. The entire rule is cleanly skipped, no ambiguity. Schrödinger's job: it exists in your YAML but never appears in the output — by design.

This is what makes test results deterministic: regardless of which files are modified in the current MR, the changes: rules are consistently neutralized, and only the label-based fallback (below) controls which jobs appear.

The force-build label workaround

The trick is to add a label-based bypass to every module's rules. In your actual CI, this serves double duty: developers use it when they need to force-rebuild a module (dependencies changed outside the changes: scope, cache issues, cosmic rays), and tests use it to simulate "this module has changes":

.api-mr-rules:
  rules:
    - if: $CI_MERGE_REQUEST_ID && $GITLAB_CI == "true"
      changes:
        - src/Api/**/*
        - src/Commons/**/*
    - if: $CI_MERGE_REQUEST_LABELS =~ /force-build-back/

In real CI, the first rule handles normal operation (job runs when matching files change). In gitlab-ci-local, the first rule is dead — only the label matters. Now the test variables file simply sets the right label:

A-MR-back.variables.yml — simulating backend changes:

CI_MERGE_REQUEST_ID: "12345"
CI_MERGE_REQUEST_LABELS: "force-build-back"

A-MR-front.variables.yml — simulating frontend changes:

CI_MERGE_REQUEST_ID: "12345"
CI_MERGE_REQUEST_LABELS: "force-build-front"

A-MR-no-change.variables.yml — the MR where only non-module files changed (docs, README, etc.):

CI_MERGE_REQUEST_ID: "12345"
CI_MERGE_REQUEST_LABELS: ""

This last one is particularly valuable: it verifies that common jobs (config generation, post-deploy checks) still run even when no module was touched. The CI equivalent of checking that the lights still work when nobody's home.

💡 We won't dive deeper into label-based pipeline control here — that topic deserves its own article. Stay tuned.

Per-module test cases

With this approach, the ci/test/ directory naturally reflects your module structure:

ci/test/
├── A-MR-no-change.variables.yml          # MR with no module changes
├── A-MR-no-change.csv
├── A-MR-back.variables.yml               # Backend module changes
├── A-MR-back.csv
├── A-MR-front.variables.yml              # Frontend module changes
├── A-MR-front.csv
├── A-MR-migrations.variables.yml         # Database migrations
├── A-MR-migrations.csv
├── A-MR-all-force-build-labels.variables.yml  # Everything activated
├── A-MR-all-force-build-labels.csv
├── B-protected-branch.csv                # Non-MR types (no changes: involved)
└── ...

The resulting CSV diffs tell a precise story. For instance, A-MR-back.csv might list 33 jobs while A-MR-front.csv lists only 18 — you can instantly verify that backend Sonar jobs don't sneak into frontend-only pipelines, and that shared deployment jobs appear in both.

On the project that inspired this approach (7 modules, 50+ jobs, 5 pipeline types), we ended up with 11 test cases covering every meaningful combination. The entire suite runs in under 10 seconds. That's less time than it takes to explain to a colleague why their MR pipeline is mysteriously empty.

8. Documentation that writes itself

The CSV reference files serve a dual purpose: automated validation and always up-to-date documentation.

If you use a doc-as-code tool like VitePress, Asciidoctor, or Docusaurus, you can render CSV files as HTML tables at build time — either natively or through a custom plugin. Most tools support CSV includes out of the box or with minimal effort, and any AI assistant can generate the glue code for your specific stack in seconds.

In your documentation markdown, it would look something like this:

## Pipeline Type D: Tag (preprod deployment)

```csv-table ci/test/D-tag-preprod.csv
```

## Pipeline Type F: Scheduled (nightly)

```csv-table ci/test/F-scheduled.csv
```

💡 Note: Adapt the csv-table syntax to your tool.

The same ci/test/*.csv files then serve two purposes:

CI Validation: gitlab-ci-local compares actual job lists against these reference files → pipeline passes or fails
Documentation build: your doc tool renders these CSV files as HTML tables → always accurate documentation

No more outdated documentation. No more "the wiki says X but CI does Y". The CSV files are the single source of truth — enforced by CI, displayed by docs, and immune to the corporate amnesia that plagues most wikis.

Wrapping up

This approach provides several benefits:

Benefit	Description
🛡️ Regression prevention	Catch unintended rule changes before they reach production
📖 Living documentation	CSV files document expected behavior for each pipeline type
🔍 Clear diffs	See exactly which jobs were added, removed, or modified
⚡ Fast feedback	Tests run in seconds, not minutes
🎯 Granular testing	Test specific pipeline variants independently

The key insight is treating your CI configuration as code that deserves its own tests. Just as you wouldn't ship application code without tests, you shouldn't ship CI changes without validating their effects.

This technique has saved countless hours of debugging "why doesn't this job run anymore?" issues. The upfront investment in setting up the test infrastructure pays off quickly as your CI configuration grows in complexity. Combined with other CI best practices to avoid widespread anti-patterns, it builds a solid foundation for maintainable pipelines.

⚗️ A local Agent with ADK and Docker Model Runner

Jean-Phi Baconnais — Fri, 20 Mar 2026 15:55:05 +0000

A French version is available on my website.

⛅ Using AI in the Cloud

I’m the first to admit it: I use AI models provided in the Cloud. As a user, it suits me perfectly. The models are powerful and give me good answers.

But is the scope of these models really adapted to my needs? They do the job, that’s a fact, but aren't they a bit too general-purpose for my specific use cases?

Running models locally is not new. It was actually one of the very first requirements that emerged: trying to deploy a model on a local machine.

The apparition of Small Language Models (SLM) has offered a concrete answer to this problem, making it possible to adapt models to specific use cases and simplify their deployment.

There are now various alternatives for deploying these models. I have first heard about Ollama, as it was, if I’m right, one of the first tools to simplify this process.

If you’re interested in Small Language Models, I highly recommend Philippe Charrière's articles available on his blog.

I took some time to make my own experience, and that’s what I’m sharing with you in this article.

🧩 My Context

For this experiment, I wanted to use my usual agent framework for its simplicity: Google’s Agent Development Kit (ADK): https://google.github.io/adk-docs/.

A Java agent can be quickly created with ADK and these lines:

public static BaseAgent initAgent() {
    return LlmAgent.builder().name("trip-planner-agent")
    .description("A simple trip helper with ADK")
    .model(System.getProperty("gemini.model"))
    .instruction("""
        You are A simple Trip Planner Agent. Your goal is to give me information about one destination.
    """).build();
}

🐳 Docker Model Runner

I had already tested Ollama to run models on my machine. But for this experiment, I wanted to try Docker's solution: Docker Model Runner (DMR). This project provides new Docker commands to pull, run, and list models available on your machine.

    docker model pull
    docker model list
    docker model run

A quick configuration is required in the Docker Desktop settings to enable this service:

After that, DMR allows you to easily fetch a model and run it on your machine. For example, to use the “gemma3” model, simply run the following command. The model will be downloaded if you don’t already have it:

    docker model run gemma3

Once started, the agent can respond to you as shown in this example:

🧩 The link between ADK / DMR

The langchain4j library will link the model specified in ADK and the model provided by DMR. This dependency must to be added:

    <dependency>
        <groupId>dev.langchain4j</groupId>
        <artifactId>langchain4j-open-ai</artifactId>
        <version>1.1.0</version>
    </dependency>

The code will be a little bit modified. Instead of calling the model with a string, we use an instance of the LangChain4j class, defined with an OpenAiChatModel instance.

OpenAiChatModel chatModel = OpenAiChatModel.builder()
    .baseUrl(modelUrl)
    .apiKey("not-needed-for-local")
    .modelName(modelName)
    .maxRetries(1)
    .timeout(Duration.ofMinutes(2))
    .build();

var adkModel = new LangChain4j(chatModel);

return LlmAgent.builder()
    .name("Travel Agent")
    .description("Travel expert using a local model")
    .model(adkModel)
    .build();

🙌 A Locally Available Agent

The agent is now plugged into a local model. The application can be started with the Maven command mvn compile exec:java -Dexec.mainClass=adk.agent.TravelAgent after starting your model with Docker Model Runner. For development, this is perfect.

Once the application was functional, I decided to set up a docker-compose.yml file to start the model and the application with a single command:

    docker compose up -d --build && docker attach adk-app

💡To avoid repackaging the application every time, a cache is implemented in the Dockerfile.

TADA! 🥳

🤔 A "Local" Future?

This project was just an experimentation, but it gives some other questions. My primary use of AI is for development. Wouldn't it be better to dedicate a locally deployed agent to this activity?

When I create agents planned to be deployed on the Cloud, perhaps a local model would be more than sufficient during the development phase? These questions have been answered by others who have tested this, but can it be implemented (and quickly) in a corporate context?

We can, of course, go even further by building our own custom model for our specific context, but that’s a topic for another day! 😁

📝 Dev.to Writers Community: One Command to Maintain Them All

Benoit COUETIL 💫 — Sat, 28 Feb 2026 17:19:00 +0000

The Community
What I Built
Demo
- Content enrichment
- Bulk operations
- Environment
Code
How I Built It
Further reading

This is a submission for the DEV Weekend Challenge: Community

The Community

The people writing technical articles right here on dev.to — the ones who keep a folder full of markdown files and occasionally wonder why they didn't just use the browser editor. Occasionally.

What I Built

A fork of devto-cli — a Node.js CLI that turns local markdown files into dev.to articles. The original tool by Yohan Lasorsa handles article creation, push to dev.to via the API, stats, GitHub-hosted images with automatic URL rewriting, and a GitHub Action for automated publishing.

I just kept running into small things it didn't cover, so I forked it and added a bunch of features. Here's what came out.

Demo

Content enrichment

Diagrams as code with Kroki

Write a diagram in your markdown:

<!-- diagram-name: shell-runner-well-sized-before-optimization -->
'''mermaid
%%{init: {'theme':'forest'}}%%
gantt
    title Shell Executor - Well-Sized Server (Before Extreme Optimization)
    dateFormat X
    axisFormat %s
    section Waiting
    Sufficient capacity                    :active, wait, 0, 1s
    section Server
    Resource allocation                    :active, prep, after wait, 1s
    section OS
    Native system (no container)           :active, env, after prep, 1s
    section Source Code
    Git fetch (local reuse)                :active, git, after env, 2s
    section Cache
    Restore (local filesystem)             :active, cache, after git, 2s
    section Artifacts
    Download artifacts                     :done, art, after cache, 3s
    section Execution
    Scripts                                :done, exec, after art, 10s
    section Termination
    Upload cache (local)                   :active, save1, after exec, 1s
    Upload artifacts (GitLab network)      :done, save2, after save1, 4s
'''

Run:

dev diaggen my-article.md

The CLI sends the block to Kroki, gets back an image, and saves it locally. After committing the image to your assets repo, dev push replaces the code block with an image link pointing to GitHub — dev.to never sees the mermaid source. But your local source is preserved, letting you fix the diagram when needed. Supports mermaid, PlantUML, BlockDiag, and many others.

See 13 diagrams generated this way in GitLab Runners: Which Topology for Fastest Job Execution?

Automatic table of contents

Add two markers anywhere in your article:

<!-- TOC start -->
<!-- TOC end -->

Then:

dev push --update-toc my-article.md

The CLI scans headings and generates anchored links between the markers. The current article uses it.

ANSI-styled terminal output

Choosing colors in a displayed log is a must. The CLI converts a simple pseudo-ANSI syntax into styled HTML blocks.

In your markdown, use {{TAG}} to start a color. The {{/}} closing tag is optional — without it, the color continues until the next tag or end of block. This means multiline content stays colored naturally:

'''ansi
{{RED}}The quick brown fox{{BOLD_RED}} jumps over the lazy dog
{{GREEN}}The quick brown fox{{BOLD_GREEN}} jumps over the lazy dog
{{YELLOW}}The quick brown fox{{BOLD_YELLOW}} jumps over the lazy dog
{{ORANGE}}The quick brown fox{{BOLD_ORANGE}} jumps over the lazy dog
{{BLUE}}The quick brown fox
{{BOLD_BLUE}}jumps over the lazy dog
{{MAGENTA}}The quick brown fox{{BOLD_MAGENTA}} jumps over the lazy dog
{{CYAN}}The quick brown fox{{BOLD_CYAN}} jumps over the lazy dog
{{WHITE}}The quick brown fox{{BOLD_WHITE}} jumps over the lazy dog
{{GRAY}}The quick brown fox{{BOLD_GRAY}} jumps over the lazy dog
{{BG_RED}}The quick brown fox{{/}} jumps over the lazy dog
{{BG_GREEN}}The quick brown fox{{BG_YELLOW}} jumps over the lazy dog
{{BG_ORANGE}}The quick brown fox
jumps over the lazy dog
{{BG_BLUE}}The quick brown fox{{BG_MAGENTA}} jumps over the lazy dog
{{BG_CYAN}}The quick brown fox{{BG_WHITE}} jumps over the lazy dog
{{BG_GRAY}}The quick brown fox{{/}} jumps over the lazy dog
'''

After dev push, this renders as a properly colored terminal block on dev.to — 9 base colors × 3 variants (plain, bold, background). No closing tag needed: colors flow until the next tag, even across lines. All colors are overridable via .env variables (ANSI_RED=#ff6161, etc.).

The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox
jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox
jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog
The quick brown fox jumps over the lazy dog

Bulk operations

Run one command, affect all your articles at once.

A shared footer file (e.g. "Further reading" links) kept in sync across all articles. Update the footer file once, then push all — the CLI finds the # Further reading marker in each article and replaces everything below it with the shared footer content:

dev push --update-toc "*.md"

Smart file renaming

When an article title changes, the filename should follow:

dev rename "*.md"

🦊 GitLab CI: A Battle-Tested Mono-Repo CI/CD Architecture
  GITLAB_mono-repo-architecture.md → GITLAB_ci-battle-tested-mono-repo-ci-cd-architecture.md

🔍 Every Developer Should Review Code — Not Just Seniors
  MISC_every-developer-should-review-code.md → MISC_every-developer-review-code-seniors.md

Strips emoji, filters 80+ English stop words (a, the, and, how…), keeps the first 5 significant words, preserves the date/category prefix.

Article badges generation

Generate visual badges for a GitHub profile README:

dev badges --jpg "*.md"

Each badge overlays the article's cover image with its title, publication date, view count, and reading time. Articles are auto-grouped by category (extracted from filename prefix) and sorted by date within each group.

The most viewed articles get golden stars ⭐ — popularity is measured relative to the 2nd most viewed article (to avoid one viral post skewing everything). ≥90% of that reference = 3 stars, ≥50% = 2, ≥25% = 1. Stars and stats refresh on every run.

Produces a _ARTICLES.md file with badge images linking to each article. Here's my GitLab section:

Embed the file in a pinned article and all your articles become browsable from one place. Badges stay up to date with every dev badges run.

Broken link checking

Before publishing:

dev checklinks my-article.md

Catches dead URLs before readers do. Smart enough to treat HTTP 403/429 as "probably fine" (bot blocking, not a dead link). Also validates cover image and canonical URL from front matter. Works on all articles at once with dev checklinks "*.md".

Environment

Configure once, forget about it.

Organization publishing

One line in .env:

DEVTO_ORG=zenika

The CLI adds organization: zenika to the front matter and resolves the org ID automatically on push.

Proxy support for corporate environments

export HTTPS_PROXY=http://proxy.company.com:8080
dev push

All API calls, Kroki requests, and link checks go through the proxy. Self-signed certificates handled too.

Code

github.com/bcouetil/devto-cli

How I Built It

This is a TypeScript / Node.js CLI, forked from sinedied/devto-cli. Each feature was added incrementally — proxy support first, then Kroki diagrams, TOC generation, organization publishing, footer management, link checking, file renaming, ANSI blocks, and finally badge generation.

This fork started as a one-line proxy fix and kept growing from there. Every feature was added because I needed it, not because it looked good on a feature list.

Illustrations generated locally by Draw Things using Flux.1 [Schnell] model

🦊 GitLab CI: Achieving 3-Second Jobs on Million-Line Codebases

Benoit COUETIL 💫 — Thu, 19 Feb 2026 21:17:00 +0000

Initial thoughts
Prerequisites: The right foundation
Classic optimizations first
Extreme optimizations: going beyond
Breaking down the 3-second job
- Job execution on a well-sized shell runner
- Phase 1: Waiting (~0s)
- Phase 2: Server (~0s)
- Phase 3: OS / Shell (~1s)
- Phase 4: Git Clone/Fetch (~1s)
- Phase 5: Cache (~0s)
- Phase 6: Artifacts (none)
- Phase 7: Script (~1s)
- Phase 8: Termination (~0s)
Final timing breakdown
Real project results
Wrapping up
Further reading

Initial thoughts

Is it really possible to run GitLab CI jobs in just 3 seconds on a codebase with several million lines of code? The answer is yes, and this article will show you how.

After comparing different runner topologies in GitLab Runners: Which Topology for Fastest Job Execution?, we found that Shell and Docker executors offer the best potential for fast job execution. Now it's time to push those runners to their absolute limits with extreme optimizations.

This isn't about theoretical performance—these are real, production results achieved on actual projects. The 3-second example is our lightest job (a JIRA/MR synchronization check), and it consistently runs in ~3-5 seconds on our 1,500,000+ line mono-repo actively maintained by 15 developers. We have jobs at various fixed speeds: one at ~3-5s, some at a few seconds, others at ~2min for resource-heavy builds, and end-to-end tests at ~15min. The optimizations in this article apply to all jobs.

Time to hunt down every millisecond of overhead — no mercy. Because, as French president Macron said, "Pipeline sometimes is too slow".

Prerequisites: The right foundation

Before diving into extreme optimizations, we need the right infrastructure foundation. Based on our topology comparison, this means:

Infrastructure choice:

✅ Shell executor (fastest) or Docker executor (fast with isolation)
✅ Single well-provisioned server (not autoscaling)
✅ Local SSD storage (NVMe preferred)
✅ Sufficient CPU/RAM for concurrent jobs
✅ Fast network connection to GitLab instance

Why this matters: Every other topology adds fundamental latencies (VM provisioning, pod scheduling, remote cache, shared resources) that cannot be eliminated through configuration. Starting with the wrong topology means you've already lost.

Classic optimizations first

Before going extreme, apply standard GitLab CI optimizations from GitLab CI Optimization: 15+ Tips for Faster Pipelines.

But these optimizations alone won't get you to 3 seconds. They'll improve your average pipeline duration. To reach sub-10-second jobs, we need to dig deeper into GitLab runners arcanes.

Extreme optimizations: going beyond

Now we enter extreme optimization territory. These techniques are specific to Shell/Docker runners and exploit their local filesystem advantages.

Here's what we'll optimize to near-zero overhead:

Waiting time → Proper server sizing
Server provisioning → Already exists (no VM/pod creation)
OS/Container startup → Native shell (1s) or cached images
Git operations → Shallow fetches, reused local clones
Cache → Local filesystem, preserved directories
Artifacts → None in our fastest jobs
Script execution → Minimal in our fastest jobs
Termination → No cache/artifact uploads in our fastest jobs

Let's break down each phase and see how to optimize it.

Breaking down the 3-second job

Job execution on a well-sized shell runner

First, let's visualize what a well-optimized shell runner job timeline looks like before extreme optimizations:

Total: already fast on fastest jobs scripts. Now let's optimize each phase to the extreme.

Phase 1: Waiting (~0s)

The problem: Jobs queue when runners are saturated. Your developers are staring at a spinner. Somewhere, a PM is asking "is the pipeline stuck again?".

The solution : proper server sizing

Size the VM for peak concurrent load (not average)
CPU: 16 cores for a 15 developers team on a mono-repo. Not the smallest, but cheap comparing to salaries
Disk I/O: NVMe SSD essential for concurrent git/cache operations
Concurrency tuned (~16 concurrent jobs for 16 CPU)

⏱️ Result: ~0s waiting (when properly sized). No more "grab a coffee" excuses — the job finishes before you stand up.

Phase 2: Server (~0s)

Server already exists — shocking, right?

Shell runner: no provisioning at all
Docker runner: no VM creation, just container scheduling
Resources immediately available
No cloud API calls needed

This is a fundamental advantage of single-server topologies over autoscaling. While Kubernetes is busy scheduling pods, our job is already done.

Phase 3: OS / Shell (~1s)

Think of it this way: Shell executor is a barefoot sprinter, Docker is a sprinter with fancy shoes. Both are fast, but one has less to put on.

For Shell executor (fastest, ~1s):

No Docker image needed
No container startup
Direct shell execution
Native OS environment

For Docker executor (fast with isolation ~1-4s):

Pre-pull images to server
Use lightweight base images (alpine)
Layer caching on local Docker
Keep containers warm when possible

Phase 4: Git Clone/Fetch (~1s)

This is where the magic happens. Or rather, where the magic doesn't happen — because the best git operation is the one you barely do.

Strategy and depth

Obviously, to achieve 3s on a large codebase, a close version of the code must already be present locally. The default algorithm is a fetch (which is perfect), meaning that the runner will just reconstruct a few commits in a build directory that already has been used by a previous job, preferably with nearly same code but different commits.

The default is 20 commits reconstructed. In fact, you only need one most of the time (when not doing git stuff).

variables:
  GIT_DEPTH: 1 # default to 20

Fetch flags

The default fetch flags are --force --prune --tags. force and prune are very useful to handle git fetch problems and keep local repo size reasonable. You can experiment with these on short-lived runners, at your own risks. We tried this but had to step back for consistency, even on our daily runners.

But fetching tags is almost never a good idea, at least by default. Even though we heavily rely on tag pipelines, we still don't need to fetch any tag. Except for a job that uses older tags to extract versions; for it we manually fetch tags.

Optionally, we can define the refmap to fetch, avoiding unnecessary fetching.

Here are our flags for merge requests :

  GIT_FETCH_EXTRA_FLAGS: --force --prune --no-tags
    --refmap "+refs/merge-requests/${CI_MERGE_REQUEST_IID}/head:refs/remotes/origin/merge-requests/${CI_MERGE_REQUEST_IID}/head"

Note: add --verbose to show what's happening, and be sure to know what takes time and what not. We still have this flag because there only a few lines added when fetch is optimised, and it does not slow down the job.

Situational: tailored clone path

When long-lived branches have a fair amount of difference (the longer the branch and/or the higher the developer count, the more differences), fetch takes time. On our projects we have thousands commits of differences between long-lived branches at worse time of our cycle!

To keep a sub-second fetch time, we configure clone in paths depending on the target branch. And yes, MR pipelines secret mode is required for this.

So our clone path depend on the pipeline type :

  # for MRs. Concurrent ID is after the branch name, to ease old branches cleaning
  GIT_CLONE_PATH: $CI_BUILDS_DIR/$CI_PROJECT_NAME/$CI_MERGE_REQUEST_TARGET_BRANCH_NAME/$CI_CONCURRENT_ID
  # for long-lived branches (same path, different variable)
  GIT_CLONE_PATH: $CI_BUILDS_DIR/$CI_PROJECT_NAME/$CI_COMMIT_REF_NAME/$CI_CONCURRENT_ID
  # for tags (rare, no need for distinction)
  GIT_CLONE_PATH: $CI_BUILDS_DIR/$CI_PROJECT_NAME/tags/$CI_CONCURRENT_ID

This can only be used when custom_build_dir is enabled in the runner’s configuration.

Phase 5: Cache (~0s)

Downloading and extracting remote cache takes time. Even with local GitLab cache, you still have to zip/unzip the folder elsewhere. That's like packing and unpacking your suitcase every time you go to the kitchen.

Shared package managers folders

Shared package managers folders on the server will reuse downloaded assets without overhead. When local cache is warm, there are no download/unzip and no zip/upload.

variables:
  NPM_CONFIG_CACHE: /cache/gitlab-runner/.npm
  NUGET_PACKAGES: $CI_BUILDS_DIR/NuGetPackages

Note: For safety, it is still better to have different folders for dev/staging/prod.

Optional : do not clean unpacked assets

Before executing the scripts, GitLab deletes any past produced files. We can save precious seconds, even minutes, by not deleting them, and, most importantly, reuse them. This is especially useful for node_modules :

variables:
  GIT_CLEAN_FLAGS: "-ffdx --exclude=**/node_modules/"

This works best for custom GIT_CLONE_PATH discussed earlier. This could lead to strange behavior in theory : we took the risk for feature branches, and never encountered problems for our 15 developers mono-repo.

Note: For safety, it is still better to clean for staging/prod environment.

Phase 6: Artifacts (none)

The fastest jobs in pipelines do not handle artifacts. We consider none here. Zero. Nada. The fastest artifact is the one that doesn't exist.

Phase 7: Script (~1s)

For the 3-second target, we're specifically measuring fast jobs like linting, formatting checks. Any standard job will naturally take longer. But hey, even our "slow" jobs appreciate having 2 seconds less overhead — that's 2 seconds of their life they'll never get back.

Phase 8: Termination (~0s)

At the end, the job handles artifacts and the cache. The fastest jobs produce no artifact and use local custom cache or none. The job exits so fast, it doesn't even say goodbye.

Final timing breakdown

Here's what the fully optimized timeline looks like:

⚡ Total: ~3 seconds per job (with sub-1s script)

The key insight: We've reduced overhead to ~2s, leaving all remaining time for actual work. Your CI is now faster than your npm start.

Real project results

Again, these aren't theoretical numbers: we experience this extreme speed on a daily basis.

Shell runner - 3 seconds

Docker runner - 13 seconds

Takeaway: If you need isolation, Docker is still very fast with these optimizations. But Shell executor is unbeatable for raw speed.

Example development pipeline - 1min45 for 20 jobs

Most jobs run in parallel on each stage. The pipeline spends minimal time on overhead and maximum time on actual work.

Wrapping up

Achieving 3-second jobs on a multi-million line codebase is possible with the right combination.

These techniques show that single-server Shell/Docker runners, when properly optimized, vastly outperform autoscaling solutions for typical development workflows. The local filesystem advantages are impossible to beat.

Not every job can be 3 seconds—builds and full test suites will always take longer. But for fast-feedback jobs, sub-10-second execution is absolutely achievable and dramatically improves developer experience. Your developers will wonder if the pipeline is broken... because it's too fast.

Illustrations generated locally by Draw Things using Flux.1 [Schnell] model

How GiLab Duo Agent Platform & Antigravity can collaborate to improve the quality of our applications

Jean-Phi Baconnais — Fri, 13 Feb 2026 13:37:56 +0000

🔎 Short introduction

GitLab Duo Agent Platform is the new AI solution available in the DevOps platform. Integrated in the Premium and Ultimate, this offers a lot of very interesting features powered by AI I tried to resume in this cheatsheet (available on dev.to):

Antigravity is a new agent developer platform created by Google which notably changes the developer mindset by turning them into an agent manager or orchestrator.

🤔 Why use these 2 AI tools?

Antigravity is a great development tool, mainly focused on the development of features or to resolve issues on projects. **GitLab Duo Agent Platform, **available for Premium and Ultimate GitLab, is present throughout the DevOps platform, helping us from project conception (epics, issues) to the CICD.

I have the chance to have access to GitLab Duo Agent Platform for personal or demo projects. For my other projects, I use Antigravity and wait, why not use Antigravity on my projects that already have GitLab Duo Agent Platform access?

🎯 This is the objective of this blog post. Show you the result of using these two tools and explain how much this can be useful to improve my projects.

For this blog post, I created a new application, very classic :

a React front end component,
a Springboot backend with a Gemini integration to generate images
a Docker compose configuration

🤗 How to combine these two Agentic Developer Platform?

GitLab Duo Agent Platform can help you generate a description of epics and issues from the title or notes you can initiate.

The first conclusion of this usage of AI (even outside the combination of GitLab Duo and Antigravity) is that it encourages me to write a maximum of information on my issues. Even on projects where I don’t have access to GitLab Duo, I maintain this behavior and try to give now more importance to the description of issues.

The next step is to initiate a Merge Request (MR) directly from the issue using the button “Generate MR with Duo”.

And the result is very interesting. GitLab launches an agent session (visible in the menu “Automate”) and after a few minutes, a MR is created and one commit appears.

Creating an issue and letting GitLab Duo work on it to initialize one MR is a great game changer. Of course, as with any MR, human reviews are still required, but a high quality is here.

I forgot to mention this point, Antigravity is based on a fork of Visual Studio Code, where you can install the GitLab Workflow extension including GitLab Duo.

🤖 AI Review of AI generated code

💡Before reviewing this MR, can I imagine delegate this task to Antigravity?

Of course. Let’s see the result. After opening the Git branch in Antigravity, I ask it to review this MR. On the previous Merge Request, Antigravity found and fixed several issues like a CORS problem, and reviewed the Java class architecture. After examining the fixes, I agree with that and I commit and push.

*💡 Next step? Does GitLab Duo agree with the changes? *

In the MR, we can ping GitLab Duo. “Hey @GitLabDuo, what do you think about the last commit”?

After a few minutes, GitLab Duo provided its review. All the items detected during the initial review are listed with their status updated with the new commits.

In this example, a demo application to generate LEGO images, the implementation of Gemini is missing but for the first step of this application, this is acceptable. I can merge it.

👉 This approach is interesting. Everyone knows that AI needs human review. While this workflow might not immediately include your human review, for complex or big features, this AI review step can fix issues the first model didn’t see. On my MR, I saw interesting discussions and conflicting opinions.

🚀 Go further

After playing with both AI tools, I noticed one action which is repeated: the manual request for GitLab Duo to make a review. To fix it, I connected the GitLab MCP, which allows me to facilitate actions on issues, merge requests, etc.

With this configuration, I can ask Antigravity to ping GitLab Duo for a new review. I can stay on my IDE and keep focused on another task.

This can be further improved by utilizing Skills. This new standard maintained by Anthropic introduces a way to specify instructions, scripts and resources that AI agents can integrate and use to perform tasks.

📖 https://github.com/agentskills/agentskills

Antigravity integrated this standard (cf doc https://antigravity.google/docs/skills) and skills have to be in the .agent/skills directory.

To reduce manual action, I create a request_review skill designed to automatically add a note into the Merge Request asking GitLab Duo to review it.

In this file, we can also add a request to GitLab Duo after each commit. As you can see in the next screenshot, I commit the skill file and we see a glab (the GitLab CLI) command being executed to add a note in the MR.

💡 A future with some AI tools?

I have used the pair GitLab Duo & Antigravity across different contexts and issues. From creating new projects to migrating Java versions or adding a feature, using these two tools was interesting. The “discussion” between them raised many questions and reflections.

For this blog post, my Lego application is done and works locally in two issues. Of course I don’t let AI create all the code, but the majority was done by GitLab Duo and Antigravity.

I am aware that this usage is primarily for demo projects or short PoCs, but I am sure that the power of these two tools can be complementary and significantly improve the quality of our application.

As I explained in this blog post and at the beginning of this one, we, developers, must change our workflow by migrating from synchronous work to asynchronously, running tasks in parallel and focusing on agent orchestration. However, we must also be careful to respect the limitations of our cognitive capacity.

🦊 GitLab Runners: Which Topology for Fastest Job Execution?

Benoit COUETIL 💫 — Fri, 30 Jan 2026 17:28:43 +0000

Initial thoughts
Understanding job execution phases
Comparing runner types
- GitLab Shared Runners (SaaS)
- Kubernetes Executor (Fixed Cluster)
- Kubernetes Executor (Autoscaling Cluster)
- Docker Executor (Single Server)
- Shell Executor (Single Server)
- Docker Autoscaler (Fleeting)
Job speed comparison summary
Recommendation: Shell or Docker executors for fastest jobs
- Why single-server executors win on speed
- Shell vs Docker trade-offs
- The performance/price/maintenance sweet spot
Wrapping up
Further reading

With multiple executor types available—from shared SaaS runners to Kubernetes clusters to single-server setups—understanding how each impacts job speed helps you make informed architectural decisions. Spoiler: the simplest topologies often deliver the fastest jobs.

Initial thoughts

Choosing the right GitLab Runner topology is crucial for fast job execution. With multiple executor types available—from shared SaaS runners to self-hosted solutions—understanding how each impacts job speed helps you make informed architectural decisions.

This article focuses on a single question: which runner topology executes jobs the fastest? We analyze different topologies through the lens of job execution phases, comparing the time overhead each infrastructure type adds before, during, and after script execution. Whether you're starting fresh or optimizing an existing setup, understanding these trade-offs is essential to minimize job duration.

📖 Note: This article focuses on intrinsic speed characteristics. Some disadvantages mentioned here can be mitigated through configuration tricks (idle pools, spot instances, over-provisioning, etc.). For detailed pros/cons and mitigation strategies, see GitLab Runners Topologies: Pros and Cons.

Understanding job execution phases

From runner selection to final cleanup, every job goes through multiple technical phases. Understanding these phases is crucial to optimizing pipeline performance.

Here's a detailed breakdown of all the technical steps involved in running a single GitLab CI job:

Each phase adds latency to job execution. Your script might take 10 seconds, but the overhead can easily triple that — death by a thousand papercuts. Different runner topologies handle these phases very differently.

Comparing runner types

Let's analyze the performance characteristics of each GitLab Runner infrastructure type, examining how they handle the execution phases differently.

📊 Reading the charts: Throughout this article, the durations shown in Gantt diagrams are relative and illustrative—actual times vary based on project size, network conditions, and infrastructure specs. What matters is the color coding:

🟢 Green: Faster than average across runner types

⚪ Grey: Average performance

🔴 Red: Slower than average across runner types

GitLab Shared Runners (SaaS)

GitLab.com provides shared runners available to all users without any setup. While convenient, these runners compete for resources with thousands of other projects, making them the slowest option for job execution.

Topology: Shared SaaS infrastructure - all users share the same pool of runners and cache storage.

Performance characteristics:

Speed advantages:

✅ No wait for infrastructure provisioning

Speed disadvantages:

❌ Slowest overall performance (all resources shared)
❌ Every job pulls images from scratch
❌ Shared network bandwidth slows git operations
❌ Unpredictable performance due to multi-tenancy
❌ Slow artifact uploads/downloads

Best for: When speed is not a priority and zero maintenance is essential.

Kubernetes Executor (Fixed Cluster)

A fixed-size Kubernetes cluster provides consistent resources for CI jobs. While more complex to set up than shared runners, it offers better performance through image caching and dedicated resources—though still limited by network-based cache and pod startup overhead.

Topology: Fixed-size cluster with shared remote cache (S3/MinIO).

Performance characteristics:

Speed advantages:

✅ Fast when warm (images cached on nodes)
✅ Pod creation relatively quick on existing nodes
✅ Consistent performance with dedicated resources

Speed disadvantages:

❌ Jobs queue when capacity is reached
❌ Remote cache adds network latency
❌ Pod startup overhead (even on warm nodes)

Best for: Teams with existing Kubernetes infrastructure where moderate speed is acceptable.

Kubernetes Executor (Autoscaling Cluster)

Autoscaling Kubernetes clusters dynamically add nodes when demand increases. This eliminates queuing issues but introduces significant cold-start delays—new nodes take time to provision, and each job starts with a fresh environment requiring full image pulls and git clones.

Topology: Cluster with autoscaler that adds/removes nodes based on load, pods distributed dynamically.

Performance characteristics:

Speed advantages:

✅ No queue time when scaling up
✅ Dedicated resources per job once running

Speed disadvantages:

❌ Very slow cold starts (node provisioning 30s-2min)
❌ Full image pulls on new nodes
❌ Complete git clones on ephemeral pods
❌ Remote cache network latency

Best for: Variable workloads where cold-start delays are acceptable trade-offs for unlimited capacity.

Docker Executor (Single Server)

A single server running Docker provides the sweet spot between isolation and performance. Containers start quickly when images are cached, git repositories are reused locally, and cache access is lightning-fast through the local filesystem—all while maintaining job isolation.

Topology: Single server with Docker Engine - container isolation but shared local cache via volumes.

Performance characteristics:

Speed advantages:

✅ Very fast local cache access (filesystem)
✅ Image layers cached locally
✅ Quick container startup when warm
✅ Local git repository reuse
✅ No network latency for cache

Speed disadvantages:

❌ Jobs queue when server capacity is reached
❌ Container overhead (minimal but present)

Best for: Teams needing container isolation with near-optimal speed.

Shell Executor (Single Server)

The shell executor is the fastest possible configuration—no containers, no image pulls, no pod scheduling. Everything runs directly on the host system with instant access to local git repos and filesystem cache. The trade-off? No job isolation, requiring trust in your codebase.

Topology: Everything is local on a single server - runner, shell execution, and cache share the same filesystem.

Performance characteristics:

Speed advantages:

✅ Absolute fastest (zero container overhead)
✅ Instant cache access (direct filesystem)
✅ Fastest git operations (local clones reused)
✅ No image pulls ever
✅ Immediate job start (no container creation)
✅ Best optimization potential

Speed disadvantages:

❌ Jobs queue when server capacity is reached

Best for: Maximum speed when job isolation is not required.

Docker Autoscaler (Fleeting)

Docker Autoscaler uses the Fleeting plugin system to spawn VMs on cloud providers. It dynamically provisions VMs when demand increases and terminates them when idle, providing unlimited capacity at the cost of cold-start delays.

Topology: Autoscaling VMs - plugin-based architecture supporting multiple cloud providers.

Performance characteristics:

Speed advantages:

✅ No queue time (infinite capacity)
✅ Dedicated resources once VM is ready

Speed disadvantages:

❌ Slow cold starts (15+ seconds VM provisioning)
❌ Full git clone on each VM
❌ Full image pull on each VM
❌ Cloud cache network latency

Best for: Variable workloads requiring autoscaling where cold-start delays are acceptable.

Job speed comparison summary

Here's a comprehensive comparison of job execution speed across all execution phases:

Legend: 🟢 Fast · ⚪ Medium · 🔴 Slow

Runner Type	Wait	VM/Pod	OS	Git	Script	Cache	Artifacts
GitLab Shared	🟢	🟢	🔴	🔴	🔴	🔴	🔴
K8S Fixed	⚪	🟢	⚪	⚪	⚪	⚪	⚪
K8S Autoscaling	🟢	⚪	🔴	🔴	🟢	⚪	⚪
Docker	🔴	🟢	⚪	🟢	🔴	🟢	⚪
Shell	🔴	🟢	🟢	🟢	🔴	🟢	⚪
Docker Autoscaler	🟢	🔴	🔴	🔴	🟢	⚪	⚪

Key insights:

GitLab Shared: Great for zero maintenance but slowest overall
K8S Fixed: Balanced approach with good warm performance
K8S Autoscaling: Best for variable loads but cold starts are slow
Docker Single Server: Fast local operations with isolation
Shell Single Server: Fastest local operations, best optimization potential
Docker Autoscaler: Maximum scalability but slowest cold starts

Recommendation: Shell or Docker executors for fastest jobs

After analyzing all runner types, Shell and Docker executors on single servers offer the fastest job execution for most teams.

Why single-server executors win on speed

1. Local everything = minimal latency

Git repositories cached locally
Dependencies and cache on local filesystem
No network round-trips for cache operations
Instant resource availability (no VM/pod provisioning)

2. Vertical scaling is underrated

Modern servers can handle dozens of concurrent jobs
SSD storage makes local caching extremely fast
RAM caching for frequently accessed data
CPU cores scale linearly for parallel jobs

3. Warm infrastructure advantage

Docker images already pulled and cached
Git repos incrementally fetched (not full clones)
Dependencies preserved between jobs
No cold-start penalties

Shell vs Docker trade-offs

Choose Shell when:

You need maximum speed
Your codebase is trusted
You can maintain consistent tooling
Security isolation is less critical
You want to push performance limits

Choose Docker when:

You need job isolation
Multiple projects with different dependencies
Security/multi-tenancy matters
Slightly slower speed is acceptable trade-off

The performance/price/maintenance sweet spot

📈 Vertical scalability compensates for the lack of horizontal scalability

💪 A properly sized server with local SSD can handle dozens of simultaneous jobs

💰 Predictable costs: No per-job pricing, one server cost

🔧 Low maintenance: Simple architecture, fewer moving parts

📖 Reference: GitLab CI: The Majestic Single Server Runner

Wrapping up

Choosing the right GitLab Runner topology depends on your specific needs, but if minimizing job execution time is your primary concern, Shell or Docker executors on well-provisioned single servers consistently deliver the fastest jobs.

Key takeaways:

Shared runners are great for getting started but have performance limitations due to multi-tenancy
Kubernetes solutions offer good isolation and scalability but add network latency
Single-server executors (Shell/Docker) provide the fastest local operations and best optimization potential
Autoscaling solutions handle variable loads well but suffer from cold-start penalties
Vertical scaling of single servers is often more effective than complex horizontal scaling

The comparison shows that while autoscaling solutions offer flexibility, a properly configured single-server runner often provides the best performance for teams with predictable workloads or those willing to size for peak capacity.

In our follow-up article GitLab CI: Achieving 3-Second Jobs on Million-Line Codebases, we dive deep into extreme optimizations you can apply to Shell and Docker runners to push performance even further—achieving job times as low as 3 seconds on multi-million line codebases!

Illustrations generated locally by Draw Things using Flux.1 [Schnell] model

How to build and serve custom simplified maps with OpenMapTiles

Noan — Tue, 13 Jan 2026 08:32:21 +0000

If you need to display a map on your website and do not plan to use online mapping services such as MapTiler or Mapbox, you may want to use OpenMapTiles to generate and serve custom tiles. This approach is also useful when you are not interested in all the features a map can display.
In this tutorial, we will create a map featuring only water, such as coastlines, lakes and rivers.
This tutorial was tested on Ubuntu 24.04.

Prerequisites

Osmium: a tool used to process OpenStreetMap data.
The OpenMapTiles repository cloned on your computer.
Docker, to run the OpenMapTiles containers.
The build-essential package (to run the make command).

1. Download the source data

OpenStreetMap provides an up-to-date export of the entire planet.

Pay attention to the licenses of the tools and data used. For OpenStreetMap and OpenMapTiles, proper attribution must be displayed on your map, for example: © OpenMapTiles © OpenStreetMap contributors

The planet.osm.pbf file is about 85GB. This is very large and can take hours to process even you are when only interested in the water data. During development, it is recommended to use an extract from GeoFabrik covering a smaller region that you know well.
In my case, I used the file bretagne.osm.pbf and then the file france.osm.pbf. They can be processed in a few seconds or minutes.

A .osm.pbf file is a compressed format for OpenStreetMap data, if you decompress it with the command osmium cat <your-region>.osm.pbf --output <your-region>.osm you will find that the .osm file is an XML file listing nodes, ways, and polygons. The documentation for this format is available on the OpenStreetMap wiki

2. Extract the relevant data

Since we are only interested in water data, the process can be sped up by reducing the input file size. Let's filter out everything that is not related to water:

osmium tags-filter <your-region>.osm.pbf  rw/waterway rw/water -o water.osm.pbf

3. Generate the vector tiles

At the root of the OpenMapTiles repository, edit the file openmaptiles.yaml to comment out all layers except those related to water:

tileset:
  layers:
    - layers/water/water.yaml
    - layers/waterway/waterway.yaml
    # All other layers are commented out
    # - layers/landcover/landcover.yaml
    # - layers/landuse/landuse.yaml
    # - layers/mountain_peak/mountain_peak.yaml
    # - layers/park/park.yaml
    # - layers/boundary/boundary.yaml
    # - layers/aeroway/aeroway.yaml
    # - layers/transportation/transportation.yaml
    # - layers/building/building.yaml
    # - layers/water_name/water_name.yaml
    # - layers/transportation_name/transportation_name.yaml
    # - layers/place/place.yaml
    # - layers/housenumber/housenumber.yaml
    # - layers/poi/poi.yaml
    # - layers/aerodrome_label/aerodrome_label.yaml
  name: OpenMapTiles
  version: 3.15.0
  id: openmaptiles
  description: "A tileset showcasing all layers in OpenMapTiles. https://openmaptiles.org"
  ...

Next, edit the .env file to specify the zoom levels to generate:

...
# Which zooms to generate with make generate-tiles-pg
MIN_ZOOM=0
MAX_ZOOM=10
...

Move the water.osm.pbf you generated earlier into the data/ directory

mkdir openmaptiles/data/
mv water.osm.pbf openmaptiles/data/

Now run OpenMapTiles to generate the tiles:

cd openmaptiles
./quickstart.sh water

Under the hood, this process will:

Populate a PostGIS database with map features. Note that the database already contains Natural Earth data for low zoom levels. At low zoom levels, coastlines in the resulting map will come frome Natural Earth data.
Create views and functions in this database responsible for querying each layer for each zoom level.
Query the PostGIS database to create a file named tiles.mbtiles. It is a SQLite database containing vector tile data for each (x, y, z) coordinate.

4. Serve the tiles

make start-tileserver

And visit http://localhost:8080

Or if you want to serve the tiles on a server without the whole OpenMapTiles project

# Make sure you have Node.js version 18.17.0 or later installed
npm install -g tileserver-gl
tileserver-gl --file tiles.mbtiles

Conclusion

In this tutorial, we have introduced techniques for generating simple vector maps: where to retrieve the data, how it can be filtered with Osmium, how OpenMapTiles processes it to generate vector tiles, and finally how tileserver-gl can serve them (although it is not production-ready on its own).

From here, you may then want to style your map with Maputnik, explore the user interactions provided by MapLibre, or dig deeper into the transformations performed by OpenMapTiles for each layer.

🔍 Every Developer Should Review Code — Not Just Seniors

Benoit COUETIL 💫 — Sat, 03 Jan 2026 15:37:07 +0000

Initial thoughts
1. Reviewing accelerates learning and skill development
2. Junior developers provide unique value and grow fastest
3. Reviewing enhances your own code quality and habits
4. It fosters system-wide understanding and reduces silos
5. Universal review enforces standards, consistency, and security
6. More reviewers distribute workload, reducing bottlenecks and accelerating delivery
7. It builds psychological safety, team cohesion, and positive culture
8. Code reviews make for better estimates
9. Google's Review Culture: A Proven Model for Excellence
10. "But we don't have time for everyone to review" — Common objections answered
How to Review Effectively at Any Level
Making Universal Review Work: Practical Implementation
Wrapping up
Further reading

Code review shouldn't be reserved for a handful of senior developers. Every team member — regardless of experience level — must participate in reviewing code. Junior developers bring fresh perspectives that catch issues seniors miss, while simultaneously accelerating their own learning. Universal review distributes knowledge, prevents bottlenecks, and transforms code quality from a gate into a shared team responsibility.

Initial thoughts

Picture this: A team of 10 developers where only 2–3 senior engineers handle all code reviews. Those seniors become overwhelmed gatekeepers, review queues grow longer, and junior developers submit code without ever learning to critically evaluate others' work. Sound familiar? Welcome to the review bottleneck club.

Mandatory code review consistently separates high-performing engineering teams from the rest. This approach mirrors the rigorous review culture that propelled Google to become one of the world's leading software providers in its early days.

Codacy.com 2024 article Code review process: how to improve developer productivity shows dominance of code review on code quality:

But code review is too often perceived as a quality gate run by seniors to catch mistakes. This is fundamentally wrong. In reality, the primary beneficiary of reviewing someone else's code is the reviewer themselves — and the entire team benefits from the shared knowledge and improved practices.

The core message: Every developer should review code. Not just approve it with a quick scan, but genuinely engage with it, ask questions, and provide feedback. Here's why.

1. Reviewing accelerates learning and skill development

Reading production code written by others exposes patterns, architectural decisions, edge-case handling, and new techniques at a rate no amount of Stack Overflow browsing can match.

A developer who only writes code sees one mental model. A developer who reviews 5–10 merge requests per week sees dozens of approaches, trade-offs, and real-world solutions every sprint. This bidirectional mentoring — juniors learning from seniors, and vice versa — grows skills across the team.

2. Junior developers provide unique value and grow fastest

The objection "I'm too junior to review" is consistently proven wrong in practice.

Engineers new to a codebase are uniquely positioned to detect:

Ambiguous naming (they still have to think about what something means)
Missing documentation or comments (context that seniors assume is obvious)
Overly clever constructs that violate the principle of least astonishment
Inconsistent style that seniors have become blind to

Fresh eyes often catch security vulnerabilities, performance issues, or logic errors overlooked due to familiarity. Meanwhile, reviewing senior code is one of the most powerful learning tools for juniors — they see production-quality patterns in context, not just in documentation.

3. Reviewing enhances your own code quality and habits

Developers who regularly review begin anticipating reviewer questions before submitting changes:

Commit messages become descriptive
Changes are split into logical, reviewable chunks
Tests are written upfront
Public APIs receive extra care

The "Hawthorne effect" kicks in: knowing your code will be reviewed magically makes you write it better the first time. Over time, this feedback loop is one of the most reliable skill accelerators observed.

4. It fosters system-wide understanding and reduces silos

When every engineer reviews code across the codebase, knowledge silos disappear.

Team members gain:

Insight into why certain retry policies or architectural choices exist
Understanding of how authentication, authorization, and critical paths actually work
Familiarity with the full system, reducing the "bus factor"

This shared context is essential for resilience, refactoring, fast incident response, better estimates, and true team flexibility. When knowledge is distributed, team members can take time off without the project grinding to a halt — no single developer holds the codebase hostage.

5. Universal review enforces standards, consistency, and security

Reviews ensure adherence to coding standards, patterns, and best practices, unifying the codebase and preventing style drift.

They catch:

Security vulnerabilities (e.g., input validation failures or duplicated code risks)
Readability and maintainability issues
Opportunities for design improvements

This early-cycle quality control promotes secure development and a maintainable codebase.

6. More reviewers distribute workload, reducing bottlenecks and accelerating delivery

The higher the number of reviewers involved, the faster code reviews tend to complete. Distributing review requests across the team minimizes bottlenecks — someone available can pick up the review promptly.

This leads to quicker merges, faster time to market, and improved overall team velocity — no more waiting three days for a single thumbs-up.

7. It builds psychological safety, team cohesion, and positive culture

When everyone both gives and receives feedback regularly, code review stops feeling personal.

Teams that practice universal review report:

Fewer surprises in production
Faster decision making
Higher engineering satisfaction and motivation
Stronger bonds through constructive, positive feedback

8. Code reviews make for better estimates

For teams performing estimation, this is a team exercise, and the team makes better estimates as product knowledge is spread across the team.

As new features are added to the existing code, the original developer can provide good feedback and estimation. In addition, any code reviewer is also exposed to the complexity, known issues, and concerns of that area of the code base.

The code reviewer, then, shares in the knowledge of the original developer of that part of the code base. This practice creates multiple, informed inputs which, when used for a final estimate, always make that estimate stronger and more reliable.

9. Google's Review Culture: A Proven Model for Excellence

Google's early dominance as a software provider was deeply rooted in its mandatory pre-commit code review process. Every change required a "Looks Good To Me" (LGTM) approval from a qualified engineer before landing.

This culture:

Caught bugs early, preventing production incidents
Maintained exceptionally high code quality standards
Avoided the "broken windows" effect
Promoted openness, teamwork, and security awareness
Enabled organic knowledge transfer and rapid onboarding
Ensured consistency across a rapidly growing codebase

These factors produced scalable, reliable products (Search, Maps, Gmail) and laid the foundation for Google's engineering reputation that still endures today.

10. "But we don't have time for everyone to review" — Common objections answered

Let's address the elephant in the room — the one wearing a "too busy" t-shirt:

Objection: "Junior reviews slow us down"

Reality: A 10–15 minute review prevents hours or days of incident response, debugging, and rework. When only 2–3 seniors on a 10-person team handle all reviews, those seniors experience overload and burnout, review queues grow, and defect leakage increases due to rushed or fatigued reviews.

Objection: "Juniors don't catch the important stuff"

Reality: Juniors catch different things — ambiguous naming, missing docs, inconsistent patterns. These "surface" issues are exactly what cause maintenance headaches down the road. Plus, they're learning while reviewing, making them better reviewers over time.

Objection: "We can't afford the time investment"

Reality: Investing just 5% of development time in review typically reduces bug-related work by 30–70% (Google, Microsoft, Atlassian benchmarks). Distributing the load prevents bottlenecks and saves far more time overall.

According to Codacy's 2024 study on code review productivity, teams practicing code review see:

10% reduction in time fixing bugs (from 35% to 25% of dev time)
10% improvement in time building new features (from 45% to 55%)
17% reduction in perceived lack of maintenance time (from 76% to 59%)

The math is simple: you can't afford NOT to have everyone reviewing.

How to Review Effectively at Any Level

For everyone:

Start with what you understand confidently — naming, tests, documentation, security basics
Ask questions rather than dictate solutions — "Why did you choose X?" beats "Change this to Y"
Keep comments focused — one clear point beats a wall of text
Target high-impact areas — correctness, design, complexity, standards
Remember the goal — improve the codebase, help the author, and learn

Use Conventional Comments for clarity:

Conventional Comments prefix feedback with labels that clarify intent, making reviews more constructive and less ambiguous:

praise: Highlight excellent work ("praise: Great error handling here!")
nitpick: Minor style suggestions ("nitpick: Consider renaming tmp to tempResult")
suggestion: Propose improvements ("suggestion: We could extract this into a helper function")
issue: Flag problems that must be addressed ("issue: This will fail when input is null")
question: Ask for clarification ("question: Why are we using a timeout here?")
thought: Share considerations without requiring action ("thought: This might impact performance at scale")

This approach helps juniors understand which comments require action vs. are optional, reduces defensive reactions, and creates consistent review language across the team.

For junior reviewers specifically:

Focus on readability: "I don't understand what this function does"
Check test coverage: "Is there a test for the error case?"
Verify documentation: "Could you add a comment explaining why we need this?"
Question assumptions: "What happens if this API call fails?"
Don't apologize for asking questions — they're valuable contributions

For seniors reviewing juniors' reviews:

Praise good catches publicly
Provide context when juniors miss architectural issues
Model constructive feedback tone
Never dismiss or override junior comments without explanation

Making Universal Review Work: Practical Implementation

1. Make it official policy

Explicitly state that everyone reviews code. Add it to onboarding documentation and team agreements.

2. Rotate reviewers

Avoid always pairing the same people.

3. Set clear expectations

Reviews should happen within 4–24 hours (depending on your workflow)
At least one approval required to merge, ideally from someone who didn't write the code
Block merging without review (enforce via branch protection rules)

4. Create review rituals

Daily "review hour" where the team focuses on pending reviews
Celebrate good reviews in standups or retrospectives
Track and visualize review participation

5. Provide training

Run workshops on effective code review
Share examples of good review comments
Create a review guidelines document specific to your codebase

6. Lead by example

Seniors must model the behavior: review promptly, give constructive feedback, accept feedback graciously, and encourage junior participation.

Wrapping up

Universal code review is not a gate. It is one of the highest-ROI engineering practices available.

Every developer — regardless of tenure — must participate. The team's velocity, quality, security, and individual growth depend on it.

The question isn't "Can we afford to have everyone review?" It's "Can we afford not to?"

Illustrations generated locally by Draw Things using Flux.1 [Schnell] model

Google Antigravity : l'ère des IDE Agentiques

Jean-Phi Baconnais — Thu, 18 Dec 2025 08:52:21 +0000

Si la “Developer eXperience” (DX) est en perpétuelle amélioration, l'intelligence artificielle générative bouscule actuellement les paradigmes de développement. Des outils comme Firebase Studio (cf annonce faite par Google) ont déjà introduit la puissance de l'IA dans les Cloud Development Environment (CDE) pour assister les développeurs·euses dans la création d'interfaces, la génération de code et l'intégration de services.

Mais Google a déjà préparé l’étape suivante : l’arrivée des agents dans le monde du développement avec Google Antigravity. Lancée en novembre 2025, cette nouvelle plateforme vise à redéfinir la façon dont nous interagissons avec les agents.

Premiers pas avec Antigravity : Installation et Configuration

Google Antigravity est une nouvelle plateforme de développement « agentique ». La promesse : l’IA ne se contente plus de suggérer des lignes de code, mais elle prend le clavier, pilote l’éditeur, le terminal et le navigateur.

Antigravity s'appuie principalement sur les modèles Gemini. Toutefois, la plateforme est construite pour la flexibilité des modèles incluant le support pour Claude Sonnet 4.5 et Claude Opus 4.5 d'Anthropic ainsi queGPT-OSS d'OpenAI.

L’installation d’Antigravity s’effectue rapidement à partir d’un package téléchargeable sur votre machine (Windows, Mac ou Linux) : https://antigravity.google/download. Actuellement en preview, Antigravity est accessible publiquement avec une limite dans les quotas d’utilisation des modèles (cf https://antigravity.google/pricing).

Une fois installé, une courte phase de configuration permet de définir le comportement des agents avec quelques options. Antigravity vous propose 4 modes de fonctionnement prédéfinis :

Développement piloté par agent (Agent-driven development)
Développement assisté par agent (Agent-assisted development)
Développement piloté par les avis (Review-driven development)
Configuration personnalisée (Custom configuration)

Ces profils sont des préréglages des options présentes sur la partie droite de l’écran, que vous pouvez ajuster manuellement si elles ne vous conviennent pas. Vous pourrez également les modifier par la suite à tout moment dans les préférences d’Antigravity, avec la possibilité d’ajouter des commandes autorisées ou interdites par les agents.

Ces options consistent à configurer l’autonomie des agents dans l’exécution, avec ou sans votre validation humaine, de commandes dans le terminal, de commandes Javascript ou pour valider les revues.

La Rupture : L'IDE Agentique vs. L'Assistance Classique

Avec les IDEs classiques, l'IA restait limitée à des rôles d'assistance, comme la complétion de lignes, des suggestions de changement dans le code, ou les réponses dans un chat latéral. Les développeurs·euses devaient attendre que l'IA ait fini de générer du code avant de poser la question suivante. L’approche agentique change la donne. Désormais les agents intègrent leurs modifications dans nos fichiers avec ou sans notre approbation.

Avec Antigravity, la logique est celle de la délégation : la mission est confiée, l’IA effectue la majeure partie du travail. L’IA n'est plus seulement un outil d'écriture de code, mais un acteur autonome capable de planifier, d'exécuter, de valider et d'itérer sur des tâches complexes

Caractéristiques	IDEs Classiques	ADE (Google Antigravity)
Objectif	Aider à écrire le code plus rapidement (complétion, snippets)	Orchestrer et exécuter des tâches complexes (délégation)
Mode de Travail	Synchrone, linéaire (le développeur/développeuse doit attendre la génération)	Agent-first, asynchrone, parallélisation (plusieurs agents travaillent simultanément)
Rôle de l'IA	Assistant, chat latéral, outil d'écriture de code	Agent autonome qui pilote l'éditeur, le terminal et le navigateur
Validation	Implicite (le développeur vérifie le code généré)	Explicite par production d'artefacts (screenshots, vidéos, etc)

Google Antigravity : IDE Agent-First

Antigravity articule son expérience utilisateur autour de deux vues principales distinctes. En plus d’avoir sa vue de développement comme tout IDE, la nouveauté réside dans l’apparition d’un écran de supervision des interactions avec les agents, l’Agent Manager.

Le Gestionnaire d'Agents (Agent Manager)

Le Gestionnaire d’Agents (ou Agent Manager) est un tableau de bord où le·la développeur·euse agit en tant qu'architecte. Il peut :

Déléguer, orchestrer et surveiller plusieurs agents travaillant de manière asynchrone sur différentes tâches (exemples : refactoriser le module d'authentification, mettre à jour l'arborescence des dépendances, générer une suite de tests pour une API).
Visualiser l'état de chaque agent, les artefacts produits et les demandes d'approbation humaine en attente.

Cette architecture permet à un développeur de déléguer jusqu’à cinq agents différents pour travailler sur cinq bugs différents simultanément.

Les artefacts

Déléguer des tâches complexes nécessite une certaine confiance envers l’agent ainsi que la nécessité de vérifier facilement le travail produit. Antigravity résout ce problème en exigeant des agents qu'ils génèrent des “artefacts“.

Un artefact peut être :

Un plan d’implémentation détaillé.
Les “diffs” de code standardisés montrant les lignes exactes qui seront modifiées.
Des captures d'écran de l'UI (avant et après une modification).
Des enregistrements d’écran de navigateur pour vérifier que les exigences fonctionnelles sont respectées lors des interactions.
Des journaux structurés des résultats de tests (réussis/échoués).

Ces artefacts sont interactifs : si un élément semble incorrect, il est possible de laisser un commentaire directement sur l'artefact et l'agent intégrera ce retour pour itérer sans interrompre son flux d'exécution.

Un navigateur embarqué pour les tests automatisés

Un élément différenciateur est la capacité des agents à lancer un navigateur embarqué, Google Chrome, pour interagir avec des pages Web. Ces agents ont accès à une variété d'outils leur permettant de cliquer, faire défiler, taper, lire les logs de la console et même prendre des vidéos de leurs actions.

Cette capacité permet aux agents de démarrer l’application localement, d’ouvrir un serveur et d'exécuter un scénario utilisateur complet (comme tester une nouvelle fonctionnalité ou reproduire un bug). L'utilisateur·trice est notifié·e lorsque l'agent prend le contrôle, souvent par une bordure bleue visible autour de la fenêtre du navigateur. L'enregistrement de toutes les actions est disponible dans les artefacts, permettant de vérifier la logique fonctionnelle d'un simple coup d'œil.

Lors de la première configuration d’Antigravity et de son browser, une fenêtre Google Chrome s’ouvre vous demandant d’installer l’extension “Antigravity Browser Extension” disponible ici https://chromewebstore.google.com/detail/antigravity-browser-exten/eeijfnjmjelapkebgockoeaadonbchdd.

Un changement d’état d’esprit

Au-delà de la nouveauté technique, Antigravity amène un changement de paradigme dans les équipes de développement.

Habituellement concentré sur le développement d’une fonctionnalité ou de la résolution d’un incident, l’aspect agentique permet de déléguer aux agents plusieurs tâches en parallèle.

La partie « Inbox » centralise le suivi des agents et de leurs discussions. Les développeurs•euses doivent s’habituer à regarder cette « nouvelle boîte de réception » pour observer les notifications informant de la fin de traitement d’un agent et contrôler le résultat des traitements des autres agents. Cela amène un important « context switching » qui peut être nouveau et déstabilisant. Une gymnastique devra être à appréhender pour orchestrer ces tâches exécutées en arrière-plan tout en étant concentré sur l’architecture et les éléments de développement sur lesquels nous voulons garder la main.

Rules, workflow et customisation

Antigravity est personnalisable grâce aux “Rules” et “Workflows” qui permettent d'adapter le comportement des agents à vos habitudes de travail. Les “Rules” guident le comportement des agents avec des consignes que vous pouvez leur donner. Ces règles peuvent être enregistrées dans le répertoire .agent/rules/de votre projet ou dans le fichier ~/.gemini/GEMINI.md et précisent vos attentes en termes de code, de tests ou l’utilisation de librairies sans avoir à les répéter dans chaque conversation. Par exemple, vous pouvez définir une règle spécifiant que tous les composants React doivent être fonctionnels ou bien que le handler de l'API HTTP ne doit jamais appeler la couche ORM directement.

Les “workflows” sont quant à eux des commandes personnalisées que vous utilisez fréquemment et qui pourront être exécutés rapidement. Ces commandes peuvent être enregistrées dans le répertoire .agent/workflows/ de votre projet ou bien à la racine de votre compte utilisateur dans le fichier ~/.gemini/antigravity/global_workflows/global-workflow.md. Un exemple de workflow pourrait être de demander de générer des tests unitaires sur le code ajouté sur cette branche de développement.

Les Model Context Protocol (MCP), utilisés dans les assistants IA pour faciliter les liens avec des services tiers, sont intégrables dans Antigravity. Une liste de MCP pré-configurée vous permet de rapidement en ajouter à votre projet. Les MCP absents de cette liste peuvent également être ajouté en éditant (ou créant) le fichier mcp.json.

Une fois configuré, vous avez la main sur l’activation ou désactivation des services des MCP configurés.

Complément ou futur de Firebase Studio ?

Antigravity n’est pas le seul à proposer une plateforme agentique pour développer des applications. Cursor est une alternative qui propose un contexte équivalent et qui est assez connue et répandue. GitLab Duo propose également une solution de développement agentique qui va cependant plus loin en intégrant des agents dans toute sa plateforme DevOps.

Dans de précédentes conférences, nous soulignions les fonctionnalités d'IA de Firebase Studio, notamment dans le prototypage et l'intégration cloud. Avec l'arrivée de la plateforme Antigravity, qui introduit un changement de paradigme vers le développement « agentique », on peut légitimement se demander si l'approche d'assistance de Firebase Studio est remise en cause.

L'atout principal de Firebase Studio réside dans la rapidité de réalisation de prototypages transformant une simple intention en un plan d’action avec des guidelines graphiques, un déploiement simple et rapide sur les services Google Cloud et le tout depuis votre navigateur. L'exécution n'a pas lieu sur votre ordinateur mais sur la plateforme Cloud de Google (GCP).

Google Antigravity, quant-à lui, exécute votre projet en local et l'IA n'est plus un assistant, mais un acteur autonome capable de piloter l'éditeur, le terminal et un navigateur embarqué. Sa force réside dans la délégation de tâches complexes de bout en bout, comme le refactoring d'un module ou la génération d'une suite de tests complète. Avec son navigateur, Antigravity peut tester lui-même son code et générer un compte rendu de ses actions. Son gestionnaire d’agents permet l'orchestration asynchrone de plusieurs agents travaillant en parallèle.

Firebase Studio est l'outil idéal pour l'entrée en matière et le déploiement rapide d'un PoC dans le cloud, tandis qu'Antigravity prend le relais pour du travail complexe en arrière-plan.

Article écrit avec Benjamin Bourgeois 🙌

ADK, Gemini & Javelit = 😍

Jean-Phi Baconnais — Mon, 15 Dec 2025 08:37:47 +0000

Tandis que les épisodes de notre podcast Zenikast se succèdent, la nécessité de produire la transcription de chaque épisode est bien entendu toujours d’actualité (cf précédent article).

Si une première approche s’était révélée concluante avec Vertex AI, une solution qui nous avait clairement aidé dans la production de qualité de ces transcriptions, nous voulions aller plus loin en rendant disponible ce moyen de transcription à l’ensemble des collaborateurs·trices de Zenika, via une interface graphique, indépendamment de leur connaissance en Vertex AI, Google Cloud Platform ou autre item technique.

En tant que développeur, l’idée de démarrer un projet, un “nième side project”, vient rapidement à l’esprit 😁. Javaiste depuis mes études, il était évident pour moi que ce nouveau projet allait se faire avec du Java !

🤖 ADK

La première question tourne autour du “comment”. Comment intégrer Gemini dans une API? Une librairie de bas niveau de Google, java-genia, couvre clairement ce besoin.

Mais mon regard s’est finalement porté vers Agent Development Kit (ADK), un framework créé par Google facilitant la création d’agents. Initialement créé en Python, des versions Java et dernièrement en Go sont disponibles.

Après avoir créé votre projet maven, vous aurez besoin de cette dépendance :

La librairie google-adk amène plusieurs classes dont voici les 3 principales et nécessaires que vous allez manipuler :

BaseAgent
LlmAgent
InMemoryRunner

La classe LlmAgent représente le builder de votre agent. C’est à cet endroit que vous allez définir votre agent avec un nom, une description, le modèle à utiliser et des instructions.

> A noter que le choix du modèle est libre et peut être un autre modèle que Gemini.

Une instance de InMemoryRunner permet d’initier et de gérer le cycle de vie de votre agent, notamment l’allocation mémoire à son fonctionnement.

Une session est ensuite à initier à partir de ce runner afin de maintenir l’état conversationnel avec l’agent :

L’exécution de votre agent peut se faire avec cet exemple :

Le résultat est récupéré à partir de l’events :

Une fois configuré, l’agent est exécuté avec cette commande et lorsque la réponse sera obtenue, votre programme sera arrêté. Votre agent est fonctionnel 🎉.

ADK met à disposition une seconde dépendance, google-adk-dev, offrant une interface graphique pour tester, utiliser et debbuger vos agents.

⚠️ Cette dépendance est à utiliser lors de vos développements.

La commande à exécuter est légèrement différente. Elle exécute la classe AdkWebServerdisponible dans la dépendance d’ADK.

Cette interface est composée de deux parties. La première, le menu de gauche, détaille les différents événements et étapes de réflexions de votre agent, comme les logs, l’état des sessions en cours et passées ainsi que les outils que l’agent peut être amené à utiliser.

La partie centrale quant à elle, est une zone de conversation où vous interagissez avec votre agent. Dans cet exemple, je lui envoie un passage audio pour vérifier la qualité de la transcription (et de mon prompt associé).

👉Retrouvez toute la documentation d’ADK sur https://google.github.io/adk-docs .

⚙️ Gemini 3

La sortie de la version 3 de Gemini a été remarquée de par sa progression par rapport à la précédente version et notamment grâce à son entraînement multimodal. Google a sorti une gamme de modèles très performant, que ce soit Gemini 3 pro, mais aussi sur son modèle d’images, Nano Banana ou bien vidéo avec Veo 3.

Après avoir testé Gemini 3 pour nos transcriptions, l’amélioration de la qualité est clairement présente.

🎨 Javelit

Javelit est un projet créé par Cyril de Catheu. Inspiré de Streamlit, une librairie de création de composants graphiques en Python, Javelit est une variante pour … Java. Ce projet n’a pas vocation àconcurrencer les frameworks Front end comme Angular, Vue ou React. Il offre la possibilité de créer rapidement des applications web dans le même langage que votre API, et ça, c’est super intéressant.

A partir de l’import de la dépendance et du package core, vous avez accès à des classes qui vous permettent d’avoir votre premier composant graphique en Java.

Dans cet exemple, je mentionne un composant “markdown” mais le catalogue de composants est très complet, avec par exemple :

Jt.title pour mettre un titre à votre page
Jt.text pour afficher du texte
Jt.code pour afficher du code
Jt.html pour afficher du code HTML l’exécution de Javascript n’est pas possible
Jt.echarts pour afficher des graphiques (basés sur la librairie ECharts)
Jt.button, Jt.radio, Jt.textInput pour faire des formulaires

👉Retrouvez la documentation complète sur https://docs.javelit.io/.

🙌 ADK + Javelit = ♥️

La puissance et la simplicité d’ADK pour créer un agent, combinées à l’efficacité de Javelit pour développer des interfaces graphiques permettent de transformer rapidement des idées en applications fonctionnelles de A à Z. L’infrastructure “mono composant” amène aussi des simplicités dans le déploiement, par exemple avec Cloud Run il est rapidement possible de déployer et mettre à disposition une application.

C’est avec ce raisonnement que l’application de transcription de podcast Zenika a été créée et déployée sur Google Cloud Platform.

Plusieurs options ont été rajoutées pour modifier ou adapter le prompt en fonction des besoins comme l’affichage de l’horodatage dans la transcription (merci Théophile pour l’idée), ou bien pour générer une transcription stricte (équivalente aux mots des intervenants·es) ou une version plus lisible.

👉 Retrouvez le projet Agent-Z-transcribe-podcast sur GitHub : http://github.com/zenika-open-source/agent-Z-transcribe-podcast/

Ce trinôme ADK, Gemini + Javelit est une belle découverte. Déployée sur une instance serverless comme Cloud Run, notre application de transcription de podcast est graphiquement agréable, sans trop de prise de tête avec du CSS 😅, et utilise la puissance du dernier modèle de Gemini pour me générer une transcription de qualité.

Cela donne des idées par la suite pour faire rapidement des projets. Si on ajoute à cette expérience, l’utilisation de l’IDE “agentique” Antigravity, la production et surtout la réalisation de nouveaux projets vont pouvoir voir le jour beaucoup plus rapidement 🚀.

Web3 : Le bilan de Google Cloud sur la blockchain en 2025

Benjamin Bourgeois — Thu, 11 Dec 2025 09:48:02 +0000

Comme chaque année (2023 et 2024), je fais le point sur les avancées de Google Cloud sur le Web3. En 2025, ce domaine est également concerné par l’arrivée de l’Intelligence Artificielle (IA). Le géant du cloud mise désormais sur la convergence entre la blockchain et l’IA. De l’infrastructure aux agents autonomes, en passant par les paiements programmables, Google étend son empreinte bien au-delà des simples services de nœuds.

🤖 Des agents IA connectés à la blockchain

L’un des temps forts de l’année est la publication par Google d’un guide complet pour créer des « Web3 AI agents », des agents autonomes capables d’interagir directement avec des smart-contracts et des données « on-chain ». S’appuyant sur Vertex AI Agent Engine et Agent Development Kit (ADK), ces agents peuvent lire des transactions, exécuter des contrats et gérer des flux en toute autonomie.

👉 Lire l’article officiel sur le blog Google Cloud

Google ne se contente plus de fournir des outils d’accès à la blockchain, il devient un acteur du Web3 intelligent, où les IA ne sont plus seulement “off-chain” mais véritablement connectées à l’écosystème décentralisé. Les agents deviennent des entités économiques à part entière, capables d’échanger, d’apprendre et d’agir dans un écosystème numérique interconnecté et sécurisé.

🏦 Stablecoins et “Universal Ledger” : Google veut sa propre infrastructure de paiement

L’annonce la plus stratégique de 2025 reste toutefois la mise en avant d’un protocole de paiement pour agents IA, appuyé sur les stablecoins ainsi que sa propre blockchain maison baptisée Google Cloud Universal Ledger. GCUL ne reposerait pas sur l’Ethereum Virtual Machine (EVM) mais plutôt sur une infrastructure indépendante avec des smart contracts écrits en Python. Selon Rich Widmann, responsable Web3 chez Google Cloud, GCUL est conçue pour être une plateforme stable, flexible, conforme aux réglementations et « crédiblement neutre », dédiée aux paiements institutionnels et les cas d’usage IA-to-IA.

Cette initiative rapproche Google des acteurs comme Stripe et Circle, tout en renforçant son positionnement face à des besoins émergents : permettre à des agents autonomes d’effectuer des transactions stables, traçables et programmables.

👉 Article du Journal du Coin sur le protocole de paiement IA

👉 Article du Journal du Coin sur GCUL

👉 Cryptoast - Google construirait sa propre blockchain

👉 CryptoDNES - Google Cloud lance sa blockchain pour concurrencer Stripe et Circle

🌐 Un écosystème Web3 en expansion

En parallèle, Google Cloud a multiplié les partenariats dans l’écosystème blockchain, confirmant sa volonté de ne pas rester seul fournisseur mais de jouer un rôle de catalyseur :

Collaboration avec Lava Network autour de la “future économie autonome”, mêlant IA et blockchain. 👉 Article sur Cryptopolitan
Partenariat avec Etherlink pour renforcer les outils de développement Web3 et améliorer les performances des infrastructures décentralisées. 👉 Source Phemex News
Coopérations avec des projets blockchain pour stimuler l’innovation Web3 à l’échelle mondiale. 👉 Article de CryptoDnes

Ces alliances traduisent une stratégie pragmatique : favoriser un écosystème performant plutôt qu’un modèle fermé, tout en s’assurant que les briques critiques, données, IA, paiements, passent par Google Cloud.

Ce qu’il faut retenir

En résumé, voici les quelques pistes à explorer en priorité :

Expérimenter les architectures d’agents IA connectés à la blockchain : les tutoriels et SDK proposés par Google facilitent les prototypes. Il y a d’ailleurs un codelab ici ou encore un exemple là.
Surveiller de près Google Cloud Universal Ledger et les initiatives de paiement stablecoin : elles pourraient transformer la manière dont les agents IA échangent de la valeur.
Garder un œil sur la gouvernance et la neutralité : plus Google s’implique dans l’infrastructure financière on-chain, plus la question de la “neutralité crédible” deviendra importante.

Conclusion

En 2025, Google Cloud franchit une nouvelle étape : du simple accès à la blockchain à la création d’une infrastructure complète pour les agents intelligents et les paiements programmables. Avec ses nouveaux outils, ses partenariats stratégiques et ses ambitions dans les paiements, le cloud de Google devient un acteur structurant de la convergence Web3 × IA.

Les clouds de demain seront-ils « on-chain et intelligents ».

Rendez-vous en 2026 !

Forem: Zenika

Agent Development Kit 2.0, ADK-java 1,1 et Go 1.0 🚀

✨ ADK

🙌 Les apports de la v2

🎉 Versions 1.0 des SDK Java et Go

🚀 Démo

Conclusion

🦊 GitLab CI: Automated Testing of Job Rules

Initial thoughts

1. The problem: CI rules complexity

2. The solution: automated job list validation

gitlab-ci-local: the cornerstone

How it works

3. Setting up the test infrastructure

Directory structure

Test case definition

Reference CSV files

4. The validation script

5. The CI job

6. Workflow: adding or modifying jobs

7. Testing with rules:changes

The problem with rules:changes and gitlab-ci-local

The force-build label workaround

Per-module test cases

8. Documentation that writes itself

Wrapping up

Further reading

All Articles by Theme

⚗️ A local Agent with ADK and Docker Model Runner

⛅ Using AI in the Cloud

🧩 My Context

🐳 Docker Model Runner

🧩 The link between ADK / DMR

🙌 A Locally Available Agent

🤔 A "Local" Future?

📝 Dev.to Writers Community: One Command to Maintain Them All

The Community

What I Built

Demo

Content enrichment

Diagrams as code with Kroki

Automatic table of contents

ANSI-styled terminal output

Bulk operations

Smart file renaming

Article badges generation

Broken link checking

Environment

Organization publishing

Proxy support for corporate environments

Code

How I Built It

Further reading

All Articles by Theme

🦊 GitLab CI: Achieving 3-Second Jobs on Million-Line Codebases

Initial thoughts

Prerequisites: The right foundation

Classic optimizations first

Extreme optimizations: going beyond

Breaking down the 3-second job

Job execution on a well-sized shell runner

Phase 1: Waiting (~0s)

Phase 2: Server (~0s)

Phase 3: OS / Shell (~1s)

Phase 4: Git Clone/Fetch (~1s)

Strategy and depth

Fetch flags

Situational: tailored clone path

Phase 5: Cache (~0s)

Shared package managers folders

Optional : do not clean unpacked assets

Phase 6: Artifacts (none)

Phase 7: Script (~1s)

Phase 8: Termination (~0s)

Final timing breakdown

Real project results

Wrapping up

Further reading

All Articles by Theme

How GiLab Duo Agent Platform & Antigravity can collaborate to improve the quality of our applications