DEV Community: albe_sf

Anthropic's Dynamic Workflows Aren't Just Another Agent Feature

albe_sf — Mon, 01 Jun 2026 15:01:48 +0000

Anthropic just shipped Claude Opus 4.8, but the real story isn't the model number. It's a feature called Dynamic Workflows, which orchestrates hundreds of parallel subagents for large-scale projects like codebase migrations. This moves the goalposts for what a coding agent does, shifting from interactive assistance to delegated, autonomous execution.

what just changed

The latest flagship model, Claude Opus 4.8, was released with a notable capability for Claude Code called Dynamic Workflows. This feature is designed to manage complex, multi-step tasks by breaking them down and running them as parallel subagents. This is a structural departure from the typical agentic model, which tends to operate serially—it takes a prompt, acts, and waits for the next instruction.

The key use case mentioned is codebase-scale work, which implies a system that can manage dependencies and context across many files and directories simultaneously. Instead of asking an agent to refactor a single file, you can theoretically define a project-level goal, and the workflow engine will orchestrate the necessary changes across the entire codebase. This suggests a higher level of abstraction where the developer acts as a system architect rather than a micromanager of prompts.

from copilot to orchestrator

This changes the nature of the work. For years, AI coding tools have been positioned as copilots. They help with line-by-line suggestions, generating boilerplate, and explaining snippets. More advanced agents can tackle multi-file changes, but the interaction remains fundamentally conversational and sequential. You are still in the driver's seat for every major step.

Dynamic Workflows point to a different interaction model. By allowing for the definition and parallel execution of sub-tasks, the system takes on the role of a project manager or a technical lead. The developer's job shifts from writing code to defining the architecture of the work itself. This requires a different skill: describing a complex change as a graph of dependent tasks that can be safely parallelized.

This is the kind of work required for daunting tasks like framework upgrades, API deprecations, or migrating a legacy frontend to a new design system. These are projects that involve thousands of repetitive, yet context-sensitive, changes that are painful to execute manually and difficult to specify in a single prompt.

defining a workflow

While the exact implementation details are not public, one can imagine a declarative format, perhaps a YAML or JSON file, that defines the stages of a large-scale refactoring. This configuration would serve as the master plan for the swarm of subagents.

A migration from an old data-fetching library to a new one might be defined like this:

# workflow.yaml
name: api-client-migration
description: "Migrate all components from legacy `ApiService` to the new `GraphQLClient`."

# Phase 1: Identify all call sites of the old service.
- name: inventory-call-sites
  description: "Scan the codebase and generate a JSON report of all files that import and use `ApiService`."
  tool: static-analysis
  params:
    target: "src/utils/ApiService.js"
  output: "migration_plan.json"

# Phase 2: Refactor components in parallel.
- name: refactor-components
  description: "For each component in the report, replace `ApiService` calls with `GraphQLClient` queries."
  type: parallel-map
  input: "migration_plan.json"
  concurrency: 50 # Run up to 50 subagents at once
  spec:
    - tool: edit-file
      params:
        file: "{{item.file}}"
        prompt: "Replace the data fetching logic here to use GraphQLClient. The required query is {{item.equivalent_query}}."
    - tool: run-linter
      params:
        file: "{{item.file}}"
        fix: true

# Phase 3: Run integration tests after all refactoring is complete.
- name: run-tests
  description: "Execute the end-to-end test suite to verify the migration."
  depends_on: ["refactor-components"]
  tool: run-command
  params:
    command: "npm run test:e2e"

This is speculative, but it illustrates the shift in thinking. The high-value work is in designing the workflow itself—defining the stages, dependencies, and the instructions for each parallel unit of work.

the so-what

For builders, this is a signal to start thinking about automation at a higher level of abstraction. The new frontier of agentic development may be less about crafting the perfect prompt and more about designing robust, automated workflows that can reliably execute complex engineering projects. If this paradigm holds, the most effective AI-powered developers will not be just expert coders, but expert orchestrators.

Sources

https://www.anthropic.com/

Mistral's Codestral Isn't Another Generalist Model

albe_sf — Fri, 29 May 2026 15:02:25 +0000

Mistral AI has released Codestral, a 22B parameter model explicitly for code generation. This is a notable release not because it's the largest model, but because it's a specialized one. The takeaway is that the frontier is shifting from massive, general-purpose models to efficient, task-specific architectures for professional tooling.

what is codestral

Codestral is an open-weight 22B model trained on a dataset covering over 80 programming languages, including Python, Java, C++, JavaScript, and more specialized ones like Swift and Fortran. Its defining feature is its focus. Unlike generalist models that handle a wide range of text-based tasks, Codestral is engineered for code-centric workflows: function completion, test generation, and filling in partial code blocks.

The model is released under a “Mistral AI Non-Production License,” which makes it available for research and testing purposes. This “open-weight” approach allows developers to download and experiment with the model's parameters directly, but the licensing implies constraints on commercial production use.

One of its key technical capabilities is a fill-in-the-middle (FIM) mechanism, which is critical for IDE-based code completion where latency is a primary concern. This suggests it's optimized for the kind of low-latency, high-frequency interactions common in tools like VSCode and JetBrains.

getting access

There are a few ways to use Codestral. For direct integration and IDE tooling, Mistral has provided a dedicated endpoint at codestral.mistral.ai. This endpoint is intended for developers integrating the model into their tools and is free during a beta period. It is also available on their standard api.mistral.ai endpoint, where usage is billed per token.

For local development and experimentation, you can run the model directly. It's available for download from Hugging Face and can be run using tools like Ollama. This allows for offline use and deeper integration into local development environments.

Here is a basic example of how to interact with the model via the Ollama API after pulling the model:

# First, pull the model with Ollama
ollama pull codestral

# Then, send a request to the local API
curl http://localhost:11434/api/chat -d '{
  "model": "codestral",
  "messages": [
    {
      "role": "user",
      "content": "Write a Python function to calculate the Fibonacci sequence."
    }
  ]
}'

Integrations are already available in frameworks like LlamaIndex and LangChain for building agentic applications, and in IDE extensions like Tabnine and Continue.dev.

why it matters for builders

The release of a dedicated, high-performance code model from a major lab is significant. It signals a move toward a multi-model future where developers will likely route tasks to specialized systems rather than relying on a single, monolithic AI. For code generation, a model trained specifically on code and fluent in dozens of languages offers a performance and latency advantage over a generalist counterpart.

The 22-billion parameter size is also an intentional choice. It is large enough to be powerful but small enough to be efficient for its target use cases, particularly code completion, where milliseconds matter. Internal evaluations cited in the announcement suggest it significantly reduces latency for autocomplete while maintaining quality.

However, the non-production license is a critical detail. While it encourages experimentation and research, it means teams looking to embed this in a commercial product need to carefully evaluate the terms. This is a different path from fully open-source models and represents a hybrid strategy for commercializing foundational models.

For engineers building AI-powered developer tools, Codestral is a new primitive to work with. It's a powerful, specialized engine for code tasks that can be run locally or accessed via a fast, dedicated API. The focus now shifts to how we build intelligent applications on top of these specialized models.

Sources

Mistral AI Announcement

Anthropic's New Security Tooling is a Wake-Up Call for Agent Builders

albe_sf — Wed, 27 May 2026 15:04:09 +0000

Anthropic just shipped a security guidance plugin and a self-hosted sandbox for Claude. This isn't just another incremental feature drop; it's a clear signal that the next phase of AI development is about hardening the agent stack. The takeaway is that security is moving from a manual review afterthought to a critical, automated first pass, and you should be building your systems accordingly.

what just shipped

Two new security-focused features for Claude were announced: a security guidance plugin and a self-hosted sandbox. The plugin acts as a proactive vulnerability scanner for developers as they write code. Anthropic reported using it internally and seeing a 30-40% decrease in security-related comments on pull requests, suggesting it serves as an effective lightweight first pass before a full human code review.

The second component is a self-hosted sandbox, currently in public beta. This allows Claude Managed Agents to operate within a user-controlled environment, including connecting to a user's private servers. This moves agent execution from a multi-tenant cloud environment to your own infrastructure, a significant change for handling sensitive tasks.

why this matters for your agent stack

For the past year, building agents has been an exercise in prompt engineering and orchestration logic. Security has often been reduced to a line in a system prompt like "You are a helpful assistant and you will not perform harmful actions." This approach is brittle and insufficient for production systems.

Anthropic's move signals a necessary shift from prompt-based security to infrastructure-based security. A local, user-controlled sandbox is a fundamental primitive for running agent-generated code safely. It provides a contained environment where an agent can execute tasks, interact with files, and run code without having access to the host system or network by default. This is table stakes for any serious enterprise use case.

The security plugin reframes AI-generated code. Instead of treating it as a magical, opaque output, it treats it like any other code written by a junior developer: something to be linted, scanned, and analyzed for common pitfalls before it ever gets to a human reviewer. It makes security proactive, not reactive.

integrating security analysis into the workflow

Adopting this model means building security checks directly into your agent's code generation and execution loop. The goal is to catch issues before they are ever executed. While the exact implementation of Anthropic's plugin isn't public, you can imagine how it fits into a CI/CD pipeline or a local development environment.

Here is a hypothetical configuration for a pre-commit hook that uses an AI security scanner on staged Python files. This is the kind of automated, low-friction check that the new tooling enables.

# .pre-commit-config.yaml
repos:
-   repo: local
    hooks:
    -   id: claude-security-scan
        name: Claude Security Scanner
        entry: bash -c 'claude-sec-scanner --level=high --fail-on-critical --scope=diff <your_files>'
        language: system
        types: [python]
        stages: [commit]

This approach automates the first pass of a security review. It doesn't replace a human expert, but it filters out the low-hanging fruit, freeing up senior engineers to focus on more complex architectural issues. The result is a faster, more secure development cycle.

the sandbox is the real story

The most significant part of this announcement is the user-controlled sandbox. For any organization working with proprietary code, customer data, or private infrastructure, allowing an external AI model to execute arbitrary code has been a non-starter. A self-hosted sandbox connected to private servers inverts the trust model. Instead of trusting the model provider's environment, you define the environment and its boundaries.

This unlocks the ability to build agents that can securely perform actions on internal systems. An agent could, for example, be given sandboxed access to a staging database to run diagnostics, or permission to interact with an internal code repository to refactor code, all without that data ever leaving your control.

the so-what

The frontier of AI is no longer just about building larger models with higher benchmark scores. It is increasingly about building the professional-grade tooling required to ship products that use those models, safely and reliably. Anthropic is providing a clear template for how to think about agent security.

As a builder, your focus should be shifting. The interesting work is less about novel agent architectures and more about the boring, critical infrastructure needed to run them in production. How do you containerize agent execution? How do you define fine-grained permissions for tool use? How do you automate security analysis for generated code? These are the problems that need to be solved to move agents from demos to deployed products, and this recent release shows one major lab is thinking the same way.

Sources

Anthropic Releases New Claude Sandbox, Security Guidance Plugin - SecurityWeek

Google's Gemini 3.5 Flash Isn't For Chat. It's For Agents.

albe_sf — Mon, 25 May 2026 15:01:49 +0000

Google shipped Gemini 3.5 Flash on May 19, the first model in its new 3.5 series. [4] The release is not just another incremental update; it’s a deliberate shift in strategy. Google is framing this model as 'agent-first, not chatbot-first,' a clear signal that the focus is moving from conversational quality to autonomous tool-use and coding. [4]

what shipped

Gemini 3.5 Flash was announced at Google I/O 2026 and, unlike many recent releases, went straight to general availability. [4, 15] It's accessible now for developers through the Gemini API and Google AI Studio, and for enterprise customers in the Gemini Enterprise Agent Platform. [15] This is the initial release from the Gemini 3.5 family, positioned as a workhorse model for developers building agentic systems. [13]

The model is engineered for speed and efficiency, but Google's performance claims place it above its previous-generation Pro model. [13] This combination of speed and capability is aimed squarely at enabling complex, multi-step tasks that provide tangible utility. [13]

an agent-first architecture

The most significant aspect of this release is the framing. Google's announcement emphasized the model's strengths in long-horizon tool-use and coding over traditional chat benchmarks. [4] The company claims Gemini 3.5 Flash outperforms Gemini 3.1 Pro on key benchmarks for agentic and coding tasks, including a 76.2% score on Terminal-Bench 2.1. [13]

This focus matters because it reflects the broader industry's maturation from chatbots to agents. The engineering challenge is no longer just about generating fluent text, but about building systems that can plan, execute, and self-correct over a series of actions. Google is explicitly designing and marketing this model for that purpose. It's part of a larger ecosystem push that includes tools like the Managed Agents API, which provides secure, Google-hosted environments for running custom agents. [13]

pricing for value, not volume

While the 'Flash' branding implies speed and low cost, the pricing tells a different story. At $1.50 per million input tokens and $9.00 per million output tokens, Gemini 3.5 Flash is significantly more expensive than previous Flash models like 3.1 Flash-Lite. [15] This price point is closer to the Gemini 3.1 Pro tier. [15]

This suggests Google is not competing for the cheapest possible text generation. Instead, it is pricing the model based on the value of the agentic tasks it can perform. For developers, this means 3.5 Flash is likely not the right choice for high-volume, low-complexity chat applications. It is intended for higher-value workflows where its advanced reasoning and coding capabilities can justify the cost.

Here is a simple configuration for accessing the model via the API:

import google.generativeai as genai

# Configure with your API key
genai.configure(api_key="YOUR_API_KEY")

# Set up the model
generation_config = {
  "temperature": 1,
  "top_p": 0.95,
  "top_k": 0,
  "max_output_tokens": 65536,
}

model = genai.GenerativeModel(
    model_name="gemini-3.5-flash",
    generation_config=generation_config
)

# Start a chat session
convo = model.start_chat(history=[])

convo.send_message("Your agentic prompt here...")
print(convo.last.text)

the so-what for builders

Gemini 3.5 Flash is a clear statement of direction from Google. The future of its AI platform is centered on agents that can automate complex work. For engineers and builders, this means the tools and models are now being explicitly optimized for these more sophisticated use cases.

The release of Gemini 3.5 Flash isn't just another model to evaluate. It's a signal to start thinking about your own product roadmaps in terms of agentic workflows. The core infrastructure to support these systems is coming online, and the models are being built specifically to power them.

Sources

Google just commoditized the agent stack with a single API call

albe_sf — Fri, 22 May 2026 15:03:03 +0000

Google's release of Managed Agents in the Gemini API is the signal to pay attention to this week. It packages the messy, stateful, and insecure parts of building agents into a single API endpoint, backed by a new, cost-effective frontier model, Gemini 3.5 Flash. The takeaway is that the infrastructure for running autonomous agents in secure, isolated environments is now a utility.

what actually shipped

On May 19, 2026, Google released two things that matter for builders: Gemini 3.5 Flash and the public preview of Managed Agents for the Gemini API. Gemini 3.5 Flash is positioned as a model optimized for performance on agentic and coding tasks. It's the engine.

The more significant release is Managed Agents. This is the platform. It gives developers the ability to build and deploy autonomous, stateful agents that run in secure, Google-hosted Linux sandbox environments. Instead of managing your own infrastructure for code execution and state, you can now spin up an agent via an API call. The first available general-purpose agent is antigravity-preview-05-2026, which can plan, reason, write and execute code, manage files, and browse the web inside its container.

from a local cli to a server-side platform

This release coincides with a strategic shift. Google is transitioning its popular Gemini CLI to a new Antigravity CLI. This isn't just a rename. It reflects a move from a local terminal utility to a client for a unified, server-side agent platform. The new CLI is built in Go for better performance and supports asynchronous workflows, letting you orchestrate multiple agents on complex tasks without locking your terminal.

This transition acknowledges that real agentic work involves multiple agents and shared context, which outgrew the initial CLI's scope. By unifying the backend into the Antigravity platform, improvements to the core agent harness are automatically available to the CLI, the desktop app, and the API. For developers, this means the agent you prototype in the terminal shares the same foundation as the one you deploy to production.

how you will use this

Building with this new API means focusing less on the infrastructure of agent execution. You are no longer primarily responsible for the security of running model-generated code or persisting state between long-running tasks. You define the task and the tools, and the managed agent handles the execution loop within its sandboxed environment.

A request to the new Interactions API might look conceptually like this. You provide the model, the agent definition, and the user's high-level task, and the platform manages the multi-step execution.

from google.ai import agents

# Configure the managed agent with a specific toolset and model
file_processing_agent = agents.ManagedAgent(
    name="projects/my-project/agents/file-processor",
    model="gemini-3.5-flash",
    # The platform provides the secure code execution environment
    harness="antigravity-preview-05-2026",
    tools=[
        agents.Tool(name="file_reader"),
        agents.Tool(name="data_transformer"),
        agents.Tool(name="report_generator"),
    ]
)

# Start a stateful session to perform a multi-step task
session = file_processing_agent.start_session()

# The agent plans and executes steps inside its isolated sandbox
final_result = session.execute("Analyze the quarterly sales data in /uploads, identify the top three regions, and generate a PDF summary.")

print(final_result.get_file("sales_summary.pdf"))

The key change is moving from a request-response loop that you manage to a persistent, stateful agent that you task. The antigravity-preview-05-2026 agent harness provides the core capabilities of file management, web browsing, and code execution out of the box.

the so-what for builders

The move toward managed, server-side agents is a significant abstraction layer. For the last year, building a truly autonomous agent meant wrestling with Docker containers, file system permissions, and state management. Google is now offering to handle that plumbing. This lowers the barrier to entry for shipping sophisticated agentic workflows.

This doesn't eliminate the hard problems of agentic reasoning and reliability. But it does commoditize the execution environment, letting you focus on the agent's actual logic and purpose. It's a platform bet that the future of AI development is less about prompting a model and more about directing a stateful worker.

Sources

Google just shifted the agent workflow from the cloud to the desktop

albe_sf — Wed, 20 May 2026 15:02:17 +0000

Google's latest announcements for agentic AI are more than just a new model. The release of Gemini 3.5 Flash and the Antigravity 2.0 development platform signals a shift from prompt-driven exploration to a more grounded, local-first engineering workflow for building agents. This matters because it changes the development loop from a slow, cloud-based iteration cycle to a faster, more tangible one on your own machine.

what changed: a fast model and a local orchestrator

Two main components define this shift. First is Gemini 3.5 Flash, a new model engineered for speed and efficiency in agentic workflows. It reportedly outperforms Gemini 3.1 Pro on most benchmarks while running significantly faster. This model is positioned as the high-speed engine needed for agents that must perform complex, long-horizon tasks with low latency.

The second, and more significant, piece is Antigravity 2.0. This is not just an API update; it's a standalone desktop application designed to be a central hub for agent interaction and orchestration. The platform is designed for developers to take an idea and build a production-ready application. This local-first approach allows for managing multiple agents in parallel, scheduling background tasks, and integrating directly with tools like Google AI Studio, Android, and Firebase.

why it matters: from prompting to engineering

For the last couple of years, building with large models has felt like working through a keyhole. You write a prompt, send it to a remote API, and get a response. Building agents required stringing these calls together with scripts and cloud functions. It worked, but it lacked the immediacy of traditional software development.

Antigravity 2.0 changes this dynamic. By providing a desktop application and a command-line interface (CLI), it treats agent development less like prompt engineering and more like systems engineering. The ability to orchestrate and deploy agents that can execute tasks in parallel from your local machine is a meaningful change. It encourages you to think about agentic systems as a collection of specialized workers, not a single monolithic model. This move from a simple request-response model to a managed, multi-agent system is where the real productivity gains will come from.

getting started with the new stack

Developers can access Gemini 3.5 Flash through Google AI Studio and what Google is calling Managed Agents in the Gemini API. The managed agent approach aims to remove the friction of infrastructure setup by delivering the power of the Antigravity agent harness through the API.

For local development, the Antigravity CLI provides a more direct interface. While the exact commands are still being documented, one could imagine a workflow for deploying a managed agent looking something like this:

# Fictional CLI command based on described capabilities

antigravity agents:deploy --name="daily-report-agent" \
  --model="gemini-3.5-flash" \
  --trigger="schedule --cron='0 9 * * *'" \
  --task-file="./tasks/generate_report.json" \
  --tools="google.workspace.sheets,google.workspace.docs"

This workflow, combining a powerful local CLI with cloud-managed execution, feels much closer to modern DevOps practices than the ad-hoc scripting that has characterized agent-building to date. Google AI Studio is also getting more integrated, with a new feature to export entire projects to Antigravity for local development and production deployment with a single click.

the takeaway for builders

This year's I/O updates are a clear signal that the infrastructure for building AI agents is maturing. The focus is shifting from the raw capability of a single model to the developer experience of building, testing, and deploying robust, multi-agent systems. We're moving from an era of AI that assists you to one where agents can independently navigate complex tasks across an entire workflow.

For engineers in the space, the message is clear: the tooling is catching up to the ambition. It's time to start thinking about agentic workflows not as a series of prompts, but as engineered systems that you can build and control from your own machine.

Sources

Google I/O 2026 Developer Highlights

Google is embedding an agent in Android. Your app is now an API.

albe_sf — Mon, 18 May 2026 15:03:17 +0000

Google's pre-I/O announcements confirmed what many of us have been expecting: the next major platform shift isn't a new device, but a new layer of intelligence embedded directly into the operating system. With Gemini Intelligence, the AI is moving from a chatbot you open into an agentic layer that lives underneath Android, with the ability to operate across apps to complete tasks. This isn't just a feature update; it's the beginning of a fundamental change in how we should think about building mobile experiences.

from chatbot to os layer

For the past few years, AI on mobile has been largely confined to specific apps or voice assistants. You open a chat window, you type a query, you get a response. Gemini Intelligence is designed to break that model. It's an underlying service intended to understand the context on your screen and execute multi-step, autonomous actions without you needing to switch between applications.

The ambition is to move from reactive assistance to proactive task completion. The demos describe workflows like the system finding a class syllabus in an email, extracting the required textbook titles, and then adding them to a shopping cart—a sequence that currently requires manual context switching and user input across multiple UIs. This implies a system where the OS itself becomes the primary user, and our apps become tools it can wield.

building for an agent

This shift has direct implications for developers. If the OS can operate your app on a user's behalf, your app needs to expose its capabilities in a machine-readable way. The traditional GUI is no longer the only interface that matters. You now have to design an API for an AI agent.

Features like "Create My Widget," where a user describes a widget in natural language and Gemini generates it by pulling data from different services, signal this new direction. It suggests a future where apps declare their capabilities, intents, and data sources to the OS. While the exact implementation details are not public, one could imagine a manifest or configuration file where you define your app's agent-callable functions.

{
  "ai.google.com/gemini-intelligence": {
    "version": "1.0",
    "app_capabilities": [
      {
        "intent": "com.example.shop.ADD_TO_CART",
        "entities": ["productName", "productID", "quantity"],
        "description": "Adds a specified product to the user's shopping cart."
      },
      {
        "intent": "com.example.docs.FIND_DOCUMENT",
        "entities": ["keyword", "creationDate"],
        "description": "Finds a document based on keywords or creation date."
      },
      {
        "intent": "com.example.music.PLAY_PLAYLIST",
        "entities": ["playlistName"],
        "description": "Starts playback of a named playlist."
      }
    ]
  }
}

This isn't about just handling intents as we do today. It's about exposing deeper, multi-step functionality that an autonomous agent can chain together with capabilities from other applications to fulfill a high-level user goal.

the platform reset is here

This move doesn't happen in a vacuum. It's a direct response to the broader industry's pivot towards agentic AI. By integrating these capabilities at the OS level, Google is positioning Android as a platform for agents, not just apps. This extends beyond the phone; the announcement of Android XR glasses powered by Gemini 2.5 Pro shows the ambition is for this intelligence layer to be present across different form factors.

For builders, the takeaway is clear. The era of designing self-contained app experiences is giving way to a new model. We need to start thinking about our apps as a collection of services that can be discovered and orchestrated by a higher-level agent. The apps that thrive will be the ones that expose their functionality most effectively to this new intelligence layer. This is a platform reset, and it's time to start planning for it.

Sources

Google's I/O 2024 announcements just reset the AI developer stack

albe_sf — Thu, 14 May 2026 06:56:29 +0000

Google's I/O 2024 developer keynote just laid out a new, more powerful, and integrated stack for building AI products. The key takeaway isn't just one model or tool, but a cohesive set of components—from a frontier model with a massive context window to a production-ready open source model and a backend framework to wire it all together. For builders, this means it's time to re-evaluate your stack.

a 2m token context window changes the game

The headline feature for many will be Gemini 1.5 Pro entering public preview with a 2 million token context window. This isn't an incremental update. A context window of this size allows an application to reason over entire codebases, multiple large documents, or long videos in a single pass. This fundamentally changes the architecture for context-aware applications, potentially simplifying or even replacing complex retrieval-augmented generation (RAG) pipelines that shuttle context in and out of a smaller window.

For high-frequency or latency-sensitive tasks where the full context isn't needed, Google also introduced Gemini 1.5 Flash, a lighter-weight variant optimized for speed and efficiency. The combination provides two distinct options for developers: a massive-context model for deep, complex reasoning and a faster model for more common, high-volume tasks.

open source gets a real contender with gemma 2

On the open-source front, the release of Gemma 2 is a significant development. The new family includes 2B, 9B, and 27B parameter models. The 27-billion parameter variant is particularly notable, delivering performance that surpasses models more than twice its size. This makes it a compelling choice for teams that want to self-host or fine-tune a powerful model without the infrastructure overhead of much larger models.

Gemma 2 introduces a new architecture designed for performance and efficiency, using Grouped Query Attention (GQA) for faster inference. For developers building specialized applications, the ability to fine-tune a capable open model like Gemma 2 on proprietary data is a critical advantage.

firebase genkit: a new backend for your ai stack

Perhaps the most practical announcement for day-to-day builders is Firebase Genkit, a new open-source framework for building AI-powered features in Node.js backends (with Go support coming soon). Genkit provides the plumbing to orchestrate multi-step AI workflows, manage prompts, call models, and integrate with services like vector databases.

It's designed to be model-agnostic, with integrations for Gemini, open-source models via Ollama, and vector stores like Pinecone and Chroma. This addresses a common pain point for developers: the significant amount of boilerplate code required to build production-ready AI features. Genkit also includes a local developer UI for testing, debugging, and inspecting execution traces.

Here's what a simple flow might look like in Genkit:

import { configureGenkit, defineFlow, genkit } from '@genkit-ai/core';
import { googleAI } from 'genkitx-googleai';
import * as z from 'zod';

configureGenkit({
  plugins: [
    googleAI(),
  ],
  logLevel: 'debug',
  enableTracingAndMetrics: true,
});

export const menuSuggestionFlow = defineFlow(
  {
    name: 'menuSuggestionFlow',
    inputSchema: z.object({ dish: z.string() }),
    outputSchema: z.object({ suggestion: z.string() }),
  },
  async ({ dish }) => {
    const llmResponse = await genkit.ai.generate({
      model: 'gemini-1.5-pro-latest',
      prompt: `Suggest a creative and appealing menu description for a dish called: ${dish}`,
      output: {
        format: 'text',
      },
    });

    return {
      suggestion: llmResponse.text(),
    };
  }
);

the so-what for builders

The announcements from Google I/O provide a more complete and accessible AI stack. You now have a top-tier proprietary model with a uniquely large context window, a competitive open-source model for custom deployments, and a dedicated backend framework to manage the complexity of building and deploying AI features. This combination lowers the barrier to entry for creating sophisticated, context-aware applications and provides the tooling to do it in a structured, production-ready way.

Sources

Your AI Agents Are Probably Accessing Data They Shouldn't

albe_sf — Thu, 14 May 2026 06:44:25 +0000

A new report on AI agent security confirms what many of us in the trenches have suspected: we are shipping agents with credentials and permissions that are fundamentally insecure. According to a global study, two-thirds of organizations using AI agents believe they have already accessed data beyond their intended scope. The core takeaway is that the identity and access management patterns we built for humans are failing for autonomous, millisecond-speed agents.

the detection-to-execution speed mismatch

The fundamental problem is a mismatch of timescales. The study found that it takes organizations an average of 14 hours to detect a compromised AI agent. An agent, however, operates in milliseconds. That massive gap between machine execution speed and human detection speed creates a critical window of vulnerability. A misconfigured or compromised agent can move laterally across multiple core systems using valid credentials long before a human security team even receives an alert.

This isn't a hypothetical risk. The same report indicates that 61% of organizations have had to revoke or rotate AI agent credentials due to a suspected exposure. The issue isn't that agents are 'breaking in' through novel exploits; they are being given keys to the front door. The problem is one of authorized access that isn't, and cannot be, governed effectively on a human timeline.

static credentials are a ticking time bomb

The root of this vulnerability lies in our continued reliance on static, long-lived credentials. We're treating agents like we treat a monolithic application server from 2015, handing them an API key that lives for months or years and often has broad permissions. More than four out of five organizations surveyed stated that a single compromised credential could impact multiple major systems.

This pattern is familiar to any of us who have shipped a system under pressure. You create a service account, generate a key, and embed it in a configuration file or environment variable. It looks something like this:

{
  "production": {
    "database_url": "...",
    "billing_api_key": "sk_live_a1b2c3d4e5f6...",
    "storage_service_account_key": "{\"type\": \"service_account\", ...}"
  },
  "staging": {
    "database_url": "...",
    "billing_api_key": "sk_test_...",
    "storage_service_account_key": "..."
  }
}

This is a liability. That billing_api_key is a persistent secret. If the agent's host environment is compromised, or if the agent itself has a flaw that allows it to leak its own environment, that key is now active in the wild until someone manually revokes it. Given the 14-hour average detection time, the potential damage is significant.

towards ephemeral, just-in-time identity

The report points towards a different model: ephemeral identity. Instead of issuing long-lived keys, agents should be granted credentials that are created just-in-time for a specific task and expire immediately afterward. This approach treats identity not as a static property but as a temporary, dynamically-scoped state.

Implementing this isn't trivial. It requires an infrastructure that can continuously govern agents at runtime, creating and destroying credentials on demand based on the immediate context of the agent's task. But it's the only model that closes the speed gap between machine action and human oversight. If a credential only lives for 500 milliseconds, the window for misuse shrinks dramatically.

As builders, we are moving from shipping code to shipping agents. These agents are not just tools; they are autonomous workers integrated into our core business systems. The study's finding that companies are already spending over $1 million on average to manage AI agent security issues shows the financial cost of getting this wrong. We need to stop handing them the equivalent of a master keycard and start building systems that grant access with the precision and speed that these new workers require.

Sources

The 2026 State of AI Agent Identity Security

GitHub's New Certification Is a Spec For the Modern AI Engineer

albe_sf — Thu, 14 May 2026 06:15:19 +0000

GitHub just quietly released a new role-based certification, and it's one of the highest-signal documents I've seen for where our jobs are headed. The 'GitHub Certified: Agentic AI Developer' exam is a spec sheet for the skills required to build and ship AI agents in production. It confirms the shift we've all felt: moving from prompt-level hacking to designing, supervising, and operating complex, stateful systems.

from prompt engineering to system integration

The skills listed for the new GH-600 exam are not about crafting the perfect prompt. They are about system-level concerns. The exam covers how to "configure tools, permissions, and environments for agents." This is the language of infrastructure and operations, not just conversational design. It signals that the core work is no longer just coaxing a model to produce a good output, but integrating it safely and reliably into a larger software development lifecycle.

Building a real agent requires you to think about its environment. What tools can it call? What are its permissions? Can it write to the file system? Does it have network access? These aren't model problems; they are application security and architecture problems. The certification's focus here tells you that building a secure, contained environment for your agent is now a baseline competency.

# Example: Running an agent in a constrained environment
# This isn't from the certification, but illustrates the principle.

podman run --rm -it \
  --security-opt no-new-privileges \
  --cap-drop=ALL \
  --network=none \
  -v ./agent-workspace:/app/workspace:Z \
  my-agent-image:latest \
  --instructions="Analyze the data in /app/workspace/input.csv and write a report to /app/workspace/output.md"

Treating agents as tier-one applications that require consistent, governed environments is the new standard. This is a world away from tweaking a prompt in a playground.

managing state and long-running execution

Another key domain in the certification is the ability to "manage memory, state, and long-running execution." This is the single biggest differentiator between a simple AI-powered feature and a true agent. Agents are not stateless functions. They have goals, they have memory of past actions, and they operate over time. This introduces a host of engineering challenges that are familiar to anyone who has built distributed systems.

How does your agent persist its state? If the process dies, can it resume its work? How do you handle memory growth in a process that might run for hours or days? These are the questions that separate toy projects from production systems. The fact that GitHub is testing for this shows that the industry expects developers to have answers. You are no longer just a model user; you are the operator of a persistent, autonomous process.

evaluation, orchestration, and human oversight

The final piece of the puzzle is about reliability and control. The certification requires developers to know how to "evaluate and improve agent performance," "coordinate multi-agent workflows," and "implement guardrails and human-in-the-loop systems."

This is the senior-level skillset. Evaluating an agent isn't about running a benchmark once. It's about continuous monitoring and creating feedback loops for improvement. Coordinating multi-agent systems is an architecture problem, requiring you to break down complex tasks and manage communication between specialized agents. And most critically, implementing guardrails and HITL systems is an admission that these systems are not perfectly reliable. The most important skill is knowing how to design for failure and ensure a human can intervene when the agent gets lost or goes off the rails.

The takeaway here is clear. The era of casual experimentation is over. The skills being codified by this certification are about building robust, observable, and controllable AI systems. It's a significant shift in what it means to be a developer in the agentic era. This exam isn't just a way to get a new badge; it's a study guide for staying relevant.

Sources

New GitHub Certified: Agentic AI Developer - Microsoft Community Hub

Anthropic's 'Dangerous' AI and the Hard Reality of Auditing Code

albe_sf — Wed, 13 May 2026 19:06:59 +0000

Anthropic's latest model, Claude Mythos, was internally deemed too 'dangerously good' at finding security vulnerabilities for a public release. But when tested against the battle-hardened curl codebase, it exposed the gap between marketing hype and engineering reality, providing a critical lesson for anyone building with AI security tools. The takeaway is not that these models are useless, but that their output is a signal that still requires rigorous human verification.

what is claude mythos

Anthropic announced that an internal AI model, Claude Mythos, demonstrated a powerful, emergent capability for discovering and exploiting software vulnerabilities. The capabilities were reportedly so advanced that the company restricted access, providing it only to a select group of organizations to allow them to patch critical flaws before a potential wider release. The model allegedly found thousands of high-severity vulnerabilities across major operating systems and browsers. This raised an immediate question for builders: are we on the verge of fully automated security auditing, or is this another case of over-indexing on a model's potential?

the curl test case

The answer came from a real-world test. Daniel Stenberg, creator of curl, was granted indirect access to a Mythos analysis of his project's 176,000 lines of C code. The model returned five 'confirmed security vulnerabilities'.

The result after human review was less dramatic. Of the five findings, four were false positives. One was a legitimate, low-severity bug. This outcome on a mature, heavily scrutinized project like curl is telling. It suggests that while AI can parse massive codebases and identify potential issues at scale, its signal-to-noise ratio is a critical variable. An AI's declaration of a 'confirmed' vulnerability is not the end of an investigation; it is the start.

ai output is a signal, not a verdict

For engineers integrating AI into security pipelines, this is the core lesson. These models are powerful pattern-matchers, but they lack the true context and world model of a seasoned security researcher. They will flag code that looks like a known vulnerability pattern, even when idiomatic usage or surrounding logic renders it harmless. A report from a model like Mythos is not a finished list of CVEs. It's a prioritized list of areas for human experts to investigate.

Your internal tooling and workflow must reflect this. When an AI flags a potential issue, the process should treat it as an assertion to be validated, not a fact to be remediated. Imagine an automated report from a similar tool:

{
  "vulnerability_id": "AI-GEN-004-RCE",
  "file_path": "/src/app/utils/parser.c",
  "line_number": 242,
  "severity": "Critical",
  "cwe": "CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')",
  "confidence": "High",
  "description": "The function `parse_user_input` uses `strcpy` to copy a user-provided buffer `input_buffer` to a fixed-size local variable `dest_buffer`. This is a potential buffer overflow vulnerability if the source buffer exceeds the destination size.",
  "recommendation": "Replace `strcpy` with `strncpy` or `snprintf` to prevent buffer overflows by specifying the maximum number of bytes to copy."
}

This looks plausible. But without a human checking if input_buffer is sanitized or length-checked upstream, acting on this report alone is premature. The value is not in the AI's conclusion, but in its ability to direct limited human attention to line 242.

what this means for builders

The Mythos-on-curl episode is a necessary recalibration. AI will undoubtedly change security auditing, but it will not eliminate the need for human expertise. It transforms the task from finding a needle in a haystack to sorting a pile of needles and pins. For builders, the mandate is clear: build systems that leverage AI for signal generation, but design workflows that depend on human experts for verification. Do not ship a system that blindly trusts an AI's security assessment. The real danger isn't a rogue AI hacker, but an engineering team that outsources its judgment to one.

Sources

Anthropic

Anthropic on AWS is Not What You Think

albe_sf — Wed, 13 May 2026 19:01:56 +0000

Anthropic's release of the Claude Platform on AWS is the most significant infrastructure shift for builders since model-specific SDKs. It’s not another managed model offering via Bedrock; it’s Anthropic’s full, cutting-edge API stack deployed on AWS infrastructure, accessible through native AWS endpoints. This solves the primary enterprise adoption hurdles—security, billing, and procurement—at the source, making Claude a legitimate alternative to Azure OpenAI for serious AWS shops.

what actually changed

On May 11, Anthropic announced the Claude Platform on AWS. Unlike the existing Amazon Bedrock integration, which offers specific Claude models as part of a multi-vendor catalog, this is a dedicated, Anthropic-managed environment running on AWS hardware. For builders, this means you get the best of both worlds: direct access to Anthropic's complete, up-to-the-minute feature set—including the full Messages API, the Files API, Managed Agents, and tool use—while operating within your existing AWS environment.

The key differences are in the plumbing. You interact with it via native AWS endpoints. Authentication is handled by AWS IAM, not by a separate Anthropic API key you have to manage and rotate. Most importantly, billing is consolidated directly into your AWS account. This isn't a minor convenience; it's a fundamental change that removes massive organizational friction.

the enterprise integration tax

For any large organization, adopting a new AI vendor is a procurement and security nightmare. It requires new contracts, new security reviews for data handling, and a separate billing pipeline that finance has to approve. While Bedrock partially solved this by putting various models under a single AWS bill, it often lags behind the native provider's API in terms of features and model availability. You get the convenience, but you sacrifice access to the latest capabilities.

The new platform collapses this trade-off. A team can now use their existing AWS enterprise agreement, leverage pre-approved IAM roles and policies for access control, and have all of their Claude usage appear as a line item on their monthly AWS bill. The CISO is happy because access is governed by the same robust IAM system used for everything else. The finance department is happy because there isn't a new vendor to onboard. And you, the builder, are happy because you get direct access to the latest from Anthropic without fighting a six-month procurement battle.

Here’s what invoking a model on this new platform might look like. Note that you're using an AWS SDK like boto3 to call an Anthropic-specific service endpoint, not the generic Bedrock one.

import boto3
import json

session = boto3.Session(profile_name='my-aws-profile', region_name='us-east-1')

# Note the service name is 'anthropic', not 'bedrock-runtime'
client = session.client('anthropic')

response = client.invoke_model(
    modelId='claude-opus-4-7',
    contentType='application/json',
    accept='application/json',
    body=json.dumps({
        "anthropic_version": "bedrock-2023-05-31",
        "max_tokens": 2048,
        "messages": [
            {
                "role": "user",
                "content": "Explain the difference between Anthropic on AWS and Claude on Bedrock."
            }
        ]
    })
)

response_body = json.loads(response.get('body').read())
print(response_body['content']['text'])

This looks familiar, but the service_name and modelId string are doing all the work, routing your request through AWS's front door to Anthropic's dedicated infrastructure.

the so-what for builders

This move signals a new phase in the AI platform wars. It’s no longer just about having the best model; it’s about having the most seamless enterprise deployment story. By embedding its native platform inside AWS, Anthropic is meeting enterprise clients where they are, offering a path of least resistance to adopt its latest technology. It’s a direct challenge to the tight integration of OpenAI models within the Azure ecosystem.

For engineers and technical leads inside companies heavily invested in AWS, the decision of which frontier model to use just got a lot more interesting. The excuse that "it's not integrated with our cloud" is gone. The friction is gone. Now, the choice between Claude and its competitors can be based purely on capability, performance, and cost—as it should be.

Sources

Claude API Docs - Changelog