DEV Community: Chinyere John-Nnah

From Playground to Code: Three Versions of One Prompt in Google AI Studio

Chinyere John-Nnah — Thu, 07 May 2026 12:32:44 +0000

A few weeks ago I wrote a breakdown of Cloud Next '26 for developers Link to keynote and closed it with a line to other frontend devs: play with Agent Studio. I took my own advice.

I tried to take my own advice and faced a technical issue with Google Cloud's new prepayment wall and pivoted. This post is what happened next: spending an hour in Google AI Studio, iterating one prompt three times and finishing with Typescript I could drop into a Next.js project. No billing required, no Cloud project. Just a Google account.

If you're stuck at the same prepayment wall, or if you just want to know what the Gemini playground actually looks like before committing to anything paid, this is for you.

What AI Studio actually is

A quick note for anyone confused by the naming, because Google has not made this easy.

There's Gemini Enterprise, which lives in Cloud Console behind a billing account; that's the enterprise stack I wrote about in the keynote piece.

Then there's Google AI Studio at aistudio.google.com, which is the public-facing Gemini playground. Sign in with any Google account. No card, no project, no setup.

Feature	Google AI Studio	Gemini Enterprise
User Type	Prototypers, Developers	Data Scientists, Enterprise
Complexity	Low (Simple)	High (Advanced)
Purpose	Experimentation	Production & Scaling
Cost	Generous Free Tier	Usage-based
Security	Standard	Enterprise-grade (GCP)

For this walkthrough, I used Gemini 3 Flash Preview which is the cheaper, faster sibling to Gemini 3 Pro. Flash Preview is the right default when you're iterating because the latency difference matters when you're running the same prompt five or six times in a row.

The input I gave it

I wanted to see how the same prompt evolved across three versions. One task, three system prompts, same user input. The point wasn't to land at a perfect prompt on the first try; it was to show what changes when you take prompt iteration seriously instead of writing one prompt and hoping.

I used the same input for all three versions:

We need a hero section for our SaaS landing page. The product is a project management tool for small design agencies. Should feel premium
but approachable. Main goal is to get visitors to start a free trial.

This is roughly how a brief actually arrives in a frontend dev's inbox: vague, opinion-loaded, half a sentence longer than it needs to be. The whole point of running it through an LLM is to turn that vagueness into a structured spec a developer can build from. So that's what I tried to make the model do.

V1: The naive prompt

I adjusted the temperature from 1(default) to 0.7 and I gave sytem instructions.

System instructions:

You are a helpful assistant. Generate a component spec based on the design brief the user provides.

The kind of system prompt anyone would write on the first try. No structure, no constraints, just "do the thing."

The output came back more beautifully than expected. An editorial document with visual guidelines, color palette with hex codes, typography choices, three headline options, a copy strategy section and even a Typescript interface for HeroProps inside the markdown.

It's genuinely impressive. And that's the trap.

V1 succeeded as a document.

It did not succeed as a spec.

There's a difference, and that difference is the whole reason this post exists.

If I want to feed this output into a code generator, populate a Notion database, or render fields dynamically in a React form, I can't. I'd have to manually parse the markdown, find the HeroProps interface, scrape the hex codes out of the prose, copy the headline options into an array. The model wrote content for humans, when what I needed was data for machines.

Token cost: 208. Cheap. Fast. Useless if you want to do anything programmatic.

V2: Asking for structure

If V1 returned prose because I asked for prose, maybe V2 returns data if I ask for data. With temperature still set at 0.7 I replaced system instructions.

New system instructions:

You are a frontend architect helping translate design briefs into
component specifications. When given a design brief, return a
structured component spec with the following information:

Component name

Purpose

Suggested props

Accessibility considerations

Suggested Tailwind classes for key elements

Return your response as JSON.

The output came back as JSON. Real JSON. Valid JSON.

Look at field names like component_name, purpose, suggested_props, primaryAction, productScreenshotUrl, trustBadges. Some snake_case, some camelCase. Some are top-level, some are nested.

This looks better. But there's a quieter problem hiding in plain sight. I didn't define the schema. The model did.

I ran the prompt again. "DesignAgencyHero" in the first prompt became "CreativeStudioHero". Also, suggested props like "headline" became "title" and "subheadline" became "description" etc. New fields appeared. Old ones vanished.

The output is JSON, but it's JSON I can't trust to stay the same shape across calls. And if the shape isn't stable, I can't write code that consumes it.

Better than V1, still not deployable.

V3: Structured outputs

This is where AI Studio earns its keep.

In the parameters panel, there's a toggle called Structured outputs. Flip it on, and AI Studio gives you a schema editor where you define exactly what comes back. Field names, types, what's required, what's optional, nested objects, all of it. The model has to conform to the shape you specified.

Here's the schema I used:

{
  "type": "object",
  "properties": {
    "componentName": { "type": "string" },
    "purpose": { "type": "string" },
    "props": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "name": { "type": "string" },
          "type": { "type": "string" },
          "required": { "type": "boolean" },
          "description": { "type": "string" }
        },
        "required": ["name", "type", "required", "description"]
      }
    },
    "accessibilityNotes": {
      "type": "array",
      "items": { "type": "string" }
    },
    "suggestedTailwindClasses": {
      "type": "object",
      "properties": {
        "container": { "type": "string" },
        "heading": { "type": "string" },
        "subheading": { "type": "string" },
        "ctaButton": { "type": "string" }
      }
    }
  },
  "required": ["componentName", "purpose", "props", "accessibilityNotes", "suggestedTailwindClasses"]
}

Defining this schema took longer than writing the prompt. That's the honest tradeoff: structured outputs aren't free, and they aren't fast. You're doing real design work upfront in exchange for output you can actually consume.

The system instruction got simpler:

You are a frontend architect helping translate design briefs into
component specifications. Return a complete, well-considered component
spec based on the design brief provided.

I no longer needed to list the fields in the system prompt. The schema does that job now.

To show the payoff clearly, I ran V3 three times with the same input but different temperatures: 0.2, 0.7, and 0.9.

Temperature 0.2: conservative settings. The model returns a tight, safe spec.

Component name: AgencyHeroSection. Compact descriptions. Predictable choices.

Temperature 0.7: middle ground.

Component name: PremiumStudioHero. Richer descriptions. More distinctive framing.

Temperature 0.9: turn the creativity dial up.

Component name: DesignAgencyHero. The most evocative copy of the three. The descriptions reach for words like "craft" and "flow."

Three runs. Three different creative interpretations. The schema stayed identical across all three. Same fields. Same types. Same nesting. The model varied the content. It could not vary the shape.

That's the entire point. Structured outputs separate the parts of the response you want stable from the parts you want creative. Field names and structure stay locked. Tone, copy, and specifics breathe within those constraints.

A note on cost: V3 at temperature 0.9 burned 9,357 tokens, compared to V1's 208. Schema definitions are part of the prompt the model sees, and a detailed schema is a long prompt. Structured outputs are powerful, but they aren't cheap. For high-volume calls, this matters.

From Playground to Code

Here's the part where this stops being a playground exercise and starts being something I could actually ship.

In the top-right of the Run settings panel, there's a button labeled Get code (<>). I clicked it with V3 still loaded schema enabled, temperature still set, system prompt still in place and AI Studio generates working code in your language of choice.

I picked TypeScript.

Here is the code:

// To run this code you need to install the following dependencies:
// npm install @google/genai mime
// npm install -D @types/node

import {
  GoogleGenAI,
  Type,
} from '@google/genai';

async function main() {
  const ai = new GoogleGenAI({
    apiKey: process.env['GEMINI_API_KEY'],
  });
  const config = {
    temperature: 0.7,
    thinkingConfig: {
      thinkingLevel: ThinkingLevel.HIGH,
    },
    responseMimeType: 'application/json',
    responseSchema: {
      type: Type.OBJECT,
      required: ["componentName", "purpose", "props", "accessibilityNotes", "suggestedTailwindClasses"],
      properties: {
        componentName: {
          type: Type.STRING,
        },
        purpose: {
          type: Type.STRING,
        },
        props: {
          type: Type.ARRAY,
          items: {
            type: Type.OBJECT,
            required: ["name", "type", "required", "description"],
            properties: {
              name: {
                type: Type.STRING,
              },
              type: {
                type: Type.STRING,
              },
              required: {
                type: Type.BOOLEAN,
              },
              description: {
                type: Type.STRING,
              },
            },
          },
        },
        accessibilityNotes: {
          type: Type.ARRAY,
          items: {
            type: Type.STRING,
          },
        },
        suggestedTailwindClasses: {
          type: Type.OBJECT,
          properties: {
            container: {
              type: Type.STRING,
            },
            heading: {
              type: Type.STRING,
            },
            subheading: {
              type: Type.STRING,
            },
            ctaButton: {
              type: Type.STRING,
            },
          },
        },
      },
    },
    systemInstruction: [
        {
          text: `You are a frontend architect helping translate design briefs into 
component specifications. Return a complete, well-considered 
component spec based on the design brief provided.

`,
        }
    ],
  };
  const model = 'gemini-3-flash-preview';
  const contents = [
    {
      role: 'user',
      parts: [
        {
          text: `INSERT_INPUT_HERE`,
        },
      ],
    },
  ];

  const response = await ai.models.generateContentStream({
    model,
    config,
    contents,
  });
  let fileIndex = 0;
  for await (const chunk of response) {
    if (chunk.text) {
      console.log(chunk.text);
    }
  }
}

main();

Every parameter I touched in the UI is now a field in the code. Temperature. Thinking level. Response MIME type. The schema. The system prompt. Nothing got lost in translation between the playground and the script.

The SDK is @google/genai, the official Google package. Install with npm install @google/genai mime and npm install -D @types/node. Get a free API key from AI Studio's "Get API key" link in the left sidebar with no billing required and a generous free tier.

This drops into a Next.js API route with minimal changes. The schema travels with the code. The system prompt travels with the code. The temperature you tuned travels with the code. The hour I spent in the playground became 60 lines of TypeScript I can paste into app/api/component-spec/route.ts and call from a frontend form.

That's the bridge. That's what makes AI Studio worth using even if you eventually move to Agent Platform: the iteration happens in the playground, the deployment happens in code, and the handoff is one button.

What this means for frontend devs

Three things I'm taking from this hour:

You don't need Cloud billing to start. AI Studio plus a free API key gets you most of the way to a working Gemini integration. If you're learning, prototyping, or building a personal project, this stack is plenty. The expensive enterprise tools are for a real production app at scale, not for figuring out whether the model can do what you need.
Prompt iteration is engineering. V1 to V2 to V3 wasn't an aesthetic exercise. Each version was a deliberate response to a real problem with the previous one: V1's prose couldn't be parsed, V2's JSON couldn't be trusted, V3's schema solved both. Treat prompts the way you'd treat any other component of your system: iterate them, version them, write them down.
Structured outputs are the real unlock. The moment your model returns the same shape every time, you stop treating AI calls as dice rolls and start treating them as normal API calls. You can write TypeScript types for the response. You can render the output in a UI without defensive parsing. You can build product around the model's behavior, not around its randomness.

The last point is what I want to keep poking at. When my Cloud account clears the prepayment wall and I get into Agent Studio, the question I'm bringing with me is: how do these same patterns translate to a deployed agent?

For now: if you're stuck at billing, don't wait. AI Studio is right here. Sign in, pick a model, iterate something useful.

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.