DEV Community: Giorgio Boa

Untyped Python? Let Antigravity /goal Do the Cleanup

Giorgio Boa — Thu, 09 Jul 2026 14:49:44 +0000

Python projects have a special way of aging.

At first, everything feels light and fast. A few scripts, some helper functions, maybe a small API. Then six months pass. The project grows. Functions start returning "whatever works." Dictionaries become informal data models. Tests still pass, mostly, but every refactor feels like walking through a dark room full of furniture.

That is exactly where Antigravity CLI's new /goal command becomes useful.

The idea behind /goal is simple: instead of giving the agent one instruction and waiting for a single pass, you define an end state. Antigravity keeps working until that goal is reached, or until it has a clear reason to stop. For refactoring, this is a very natural fit, because cleanup work is rarely one-and-done. You fix one issue, run the toolchain, uncover ten more, repeat.

A great example is taking an older Python project with little or no type discipline and moving it toward a cleaner, more maintainable baseline.

My preferred first step is not "add perfect typing everywhere." That is usually too big, too vague, and too easy to derail. Instead, start with formatting and linting. Install Ruff, let it enforce consistency, and use Antigravity's /goal command to loop until the codebase is clean.

First, add Ruff:

uv add --dev ruff

or, if the project still uses pip:

pip install ruff

Then configure a basic pyproject.toml if one does not exist:

[tool.ruff]
line-length = 100
target-version = "py314"

[tool.ruff.lint]
select = ["E", "F", "I", "UP", "B"]

Now the useful part: give Antigravity a measurable goal.

/goal Refactor this Python project toward a clean Ruff baseline. Run `ruff check --fix; ruff format;` repeatedly, inspect remaining errors, and update the code until Ruff reports no errors. Preserve behaviour and avoid broad rewrites unless required.

That prompt works because the finish line is concrete: Ruff must pass. The agent is not guessing what "clean up the project" means. It has a command to run, feedback to read, and a clear loop: fix, format, check, repeat.

This is where Antigravity CLI feels different from a normal chat-style coding session. The asynchronous workflow lets the agent keep running commands and iterating without turning every lint error into a manual back-and-forth. You can stay focused on the higher-level direction while the tool handles the mechanical cleanup.

For untyped Python projects, Ruff is a good first refactor gate because it catches high-signal problems without requiring a full typing migration. Unused imports disappear. Import order becomes consistent. Risky patterns get flagged. Old syntax can be modernised. Formatting stops being a debate.

After Ruff passes, you can raise the bar:

/goal Add lightweight type hints to the public functions in this project. Keep changes minimal, run tests after each batch, and stop when tests and Ruff both pass.

That second goal is much safer after the first cleanup. The code is already formatted, obvious lint issues are gone, and the agent has less noise to fight through.

The most important lesson: /goal works best when paired with verifiable commands. "Make this better" is weak. "Run Ruff until it passes" is strong. "Add types while tests keep passing" is strong. "Refactor without changing behavior" becomes much more realistic when the agent has tests, linters, and formatters as feedback.

For me, this is the real value of Antigravity CLI's /goal: it turns refactoring from a single fragile prompt into a controlled loop. The agent is not just editing code. It is working against a measurable definition of done and for messy Python projects, that is exactly what you want.

You can follow me on GitHub, where I'm creating cool projects.

I hope you enjoyed this article, until next time 👋

Giorgio BoaFollow

Giorgio Boa is a full stack developer and the front-end ecosystem is his passion. He is also international public speaker, active in open source ecosystem, he loves learn and studies new things.

Moving Fast Without Losing Track: My antigravity-cli Changelog Habit

Giorgio Boa — Thu, 09 Jul 2026 14:29:04 +0000

As a consultant, I am used to working at different speeds.

At the beginning of a project, especially when preparing the first proof of concept, the pace is fast. Very fast. It feels close to startup mode: short feedback loops, quick decisions, and a strong focus on delivering something usable in the shortest possible time. The goal is not to build the final version immediately. The goal is to test an idea, reduce uncertainty, and put something concrete in front of people.

In that phase, speed matters more than ceremony. A proof of concept gives the team real evidence: does the workflow make sense, does the model answer correctly, does the tool integration work, does the user understand the value?

But after the POC works, things change.

Once the first version is tested and released to production, the project enters a different rhythm. The code is no longer only an experiment. It becomes something users depend on. Every change can affect a real workflow, so the team needs more control over what will go live.

This is why, with atigravity-cli, I usually add a skill that updates the changelog after every modification. It is a small habit, but it creates a useful control layer. Each code change leaves a written trace.

Here is a simple example from my Google ADK TypeScript project. The root agent is a sequential ADK workflow: first it converts currency, then it estimates how many LEGO pieces could be bought.

import { SequentialAgent } from "@google/adk";
import { currencyAgent } from "./sub-agents/currencyAgent.ts";
import { legoPiecesAgent } from "./sub-agents/legoPiecesAgent.ts";

export const rootAgent = new SequentialAgent({
  name: "currency_pipeline",
  description:
    "Converts currency, then calculates LEGO pieces needed for the converted amount.",
  subAgents: [currencyAgent, legoPiecesAgent],
});

This is still a small project, but it already has a structure that can grow: a root agent, sub-agents, tools, a README, and a changelog. The currency agent is focused on one job only.

export const currencyAgent = new LlmAgent({
  name: "currency_agent",
  model: "gemini-3.5-flash",
  description: "An agent that can help with currency conversions.",
  instruction: `${SYSTEM_INSTRUCTION} When converting an amount, clearly include the final converted amount and target currency in your response.`,
  tools: [getExchangeRate],
  outputKey: "currencyResult",
});

The tool itself calls the Frankfurter API and keeps the external integration isolated.

const url = new URL(`https://api.frankfurter.app/${currency_date}`);
url.searchParams.set("from", currency_from.toUpperCase());
url.searchParams.set("to", currency_to.toUpperCase());

const response = await fetch(url);

Then another agent reads the conversion result and calculates a LEGO estimate. In the example, the logic supports USD and EUR.

If the target currency is EUR,
estimate LEGO pieces using the average retail price range for a new LEGO piece:
EUR0.10 to EUR0.13 EUR per piece.

This kind of change may look small. But in production, even small changes matter. Supporting EUR in the LEGO estimation changes the behavior users see. With a changelog, it becomes visible.

The project includes a custom rule:

After you modify, add, or delete any files in the workspace,
trigger and follow the update-changelog skill.

And the skill defines the process:

Check which files were modified, read package.json,
read CHANGELOG.md, then write clear user-facing bullet points.

The result is simple but powerful:

For me, this is the difference between moving fast and moving blind. During the POC, I want maximum speed. After production, I still want speed, but with memory.

That context helps consultants, developers, stakeholders, and future maintainers. It turns an AI-assisted workflow into something easier to review, easier to release, and easier to trust.

You can follow me on GitHub, where I'm creating cool projects.

I hope you enjoyed this article, until next time 👋

Giorgio BoaFollow

Giorgio Boa is a full stack developer and the front-end ecosystem is his passion. He is also international public speaker, active in open source ecosystem, he loves learn and studies new things.

Stop Giving AI Agents Your Whole Laptop: Secure Them with Dev Containers

Giorgio Boa — Wed, 08 Jul 2026 09:31:07 +0000

I recently started using Visual Studio Code Dev Containers with LLM coding agents and I thought to share it because, in my opinion, it is one of the simplest ways to make agentic development safer.

LLM agents are incredibly useful, but the first time you run one with full access to your laptop you may have the same thought I had:

"Do I really want this thing to see my whole filesystem, my SSH keys, my cloud credentials, and all the random projects I have locally?"

Developer Experience

The best developer experience is not only about speed.

It is also about having an environment where you can experiment without constantly worrying about what the tool can touch.

This is where Dev Containers are very useful: you can give the agent a clean workspace, the exact dependencies it needs, and nothing else.

Visual Studio Code Dev Containers

The Visual Studio Code Dev Containers extension lets you use a Docker container as a full-featured development environment. It allows you to open any folder or repository inside a container and take advantage of Visual Studio Code's full feature set.

For LLM agents, this means you can run the editor, terminal, tools, and agent inside a container instead of directly on your machine.

The agent can still edit files, run tests, install packages, and execute commands, but only inside the environment you prepared for it.

Why This Matters For LLM Agents

When you run an agent locally, the risk is not only that it writes bad code.

The bigger concern is access.

If your whole home directory is available, the agent may accidentally read files that are unrelated to the project. If your shell has access to credentials, tokens, cloud CLIs, SSH config, or production scripts, the blast radius is much bigger.

With a Dev Container you can avoid sharing all your system and credentials. You mount only the project folders you want to work on, install only the tools needed for that environment, and decide explicitly which secrets, if any, are available.

YOLO Mode

Many LLM coding tools have a mode where the agent can run commands and edit files without asking for confirmation every time.

Sometimes people call this "YOLO mode".

It is convenient, but on your host machine it can be scary.

Inside a Dev Container, it becomes much more reasonable: if the agent installs the wrong package, breaks the environment, or creates a mess, you can rebuild the container and start again.

You are not giving it your entire laptop.

You are giving it a disposable development box.

My Setup

Instead of adding a .devcontainer folder to every project, I keep one separate folder that only describes the agent environment.

Something like this:

.
|-- devcontainer
|   |-- devcontainer.json
|   `-- Dockerfile
|-- project-a
|-- project-b
`-- project-c

I build and start the container from the devcontainer folder.

Then, when I want to work on a project, I attach that project folder into the running container and connect VS Code to the container.

This gives me one reusable environment for LLM agents, without having to copy the same Dev Container configuration into every repository.

Configuration

devcontainer.json

The devcontainer.json file describes the reusable container environment.

Here is a simple example:

{
  "name": "agent-safe-workspace",
  "build": { "dockerfile": "Dockerfile" },
  "workspaceFolder": "/workspaces",
  "remoteUser": "node"
}

The important idea is that this folder describes the agent box, not a specific application.

Your projects can stay separate, and you decide which ones are attached to the running container.

Dockerfile

The Dockerfile defines what is installed inside the container.

For example, for a Node.js based environment:

FROM mcr.microsoft.com/devcontainers/javascript-node:1-22-bookworm

RUN apt-get update && apt-get install -y \
    ripgrep \
    jq \
    && rm -rf /var/lib/apt/lists/*

WORKDIR /workspaces

You can adapt this depending on your stack: Python, Go, Rust, Java, or anything else.

The important part is that the dependencies are installed in the container, not directly on your host machine.

Starting The Container

From the folder that contains the Dev Container configuration, you start the container separately.

For example, you can use the Dev Containers extension to open only that devcontainer folder, or you can build and run the Docker image yourself.

After the container is running, attach VS Code to it with:

Dev Containers: Attach to Running Container

At that point you are inside the isolated environment.

Then you attach or mount the project folder you want to work on into the container and open it from there.

The workflow becomes:

1. Start the reusable agent container
2. Attach your project to the running container with VS Code
3. Run the LLM agent inside the container

This is different from the usual flow where each project owns its own .devcontainer folder.

In this setup, the container is the stable tool environment, and the project folders are the inputs you choose to expose to it.

Credentials

Be intentional with secrets.

Do not mount your entire ~/.ssh, ~/.aws, ~/.config, or home directory by default.

If the agent needs a token, create a limited token for that task. If it needs GitHub access, prefer a token with the smallest useful scope. If it does not need credentials, do not provide them.

The point of the container is to make access explicit.

Docker

Obviously, you need Docker up and running on your machine.

After that, VS Code can connect to the container and give you the usual editor experience inside the isolated environment.

VS Code Extension

To use this workflow, install the Dev Containers extension.

The command I use most in this setup is:

Dev Containers: Attach to Running Container

This lets me keep the container lifecycle separate from the project lifecycle.

Ready To Go

Once the container is running and the project folder is attached, start your LLM agent from the VS Code terminal inside the container.

Now the agent sees the project workspace and the tools you installed there.

That is the main advantage: you can let the agent move faster, even in YOLO mode, while keeping a clear boundary between the experiment and the rest of your machine.

It is not a magic security solution, but it is a very practical improvement. The only tedious part is writing the correct Dockerfile, but once it is done, the environment becomes reusable, predictable, and safe to use.

For day-to-day agentic coding, a reusable disposable Dev Container is one of the easiest ways to reduce risk without making the workflow painful.

You can follow me on GitHub, where I'm creating cool projects.

I hope you enjoyed this article, until next time 👋

Giorgio BoaFollow

Giorgio Boa is a full stack developer and the front-end ecosystem is his passion. He is also international public speaker, active in open source ecosystem, he loves learn and studies new things.

Scalable Micro-Frontends on Cloudflare

Giorgio Boa — Mon, 06 Jul 2026 14:49:20 +0000

In a traditional monolithic front-end, coordinating releases across multiple teams introduces significant organisational friction. Teams often find themselves bottlenecked by shared deployment pipelines, where a single bug in one feature can block unrelated updates from shipping to production. Additionally, managing massive merge conflicts, coordinating deployment windows, and aligning testing cycles across disparate product areas frequently lead to slower release cadences and diluted domain ownership. Micro-frontends address these challenges by decoupling the frontend into autonomous modules, enabling each team to deploy updates on their own schedule without requiring cross-organisational synchronisation.

However, traditional micro-frontend setups often introduce latency, complex Cross-Origin Resource Sharing (CORS) configurations, and complicated deployment pipelines.

By combining Module Federation (@module-federation/vite) with Cloudflare Workers—utilizing Service Bindings, @cloudflare/vite-plugin, and Wrangler—you can create a scalable, performant micro-frontend monorepo.

This approach resolves remote micro-frontends (MFEs) via a same-origin proxy mechanism directly on Cloudflare’s edge network, completely avoiding CORS issues in production while preserving a native development experience locally.

Architecture Overview

In this example of monorepo architecture, we split our system into a single Host Shell and multiple Remote micro-frontends (remote-a and remote-b):

├── apps/
│   └── host/     # Host shell (Vite + Cloudflare Worker)
└── mfes/
    ├── remote-a/ # Exposed Micro-Frontend A (Assets-only Worker)
    └── remote-b/ # Exposed Micro-Frontend B (Assets-only Worker)

The Production Same-Origin Proxy Pattern

In production, the host worker acts as an API gateway and static asset router. When a user requests /remote-a/remoteEntry.js, the host worker intercepts the route and proxies the request to the remote-a Worker via Cloudflare Service Bindings.

This offers several operational, performance, and cost advantages:

Zero CORS Issues: Because all micro-frontends are served under the host’s primary domain, the browser views them as same-origin. This removes the need for complex, fragile, and potentially insecure cross-origin HTTP header management.
Minimal Latency: Cloudflare Service Bindings allow Workers to execute within the same thread on the same physical edge server [1.2.2]. This allows them to pass requests internally with near-zero network overhead, routing traffic instantly without going back out to the public internet.
No Request Duplication Costs (Free Subrequests): On Cloudflare Workers, you only pay for the initial user request hitting the Host Worker. The subsequent internal calls to the remote Workers via env.REMOTE_A or env.REMOTE_B are treated as internal subrequests, which carry zero additional request fees. This allows you to split your application into as many micro-frontends as required without multiplying your Cloudflare request charges.
Elimination of Gateway Infrastructure Overhead: Historically, avoiding CORS in a micro-frontend architecture required provisioning, patching, and maintaining a cluster of dedicated reverse-proxy servers (e.g., NGINX running on virtual machines) or configuring expensive cloud load balancers. Cloudflare Workers scale to zero, eliminating the maintenance effort and baseline idle-VM costs associated with dedicated routing infrastructure.
Robust Environment Isolation: The host can map service bindings dynamically across environments (e.g., routing /remote-a/* to remote-a-qa in the staging environment and remote-a-prod in production). This permits deployment pipelines to deliver changes safely without running separate physical infrastructure stacks for each target environment.

1. Configuring the Remote Micro-Frontends

Each remote MFE functions as an assets-only Worker. It builds its static files—including the Module Federation container entrypoint (remoteEntry.js)—and serves them directly.

Vite Configuration (`mfes/remote-a/vite.config.ts`)

The remote uses the @module-federation/vite plugin to bundle components and expose them. It also declares shared dependencies like react and react-dom as singletons to prevent multiple React runtimes from loading in the browser.

import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
import { federation } from '@module-federation/vite'

export default defineConfig({
  plugins: [
    react(),
    federation({
      dts: false,
      name: 'remoteA',
      filename: 'remoteEntry.js', // Emitted container entrypoint
      exposes: {
        './Widget': './src/Widget.tsx', // Exposed remote component
      },
      shared: {
        react: { singleton: true },
        'react-dom': { singleton: true },
      },
    }),
  ],
  build: {
    // Module Federation relies on top-level await; esnext target is required
    target: 'esnext',
  },
  server: {
    port: 5174,
    strictPort: true,
    cors: { origin: '*' }, // Required for local cross-origin loading in dev
  },
})

Wrangler Configuration (`mfes/remote-a/wrangler.jsonc`)

For the remote micro-frontends, we configure them as assets-only deployments. A crucial setting is "not_found_handling": "none". Unlike single-page applications (SPAs) which fallback to index.html on missing assets, MFE chunk directories must strictly return a 404 Not Found if a chunk is missing to prevent the federated runtime from swallowing errors.

{
  "$schema": "node_modules/wrangler/config-schema.json",
  "name": "cloudflare-react-remote-a",
  "compatibility_date": "2026-06-16",
  "assets": {
    "directory": "./dist",
    "not_found_handling": "none" // Crucial: return 404s for missing asset chunks
  },
  "workers_dev": true,
  "env": {
    "qa": {},
    "prod": {}
  }
}

2. Configuring the Host Worker

The host application consists of a React SPA built with Vite, run inside the Workers environment locally and in production via the official @cloudflare/vite-plugin.

Vite Configuration (`apps/host/vite.config.ts`)

The host references the @cloudflare/vite-plugin to run worker-level code locally in a workerd environment.

import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
import { cloudflare } from '@cloudflare/vite-plugin'
import { federation } from '@module-federation/vite'

export default defineConfig({
  plugins: [
    react(),
    cloudflare(),
    federation({
      dts: false,
      name: 'host',
      remotes: {}, // Configured dynamically at runtime instead of statically
      shared: {
        react: { singleton: true },
        'react-dom': { singleton: true },
      },
      shareStrategy: 'loaded-first',
    }),
  ],
  build: {
    target: 'esnext',
  },
})

Wrangler Configuration (`apps/host/wrangler.jsonc`)

The host wrangler config binds the remote Workers using services and sets up run_worker_first routing. The run_worker_first configuration routes the matching path prefixes to the worker code instead of attempting to look them up inside the host’s static asset bucket.

{
  "$schema": "node_modules/wrangler/config-schema.json",
  "name": "cloudflare-react",
  "main": "worker/index.ts",
  "compatibility_date": "2026-06-16",
  "assets": {
    "binding": "ASSETS",
    "not_found_handling": "single-page-application",
    "run_worker_first": [
      "/remote-a/*",
      "/remote-b/*",
      "/api/*"
    ]
  },
  "services": [
    {
      "binding": "REMOTE_A",
      "service": "cloudflare-react-remote-a"
    },
    {
      "binding": "REMOTE_B",
      "service": "cloudflare-react-remote-b"
    }
  ],
  "env": {
    "qa": {
      "services": [
        { "binding": "REMOTE_A", "service": "cloudflare-react-remote-a-qa" },
        { "binding": "REMOTE_B", "service": "cloudflare-react-remote-b-qa" }
      ]
    },
    "prod": {
      "services": [
        { "binding": "REMOTE_A", "service": "cloudflare-react-remote-a-prod" },
        { "binding": "REMOTE_B", "service": "cloudflare-react-remote-b-prod" }
      ]
    }
  }
}

3. Implementing the Host Worker Entrypoint

The host worker’s router handles routing for local assets, remote proxy routing, and server-side logic APIs. When a route begins with /remote-a/* or /remote-b/*, the request is modified and forwarded via Service Bindings to the correct remote worker.

// apps/host/worker/index.ts
export interface Env {
  ASSETS: Fetcher;
  REMOTE_A: Fetcher;
  REMOTE_B: Fetcher;
}

function withAssetCache(res: Response, pathname: string): Response {
  const out = new Response(res.body, res);
  // Immutable caching for content-hashed production asset bundles
  out.headers.set(
    "Cache-Control",
    pathname.startsWith("/assets/")
      ? "public, max-age=31536000, immutable"
      : "no-cache",
  );
  return out;
}

export default {
  async fetch(request, env) {
    const url = new URL(request.url);

    // Dynamic routing maps to remote service bindings
    const remoteRoutes = [
      { prefix: "/remote-a", service: env.REMOTE_A },
      { prefix: "/remote-b", service: env.REMOTE_B },
    ];

    for (const { prefix, service } of remoteRoutes) {
      if (url.pathname === prefix || url.pathname.startsWith(prefix + "/")) {
        const target = new URL(request.url);
        // Strip the path prefix so the remote worker receives its root path
        target.pathname = url.pathname.slice(prefix.length) || "/";
        return service.fetch(new Request(target, request));
      }
    }

    if (url.pathname.startsWith("/api/")) {
      return Response.json({ name: "Cloudflare Workers Edge API" });
    }

    // Default: Serve static front-end assets for the host SPA
    return withAssetCache(await env.ASSETS.fetch(request), url.pathname);
  },
} satisfies ExportedHandler<Env>;

4. Resolving Micro-Frontends Dynamically at Runtime

Statically defining remote URLs in vite.config.ts forces a rebundling step for every distinct environment deployment. To achieve a single-build deployment model, register your remotes programmatically using @module-federation/runtime.

Endpoint Mapping (`apps/host/src/moduleFederation/mfeUrls.ts`)

The remote resolution strategy shifts based on whether the code executes in local development or a production Worker. Vite's standard import.meta.env.DEV variable determines the target origin.

const devRemoteEntry = (envOverride: string | undefined, fallback: string) => {
  const origin = (envOverride ?? fallback).replace(/\/$/, '');
  return `${origin}/remoteEntry.js`;
}

export const mfeUrls: Record<string, string> = {
  remoteA: import.meta.env.DEV
    ? devRemoteEntry(import.meta.env.VITE_REMOTE_A_URL, 'http://localhost:5174')
    : '/remote-a/remoteEntry.js',
  remoteB: import.meta.env.DEV
    ? devRemoteEntry(import.meta.env.VITE_REMOTE_B_URL, 'http://localhost:5175')
    : '/remote-b/remoteEntry.js',
};

Initializing the Runtime (`apps/host/src/moduleFederation/moduleFederationRuntime.ts`)

Before importing any remote React code, initialize the federation container.

import { registerRemotes, loadRemote } from '@module-federation/runtime'
import { mfeUrls } from './mfeUrls'

let initialized = false;

export const initializeModuleFederationRuntime = (): void => {
  if (initialized) return;
  registerRemotes(
    Object.entries(mfeUrls).map(([name, entry]) => ({
      name,
      type: 'module',
      entry,
    })),
    { force: true }
  );
  initialized = true;
};

export const loadRemoteComponent = async <TProps = Record<string, never>>(
  remoteId: string
): Promise<{ default: React.ComponentType<TProps> }> => {
  initializeModuleFederationRuntime();
  const remoteModule = await loadRemote<{ default: React.ComponentType<TProps> }>(remoteId);
  if (!remoteModule) {
    throw new Error(`Remote "${remoteId}" failed to resolve.`);
  }
  return remoteModule;
};

5. Integrating Remote Components in React

To handle potential loading failures gracefully (such as network drops or remote MFE redeployments), load the federated components dynamically using React.lazy and enclose them in a React Error Boundary.

// apps/host/src/moduleFederation/RemoteWidget.tsx
import { Component, lazy, Suspense, ReactNode } from 'react'
import { loadRemoteComponent } from './moduleFederationRuntime'

type WidgetProps = { greeting?: string }

const lazyByRemoteId = new Map<string, any>()

const getRemoteWidget = (remoteId: string) => {
  let component = lazyByRemoteId.get(remoteId);
  if (!component) {
    component = lazy(() => loadRemoteComponent<WidgetProps>(remoteId));
    lazyByRemoteId.set(remoteId, component);
  }
  return component;
};

class RemoteErrorBoundary extends Component<{ children: ReactNode }, { error: Error | null }> {
  state = { error: null as Error | null };

  static getDerivedStateFromError(error: Error) {
    return { error };
  }

  render() {
    if (this.state.error) {
      return (
        <div className="error-card">
          <h4>Failed to load Remote Component</h4>
          <p>{this.state.error.message}</p>
        </div>
      );
    }
    return this.props.children;
  }
}

export function RemoteWidget({ remoteId, greeting }: { remoteId: string; greeting?: string }) {
  const Widget = getRemoteWidget(remoteId);
  return (
    <RemoteErrorBoundary>
      <Suspense fallback={<div>Loading remote MFE components...</div>}>
        <Widget greeting={greeting} />
      </Suspense>
    </RemoteErrorBoundary>
  );
}

Conclusion

By deploying your monorepo micro-frontends with Module Federation, @cloudflare/vite-plugin, and Wrangler, you combine the agility of modern UI composition with the performance profile of Cloudflare's edge network. Using same-origin proxying via Service Bindings avoids complex client CORS setups entirely. When combined with dynamic runtime federation entry resolution, this setup simplifies local development workflows and provides robust routing capabilities in production environments.

Special thanks to Sultanyaron for your amazing example https://github.com/Sultanyaron/vite-module-federation-cloudflare-deployment. You inspired this article.

You can follow me on GitHub, where I'm creating cool projects.

I hope you enjoyed this article, until next time 👋

Giorgio BoaFollow

Giorgio Boa is a full stack developer and the front-end ecosystem is his passion. He is also international public speaker, active in open source ecosystem, he loves learn and studies new things.

Reason, Act, Remember: Advanced AI with Microsoft Agent Framework

Giorgio Boa — Thu, 19 Feb 2026 09:15:01 +0000

Artificial Intelligence has moved beyond simple chatbots and into the realm of intelligent agents. These agents are not just passive responders; they are capable of reasoning, acting, and remembering. The Microsoft Agent Framework provides a comprehensive set of tools and libraries that empower developers to build these sophisticated AI systems.

The first step in this journey is installing the dependency.

pip install agent-framework --pre

Now that we have the right package, let's start by understanding what an agent actually is. In the simplest terms, an agent is a piece of software that uses a Large Language Model (LLM) to understand and generate human language.

The framework makes it incredibly easy to bring such an entity to life. With just a few lines of code, a developer can connect to Azure's powerful AI infrastructure. You can give your agent a name and a set of instructions. For instance, you might tell it to be a friendly assistant or a technical expert. The framework handles all the complex communication with the AI model, allowing you to focus on what you want the agent to do.

You can interact with this agent in two ways:

ask a question and wait for the complete answer, which is great for short queries
for longer responses, you can use streaming, where the agent "types" the answer out in real-time, making the experience feel much more interactive and responsive, just like a human typing a message.

import os
from agent_framework.azure import AzureOpenAIResponsesClient
from azure.identity import AzureCliCredential

# Create an agent
credential = AzureCliCredential()
client = AzureOpenAIResponsesClient(
    project_endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
    deployment_name=os.environ["AZURE_OPENAI_RESPONSES_DEPLOYMENT_NAME"],
    credential=credential,
)

agent = client.as_agent(
    name="HelloAgent",
    instructions="You are a friendly assistant. Keep your answers brief.",
)

# Run agent (non-streaming)
result = await agent.run("What is the capital of France?")
print(f"Agent: {result}")

# Run agent (streaming)
print("Agent (streaming): ", end="", flush=True)
async for chunk in agent.run("Tell me a one-sentence fun fact.", stream=True):
    if chunk.text:
        print(chunk.text, end="", flush=True)
print()

Expanding Capabilities with Tools

However, an AI that can only talk is limited. The real magic happens when you give your agent the ability to interact with the world. This is where the concept of "Tools" comes into play.

Imagine you want your agent to know the current weather. A standard language model only knows what it was trained on and cannot know if it is raining outside right now. You can define standard Python functions and attaching them to your agent.

You could write a simple function that checks a weather API. When you ask the agent about the weather, it analyses your request, the system intelligently decides to call the function you provided. It then takes the result from that function and uses it to formulate a natural language response.

from typing import Annotated
from agent_framework import tool
from pydantic import Field
from random import randint

@tool(approval_mode="never_require")
def get_weather(
    location: Annotated[str, Field(description="The location to get the weather for.")],
) -> str:
    """Get the weather for a given location."""
    conditions = ["sunny", "cloudy", "rainy", "stormy"]
    return f"The weather in {location} is {conditions[randint(0, 3)]} with a high of {randint(10, 30)}°C."

# Create agent with tools
agent = client.as_agent(
    name="WeatherAgent",
    instructions="You are a helpful weather agent. Use the get_weather tool to answer questions.",
    tools=get_weather, <-- here you have to define the tool
)

result = await agent.run("What's the weather like in Seattle?")
print(f"Agent: {result}")

Multi-Turn Interactions with Sessions

If you tell an agent your name at the start of a chat, you expect it to remember that name five minutes later. The framework solves this through "Sessions".

A session acts as a container for the conversation history. When you talk to the agent within a session, the framework automatically keeps track of what has been said.

This allows for multi-turn conversations where the agent maintains context. This creates an experience that feels personal and coherent rather than robotic.

# Create a session to maintain conversation history
session = agent.create_session()

# First turn
result = await agent.run("My name is Alice and I love hiking.", session=session)
print(f"Agent: {result}\n")

# Second turn — the agent should remember the user's name and hobby
result = await agent.run("What do you remember about me?", session=session)
print(f"Agent: {result}")

The Microsoft Agent Framework provides a comprehensive toolkit for building intelligent AI agents that reason, act, and remember. Key features include core agent interaction via LLMs, dynamic tool integration for real-world tasks, and session-based conversation persistence. Finally the journey for building an AI agent is both accessible and powerful.

You can follow me on GitHub, where I'm creating cool projects.

I hope you enjoyed this article, until next time 👋

Giorgio BoaFollow

Giorgio Boa is a full stack developer and the front-end ecosystem is his passion. He is also international public speaker, active in open source ecosystem, he loves learn and studies new things.

Copilot: Secret Tip to Troubleshooting Your GitHub Actions

Giorgio Boa — Thu, 12 Feb 2026 08:16:04 +0000

GitHub Actions have become an indispensable tool for automating software development workflows, enabling continuous integration and delivery directly within your repositories. However, even the most meticulously crafted pipelines can encounter issues, leading to frustrating debugging sessions. This is where GitHub Copilot emerges as a powerful assistant, offering intelligent insights and streamlining the troubleshooting process for your GitHub Actions workflows.

Traditionally, pinpointing the root cause of a failed GitHub Actions run involves sifting through extensive logs, meticulously checking syntax, and understanding the intricate interplay of various actions and conditions. This can be a time-consuming, especially for intricate workflows or those managed by multiple contributors.

Copilot aims to transform this experience, acting as an intelligent partner that can quickly analyse failures and suggest solutions.

Here is an example:

One of Copilot's most compelling features for GitHub Actions troubleshooting is its ability to provide immediate explanations for failed checks. You no longer need to manually navigate through layers of logs to understand what went wrong. With a simple click on the "Explain error" option next to a failed check in the merge box or on the workflow run summary page, Copilot springs into action. It opens a chat window, where it will analyze the context of the failure and offer actionable instructions to resolve the issue. This direct and contextual guidance significantly reduces the time and effort required to diagnose problems.

This kind of intelligent assistance can be invaluable for understanding the flow of your workflow and identifying logic errors more efficiently.

It acts as an intelligent accelerator, helping you navigate complex scenarios and quickly pinpoint solutions. By leveraging Copilot as a helper in your GitHub Actions pipelines you can spend more time building and less time debugging.

You can follow me on GitHub, where I'm creating cool projects.

I hope you enjoyed this article, until next time 👋

Giorgio BoaFollow

Giorgio Boa is a full stack developer and the front-end ecosystem is his passion. He is also international public speaker, active in open source ecosystem, he loves learn and studies new things.

Hooks are here: Now you can intercept and direct the path of the Gemini CLI

Giorgio Boa — Thu, 29 Jan 2026 09:11:47 +0000

The Gemini Command Line Interface (CLI) is a powerful tool, and with the introduction of its "hooks" feature, users can now significantly extend and customise its behaviour without ever touching the core source code.

Hooks are essentially scripts or programs that the Gemini CLI executes at specific, predefined points within its agentic loop, offering unparalleled control and flexibility.

Use Cases

Imagine being able to inject crucial context before your AI model even sees a request, validate potentially risky actions before they execute, or even enforce company-wide compliance policies directly within your development workflow. This is precisely the power that Gemini CLI hooks bring to the table. By running synchronously as part of the agent loop, hooks ensure that the CLI waits for their completion before proceeding, guaranteeing that your custom logic is always applied.

Getting Started

Hooks communicate with the CLI via strict JSON requirements over stdin and stdout – the "Golden Rule" dictates that your script must only print the final JSON object to stdout, reserving stderr for all debugging and logging. Exit codes play a crucial role, with 0 signifying success and allowing stdout to be parsed, while 2 indicates a "System Block," aborting the target action and using stderr as the rejection reason. Hooks can also be selectively triggered using "matchers," which are regular expressions for tool events and exact strings for lifecycle events.

Real Case Scenario

Consider a scenario where you want to prevent the delete_file tool from being executed if a specific environment variable isn't set. You could configure an hook with a matcher for delete_file. This hook script would check for the environment variable. If it's missing, the script would print a JSON object like {"decision": "deny", "reason": "Environment variable 'ALLOW_DELETIONS' not set."} to stdout and exit with code 0. The Gemini CLI would then parse this and block the delete operation.

Configuration

Here is the official announcement with all the possibile configurations.

The configuration is handled in settings.json, with a clear hierarchy of precedence from project to system settings. This allows for granular control, from project-specific security checks to global compliance policies. The configuration schema defines fields like type (currently only "command" is supported), the command to execute, a friendly name, and an optional timeout.

e.g.

{
  "hooks": {
    "BeforeTool": [
      {
        "matcher": "write_file|replace",
        "hooks": [
          {
            "name": "security-check",
            "type": "command",
            "command": "$GEMINI_PROJECT_DIR/.gemini/hooks/security.sh",
            "timeout": 5000
          }
        ]
      }
    ]
  }
}

Hooks execute arbitrary code with your user privileges. Therefore, caution is advised, especially with project-level hooks in untrusted projects.

Mastering these hooks means gaining control over your AI interactions, ensuring that the Gemini CLI operates exactly as you intend, securely and efficiently, across all your projects.

You can follow me on GitHub, where I'm creating cool projects.

I hope you enjoyed this article, until next time 👋

Giorgio BoaFollow

Giorgio Boa is a full stack developer and the front-end ecosystem is his passion. He is also international public speaker, active in open source ecosystem, he loves learn and studies new things.

Senior Developer's Secret: AI-Driven Iteration with VSCode, Cline & Playwright

Giorgio Boa — Mon, 26 Jan 2026 14:23:09 +0000

The integration of VSCode, Cline, and the Playwright Model Context Protocol (MCP) Server marks a significant leap forward in frontend application development, testing, and refinement.

This powerful combination empowers developers to iterate with browsers more effectively, streamlining workflows and accelerating the delivery of high-quality web experiences.

The New Frontend Development Workflow

This integration creates a seamless and highly efficient feedback loop for frontend developers. With Cline embedded in VSCode, developers can leverage AI to generate code snippets, refactor existing code, and understand complex codebases. Cline can even execute commands directly in the terminal, adapting to the development environment and toolchain. This dramatically speeds up the initial coding phase and helps maintain code quality.

The Playwright MCP Server is the bridge that connects the AI capabilities of Cline (or other LLMs) with actual browser environments. It exposes Playwright's browser automation functionalities, such as navigating pages, clicking elements, and filling forms, as structured tools that an AI can utilize. Instead of manually scripting every interaction, developers can use natural language prompts to instruct the AI to perform complex browser actions.

This is where the integration truly shines. The AI, powered by Playwright MCP, can open a browser and validate changes made to the application.

Developers can ask the AI to verify specific UI behaviors, generate automated tests based on natural language descriptions, and even suggest fixes for failing tests. Playwright's inherent capabilities, like auto-waiting for elements, web-first assertions, and detailed tracing, further enhance the reliability and debuggability of these AI-driven tests.

Cline can explore the application, suggest new test cases, and automatically generate tests, significantly reducing the manual effort in quality assurance. This rapid iteration cycle means that frontend issues can be identified and resolved much faster, leading to a more robust and polished user experience.

Real Use Case

I stumbled upon a fantastic UI component on the web and, without missing a beat, grabbed a screenshot. Then, the magic happened. I pasted that image directly into Cline.
What followed was an incredible display of AI power.
Through just a few iterative "AI loops" within Cline, the platform intelligently analysed the screenshot, understood its structure and styling, and then, almost effortlessly, translated it into functional code. After few minutes, that stylish component was not just an image on my screen, but a live, interactive part of my own application. This seamless transition from a visual idea to a working element, all powered by AI, truly felt like the future of development.

In conclusion, the sophisticated integration of VSCode, Cline, and the Playwright MCP Server is transforming the landscape of frontend development. Developers can now build, test, and refine frontend applications with unprecedented speed and accuracy, thanks to a new era of intelligent, efficient, and highly effective workflows, leading to superior web experiences for users.

You can follow me on GitHub, where I'm creating cool projects.

I hope you enjoyed this article, until next time 👋

Giorgio BoaFollow

Giorgio Boa is a full stack developer and the front-end ecosystem is his passion. He is also international public speaker, active in open source ecosystem, he loves learn and studies new things.

Agent Flows At Scale with Google’s ADK for TypeScript

Giorgio Boa — Sat, 20 Dec 2025 22:08:47 +0000

The landscape of Artificial Intelligence is undergoing a seismic shift. We are moving rapidly beyond simple, single-purpose chatbots toward autonomous, intelligent multi-agent systems capable of complex reasoning and task orchestration.

To empower developers in this new era, Google has officially introduced the Agent Development Kit (ADK) for TypeScript. This open-source framework marks a pivotal moment for the JavaScript ecosystem, bringing a strict "code-first" philosophy to AI development.

The Code-First Revolution

For too long, building AI agents felt like an exercise in abstract prompt engineering. The ADK changes this paradigm by allowing developers to define logic, tools, and orchestration directly in TypeScript. As highlighted in Google’s December 2025 announcement, this approach enables engineers to apply standard software development best practices—such as version control, automated testing, and CI/CD integration—to their AI workflows.

The framework offers end-to-end type safety, meaning developers can build their agent backend and application frontend in a cohesive language, drastically reducing integration errors. By utilising modular components like Agents, Instructions, and Tools, the ADK transforms complex AI behaviours into clean, readable, and scalable code.

Case Study: The "Chef & Sommelier" Multi-Agent System

Here you can find the working project, you only need to add your Gemini API Key.

To demonstrate the power of the ADK, let’s explore a practical implementation: a hierarchical Chef Agent. This project uses the latest Gemini 3 model gemini-3-pro-preview model to create a culinary experience that goes beyond simple recipe generation.

The project structure is clean and modular, a hallmark of the ADK methodology:

chef-agent/
├── agent.ts (The Head Chef)
└── sommelier-agent/
    └── agent.ts (The Wine Expert)

The Hierarchical Architecture

The core of this application lies in chef-agent/agent.ts. Here, the root agent is defined as the "Chef," whose instruction is to take a single ingredient input and generate a masterpiece dish, complete with a name, description, recipe, and plating instructions.

However, the true power of the ADK is showcased in how it handles sub-agents. The Chef isn't working alone.

The code explicitly defines a subAgents array:

import { LlmAgent } from "@google/adk";
import { sommelierAgent } from "./sommelier-agent/agent";

export const rootAgent = new LlmAgent({
  name: "chef_agent",
  model: "gemini-3-pro-preview",
  description: "A chef that creates amazing food based on a single ingredient.",
  instruction: `You are a world-renowned Chef with a passion for creating culinary masterpieces.
Your specialty is taking a SINGLE INGREDIENT provided by the user and designing a complete, delicious, and amazing dish around it.

When you receive an input (which will be an ingredient):
1.  **Conceive a Dish**: Create a unique name for a dish highlighting that ingredient.
2.  **Description**: Write a mouth-watering description.
3.  **Recipe**: Provide a detailed recipe including:
    *   Ingredients list (quantities and items).
    *   Step-by-step cooking instructions.
4.  **Presentation**: Suggest how to plate the dish for maximum visual appeal.

Be enthusiastic, professional, and creative.
You also have a colleague, "sommelier_agent", who must suggest wine pairings for the dish you create.`,
  subAgents: [sommelierAgent],
});

This configuration tells the Chef agent that it has access to a colleague. When the Chef generates a recipe, it can automatically consult the sommelier_agent. defined in sommelier-agent/agent.ts. This sub-agent has a specific, narrow scope: suggesting the perfect wine pairing based on the flavour profile of the dish the Chef just created.

The sommelier_agent code:

import { LlmAgent } from "@google/adk";

export const instruction = `You are an expert Sommelier.
Your goal is to suggest the perfect wine pairing for a given dish.
When provided with a dish name or description:
1. Suggest a specific type of wine (e.g., Cabernet Sauvignon, Chardonnay).
2. Explain why it pairs well with the dish (flavor profile, acidity, etc.).
3. Recommend a specific region if applicable.`;

export const sommelierAgent = new LlmAgent({
  name: "sommelier_agent",
  model: "gemini-3-pro-preview",
  description: "A sommelier that suggests wine pairings for a given dish.",
  instruction,
});

The Developer Experience

The project leverages the @google/adk library and offers a seamless developer experience. Looking at the package.json, we see built-in scripts that use the ADK devtools:

Terminal Mode: pnpm run run:terminal allows the developer to interact with the Chef directly in the command line for rapid testing.

Web Interface: pnpm run run:web launches a local server (localhost:8000), providing a chat interface to visualize the interaction between the user, the Chef, and the hidden Sommelier sub-agent.

The Chef Agent project perfectly illustrates why the ADK for TypeScript is a game-changer. It creates a structured environment where distinct AI personalities (the Chef and the Sommelier) interact through typed contracts rather than vague prompts.

By combining the reasoning capabilities of the new Gemini 3 models with the reliability of TypeScript, Google’s ADK provides the foundation for the next generation of software—where code doesn't just execute commands, but thinks, creates, and collaborates.

You can follow me on GitHub, where I'm creating cool projects.

I hope you enjoyed this article, until next time 👋

Giorgio BoaFollow

Giorgio Boa is a full stack developer and the front-end ecosystem is his passion. He is also international public speaker, active in open source ecosystem, he loves learn and studies new things.

Agent Development in Hours, Not Weeks: Accelerating with Gemini 3 and Google ADK

Giorgio Boa — Thu, 18 Dec 2025 18:13:04 +0000

In the rapidly evolving landscape of artificial intelligence, the ability to iterate and deploy intelligent agents with speed is no longer a luxury – it's a critical competitive advantage. Traditionally, bringing a sophisticated AI agent from concept to production could take weeks, bogged down by complex model training, intricate API integrations, and the laborious process of building robust applications around the core AI.

However, a revolutionary shift is underway, largely thanks to the potent synergy between Gemini 3's advanced capabilities and the streamlined tooling provided by the Google Agent Development Kit (ADK). This powerful combination isn't just about incremental improvements; it represents a paradigm shift, compressing development timelines from weeks of effort down to mere hours.

The Powerhouse: Gemini 3

At the heart of this acceleration lies Gemini 3, Google's next-generation multimodal AI model.

Gemini 3 is not just an incremental update; it's engineered for enhanced reasoning, complex task understanding, and superior performance across a vast array of modalities, including text, image, audio, and video.

Gemini 3 excels at understanding complex instructions and performing multi-step reasoning. This means less hand-holding and explicit programming for the agent's logic, as Gemini 3 can often infer intent and execute sophisticated workflows based on high-level prompts.

The Accelerator: Google Agent Development Kit (ADK)

While Gemini 3 provides the brain, the Google ADK provides the entire nervous system and skeletal structure, making it incredibly easy to connect that brain to the real world. The ADK is more than just a library; it's a comprehensive ecosystem designed specifically for rapid agent prototyping and deployment.

Key Features of ADK

The ADK offers a rich collection of pre-built components, templates, and example agents that demonstrate common use cases. This allows developers to start from a solid foundation rather than building everything from scratch.
ADK provides seamless, abstracted interfaces for interacting with LLMs, allowing developers to focus on the agent's behaviour rather than the intricacies of API calls.
It is designed to work hand-in-hand with Google Cloud's robust infrastructure, offering simple paths to deploy agents as scalable, production-ready services.

Amazing Developer Experience

Features like interactive playgrounds, debugging tools, and quick deployment options massively reduce the iteration cycle. Developers can test, refine, and redeploy their agents in minutes, not hours.

With ADK is easy to orchestrate complex agent behaviours, managing state, memory, and interactions with various external tools and systems. e.g. logging tools, safety security tools.

In a world where AI innovation moves at an unprecedented pace, the combination of Gemini 3 and the Google ADK isn't just a development advantage; it's the new standard for building the intelligent agents of tomorrow, today. Start building and watch your project development time drop from weeks to hours.

You can follow me on GitHub, where I'm creating cool projects.

I hope you enjoyed this article, until next time 👋

Giorgio BoaFollow

Giorgio Boa is a full stack developer and the front-end ecosystem is his passion. He is also international public speaker, active in open source ecosystem, he loves learn and studies new things.

Thinking, Planning, Executing: Gemini 3's Agentic Core in the Antigravity Sandbox

Giorgio Boa — Thu, 18 Dec 2025 16:06:24 +0000

In the ever-accelerating landscape of artificial intelligence, the promise of true agency, where systems not only perform tasks but proactively think, plan, and execute, has long been the holy grail.

Today, we stand on the precipice of that realisation with the advent of Gemini 3’s revolutionary agentic core, particularly as its capabilities unfold within the controlled yet expansive environment of the Antigravity Sandbox.

This isn't just about faster computation; it's about fundamentally reshaping how we approach complex problems, entrusting their lifecycle management from conceptualisation to completion to an intelligent system.

At the heart of Gemini 3 lies a sophisticated architecture designed to mirror human cognitive processes, yet unbound by human limitations.

Its agentic core is not a collection of isolated functionalities, but rather an interconnected suite of modules enabling seamless transitions between ideation and action.

This integration manifests in three critical phases:
thinking, planning, and executing.

Thinking

The "thinking" phase in a Gemini 3 agent is where the magic begins. When presented with a goal or a problem within the Antigravity Sandbox, the agent doesn't immediately jump to the most obvious solution. Instead, it engages in a deep analysis of the context, drawing upon its vast knowledge base and learned patterns. This involves interpreting ambiguities, identifying underlying constraints, and even hypothesising potential causal relationships.

Planning

This detailed understanding then seamlessly transitions into the "planning" phase. This isn't just about generating a linear sequence of steps; it's about dynamic, adaptive strategy formulation. Gemini 3 agents in the Antigravity Sandbox are capable of generating intricate workflow diagrams, complete with contingencies and alternative pathways. They anticipate potential roadblocks, perhaps a database dependency that might impact downtime, or a security policy that could bottleneck deployment. Crucially, the planning phase is iterative and self-correcting.

Executing

Finally, we arrive at "execution", where the carefully crafted plans are brought to life. Within the Antigravity Sandbox, Gemini 3 agents aren't merely observers of the execution process. It leverages its ongoing monitoring capabilities to detect anomalies, analyse the deviation against its planned state, and then initiate an intelligent re-planning or recovery sequence.

We are moving beyond simply tooling intelligence, to truly partnering with it. The precipice has been crossed; the landscape of possibility is now immeasurably wider, inviting us to dream with an intelligence that doesn't just assist, but truly, profoundly, leads the way.

You can follow me on GitHub, where I'm creating cool projects.

I hope you enjoyed this article, until next time 👋

Giorgio BoaFollow

Giorgio Boa is a full stack developer and the front-end ecosystem is his passion. He is also international public speaker, active in open source ecosystem, he loves learn and studies new things.

Antigravity for Developers: Lifting the Burden with Gemini 3 Agents

Giorgio Boa — Tue, 16 Dec 2025 09:05:57 +0000

The constant pressure to innovate and deliver faster is a familiar burden for every developer. Days are often consumed by repetitive tasks, debugging, and navigating complex workflows, leaving little room for the creative problem-solving that truly fuels progress.

What if developers could experience a form of "antigravity," liberating them from these tedious constraints? The answer might lie in Gemini 3 Agents.

These intelligent agents, powered by the cutting-edge reasoning capabilities of Gemini 3, promise to revolutionise the development landscape by automating complex, multi-step tasks.

They act as tireless assistants, capable of understanding intricate instructions and executing them with precision and efficiency. Imagine offloading tasks like code generation, bug fixing, documentation creation, and even complex refactoring to a dedicated agent. This is the potential unlocked by Gemini 3 Agents.

Automate Impossible Tasks

Unlike simple scripts that follow rigid instructions, Gemini 3 Agents can interpret natural language requests, reason about the underlying code, and dynamically adjust their strategies based on the context of the project. This level of intelligence allows them to tackle tasks that were previously impossible to automate, freeing up developers to focus on higher-level challenges.

The key to their transformative power lies in their ability to understand and adapt to the nuances of the development process.

How do Gemini 3 Agents work in practice?

Consider a scenario where a developer needs to implement a new feature. Instead of manually writing all the code, they can instruct a Gemini 3 Agent to generate the initial code structure, including necessary functions and classes, based on a brief description of the feature's requirements. The agent can then integrate this code into the existing codebase, ensuring compatibility and adherence to coding standards. Furthermore, it can even write unit tests to verify the functionality of the newly implemented feature.

The benefits extend beyond simple code generation. Gemini 3 Agents can also play a crucial role in debugging and error resolution.

By analysing error logs and code snippets, they can identify potential causes of bugs and suggest solutions. They can even automatically implement fixes, significantly reducing the time spent on tedious debugging sessions.

The advantages

Automating repetitive tasks frees up developers to focus on more complex and creative aspects of their work, leading to a significant boost in overall productivity. This streamlined workflows and automated tasks contribute to faster development cycles, allowing teams to deliver projects more quickly. By removing the burden of tedious tasks, Gemini 3 Agents can improve developer satisfaction and create a more engaging and fulfilling work environment.

The introduction of Gemini 3 Agents marks a paradigm shift in software development. It's not about replacing developers, but about augmenting their capabilities and empowering them to achieve more. As these agents become more sophisticated and integrated into the development ecosystem, the potential for unlocking unprecedented levels of productivity and innovation in the software industry is truly limitless. The future of development is here, and it's lighter than ever before.

You can follow me on GitHub, where I'm creating cool projects.

I hope you enjoyed this article, until next time 👋

Giorgio BoaFollow

Giorgio Boa is a full stack developer and the front-end ecosystem is his passion. He is also international public speaker, active in open source ecosystem, he loves learn and studies new things.

DEV Community: Giorgio Boa

Untyped Python? Let Antigravity /goal Do the Cleanup

Giorgio BoaFollow

Moving Fast Without Losing Track: My antigravity-cli Changelog Habit

Giorgio BoaFollow

Stop Giving AI Agents Your Whole Laptop: Secure Them with Dev Containers

Developer Experience

Visual Studio Code Dev Containers

Why This Matters For LLM Agents

YOLO Mode

My Setup

Configuration

devcontainer.json

Dockerfile

Starting The Container

Credentials

Docker

VS Code Extension

Ready To Go

Giorgio BoaFollow

Scalable Micro-Frontends on Cloudflare

Architecture Overview

The Production Same-Origin Proxy Pattern

1. Configuring the Remote Micro-Frontends

Vite Configuration (mfes/remote-a/vite.config.ts)

Wrangler Configuration (mfes/remote-a/wrangler.jsonc)

2. Configuring the Host Worker

Vite Configuration (apps/host/vite.config.ts)

Wrangler Configuration (apps/host/wrangler.jsonc)

3. Implementing the Host Worker Entrypoint

4. Resolving Micro-Frontends Dynamically at Runtime

Endpoint Mapping (apps/host/src/moduleFederation/mfeUrls.ts)

Initializing the Runtime (apps/host/src/moduleFederation/moduleFederationRuntime.ts)

5. Integrating Remote Components in React

Conclusion

Giorgio BoaFollow

Reason, Act, Remember: Advanced AI with Microsoft Agent Framework

Expanding Capabilities with Tools

Multi-Turn Interactions with Sessions

Giorgio BoaFollow

Copilot: Secret Tip to Troubleshooting Your GitHub Actions

Here is an example:

Giorgio BoaFollow

Hooks are here: Now you can intercept and direct the path of the Gemini CLI

Use Cases

Getting Started

Real Case Scenario

Configuration

Giorgio BoaFollow

Senior Developer's Secret: AI-Driven Iteration with VSCode, Cline & Playwright

The New Frontend Development Workflow

Real Use Case

Giorgio BoaFollow

Agent Flows At Scale with Google’s ADK for TypeScript

The Code-First Revolution

Case Study: The "Chef & Sommelier" Multi-Agent System

The Hierarchical Architecture

The Developer Experience

Giorgio BoaFollow

Agent Development in Hours, Not Weeks: Accelerating with Gemini 3 and Google ADK

The Powerhouse: Gemini 3

The Accelerator: Google Agent Development Kit (ADK)

Key Features of ADK

Amazing Developer Experience

Giorgio BoaFollow

Thinking, Planning, Executing: Gemini 3's Agentic Core in the Antigravity Sandbox

Thinking

Planning

Executing

Giorgio BoaFollow

Antigravity for Developers: Lifting the Burden with Gemini 3 Agents

Automate Impossible Tasks

How do Gemini 3 Agents work in practice?

The advantages

Giorgio BoaFollow

Vite Configuration (`mfes/remote-a/vite.config.ts`)

Wrangler Configuration (`mfes/remote-a/wrangler.jsonc`)

Vite Configuration (`apps/host/vite.config.ts`)

Wrangler Configuration (`apps/host/wrangler.jsonc`)

Endpoint Mapping (`apps/host/src/moduleFederation/mfeUrls.ts`)

Initializing the Runtime (`apps/host/src/moduleFederation/moduleFederationRuntime.ts`)