DEV Community: Chinyere John-Nnah

From Chatbots to Coworkers: What Google Cloud Next '26 Means for Developers

Chinyere John-Nnah — Mon, 27 Apr 2026 09:14:39 +0000

A developer's breakdown of everything that matters from the Google Cloud Next '26 keynote and what to build with it next.

This is a submission for the Google Cloud NEXT Writing Challenge

For the last two years, every AI keynote has felt like a magic show "look at this thing that can write a poem."

Google Cloud Next '26 was different.

The magic show is over.

The actual machinery is here.

Thomas Kurian and Sundar Pichai opened the keynote with a single, quietly disruptive idea: we're done with chatbots that talk. The new era is about agents that do: systems with persistent reasoning and autonomous execution that can hold context for days, plan multi-step workflows, and verify their own work.

2024 and 2025 asked, "Can we build an agent?", 2026 asks, "How do we manage thousands of them?"
For developers especially those of us building at the intersection of frontend, data, and distributed systems this is the most consequential Next in years. Here's what actually shipped, what it means, and where to start.

The Agentic Enterprise Blueprint

Kurian framed the entire conference around one concept: The Agentic Enterprise. The pitch is that the org chart of the future doesn't just have humans it has digital teammates working alongside them, and every employee becomes a builder who orchestrates a swarm of agents instead of executing tasks manually.

The strategy rests on two ideas:

Persistent reasoning: Unlike a chatbot that forgets you the moment you close the tab, agents maintain state across days. They can pause, wait for an external trigger, resume, and finish the job like a human colleague would.
Owning the full stack: Custom silicon (TPUs), the data layer (BigQuery), and the UX (Workspace) all built to work together. Kurian's not-so-subtle jab at competitors: they "hand you the pieces, not the platform."

Whether you buy that framing or not, the takeaway is clear Google is betting that vertically integrated infrastructure wins the agent era. And the rest of the keynote was them showing receipts.

Gemini Enterprise Agent Platform (The Vertex AI Rebrand)

The biggest rebrand of the event: Vertex AI is now the Gemini Enterprise Agent Platform. It's no longer a model garden it's a unified environment for the entire agent lifecycle, from prototype to production to post-deployment monitoring.

The core features that make up the platform:

Agent Studio: A low-code, visual builder inside Workspace. Defines agent goals in natural language, wire up tools, and ship.
Agent Development Kit (ADK) v1.0: The pro-code framework for the rest of us. Supports Python, JavaScript, Java, and Go, and lets you build graph-based agent networks (think LangGraph, but native).
Agent Identity: Every agent gets a unique cryptographic ID. Every action it takes is auditable. This is huge for compliance finally, a real answer to "Which agent did that, and why?"
Agent Gateway: Air traffic control for your agent fleet. Enforces policy, manages traffic, and uses Model Armor to block prompt injection attacks at the edge.
A2A (Agent-to-Agent) Protocol: A standardized handshake that lets a Google-based agent securely delegate tasks to a Salesforce or SAP agent. Cross-vendor interoperability, finally.
Agent Runtime: A re-engineered execution environment built for long-running agents. Your agent can fire off a task, wait three days for an external API to respond, and pick up exactly where it left off.
Agent Simulation & Evaluation: Stress-test your agent against thousands of simulated user interactions before it ever sees production. Catches logic drift before your users do.

What's Actually Shipping

If Day 1 sold the strategy, Day 2 showed the developer loop underneath it. The framing: build an agent system that plans a marathon for 10,000 runners through the Las Vegas Strip, using three agents — a planner (generates routes), an evaluator (scores them against constraints), and a simulator (runs the route end-to-end). The entire codebase and every demo were open-sourced as a GitHub repo plus Codelabs. The platform was anchored around four pillars and each pillar got its own demo segment.

🛠️ Build

ADK (Agent Development Kit): the code-first framework, supporting Python, JavaScript, Java, and Go, with a new graph-based runtime for defining how agents collaborate.
Agent Studio: the low-code counterpart. Define agent goals in natural language, wire up tools, publish.
Managed MCP: Google now hosts the Model Context Protocol layer, eliminating a week of self-hosting plumbing.
Agent Registry: described as "the DNS of your internet of agents." Auto-indexes every agent deployed to Agent Runtime, making them discoverable and governable.
Agent Marketplace: third-party agents from Atlassian, Box, Lovable, Oracle, ServiceNow, Workday, and more, deployable directly from Gemini Enterprise.
Model Garden: explicitly supports Claude, Gemini 3.1 Pro, Gemini 3.1 Flash, and others. Pick your model, swap when needed.

📈 Scale

Serverless Agent Runtime: handles long-running state across days. Agents pause, wait for an external trigger, and resume without losing context.
A2A (Agent-to-Agent) Protocol: the cross-vendor handshake. Created by Google, donated to the Linux Foundation. A Google agent can hand work to a Salesforce or SAP agent without brittle API code.
A2UI (Agent-to-User Interface): an open standard letting agents generate dynamic UI components instead of returning plain text. The marathon simulator's UI (Angular + 3D rendering of the Las Vegas Strip) was assembled live by the agent itself, not hardcoded.

The evaluation layer is now first-class. A separate model as a judge scores outputs across deterministic criteria (a marathon is exactly 26 miles 385 yards / 42.195 km) and non-deterministic ones (community impact, route quality). Agents auto-generate their evaluation UIs from the schema of their own outputs the path from "fragile, unpredictable agentic loops" to "a rigorously evaluated network of experts."

🔒 Govern

The framing here was sharp: stop telling developers to "shift left" (own everything earlier) and start letting them "shift down" push the responsibility into the platform layer.

Agent Identity: every agent gets a unique, immutable cryptographic credential. Every action is auditable back to a specific agent instance.
Agent Gateway: air traffic control for the agent fleet. Understands MCP and A2A protocols. Uses IAM policies to scope which sources can invoke agent actions.
Agent Policies: configurable guardrails. An agent permitted to read from BigQuery but blocked from triggering spend over a threshold.
Model Armor: inline protection against prompt injection, tool poisoning, and sensitive data leakage at the gateway layer.

⚙️ Optimize

The end-to-end debugging story for when an agent breaks in production:

Agent Runtime trace view: surfaces exactly where the reasoning chain or tool call failed.
Gemini Cloud Assist Investigation: takes a natural-language query and explores logs and events to surface the failing component down to a specific line.
Antigravity IDE: powered by Gemini 3, connected via MCP. Proposes parameter-level remediations. In the demo: a missing token_threshold on the event-compaction config that was silently truncating the agent's working memory.
Wiz Green Agent inside Claude Code with Opus: Wiz now scans both agent code and infrastructure, and the same remediation surface runs inside Anthropic's IDE on Anthropic's model. An explicit multi-vendor signal: security tooling travels with the developer, regardless of stack.

What it means for you

Day 1 sold the agentic enterprise. Day 2 laid out the loop you'll actually live in: build → scale → govern → optimize. Three things to actually act on:

The evaluation layer is the part most teams will sleep on and regret. Judge models, deterministic + non-deterministic checks, auto-generated eval UIs: this is where agentic systems silently fail today, and it's now baked in.
A2A and A2UI are open standards, not Google-only. The Linux Foundation handoff matters. Don't dismiss them as vendor lock-in.
Antigravity is the bet to watch. It's Google's claim on what "agentic developer experience" means in 2026 and the multi-vendor Wiz/Claude Code integration shows the surface area is intentionally portable.

The AI Hypercomputer: 8th-Gen TPUs

To run millions of persistent agents in production, you need silicon designed for the workload. Google's answer is the 8th-generation TPU and crucially, it's a dual-chip strategy that splits training and inference into purpose-built hardware. This is Google explicitly attacking the "memory wall" that's been bottlenecking large models.

What it means for you: Cloud developers now have a dedicated inference engine in the TPU 8i. The economics of running a complex, multi-turn agent for every single user in your app just got real. The "one agent per user" pattern was a fantasy in 2024 at these unit costs, it becomes a default architecture.

Agentic Data Cloud: From Passive Storage to System of Action

"Reasoning without context is just a guess" that's how Karthik Narain, Google Cloud's Chief Product and Business Officer, framed the thesis behind the Agentic Data Cloud, which reimagines data as something agents act on, not just query.

Three pieces matter most:

Knowledge Catalog: Replaces traditional metadata catalogs. It auto-maps the business meaning of data across your entire estate (Google Docs, Slack, SQL warehouses, the lot). Your agents now understand that "ARR" in finance means the same thing as "Annual Recurring Revenue" in your CRM.
Memory Bank: Long-term memory for agents. Where chat sessions used to forget you in five minutes, Memory Bank persists user preferences and project history across months of interaction.
Managed MCP: You no longer host your own Model Context Protocol servers. Google now manages the connective tissue between Gemini and your databases, which kills a whole class of plumbing work.

Agentic Defense: The Wiz Integration Goes Live

With the $32 billion Wiz acquisition fully closed, Google rolled out a "Cyberforce" of defensive agents. The pitch: stop reacting to alerts, start hunting threats autonomously.

Threat Hunting Agent: Proactively scans for novel attack patterns that signature-based firewalls miss.
Detection Engineering Agent: Writes and deploys new security rules in real time as threats evolve. The rule that catches tomorrow's attack didn't exist yesterday.
Wiz "Red Agent": An autonomous penetration tester that constantly probes your cloud infrastructure for unlocked doors before real attackers find them.

The Agentic Taskforce: Companies Already Shipping

The keynote closed with proof points companies actually getting ROI from agents in production right now. The pattern across all of them: agents handling the long-tail repetitive work, humans focusing on judgment calls. A few standouts worth zooming in on:

KPMG's Tax Swarms are the clearest A2A protocol use case in the wild; their tax agent talks directly to a client's audit agent.
Virgin Voyages going from 6-hour rebookings to 11 minutes is the clearest "Agent Runtime + long-running state" example.
Goldman Sachs querying 10,000+ page filings in minutes is what the Knowledge Catalog actually unlocks at enterprise scale.
Walmart and Bosch prove agents work at the edge — store floors and factory floors, not just data centers.

So What Should You Actually Do With This?

If you take one thing from Next '26, take this: the agent era isn't a future bet, it's a current one. The infrastructure is shipping, the protocols are standardizing, and Fortune 500s are already in production.

Concretely, here's where to start depending on your stack:

Frontend devs: Play with Agent Studio. The low-code builder is the fastest way to feel what an agentic UX is even supposed to look like.
Backend / data folks: The Knowledge Catalog and Memory Bank are the most underrated announcements. Try wiring an agent to your own data with Managed MCP and skip a month of plumbing.
Infra / platform engineers: Watch the TPU 8i pricing closely. The economics of "an agent per user" change your architecture decisions for the next two years.
Security teams: Don't wait. Threat Hunting and Red Agent are the kind of tools your blue team will quietly start depending on by Q3.

The chatbot era taught us how to prompt. The agent era is going to teach us how to delegate. The developers who figure that out first are going to look like wizards by the end of 2026.

If you watched the keynote too, what stood out for you? Drop a comment especially if you've started prototyping with the ADK. I'm curious what's actually working vs. what's still demo-ware.

I Automated 90% of The Ethers.js v5 v6 Migration using Codemods and AI

Chinyere John-Nnah — Sat, 18 Apr 2026 13:29:53 +0000

Ethers v6 dropped a breaking change on every project that touched BigNumber, utils, or providers — which is basically every DeFi frontend ever written. The migration guide listed over 40 breaking changes. Some were simple renames. Some required understanding whether a variable was a BigNumber before deciding what to do with it. Doing this by hand across 31 files is exactly the kind of work that makes engineers quit. I built a codemod pipeline to handle the mechanical ones automatically — and wrote AI prompts for the rest.

Why ethers v5 → v6 is painful

BigNumber is gone. In v5, every numeric value coming off a contract was a BigNumber instance with its own method API: .add(), .mul(), .toNumber(), .toHexString(). In v6, native JavaScript bigint takes over. That's a good change long-term, but it means every arithmetic expression, every comparison, every conversion in your codebase needs to change — and if you mix a bigint with a number by accident, you get a runtime TypeError with no static warning unless you're fully strict about types.

The entire ethers.utils namespace was flattened. In v5, utility functions lived under ethers.utils: ethers.utils.parseEther, ethers.utils.keccak256, ethers.utils.arrayify. In v6, they're all top-level on the ethers object. That's 15+ functions to find and rename across your codebase, and three of them got renamed too: arrayify became getBytes, hexZeroPad became zeroPadValue, and splitSignature became Signature.from().

Providers moved and Web3Provider is gone. The entire ethers.providers sub-namespace was dissolved. new ethers.providers.JsonRpcProvider(url) is now new ethers.JsonRpcProvider(url). new ethers.providers.Web3Provider(window.ethereum) — the line in basically every frontend DeFi app — is now new ethers.BrowserProvider(window.ethereum). StaticJsonRpcProvider was merged into JsonRpcProvider. If you have TypeScript type annotations using ethers.providers.X, those need to change too.

My approach: codemods + AI

The insight that made this tractable is recognizing that these changes fall into two completely different categories.

Mechanical renames have one right answer. ethers.utils.parseEther always becomes ethers.parseEther. new ethers.providers.Web3Provider(x) always becomes new ethers.BrowserProvider(x). These changes are safe to automate because the transformation is deterministic — given the same input, there's only one correct output. A codemod handles these at AST level: it parses the source into a syntax tree, finds the exact nodes to change, replaces them, and prints the result with formatting preserved. No regex, no string munging, no accidental replacements inside comments or string literals.

Semantic changes require context. When you see someVar.toNumber(), the right migration depends on where someVar came from. If it's the direct result of BigNumber.from(x), you can mechanically replace it with Number(BigInt(x)). But if it came from a contract call two scopes away, you need to understand the data flow, check whether the value could exceed Number.MAX_SAFE_INTEGER, and decide whether Number(), parseInt(), or staying with bigint is right. No static tool makes that call correctly 100% of the time. AI does, given enough context.

The combination is the only approach that scales. Codemods alone leave the semantic cases as silent bugs. AI alone on a 31-file codebase is slow and expensive. Together, you get deterministic correctness where it's possible and targeted AI review where it's necessary.

The 8 transforms I built

rename-utils — Lifts all 17 ethers.utils.* functions to the top-level namespace. Handles both import * as ethers and import { utils } styles, rewrites the import declaration, and covers the two structural changes.

// before
const amount = ethers.utils.parseEther('1.0');
const bytes  = ethers.utils.arrayify(hexString);

// after
const amount = ethers.parseEther('1.0');
const bytes  = ethers.getBytes(hexString);

bigNumber-to-bigint — Replaces BigNumber.from(x) with BigInt(x) and rewrites instance methods on statically-confirmed BigNumber variables to native operators. Uses a conservative two-phase approach: method rewrites run first to handle chains like BigNumber.from(x).toNumber() atomically, then standalone BigNumber.from() nodes are replaced.

// before
const fee = BigNumber.from('1000000');
const total = fee.add(BigNumber.from('500000'));

// after
const fee = BigInt('1000000');
const total = fee + BigInt('500000');

rename-providers — Renames all 7 provider classes and updates TypeScript type annotations. StaticJsonRpcProvider merges into JsonRpcProvider. Handles destructured import { providers } by injecting the specific v6 names that were actually used.

// before
const provider = new ethers.providers.Web3Provider(window.ethereum);
let p: ethers.providers.JsonRpcProvider;

// after
const provider = new ethers.BrowserProvider(window.ethereum);
let p: ethers.JsonRpcProvider;

gasPrice-to-feeData — Rewrites await provider.getGasPrice() by replacing the entire AwaitExpression node. This means the parentheses around the await are handled automatically by recast's printer based on operator precedence — I don't insert them manually.

// before
const gasPrice = await provider.getGasPrice();

// after
const gasPrice = (await provider.getFeeData()).gasPrice;

rename-constants — Replaces all ethers.constants.* accesses with their v6 equivalents. Named constants become top-level properties (AddressZero → ZeroAddress, MaxUint256 → MaxUint256). The four numeric constants become native bigint literals since BigNumber is gone.

// before
const zero = ethers.constants.AddressZero;
const max  = ethers.constants.MaxUint256;
const one  = ethers.constants.One;

// after
const zero = ethers.ZeroAddress;
const max  = ethers.MaxUint256;
const one  = 1n;

rename-contract-methods — Rewrites the four v5 contract method bucket patterns. In v5, less-common operations were accessed via intermediate buckets (callStatic, estimateGas, populateTransaction, functions). In v6 they moved to direct methods on the contract function itself.

// before
const result = await contract.callStatic.balanceOf(addr);
const gas    = await contract.estimateGas.transfer(to, amount);

// after
const result = await contract.balanceOf.staticCall(addr);
const gas    = await contract.transfer.estimateGas(to, amount);

rename-provider-methods — Handles three provider/transaction method changes. sendTransaction was renamed on the Provider side to broadcastTransaction (Signer's sendTransaction is unchanged — the transform adds a TODO so you can verify which one it is). parseTransaction and serializeTransaction became Transaction.from().

// before
await provider.sendTransaction(signedTx);
const tx = ethers.utils.parseTransaction(bytes);

// after (with TODO comment added for sendTransaction)
await provider.broadcastTransaction(signedTx);
const tx = ethers.Transaction.from(bytes);

update-imports — Runs last. Removes deprecated specifiers (utils, BigNumber, providers, constants) from import { ... } from 'ethers' declarations once the other transforms have finished introducing their replacements. If no specifiers remain, it removes the entire import statement.

// before
import { utils, BigNumber, providers, Contract } from 'ethers';

// after
import { Contract } from 'ethers';

Does it actually work on real code?

I ran the pipeline against Uniswap/v3-periphery, which is on ethers ^5.0.8 — a production-grade codebase I had no hand in writing.

Metric	Result
Files scanned	31
Files automatically migrated	28
Lines changed	502 lines (231 insertions, 271 deletions)
Files flagged for AI review	3
Automated coverage	90.3%
False positives	0

I verified every change with git diff before counting. The 0 false positives claim I validated separately: running the same pipeline against scaffold-eth-2 (already on ethers v6) produced 0 changes and 0 TODOs.

One honest limitation: the codemod only tracks direct imports from 'ethers'. If your project wraps ethers behind an internal utility library or re-exports it from an index file, the transforms won't fire. I decided false negatives (missed cases) are safer than false positives (broken code), so the conservative approach was the right call.

What the AI handles

The 3 flagged files — PairFlash.spec.ts, snapshotGasCost.ts, TickLens.spec.ts — all had the same pattern: BigNumber method calls on variables that came from contract return values or function parameters. The codemod added a comment to each one:

// TODO(ethers-codemod): verify this BigNumber method call and migrate manually
const result = returnedFromContract.toNumber();

For these, I used this prompt:

I'm migrating from ethers.js v5 to v6. In v6, BigNumber is replaced by native bigint.
The codemod flagged this code because it couldn't statically confirm the receiver is a
BigNumber. Please help me migrate it:

[paste the flagged code block]

Key rules:
- .toNumber() → Number(value) if the bigint fits safely in a JS number
- .toHexString() → value.toString(16)
- .add(x) → value + x  (both sides must be bigint — check that x is also bigint)
- Values returned from contract calls are already bigint in ethers v6, no conversion needed
- If a value could exceed Number.MAX_SAFE_INTEGER, keep it as bigint

Three files, one prompt each, done in under ten minutes.

How to use it right now

npx ts-node src/run.ts ./your-project

The runner finds all .ts, .tsx, .js, .jsx files, skips anything with no ethers imports, runs all 5 transforms in the correct order, and prints a summary with per-transform change counts and a list of any files that need AI review.

Source and full documentation: https://github.com/Chinyereee/ethers-v5-to-v6-codemod

Conclusion

28 files migrated automatically. 502 lines changed with zero false positives. 3 files handed off to AI with precise, targeted prompts. Total time to run: under 30 seconds.

This is what software maintenance should look like. Mechanical changes — the ones with one right answer — get automated at the AST level, fast and correct. Human judgment gets reserved for the semantic changes that actually need it: the data flow questions, the precision questions, the "what did the original author intend" questions that no static tool can answer reliably. The codemod tells you exactly which files those are and why. The AI handles them in minutes.

The weekend you were dreading becomes an afternoon. Most of it spent verifying a diff, not writing one.

A note on the test repo choice: I tried scaffold-eth-2 first. It was already on v6 — which was actually useful, it confirmed the codemod produces zero changes on modern code. But I needed a real v5 target. Uniswap v3-periphery is widely known, actively maintained, and represents how real protocols actually use ethers. It felt like the honest benchmark to report against.