Forem: albe_sf

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

Hello world

albe_sf — Tue, 12 May 2026 22:27:45 +0000