EDITOR’S NOTE

Dear Nanobits readers, 

A few months ago, my right arm decided it had had enough.

I have tenosynovitis, where your wrist and forearm tendons get inflamed from overuse. For someone who writes for a living, this is a professional crisis. The pain was severe. Typing was off the table.

So I went looking for a speech-to-text app. Most of the apps I tried, including native voice-command features in WhatsApp, ChatGPT, Claude, etc., gave me verbatim transcripts of my own rambling, filler words, and all. Those apps worked well, but stopped the moment I moved to Gmail or Notion. I needed something that worked everywhere and understood that people don't speak in clean, punctuated sentences.

That's when someone recommended Wispr Flow.

Voice AI has been around for decades. For most of that time, it meant Jarvis. Then came Siri, Alexa, and Google Assistant. Voice that was real but deeply frustrating. One misunderstood word and you were looking up the wrong restaurant in the wrong city.

How many have your fu**’s been autocorrected to ducks and your hell no’s into he’ll no’s.

GenAI changed that. Models now understand intent, not just words. That shift made voice dictation genuinely useful for the first time.

Reid Hoffman, founder of LinkedIn, calls it being "voicepilled." He described it as the moment you realize that speaking to technology opens a new way to work. He said it publicly about Wispr Flow, then went on his podcast Possible to declare the keyboard's obituary, episode title and all: R.I.P. Computer Keyboard.

My voicepilled moment came from an arm flare-up, not a productivity epiphany. Sometimes the best tools find you when you're not looking.

This week's Nanobits covers Wispr Flow: what it is, how real people use it, and the honest good, bad, and ugly of living with it.

The Evolution of Voice AI

Humans think at roughly 400 words per minute. We speak at around 150. We type at only 40. For most of human history, thinking and speaking were inseparable. Writing slowed that down. The keyboard slowed it down further. We trained ourselves to compress thoughts into whatever our fingers could keep up with, and we called it productivity.

Voice is making a comeback, and this time it has the intelligence to match.

For most of the last two decades, "voice command" meant Jarvis. Omniscient, contextually brilliant, fictional. Then the real versions arrived. Siri in 2011. Alexa in 2014. Google Assistant in 2016. Useful for timers and music. Occasionally embarrassing when they mishear you in public. The gap between Jarvis and reality was enormous, not because the hardware wasn't there, but because the intelligence wasn't.

GenAI closed that gap. LLMs turned voice from a transcription problem into a comprehension problem, one that AI was suddenly very good at solving. Models that understand intent and context, not just words.

Now people are realizing the bottleneck was never their thinking. It was the keyboard. Voice lets you capture ideas closer to the speed you actually have them, and that's a hard thing to go back from once you've felt it.

Reid Hoffman, who has watched technology cycles for thirty years, called going voicepilled a cognitive upgrade, not just a productivity one, and said it about Wispr Flow specifically. 

The keyboard isn't going away. It has real competition now.

What is Wispr Flow?

Let's start with something every phone user has felt at least once.

You're typing a message, and you want to write a product name, a colleague's unusual name, or a niche term from your industry, and your keyboard autocorrects it into something completely wrong. You fix it. It happens again.

Wispr Flow works differently. You speak naturally, and it doesn't just transcribe. It understands. 

Wispr Flow is a system-wide AI voice dictation tool. It doesn't live inside a single app. It works in every text field on your computer and phone: Gmail, Slack, Notion, WhatsApp, Claude, ChatGPT, VS Code, and LinkedIn. You press a hotkey, speak, and, in under a second, clean, formatted, punctuated text appears. Filler words stripped (well, mostly of the time), sentence structure intact.

Here's what makes it more than just fast transcription:

• Hotkey activation: press a shortcut anywhere on your device, speak, and Wispr Flow inserts clean text directly into whatever app you're in. Although I would have preferred a wake-up command like “Hey, Siri” or “Ok, Google.”

• It has great auto-formatting (e.g., paragraph breaks, numbered lists, cuts out self-corrections); WSJ considers it “scary good.”
  

  

• Custom dictionary: Add names, brands, technical terms, or Hinglish phrases. Wispr Flow never auto-corrects what you've intentionally saved. Some of us have also added an entire glossary of Gen Z slang just to keep up with our interns. No judgment. The dictionary holds it all.

• Personalized writing style: It learns how you write,  formal, casual, punchy, detailed, so the output sounds like you, not like a generic AI cleanup pass
  

  

• Language picker: Supports 100+ languages, including mid-sentence code-switching, a genuine advantage if English isn't your only working language. It also supports Hinglish.
  

  

• File tagging: Developers can tag files mid-dictation without breaking their flow, one of the more underrated features for technical users

  

<One honest caveat>: Wispr Flow cleans up your speech, but it doesn't fix shaky grammar. If your sentence structure is loose when you speak, the output reflects that. I still use <Grammarly> alongside it. Wispr Flow handles speed and cleanup. Grammarly handles grammar.

In partnership with

The best prompt engineers aren’t typing. They are talking.

Power users figured this out early: speaking a prompt gives you 10x more context in half the time. You include the edge cases, the examples, the tone you want because talking is fast enough that you don't skip them.

Wispr Flow captures everything you say and turns it into clean, structured text for any AI tool. Speak messy. Get polished input. Paste into ChatGPT, Claude, Cursor, or wherever you work.

89% of messages sent with zero edits. 4x faster than typing. Works system-wide on Mac, Windows, and iPhone.

Start flowing free

Who is Wispr Flow for, and how are people using it?

Wispr Flow fits anyone whose work lives in text fields: writers, developers, founders, sales teams, and anyone who finds typing slow, painful, or just inconvenient.

Developers dictate code comments, prompts, and documentation directly into VS Code without breaking their flow. One developer wrote thousands of lines of code without touching a keyboard; he was on a treadmill.

Founders & builders: someone built an app while running a marathon, dictating product decisions and feature prompts mid-stride. If your ideas come faster than your typing, this is your tool.

People are setting up Wispr Flow for their parents because typing is painful or slow for older hands. It may be the most practical use case the community has surfaced and the most underrated.

Sales & GTM teams: Clay deployed Wispr Flow as the default input layer across their entire go-to-market stack - demos, Slack updates, CRM notes, and follow-up emails. The result was 52% faster response times and 20% more customer calls per day. 

Content creators & newsletter writers dictate first drafts, LinkedIn comments and replies, and long AI prompts on the go. The lower barrier to typing means you capture ideas the moment they hit, not an hour later when you're back at your desk.

AI power users are dictating longer, richer context into Claude and ChatGPT because the friction of typing goes away; more context in means better output out.

Then there's a whole microculture of people publicly sharing their WPM stats and annual word counts. One user dictated 161,934 words in a year; another consistently clocked 160 WPM. Wispr Flow has leaned into this as a marketing angle, productivity data as social currency.

Here’s a snapshot of my usage

Wispr Flow’s Go-to-Market

Most AI companies market with benchmarks and blog posts. Wispr Flow is marketed with auto rickshaws and a Porsche.

Wispr Flow wrapped 100 auto rickshaws in branding and drove them through Bengaluru's tech corridors: Koramangala, HSR Layout, Indiranagar. The logic was straightforward. Bengaluru's traffic is brutal, and every developer stuck behind an auto has nothing to do but read what's in front of them. The campaign, run by Owled Media, reached 30 million people. If you're based in Bengaluru, there's a reasonable chance you've already seen one.

Someone on the internet joined the marketing campaign with their creativity, reimagining how Wispr Flow would market in Tier-2 and Tier-3 cities in India. 

In February 2026, Wispr Flow offered a Porsche 911 GT3 RS, worth roughly ₹3 crore, to anyone who could get the app to produce a transcription error. Five challengers tried everything: speaking at full speed, rapping, whispering, switching languages mid-sentence, and throwing technical jargon. Wispr Flow got every single one right. The video hit 3.5 million views. They then opened the challenge to everyone: beat Wispr Flow in a typing speed race and win the Porsche. Nobody has claimed it yet.

Two campaigns, one consistent message: they are confident enough in this product to bet a sports car on it.

Wispr Flow vs The Alternatives

Before you commit to any tool, it helps to know how Wispr Flow stacks up against the voice options you've probably already tried:

The core trade-off is this: Wispr Flow wins on seamlessness; nothing else works as invisibly across every app on your machine. But SuperWhisper is the honest alternative if you need to transcribe locally for privacy reasons, you want power-user customizations (e.g., you want to specify custom instructions about how to tidy or format your dictation), or you'd rather pay once and own the tool. And if you only need voice inside your AI chatbot of choice, the built-in voice modes on Claude, ChatGPT, or Perplexity are already good enough.

The built-in voice modes in these apps are session-bound, great inside that one window, and invisible everywhere else. Wispr Flow's value is the “everywhere else."

The Good, The Bad, and The Ugly

No tool is perfect. Here's the honest breakdown.

The Good

Once the habit forms, 89% of messages go out with zero edits. You stop noticing you're dictating. It works across every app without setup, and the App Store rating of 4.8/5 across 8,500+ ratings reflects that daily users are genuinely satisfied. Context-sensitive formatting means a Slack reply sounds like a Slack reply, not a dictated essay. The custom dictionary solves the autocorrect problem permanently: one setup, done.

The Bad

Wispr Flow polishes your speech but doesn't fix how you structure sentences. If your grammar is shaky when you speak, the output reflects that. Keep Grammarly in your stack. 

The Windows version runs heavy at around 800 MB RAM at idle and has been reported to freeze apps like VS Code. 

The AI cleanup layer occasionally over-edits, rewriting what you said rather than polishing it. 

There's no offline mode, so a dropped connection makes it unusable. Performance also dips on laptop mics; a decent headset makes a real difference.

The Ugly

Trustpilot sits at 2.7/5, a sharp contrast to the App Store rating. Complaints cluster around reliability dropping after the free trial, and support that doesn't match what a paid subscription should feel like. 

The context-awareness feature captures screenshots of your active window every few seconds and sends them to cloud servers. For most users, this is fine. For anyone handling sensitive documents or confidential client data, it's worth knowing before you install.

There's an unexpected, rather embarrassing side effect of using Wispr Flow. After months of dictating, I've noticed my spoken English has gotten sloppier, more filler words, less precision. My most-used offender is "like," a word I genuinely dislike and now hear coming out of my own mouth constantly. 

Wispr Flow strips filler words from the output, so the text looks clean. But the habit of speaking carelessly has crept in anyway. It's something I'm actively working on. The tool cleaned up my writing. It also revealed how much work my speaking still needs.

End Note

I will be honest with you, I'm still not fully voicepilled.

Writing comes more naturally to me than dictating. When I type, I can hold three half-formed thoughts simultaneously and weave them together as my fingers catch up. When I speak, I have to commit to one idea at a time coherently, linearly, and out loud. That's a different kind of discipline. And some days, my brain just isn't built for it.

But here's what I've learned from using Wispr Flow through a flare-up that made typing genuinely painful: the tool isn't asking you to replace how you think. It's asking you to stop losing what you think. How many half-formed ideas have you dropped because your hands were busy, or your keyboard was across the room, or typing felt like too much friction for a thought that wasn't quite fully formed yet?

That's what Wispr Flow is solving for. Not every workflow. Not every person. But that specific gap, the one between the idea and the text field, it closes it faster than anything else I've tried.

I still use it alongside Grammarly. I still type more than I dictate. My tenosynovitis flares up less now, partly because I reach for my voice before I reach for my keyboard when a thought hits mid-walk or mid-meeting.

You don't have to go fully voicepilled to get value from it. Use it for your longest prompts. Use it when your hands are tired. Use it to onboard your parents. Start with the 14-day free trial, no credit card needed, and let the habit find its own shape.

The keyboard isn't dead yet. But it now has competition worth taking seriously.

EDITOR’S NOTE

Dear Nanobits readers, 

AI image generation has long had a gap between what you intend and what the model produces. You've seen the outputs: beautiful in a vague, slightly uncanny way, recognizable as AI from ten feet away, and just different enough from what you asked for that you spend more time fixing than creating.

AI has always distorted the image generation of hands and feet

For experienced professionals, this has been the persistent frustration. You bring years of context to the work. You know what a good infographic should communicate before the first element goes on the page. You know what the client will push back on, what the brand guidelines mean in practice, and why the stock photo your junior designer picked feels slightly off, even if they can't articulate why. That accumulated judgment is not something a better prompt can replicate. But until recently, the tools couldn't keep up with it either. You'd know exactly what you wanted, yet still end up with something that needed a designer to rescue.

That's been shifting. Claude's recent Design updates, Google's Nano Banana, and now OpenAI's ChatGPT Images 2.0 are all pushing toward the same threshold: outputs that not only look good but are also ready to use. Fewer AI tells. Better text rendering. Real instruction following. The kind of precision that lets your expertise drive the output instead of fighting against the tool's limitations.

In this edition of nanobits, we're covering ChatGPT Images 2.0, what changed, what it means for how you work, what the internet thinks of it, and a few prompts to try today.

What is ChatGPT Images 2.0?

Images 2.0 is the smartest image generation model ever built, capable of generating complex, polished, and production-ready visuals with accurate text and structured design. This model generates images by thinking, not just pattern-matching.

The bigger addition is the thinking mode. When you select a thinking or Pro model in ChatGPT, Images 2.0 can search the web for current information, reason through the structure of an image before generating it, and produce multiple distinct, coherent images from a single prompt.

OpenAI prompt: Search for the merch in OpenAI supply co website and make a professional poster displaying our merch in a nice layout. The title of the poster should be "Thinking Mode Searches". Along the title there is a subtitle "With thinking mode, the model can automatically browse the internet and find relevant contents for reference." Below that, add a caption for the images below: "Prompt: Make a poster about OpenAI merch available on the official website right now." Aspect ratio: 4:5 portrait.

Its new multilingual capabilities let you create visuals in multiple languages for audiences worldwide.

OpenAI prompt: I want to create a magazine page that features a professional realistic photography in an Indian bookstore that selling indian books in different languages used in India. The photography should feature book covers in Hindi, Bengali, Marathi, Telugu, Tamil, Urdu, Gujarati, Kannada, Odia. The books must be made-up books with title related to "art" in these languages, but looks like actual book covers rather than a set. The publisher must be "OpenAI". All text must be clearly visible. The purpose of this photography is to show case the diversity of India language. The page should be a picture entirely, no meta text nor title. Aspect Ratio: 1440x2560 portrait

And for the first time in image generation, you can create multiple distinct images at once. Generate entire magazines with structured typography and photorealistic photos, e-commerce landing pages, full renovation plans for every room in your house, or manga comics with recurring characters and evolving storylines. Images now render in 2K resolution across multiple aspect ratios, with extraordinary micro-level detail.

User prompt; source: x.com

5 upgrades worth noticing

Text rendering, accurate and dense, in any language

Earlier image models couldn't handle dense text well. Small labels blurred. Paragraphs scrambled. UI copy turned into visual noise. Images 2.0 renders dense, small text correctly inside the image. If your work involves infographics or explainers, this is the change you'll feel most quickly.

Instruction following, spatial layout, precise placement

Spatial placement was a consistent failure point in older models. You'd ask for an object on the left and get something approximate. Images 2.0 follows the layout instructions precisely. Object position, relative spacing, compositional constraints, all of it lands where you put it.

For example, with older models, even if you asked for a specific time, the clock would almost always show 10:10. That's because watch and clock companies typically use 10:10 in advertisements because the internet is full of images showing that time. The model had absorbed that bias.

With older models

With the new ChatGPT Images 2.0
Prompt: generate 4 retro-looking clocks. one is showing at 2:25; one is 2:30; one is 9:10; one is 7:45.

Multilingual support across non-Latin scripts

Japanese, Korean, Chinese, Hindi, and Bengali now render correctly and as part of the design, not as an add-on. For teams producing content across languages, this removes a step that previously required a separate design pass.

Flexible aspect ratios up to 2K resolution

The model supports aspect ratios from 3:1 wide banners to 1:3 tall posters, at up to 2K resolution in the API. You specify the format in the prompt or pick from presets. The output fits the channel it's going into.

Thinking mode, web search, up to 8 images at once

Select a thinking or Pro model, and Images 2.0 goes further than generating a single image. It searches the web, reasons about the image structure before producing it, and can output up to eight distinct, consistent images from a single prompt. For complex briefs, you hand it a task, and it works through the steps before returning a result.

Here are 4 things I tried to test the new features

Prompt 1: The multilingual poster test

I wanted to test text rendering and multilingual accuracy in a single prompt.

Create a tall 1:3 poster explaining the three phases of the water cycle. Include labeled diagrams, a dense paragraph of explanation at the bottom, and render the text in Hindi.

Prompt 2: The spatial layout test

Older models consistently failed this. Let’s see how precisely it follows spatial instructions now.

Draw a flat lay photo. Coffee mug in the center, notebook directly to the left, phone above the mug, sunglasses below, pen to the right.

Prompt 3: The thinking mode test

I want the model to search the web, pull references, and produce a research-backed multi-image output.

Research the most iconic product packaging designs of the last decade. Create a magazine-style spread with annotations explaining what makes each one work visually.

Prompt 4: The multilingual brand test

In this exercise, I wanted to test whether multilingual text renders correctly inside a designed layout.

Create a promotional poster for a fictional tea brand. Tagline in Japanese, product description in English, price in Korean. Minimal, modern aesthetic.

This is the Japanese translation.

Here is the Korean translation.

Storyboarding to animated videos

This is one of my favorite use cases of ChatGPT Images 2.0 so far.

Twitter tweet

The good, bad, and the ugly

Most users are blown away by ChatGPT Images 2.0’s jump in quality and “intelligence,” but there’s a parallel thread of concern about artifacts, editing limits, and the potential for realistic images to be misused.

The good

The dominant reaction across Reddit, X, and tech media is that this is a non-incremental leap. 

People are blown away by instruction following, character consistency across angles, and text rendering that actually works. 

India in particular has emerged as one of the most enthusiastic early user bases, with strong adoption for everything from stylized portraits to educational graphics. 

Power users running complex prompts in thinking mode are reporting outputs they genuinely didn't expect to be possible yet.

The bad

Iterative editing is a known friction point. The first edit or two go through fine, then the model gets stubborn and changes stop landing. 

Most users are working around this by starting fresh chats. There are also still rough edges with maps, geography, and domain-specific layouts that need accuracy.

The ugly 

The "death of graphic design" discourse is back, louder this time. Designers and illustrators are genuinely worried, and not without reason. 

The quality is now high enough that some paid creative work is at risk. There are also serious questions about deepfakes, scientific image integrity, and how people will verify what's real versus generated when outputs look this convincing. These are not hypothetical concerns anymore.

A hyper-realistic AI-generated cheque of Rs 69,000 was created using CHATGPT Images 2.0, closely mimicking real banking details. It’s doing rounds on social media, alarming users about how easily such documents could be forged. While some experts noted that actual encashment would still require secure features that AI cannot replicate, the incident has triggered a broader debate about digital security, trust, and the risks of increasingly sophisticated AI tools.

source: x(dot)com Photoshop did this 20 years ago, the change isn't that it's possible, it's that the skill floor dropped from "practiced forger" to "kid with a prompt". That's the actual delta.

End Note

Image generation has moved from a creative novelty to a production tool. The deck you're building, the training material your team needs, the social campaign going out next week, Images 2.0 now fits into those workflows directly. You don't need to route through a designer to get something usable. The model meets you at the brief.

That's the shift. Not that AI can make pretty pictures. It's that visuals now carry the same kind of working intelligence that text tools brought to writing two years ago.

Who should pay attention right now?

Marketers: localized ads, social graphics across formats, and campaign mockups without a design round trip.

Educators and L&D teams: textbook-style explainers, visual slide decks, and infographic summaries of complex topics built from a single prompt.

Strategists and consultants: research-backed visual reports and one-page briefs, with real data the model pulls from the web.

Content creators: magazine layouts, manga-style panels, recurring characters across a full story arc.

Where to keep expectations calibrated

The model still struggles with tasks that require a complete physical-world model, such as origami, the Rubik's Cube, and objects on angled or hidden surfaces. Very dense repetitive textures test their limits. Arrow-based diagrams and part labels need a human review pass. Iterative editing stalls after a few rounds. Start a new chat when that happens.

A year ago, AI images were something to look at. Now they're something to work with, build from, and in some cases, worry about. The tool got smarter. The outputs got harder to question. That's useful and uncomfortable in equal measure. The professionals who get the most from it will be the ones who bring enough context to know when to trust it and when to check it.

EDITOR’S NOTE

Dear Nanobits readers, 

I'm going to be honest with you. Keeping up with Claude this year has felt like trying to read a book while someone keeps tearing out the pages and replacing them with newer ones.

Since January, Anthropic has shipped Claude Cowork, Opus 4.7, Sonnet 4.6, Excel and PowerPoint integrations, persistent memory for all users, and now Claude Design. 

Seems like a sprint with no finish line!

The internet is split. On one side, you have developers calling Claude Code "alien technology," shipping year-long projects in hours, and half-joking that they spent the holidays with Claude instead of family. On the other, you have builders talking about "token shrinkflation," launch fatigue, and one particularly blunt post that described vibe-coding with Claude as "cocaine for builders: incredible short-term output, quietly loading your project with future maintenance pain."

Both sides are right, and that tension is real.

What I've also noticed, and I suspect you have too, is a dull anxiety that runs underneath all of this. Every time a new Claude capability drops, there's a brief, uncomfortable moment where you wonder, does this do what I do? How long before it does it better? It's not a dramatic fear. It's more like a low hum that shows up, lingers for a day, and then fades when you get back to actual work.

I decided to stop letting that hum run in the background and actually get a grip on what's happening. Ruben Hassid, who writes the newsletter "How to AI" and has spent years helping people get practical with these tools, frames it well. There are levels to this: 

The point isn't to use everything. The point is to know where you are and move one level up, deliberately.

So in this edition, I want to do two things. First, give you a quick map of what Claude has actually launched since January, so you stop feeling like you've missed something critical. Second, take one launch, Claude Design, and go deep on it. What it is, who it's actually for, and whether it's worth your time right now.

Let's get into it.

What’s Claude been up to since January 2026?

Since I was already writing about Claude Design, I figured I'd put it to work. I asked Perplexity to research every major Claude launch since January, fed that into Claude Design, and built a presentation out of it. Just a prompt and a few rounds of back and forth. 

I want to call out <Claude Mythos> specifically. It is Anthropic’s unreleased frontier model, a general‑purpose LLM that accidentally became a superhuman cybersecurity engine, finding thousands of vulnerabilities and outperforming many human experts on multi‑step security tasks. Anthropic has explicitly chosen not to release it broadly, restricting access to a handful of critical infrastructure partners through its Glasswing program due to destabilization risks.

Strategically, Mythos is the clearest signal of Claude’s trajectory: from <a safe chatbot to a deeply capable enterprise first work infrastructure> that leans into coding, long‑context reasoning, and agentic workflows rather than pure consumer scale. The pattern, Code, Cowork, enterprise Skills, then Mythos, suggests Anthropic wants to own the high‑stakes, high‑margin end of AI (security, core systems, regulated industries) while advertising its safety brand.

Netizens are fascinated and uneasy. Reddit and X debates oscillate between “marketing overreach” and “this is a watershed hacking moment,” with most technical users landing on “very real capabilities, but also very real risks.”

Here's the presentation. Scroll through everything Claude has shipped this year before we go any further.

In the next section, I'll walk you through exactly how I made this, step by step.

What is Claude Design?

Alright, now, let’s get into the tool. 

Claude Design is Anthropic’s AI design workspace that turns natural-language prompts into interactive, on‑brand prototypes, screens, and visuals in a browser‑based canvas. It combines a chat panel on the left with a live design canvas on the right, so you can describe what you want, see it rendered, and refine it in place. 

During onboarding, it ingests your existing design system and codebase to automatically respect your colors, typography, and components in every new project. You iterate through conversation, inline comments, direct edits, and sliders for layout, spacing, and color, making it feel like a collaborative design partner rather than a one‑shot generator.

I wondered how different it is from Claude Artifacts. If you've used Claude Artifacts before, the difference is scope. Artifacts gave you a quick, self-contained output inside a chat, useful for a snippet of code or a simple visual. Claude Design is a full working environment, with persistent sessions, a live canvas, design system awareness, and the ability to hand finished work directly to Claude Code for implementation.

How to get started with Claude Design?

Step 1: Head to claude.ai/design

You don't need a new account or a separate sign-up. If you're already on a paid Claude plan (Pro or Max), you have access. Go to claude.ai/design, and you'll land on a starting screen with four tabs across the top: Prototype, Slide deck, From template, and Other.

• Prototype is for anything interactive, whether that's an app idea, a landing page, or a flow someone can click through. 

• Slide deck is for presentations you want to export as PowerPoint or send to Canva. 

• From template currently has one option, an animation template for motion-based pages. 

• Other covers everything else.

If you're not sure where to begin, pick Prototype. It handles most use cases.

Step 2: Choose High Fidelity, not Wireframe

Once you're inside Prototype, you'll see two modes: Wireframe and High Fidelity. Go with High Fidelity every time. Wireframe gives you rough placeholder boxes. High Fidelity gives you something that actually looks designed, something you can put in front of another person without a disclaimer attached. The whole point of Claude Design is to skip the rough sketch phase entirely, so don't reintroduce it here.

Step 3: Take the clarifying questions seriously

Before Claude builds anything, it asks you questions about the visual direction and tone. Most people rush through this screen. That's the biggest mistake you can make with the tool.

The question about how bold you want the design is the one that matters most. The default instinct is to play it safe and pick something conservative. The output then looks generic, technically correct, but completely forgettable. Go bolder than feels comfortable. If the first draft overshoots, you can pull it back with a single adjustment. It's much easier to tone something down than to inject personality into something flat.

3 things I did on Claude Design

Landing Page

The first thing I created was a landing page. I was asked to create a landing page for a use case page for a solution that one of my previous companies offered. I had no time to coordinate with a designer to work on it since we had to demo it to our CEO in a couple of hours. So. I decided to create one myself. Here is where Claude design really came to the rescue. 

Input files:

• Tab: Prototype

• Mode: High Fidelity

• Content and design brief document for the landing page

My prompt <I wrote a lazy prompt, but you can structure it better.>:

i am the cmo of <company name>, <what does the company do>. here is the website: <enter the website>

i want you to study the design language of the website and its solution pages specifically and help me create a solution landing page for its collection use case [i have attached the content and design brief/wireframe of how i want the landing page to be]. 

ask clarifying questions if you need to.

Tip: It’s better to add screenshots of the reference page as inputs.

And this is the final output [one-shot]:

You can then export it to standalone HTML or Claude Code. 

Presentation

Then I created a presentation. Previously, you saw the slide deck that I created to showcase all Claude launches since January 2026. 

Input files:

• Tab: Slide deck

• Content from Perplexity about the recent launches [shown as pasted text (53 lines) in the image below]

My prompt <I wrote a lazy prompt, but you can structure it better.>:

make a slide deck of all the new launches by claude since jan 2026. it will be used as a primer to help people who are not able to keep up with what claude has been up to.

And here is the presentation:

I also created a presentation for a messaging workshop focused on an upcoming product launch. Here is a glimpse of it. 

One important tip to remember: turn on the speaker notes toggle when you choose the presentation tab. This ensures your slides are clean and not too text-heavy.

Simple mobile app interface design 

Along with the landing page, I wanted to try out mobile screen development as well. 

Input files:

• Tab: Prototype

• Mode: High Fidelity

My prompt:

Create a simple iOS signup flow for a bikesharing app. Show screens on a canvas. Blue + orange modern color scheme.

A quick tip: To ensure the prototype aligns with your brand, you can upload your existing design systems and instruct Claude Design to adapt its output to your specific design language.

How to edit what Claude Design builds

The first draft won't be perfect. That's by design. Claude Design is built for iteration, and the order in which you make changes matters.

Tweaks first. Run through the Tweaks panel before touching anything else. One adjustment updates all screens at once: accent color, illustration style, and background tone. It's free, takes 90 seconds, and closes about 60% of the gap between the default output and what I actually needed.

Then edit directly. Click any element and change it on the spot. It costs nothing. The mistake I kept making early on was writing a comment for something I could have just clicked and fixed myself. Comments cost tokens. Direct edits don't.

Comments last. Save these for structural changes, a layout that doesn't work, a screen in the wrong order. Be specific and batch your feedback. Three notes in one send, not three separate sends.

The good, bad, and the ugly

Claude Design has generated intense debate since its April 2026 launch, sharply dividing those who see revolutionary potential from those who identify serious limitations.

The good

<Impressive for non-designers>
Extracts design systems from repos or images, generates coherent UI from prompts, and outperforms tools like Stitch or Variant on consistency.
"It did astonishingly well with the first design pass. Really outstanding." 

<Developers finally have mockups>
Removes the awkward solo-developer phase of mocking up in Figma before implementation. Solid B-grade starting points, fast.

<Intent-based editing>
Understands prompts like "make this look more trustworthy" — something no traditional design tool handles. One designer called it "like working with a pretty decent junior designer."

The bad

<Token limits hit fast>
Multiple users burned through 95% of their weekly allowance on simple tests. One hit their cap after 4 designs on Claude Max.

<Generic outputs>
Outputs lean toward a few opinionated styles. Reviewers note the designs look like other AI-generated work, with minimal customization and the same visual fingerprint across projects.

<Context loss on larger files>
When the context window fills, Claude loses track mid-session.

"I've lost the specific task details in the context trim. Could you remind me what you'd like me to build?" Claude, mid-session

The ugly

<Code quality under the hood>
A simple 7-page app generated a 2,000-line CSS file with custom classes fighting Tailwind classes fighting inline styles. Looks good on screen; messy to maintain.

<Hallucinations and extras>
Frequently invents logos despite brand guidelines. When asked to replicate high-fidelity designs, adds unsolicited elements.

"You wanted a bacon sandwich; here's the bacon sandwich and his 20 friends." - someone on Reddit

<Not production-ready>
Anthropic says so explicitly. The Code handoff still has friction, and many see it as "Claude Code in disguise," a prototyping tool, not a Figma replacement.

<Market positioning confusion> 
Many see it as "Claude Code in disguise" rather than a genuine design tool. The "Figma killer" framing appears overblown; it's more accurately a rapid prototyping tool for developers, not a replacement for professional design collaboration.

End Note

Claude Design is a promising start, and I think it's the next disruptive surface for design. My read is that ai/ps, Figma, and Claude Design will all co-exist, each serving a different stage of the process.

The capability itself isn't new. Anthropic's models, especially Opus, could already do something like this. What's new is the interface wrapped around it. This is essentially what Figma Make should have been, before they dropped the ball.

That said, the reality of using it is more complicated than the launch posts suggest.

Every design change, colors, spacing, button sizes, and section placement requires you to describe it in a prompt, wait, check the result, and go again. That loop adds up fast. 10 rounds of refinement is not unusual, and each round costs time and tokens. There's a hidden prompt tax that nobody warns you about upfront, and you only feel it mid-session when your weekly limit disappears faster than expected.

There's also a fit problem worth naming. Claude Design generates interactive HTML, which works well for pages that do something: calculators, simulations, and clickable prototypes. For pages that need to say something and convert, landing pages, campaign pages, brand-led work, and visual tools like Framer and Webflow still have the edge. They let you refine by clicking and dragging, not by describing and waiting.

The smarter approach is to use Claude Design to get 60 to 70% of the way there, then move to a visual tool for the final refinement. AI for structure, GUI for polish.

Anthropic is positioning this as a marketing generalist tool, but the strongest early adopters will be designers and PMs who already know what good looks like and can direct Claude precisely. For everyone else, the learning curve is in learning how to prompt, not how to design.

EDITOR’S NOTE

Dear Nanobits Readers,

A few weeks ago, a message landed in my DMs that made me stop scrolling.

A friend, Rahul, a Product Leader, who builds quietly and thinks deeply, casually mentioned that he had built an AI assistant that pushed back on him. Not with a generic disclaimer. Not with a hedge. It called out a specific pattern he falls into, in a specific type of situation, and offered a better path. One he wouldn't have taken on his own.

This sounded exciting and so I needed to know everything.

Turns out, Rahul had built something that the rest of the tech world has started describing in theory recently and building: a true second brain. One that doesn't just store your notes, but knows your behavior. And he built this whole thing, which runs on a $70 computer sitting on his desk. And this data does not leak.

I invited him to write this edition of Nanobits. What you are about to read is his story, the problem he was solving, how he built it, and what surprised him on the other side. I have added context from the broader world of second brains, because honestly, the timing of what Rahul built and what the rest of the field is converging on is remarkable.

This one is worth your full attention.

— Geetika

THE PROBLEM WITH AI TOOLS YOU ARE USING

Here is a thing that happened to me few weeks back.

I opened a new chat with an AI assistant. Described a situation I was navigating at work. Got a thoughtful, well-structured response. It was as helpful as a smart stranger on an airplane is helpful, intelligent, well-intentioned, and completely unaware of the twenty things about me that would change every piece of advice it just gave.

This is the fundamental problem. Every session starts from zero. The AI knows nothing about you. It doesn't know the patterns you repeat, the mistakes you have made before, the people you are dealing with, or what you have already tried. You get generic answers because you have given the system nothing specific to work with.

Andrej Karpathy, OpenAI co-founder, the man who coined "vibe coding", just described this exact frustration on 2nd April, in a post that got nearly 20M views. He called it the "stateless AI problem." Each session, the AI forgets. Each time, you are rebuilding context. And the cost isn't just inconvenience, it's the quality of every answer you ever get.

His solution was an LLM Wiki: dump raw research into a folder, point an AI at it, and let it build and maintain a self-updating, interlinked knowledge base. No vector databases. No fancy infrastructure. Just markdown files and an AI that acts as a full-time librarian. His research wiki on a single topic: 100 articles, 400,000 words, maintained almost entirely by the AI.

What Rahul built is a different flavor of the same insight. And I would argue, more personal. And he built it before this post came out.

Credits: X/karpathy@

THE AI THAT KNOWS YOUR WEAKNESSES

By Rahul

My AI pushed back on me last week. Not generically, not a hedge or a disclaimer. It called out a specific pattern I fall into in a specific type of situation, and suggested something I wouldn't have defaulted to on my own.

It was right.

That's not something a chatbot does. That's something a system does, one that has been quietly accumulating context about you for months, building a profile not just of what you know, but of how you behave.

The model isn't doing the heavy lifting here. The context is.

What I built?

A vault of organized notes, thoughts, observations, recurring situations, behavioral patterns, all in plain markdown files I own and control. A bot that lives on Telegram. A Raspberry Pi on my desk that keeps it running 24/7. An API call to Claude that gets more useful every time I add something to the vault.

When I send a message, the bot reads the relevant vault files, loads them as context, and responds. The AI never sees my vault cold, it always has the right files for what I am asking. Meeting prep, task review, a difficult conversation I am navigating, all of it answered with context no commercial AI assistant has about me, because I built that context myself over time, in files I own.

One of the work chats with the bot

What's in the vault?

A folder of .md files: work context, people profiles, open loops, and one for about-me, the behavioral patterns I have noticed in myself, the situations I keep mishandling, the things I default to that I know aren't right.

When I message "What do I need to know before my call with Ajay?" the bot doesn't just surface my notes. It tells me which thing Ajay cares about most right now, what I committed to him last time and whether I have closed it, and which angle to lead with given his current priorities. That answer came entirely from context I had maintained over weeks, meeting notes, priorities I had logged, decisions I had captured in two-minute entries after things happened.

The files do the work. The AI just knows how to read them.

How the bot navigates the vault?

This is the part most people skip over, and it's what makes the difference between a retrieval system and a prompt stuffed with notes.

You can't load every vault file on every message. The context window has limits, cost adds up, and more importantly, noise degrades the response. If every question gets answered with everything you have ever written, the AI loses the thread.

The solution is an index. My vault has an index.md, a plain-text map of every file in the vault, what it contains, and when it was last updated. When a message comes in, the bot loads the index first and asks the AI a simple routing question: given this message, which files are relevant? The AI reads the map, picks the right files, and only those get loaded into context for the actual response.

Loading 2-3 relevant files instead of the full vault cuts token usage by around 75% on a typical query. The routing call itself is tiny, it only reads the index, which is small and stable, so it hits the prompt cache almost every time, costing fractions of a cent. The main response uses a stronger model only when the query warrants it; routing decisions and simple lookups run on a cheaper tier. Conversation history is a rolling window, not an infinite append.

The result: the system runs continuously, handles multiple queries a day across work and personal contexts, and costs less per month than a single ChatGPT Plus subscription.

The index is also what you maintain most carefully. Each time you add a file or restructure something, you update the map. It's the navigation layer that makes everything else work, both in quality and in cost.

The behavioral layer

When you describe a situation you are navigating and the system cross-references your own documented patterns, you stop getting advice calibrated for a hypothetical rational person. You get advice calibrated for you including the specific ways you tend to go wrong.

I started noticing things about myself I had been vaguely aware of but never had to confront directly. The vault made them undeniable. The AI made them actionable.

Most second brain systems are search engines for your notes. This is something different a system that knows you well enough to push back.

A note on privacy

The vault contains your behavioral patterns, your recurring failures, the private details of situations you keep navigating wrong, the inside story of every relationship that matters to you professionally and personally. This is some of the most sensitive data that exists about a person. It's also exactly the kind of data you had never want living on a vendor's server, training someone else's model, sitting inside a terms-of-service you didn't fully read.

When it runs on your hardware, in files you control, that problem disappears. The system gets more useful the more personal it gets and you never have to choose between depth and privacy.

The whole thing runs on a Raspberry Pi 5. $70. Plugged directly into my router. It's been running for months without me thinking about it.

How the vault grows

The vault grows the way a good notebook grows: you feed it. After a significant meeting, you add a note. When you notice a pattern in yourself, you log it. When a relationship has a new dynamic, you update that person's file.

There's an inbox file where raw thoughts land when you don't have time to organize. Periodically you ask the bot to process the inbox, it proposes where everything should go, you confirm or redirect, and it moves things accordingly.

You are not maintaining a database. You are maintaining a set of living documents about your own life. The effort is low because the format is just writing.

The stack

My stack has four moving parts:

1. Telegram + Telegraf: your interface. Message @BotFather on Telegram, get a token in two minutes. Telegraf is a Node.js library that handles everything on the Telegram side, message routing, long-polling, sending responses.

2. Claude API (or any LLM): the brain. You pass it a system prompt, your relevant vault files as context, and the user's message. It responds. My setup has a config-driven AI router that supports multiple providers and fails over automatically, but for a first version, a single API call is all you need.

3. A vault: a folder of .md files. Work context, people profiles, open loops, behavioral notes. This is where the intelligence lives, not in the model.

4. Raspberry Pi + systemd: keeps it running 24/7. The vault syncs to Google Drive via rclone, a FUSE mount that makes Google Drive behave like a local folder. Edits from your laptop or phone appear on the Pi in about 30 seconds.

Three terminals to monitor performance

The above system is always monitoring performance:

• For service itself: reliability and latency

• ⁠For Gdrive sync: ensuring I have backup + direct laptop access

• ⁠For AI evals: what’s the input and what output it gave

How it all connects?

Here is my data flow:

Your phone (Telegram)
|
| sends message
▼
Raspberry Pi — Node.js bot process
|
├── Auth check (is this an allowed user?)
|
├── Session Manager — loads conversation history from file
|
├── Vault Reader — reads relevant .md files as context
|
├── AI call — [system prompt + vault context + message] → Claude
|
└── Response back to Telegram
|
▼
Your phone

The vault itself looks like this:

Z/
├── index.md ← master map of what's in the vault
├── work.md ← current projects, open decisions, commitments
├── people.md ← colleagues, family, their priorities and quirks
├── open-loops.md ← things said, not yet done
├── about-me.md ← behavioral patterns, recurring failures, self-notes
├── inbox.md ← raw capture; processed periodically by the AI
├── sessions/ ← conversation history files, one per chat session
└── logs/ ← activity and AI call logs

No database anywhere in this system. Every piece of state, sessions, vault content, logs, lives in flat files synced to Google Drive. The AI reads what it needs on each request. This is the design philosophy that makes the whole thing buildable in a weekend.

The bot runs in two modes. Normal mode handles everything conversational, task review, meeting prep, behavioral pushback, questions against the vault. Vault Organization mode is triggered explicitly when you want to process your inbox: the bot reads your raw captures, proposes where everything should go, waits for your confirmation, and executes. Nothing moves without a human saying yes.

To get from zero to a working first version:

Step 1: Create your bot. Message @BotFather on Telegram, send /newbot, follow the prompts. You get a token. Done.

Step 2: Set up your vault. Create a folder with four files: work.md, people.md, open-loops.md, about-me.md. Write a few real sentences in each. The quality of this step is the quality of your system.

Step 3: Write a context loader. A function that reads those files and concatenates them into a string to pass as context. My vault also has an index.md, a master map of what's in every file, so the AI knows what to request without reading everything on every call.

Step 4: Wire up the bot. On every incoming message: load context, call your AI API, send the reply. Telegraf makes this straightforward in Node.js. The system prompt is where you invest the most thought, it tells the AI what the vault is, who you are, and how to behave. Mine is about 200 words.

Step 5: Deploy to the Pi. Copy the repo, create a systemd service file, run sudo systemctl enable and start. It restarts automatically on crashes. Set up rclone to mount your Google Drive. From here, the system runs without you.

Build time for a working v1: a weekend. The whole thing: bot code, vault, systemd config, fits in a single repository.

LESSONS LEARNED. THINGS TO KEEP IN MIND

A few things that only become clear after you have run a system like this for a while:

The quality of the output is directly proportional to the quality of what you put in. A sparse vault gives you a slightly smarter chatbot. A rich vault gives you something that knows you. The delta between those two things is larger than you wouldd expect.

You start writing for your future self, not for the AI. The discipline of capturing things in a way the system can use, concrete, specific, behavioral, ends up being a form of reflection that's valuable independent of the AI. Think of this like your journal and more than that.

The hardest file to maintain is about-me.md. Not because it's time-consuming. Because it requires admitting things about yourself you'd rather not document. It's also the most valuable file in the vault.

Two minutes after a meeting compounds over months. It doesn't feel significant in the moment. Collectively, it's the thing that makes the entire system work.

The system doesn't replace judgment. It makes judgment better. The AI isn't making decisions for you. It's ensuring that when you make decisions, you are doing it with the full context you have built up, not just what you happen to remember right now.

Build for modules, not features. The architecture that handles task review and meeting prep is the same one now running a FitCoach module, workout scheduling, injury context, equipment preferences, and integrating with Hevy, a workout tracking app, via MCP. WhatsApp support is next. None of these required rethinking the core. New capability means a new vault section, a new handler, and a new prompt. The foundation holds. At some point, probably soon, the number of modules will tip into needing a proper orchestrator to route between them. That's a good problem to have.

- Thanks, Rahul

WHAT ELSE COULD THIS DO?

The architecture Rahul built isn't just useful for individuals. The same pattern extends:

For teams: A shared vault of product context, user research, stakeholder priorities, and past decisions, queryable by any team member, maintained collaboratively. The research you did last quarter doesn't disappear when the project ends.

For founders: A running knowledge base of investor conversations, customer insights, competitive moves, and company decisions. Onboarding a new hire means giving them vault access, not hoping they absorb six months of context in three weeks.

For PMs specifically: User interviews, competitive teardowns, stakeholder context, past PRDs. Karpathy's most viral post framed this exactly: "the research you did last quarter is gone. It all lived in your head and disappeared when the project ended." A queryable vault fixes this.

For learning: Feed papers, articles, and transcripts into a vault organized by domain. Ask questions that synthesize across everything you've read. Watch your knowledge compound instead of evaporate.

EDITOR'S NOTE: WHY THIS MATTERS RIGHT NOW

The tooling for second brains has never been better. Obsidian, Notion, new AI-native platforms, all of them are genuinely useful. But the graveyard of elaborate Notion setups that got abandoned in month two is real, and most people reading this have at least one tombstone in it.

The Tiago Forte version of "building a second brain", the one that sold hundreds of thousands of books, was about externalizing your notes so you stop relying on memory. Capture, Organize, Distill, Express. Tools like Notion and Obsidian became the standard implementations. The problem: most people build elaborate systems and abandon them. The maintenance kills it every time.

Karpathy's insight shifts the equation: stop maintaining it yourself. Let the AI be the librarian. You are the curator. Lex Fridman built a similar setup and now uses it on long runs, generating a focused mini-wiki he listens to in voice mode. Garry Tan at Y Combinator built a consulting tool on the same architecture. The pattern is spreading fast.

Rahul's insight goes a layer deeper. Don't just capture knowledge about the world. Capture knowledge about yourself. The behavioral layer is the part every productivity system leaves out, because building it requires honesty, consistency, and a format the AI can actually use.

What Rahul built and what Karpathy gestured at is a different theory of the problem. The bottleneck isn't the tool. It's the context. And context accumulates through consistent, low-friction capture over time, not through picking the right app.

The Raspberry Pi on Rahul's desk isn't the interesting part. The about-me.md file is.

If this resonated, or if you want to go deeper on Karpathy's LLM Wiki architecture, getting started with your own vault, or what a PM-specific second brain looks like in practice, reply to this email. If enough of you are curious, we will do a follow-up. If you are interested in knowing more questions about how Rahul built it, you can reach out to him here.

EDITOR’S NOTE

Dear Nanobits readers,

I have been sitting with this one for a few weeks now, honestly.

Every time I open LinkedIn or scroll through my feeds, someone is either declaring that Anthropic has "won" the AI race, or that OpenAI is in chaos, or that the whole thing is a distraction from whatever the next headline is. The discourse is loud and moves fast, and most of it, I would argue, is built on a false premise that these two companies are in a head-to-head race for the same finish line.

I don't think that's true anymore. And I think understanding why matters not just as a spectator, but because it shapes which tools you build with, which platforms you trust your workflows to, and where the actual opportunities are quietly sitting while everyone argues about benchmarks.

This week, I want to break down what's actually happening between Anthropic and OpenAI. Not the version the breathless tech headlines give you ("OpenAI is CRASHING OUT!" / "Anthropic is taking OVER!") but the more honest, more interesting version.

Let's get into it.

THE SPLIT THAT NOBODY CALLED

Cast your mind back to 2022. OpenAI launched ChatGPT, broke every adoption record in history, and created the entire modern AI category essentially overnight. Anthropic, founded just a year earlier by ex-OpenAI researchers, was the safety-focused upstart that most people had barely heard of.

Fast forward to today, and the gap is still enormous in some ways. OpenAI's ChatGPT has over 900 million weekly active users. Claude's web traffic is about 70x smaller. By consumer numbers, it's not even a competition.

But here's the thing: revenue is not the same as users. And enterprise is not the same as consumer.

By 2026, the difference between the two has become this: OpenAI is a consumer company trying to make enterprise products. Anthropic is an enterprise company that also has a consumer product. That's not spin. That's what the data is showing.

Claude has an estimated 18.9 million monthly active users, roughly 5% of ChatGPT's user base. Yet this smaller, more focused audience generates 40% of OpenAI's revenue relative to scale. Anthropic has a fraction of OpenAI's user base but generates revenue at a dramatically higher rate per user because nearly 80% of its revenue comes from enterprise contracts, not consumer subscriptions.

Credits: Menlo Ventures

That is not a story about who's "winning." That's a story about two completely different games being played on the same court.

ANTHROPIC'S REMARKABLE RUN

Anthropic just had one of the most remarkable quarters any AI company has ever had. OpenAI just shut down its most hyped product. These two things are connected

Anthropic was at roughly $1 billion in annual revenue in December 2024. It hit $4 billion by mid-2025. It crossed $9 billion by end of 2025. And then $14 billion in February 2026: that's $1B → $14B in about 14 months.

Credits: Saastr.com

As Meritech's Alex Clayton noted: "We've looked at the IPOs of over 200 public software companies, and this growth rate has never happened."

The engine behind it? Claude Code. Claude Code's run-rate revenue grew to over $2.5 billion, more than doubling since the beginning of 2026. The number of weekly active Claude Code users also doubled since January 1. A recent analysis estimated that 4% of all GitHub public commits worldwide are being authored by Claude Code.

And in late March 2026, Anthropic shipped computer use: the ability for Claude to actually control your desktop, navigate apps, fill forms, move files, run terminal commands, all through natural language. Launched on March 23, 2026, the feature works across both Cowork (Anthropic's tool for non-developers) and Claude Code, letting you assign tasks from your phone via Dispatch and come back to finished work on your computer. Think of it as giving Claude hands, not just a voice.

A December 2025 report from Menlo Ventures found that Anthropic captures 40% of enterprise LLM spend, up from 24%, while OpenAI's share fell to 27%, down from 50%.

The bet Anthropic made, coding as the gateway into enterprise, safety as a differentiator, reliability over spectacle, is paying off in a way that would have seemed implausible two years ago.

WHAT HAPPENED TO OPENAI?

This is the part of the story that requires some nuance, because the "OpenAI crashing out" narrative is both partially true and quite misleading.

Let's start with the honest version.

Sora, OpenAI's AI video generation tool, was burning through roughly $1 million every day in compute costs not because people loved it but because video generation is extraordinarily expensive to run. While a whole team inside OpenAI was focused on making Sora work, Anthropic was quietly winning over the software engineers and enterprises that actually drive revenue. Sora's estimated $15 million daily inference costs at peak dwarfed its $2.1 million total lifetime revenue. Downloads had dropped 66% from their November 2025 peak.

Credits: X.com

Disney, which had committed a billion dollars and a three-year character licensing deal featuring 200+ Marvel, Pixar, and Star Wars characters, reportedly found out about the shutdown less than an hour before the public announcement. That's not a graceful product sunset. That's an emergency stop.

At an all-hands meeting on March 16, OpenAI's Applications CEO, Fidji Simo, bluntly stated that Anthropic was a "wake-up call" and that the company was "spreading its energy across too many applications and technology stacks."

But here's where I want to push back on the "crashing out" framing: OpenAI is generating $2 billion in revenue per month and made $13.1 billion in revenue last year. That is not a failing company. That is a company that got distracted and is now course-correcting.

And on March 31, 2026, just days ago, OpenAI officially closed the largest private funding round in Silicon Valley's history: $122 billion in committed capital at a post-money valuation of $852 billion. The round was led by SoftBank, a16z, D.E. Shaw Ventures, MGX, and TPG, with participation from Amazon ($50B), Nvidia ($30B), and Microsoft. Enterprise customers now make up over 40% of revenue, and OpenAI says they're on track to reach parity with consumer by end of 2026.

This is not a company in panic mode. This is a company that was spread too thin, made a very public correction, and now has an eight-hundred-billion-dollar war chest to execute on its refocused strategy. The Sora shutdown wasn't a white flag. It was an IPO-readiness move.

THE REAL BATTLEGROUND: NOT BENCHMARKS, BUT MOATS

Here's what I think the AI discourse gets wrong constantly: it treats this like a benchmark race. Who scored higher on MMLU? Who's better at math? Who has the longer context window?

That's not the competition anymore.

Choosing Claude has become a signal of professional identity for engineers and researchers who value precision and transparency over sheer scale. Data from a16z's Top 100 Gen AI Consumer Apps report confirms that these two platforms are no longer trying to occupy the same market niche.

Anthropic has a cultural moat. Their Constitutional AI approach, their safety-first positioning, their refusal to let certain government uses go forward, regardless of what you think about the politics of it, has made them the preferred choice for a specific kind of enterprise buyer. The kind that cares about auditability and not being in the headlines for the wrong reasons. In early 2026, Ramp's spending data showed Anthropic capturing over 73% of all spending among companies buying AI tools for the first time.

OpenAI has a distribution moat. A billion users is not a small thing. The network effects of ChatGPT being the verb for AI, the way Google became the verb for search, is genuinely defensible. Kids start there. Companies start there. Enterprise customers now accounting for 40% of OpenAI's $25B ARR means the enterprise play isn't dead, it's just getting serious.

The question for the next 24 months isn't "who wins." It's whether these moats hold as Google (which already has your Calendar, your Gmail, your Docs) figures out how to deploy its agent features at scale.

WHY THIS MOMENT MATTERS FOR BUILDERS

Why I am covering this particular story today: because I have been building with these tools, and the gap between watching this happen and making things happen is smaller than it's ever been.

In the past 3 weekends, I built using Claude Code 1/ a real-time flight detection system, the Flight Whisperer, that sends WhatsApp notifications using Twilio and the OpenSky API; 2/ a custom Alexa skill called Calendar Buddy that pulls from Google Calendar and announces as well as books your calendar; and 3/ a system, The Message you Leave Behind, using Google Apps, Gmail and Google Drive to send letters to your loved ones even if you are not there. All of it in a fraction of the time it would have taken even 18 months ago.

These weren't prototype demos. They were working tools I use. And the pattern I keep seeing is that Claude Code has fundamentally changed what "building something" means, you're no longer fighting the environment to get to the idea.

Four engineers built Cowork in 10 days, with most of the code written by Claude Code itself. That's the company's own internal product, built by the tool it's selling. That tells you something about where we actually are.

The people winning right now aren't necessarily the ones with the biggest teams or the most funding. They are the ones who picked a problem worth solving and got moving.

WHERE DOES THIS GO?

A few things I am actively watching:

The consumer monetization question is genuinely unresolved. 79% of companies paying for Anthropic are already paying for OpenAI too. Enterprises aren't picking sides, they are running both in parallel. Which means the real question is which model gets chosen for which workflow. That's going to be won by UX and reliability, not press cycles.

Google is the sleeping giant here. They already have access to your email, your calendar, your documents. CIOs project that by 2026, OpenAI will hold 53% market share, while Anthropic and Google are each expected to account for 18%. The Google agent, when it properly ships, inherits trust that no new entrant can buy.

The SaaS disruption is real, not hype. The Cowork launch triggered a massive selloff in global SaaS stocks. The software sector lost roughly $2 trillion in market cap as investors recognized that agentic AI tools could disrupt traditional enterprise software models. Worth watching closely.

END NOTE

The honest take: Anthropic and OpenAI are not competing for the same thing anymore, and trying to crown a winner misses the more interesting question: which is what happens when the infrastructure layer of AI stabilizes and the application layer explodes.

That's where the next set of opportunities live. Not in the model race, but in the problem layer on top of it.

If you are building something, anything, this is probably the best moment in history to do it. The tools have never been this good, this accessible, or this willing to do the boring parts for you.

See you next week!!

EDITOR’S NOTE

One marketer. More than three years to ChatGPT. A real answer to the question everyone is asking.

Dear Nanobits Readers,

The question underneath every AI conversation right now is not, "What can AI do?" Most people have already seen the demos. The real question is more personal: if AI can do this, what do I actually do?

This edition is a continuation of the AI-native functional experts series on Nanobits. We are talking to functional leaders who have genuinely figured out how to work with AI at a high level. Not people who read about it. People who built workflows, shipped things, changed how their teams operate, and can tell you exactly what broke and what held.

Somya Sinha and I (Monalisa Sethi) sat down to have exactly this conversation. Somya runs AI with Somya on Substack, and this edition is a collaboration between her newsletter and Nanobits.

By the end of this piece, you will know the exact marketing tech stack, what good AI-native marketers do manually versus with AI, and the three things we believe will keep any business leader relevant.

If you are a marketer trying to figure out what to automate and what to keep, a business leader rethinking your GTM stack, or anyone asking whether they still have a place in an AI-heavy workflow, this one is for you.

Where did my AI journey start?

"When ChatGPT-3 launched, I was at a series-B fintech start-up. Our leaders encouraged us to use GenAI for copywriting.

In mid-2023, I took a career break and did a copy traineeship with Terribly Tiny Tales. I started using AI for a lot of writing and quickly saw that purely AI-generated writing looks soulless. Too many emojis. Dead giveaways everywhere.

So I started building guidelines for writing with AI while keeping my own voice. Blake Stockton's blog on avoiding AI slop was useful here.

I also love reading about technology. By the end of 2023, I had subscribed to 25 AI newsletters. Allie Miller, Karen Hao, Rundown, Alpha Signal, and others. My social media feed filled up with interesting AI content, and that kept compounding."

How did I actually learn AI?

"I did not take a single AI course. Two things worked for me.”

The first was learning by writing about AI. Together with Geetika Mehta, I started Nanobits in early 2024. We noticed a gap in Indian AI news coverage and went after it - covering Indian news, tool teardowns, and AI concepts. It pushed me to run deep experiments and write about firsthand learning rather than just consume content.

The newsletter built my credibility as an AI expert and directly led to AI consulting gigs. In one gig, I did ghostwriting for an entire team of CXOs by creating a Custom GPT for each leader, which brought down copy revisions from 'n' rounds to just one.

The second was learning by implementing AI at work. When I joined an industrial saas series-B company as a marketing leader, I immediately got down to researching how to strengthen our GTM stack and introduced new tools for the team. Even now, before starting my next role, I'm already researching how to use Claude Code for GTM."

My marketing stack. What do I do manually vs. with AI?

"The most important thing I can say upfront: when machines create everything, the last scarce resource might be humans. If you do not know what questions to ask, no tool will give you answers on its own."

Here is how my tech stack breaks down across the full marketing function.

Content Creation: Gemini + Claude

Research comes first. For all third-party research, I use Gemini 3 Pro in Deep Research mode. This includes deep dives on people, including profiling 50 webinar attendees ahead of an event.

The first draft is always manual. That is a firm rule.

For refining writing, including newsletters, I use Claude Projects. I enter all the relevant context myself and tweak the memory manually. My usage splits into two modes. Claude on the web is for open-ended thinking and brainstorming. Cowork handles repeatable tasks, such as repurposing a weekly newsletter into posts for Reddit, X, and LinkedIn, or analyzing 20 customer calls, grouping them by theme, and sending those summaries to the sales team on Slack.

I am still working out where Claude Code fits. One experiment I am considering: building a GTMBuddy-style tool to track whether the GTM team is actually using the decks, one-pagers, and assets that marketing creates for them. My view on tool adoption is deliberate. "It is very important not to chase every shiny tool that gets launched. Explore, no doubt, but mindfully."

For instance, platforms like SEMRush, Ahrefs, and WebFX offer native AI features to help with content refinement and distribution. However, their impact on revenue has been incremental so far.

Because everyone is publishing AI-written articles right now, the problem is two-fold. Google penalizes content published at that pace, and AI-written articles carry no authority on their own.

The hard part, and the part very few people do today, is pulling real insight from prospect and client call recordings and getting input from industry voices for writing a good thought leadership piece. That gap is what sets a good marketer apart.

The deeper issue goes beyond AI-generated content. 

There is also a structural problem in how most teams approach content. One blog, one white paper, and one ebook, each treated as a standalone output. Good marketing leaders are moving away from that. They think like a content studio, where everything connects, addresses real audience needs, and fits into a unified view. If you cannot answer why you are writing a particular blog and how it’s going to be distributed, the strategy is fragmented. Start with "why" and build from there.

It comes down to what you are optimizing for. SEO rankings, brand building, or pipeline? An AI-generated thought leadership piece is not thought leadership. You can game SEO and ranking, but if the piece is not unique, no one will read it.

GTM Launch Playbook: Human Judgement + Claude + Notion MCP + Asana MCP

The structure of a launch plan comes from experience. A D-minus-45 to D-zero Gantt chart, the channel-by-channel plan, and the stage-wise task list: these are built by a human. "If you ask someone with 15 years of marketing experience to list everything needed for a product launch, they will have no problem. I am yet to see a junior or mid-level resource produce a solid launch list and execute it flawlessly with AI alone."

Once the plan is in place, Claude, Notion MCP, and Asana MCP take over admin. Tasks push to Asana automatically. Stakeholders get reminders. Overdue items surface without anyone having to chase them manually. "The senior marketer running the launch has a full plate. Offloading the admin frees them to do the actual marketing."

Analytics: Salesforce + HubSpot + Mixpanel

For sales and partnership-led motions, Salesforce and HubSpot mostly cover what the team needs. For product-led growth, Mixpanel predominantly handles the analytics.

HubSpot now has an MCP server. Connect it to Claude and ask questions in plain language: "What was deal velocity last quarter, and how does it compare to the historical average?" No SQL required.

The most important point to remember that applies to every tool in the stack is that "humans operate the tools, not the other way around. If the marketer does not know what questions to ask, no tool will surface insights on its own."

Signals and Prospecting: Clay + ZoomInfo

For lead research and scoring, I use Clay and ZoomInfo, supplying third-party intent signals at the contact level. Clay is the stronger tool. It can pull details from, say, the 10-K reports of prospective customers, allowing the team to ask specific questions: "Which prospect has a stated cost-cutting goal as part of their digital transformation?" ZoomInfo and Clay both depend on Bombora for that contact-level signal layer.

The business logic for scoring stays manual. Deciding which activities count more and which signals to weight is a human call.

Sales Engagement: Gong + Outreach + LinkedIn Navigator + HubSpot Sales Hub

The standout use case here is Gong. If the team is in early-stage talks with a new prospect and already has a similar client in the portfolio, they pull that client's account from Gong and use the native AI feature to surface relevant insights. Those insights feed directly into the new prospect conversation.

If you are using competitive intelligence tools like Klue: "These cost $40,000 to $60,000 a year. I would much rather hire a person to do CI than buy a tool. Most martech tools average $25,000 to $30,000 annually. Vendor sprawl also creates fragmented data. Building any AI layer on top of fragmented data becomes a serious problem."

Sales Engagement: Gong + Outreach + LinkedIn Navigator + HubSpot Sales Hub

The standout use case here is Gong. If the team is in early-stage talks with a new prospect and already has a similar client in the portfolio, they pull that client's account from Gong and use the native AI feature to surface relevant insights. Those insights feed directly into the new prospect conversation.

If you are using competitive intelligence tools like Klue: "These cost $40,000 to $60,000 a year. I would much rather hire a person to do CI than buy a tool. Most martech tools average $25,000 to $30,000 annually. Vendor sprawl also creates fragmented data. Building any AI layer on top of fragmented data becomes a serious problem."

What does the future of the marketing workforce look like?

The role of a marketer is not disappearing. Its shape is changing fast.

Teams will likely be smaller. A marketing leader hiring today does not need as many writers and editors as they did three years ago. AI handles a real portion of what used to require headcount. But that does not make the marketer redundant. It makes the marketer's judgment more central, not less.

Deloitte describes this shift as the rise of "superjobs," roles that combine work from multiple traditional positions, using technology to expand what one person can own and deliver. The work that remains for humans after automation is more interpretive and strategy-driven: problem-solving, data interpretation, and knowing what questions to ask in the first place. In marketing, that translates directly.

The marketer of 2026 is part strategist, part analyst, part editor, and part workflow architect. One person, broader scope.

The job description for a marketer is also changing, and for the better.

A portfolio of standalone content pieces is no longer an effective signal. What stands out when hiring is evidence of content projects, not content outputs. Industry reports such as Amagi's FAST Report and Mailmodo's State of Email Marketing are good examples. These are not one-off blog posts. They are content IPs, built to repeat, compound, and own a conversation in the market over time. Has the candidate worked on something like this? Have they thought about distribution, not just creation?

The parameters for hiring a marketer have shifted. The right candidate today has three things: primary research instincts, distribution experience, and an understanding of how AI fits into their workflow without replacing their thinking. Everyone involved in hiring and in being hired needs to raise their game accordingly.

The bottom line: marketing teams may get leaner, but the marketers who remain will carry more responsibility, not less.

End Note: How does one stay relevant as a marketer in the age of AI?

Three things. I think about these a lot.

Build something and sell it. Anyone can build now with tools like Lovable. What sets people apart is taking something to users and getting them to pay or engage. When I started building this newsletter during my career break, it always opened up deeper conversations in interviews. People were skeptical, but the newsletter proved I knew my subject well. When I was interviewed for my last role, the AI workflows I had built in Make.com and n8n.io got the hiring team's attention. Have something to show, not just something to say.

Write your first drafts yourself. AI works well for research, refinement, and distribution. But the first draft has to come from you. Most people prompt their way from zero to a finished piece today. That is exactly why original thinking is getting rarer and more valuable. The angle, the opinion, and the insight: those have to be yours.

Build your tribal knowledge. AI has no access to what you absorb from your managers, leaders, from customers, or from being in the room when a deal closes or falls apart. The more you observe and learn from the people around you, the stronger your real-world judgement becomes. That is the part no model can replicate.

A note from Somya about this conversation: 

This series will continue. Next up, we will talk to leaders in sales, consulting, design, finance, HR, etc., all asking the same question. Subscribe so you do not miss it. And if you are someone doing interesting AI work, reply to this email. We would like to feature you.

EDITOR’S NOTE

Dear Nanobits Readers,

Imagine this. You have an app idea. You open an AI coding tool, describe what you want, and in twenty minutes you have something that actually works. The logic is right. The data flows. And then you open it in the browser and it looks like it was assembled by someone who has never used a real product in their life. Flat grey cards. A font that came pre-installed on a 2009 laptop. A color palette that says "I pressed generate and accepted the default."

This is the AI slop problem. And if you have built anything with Bolt, Lovable, or even Claude Code, you have felt it.

Now imagine the flip side. You are a product manager trying to get a team aligned on a new feature, and the fastest way to do that is a visual but you're not opening Figma at 11pm to manually build wireframes. Or you're a founder who needs to show investors something real in 48 hours, not a slide deck with boxes and arrows. Or you're a designer who wants to explore six layout directions before committing to one, without burning a week to do it.

Google just shipped an update to Stitch that is genuinely trying to solve all of this, for builders, PMs, designers, and founders alike. The headline feature is called design.md, and I spent a few days testing it, including rebuilding a full Spotify-inspired music app experience from scratch. Here's the full picture, the exciting, the practical, and the parts they still haven't figured out.

Let's jump right into the details.

What is Google Stitch now?

A quick bit of history first. Stitch started its life as Galileo AI, a startup Google acquired in 2025 and rebranded. In its earlier form it was a simple text-to-UI tool: describe a screen, get a mockup, move on. Useful for a quick sketch, not much else.

The latest version is a completely different product: a full AI-native canvas where you can bring ideas in whatever form they take: images, text, sketches, or code directly onto the canvas as context. Think of it the way you think about Claude Code for developers, except Stitch is that for everyone who needs to design something and doesn't want to spend three hours in Figma to do it.

The tool runs on Gemini models: Standard Mode uses Gemini 2.5 Flash for speed, while Experimental Mode uses Gemini 2.5 Pro for more detailed, refined outputs. You pick based on what you need: fast exploration or careful execution.

The Feature that Actually Changes Things: Design.md

If you have used CLAUDE.md or agents.md in a coding project, you already understand the concept. Design.md is a markdown file that captures your entire design system, colors with exact hex codes, typography scales, spacing rules, component patterns, dos and don'ts in a format that any AI coding tool can read and follow consistently.

Before this existed, the workflow looked like this: design something carefully → try to describe it to an AI coder → watch it ignore half your choices, invent the rest, and produce something that looks nothing like what you had in mind. Every single time.

Design.md is the translation layer, you can export or import your design rules to or from other design and coding tools, so you don't have to reinvent the wheel every time you start a new project. And critically, Stitch generates it automatically as you design. You don't write it. You design, and it documents itself.

What ends up inside it: your full color palette with hex codes and tonal scales, your typography hierarchy from display headings down to body labels, component-level rules with visual examples, spacing tokens, and rules framed explicitly as dos and don'ts so an AI coder can't misinterpret them. It's not just documentation. It's a design contract your coding tool has to honour.

What Else is New?

URL ingestion. You can extract a design system from any URL, drop a live website into the canvas and Stitch pulls out the colors, fonts, and component style automatically. Useful if you're redesigning an existing product or matching an established brand.

Smarter design agent. You can speak directly to the canvas via voice to describe your design needs, generate new interfaces, modify existing ones, or get real-time design critiques where the AI proactively flags poor contrast or unclear layouts.

Instant prototypes. Select screens, hit Play, and Stitch wires them into a clickable flow, it can even automatically generate logical next screens based on a click, mapping out user journeys effortlessly.

Attention heatmaps. Select any screen, go to Generate → Predicted Heatmap, and Stitch shows you where users' eyes will land first. It's an attention audit before you write a single line of code.

Stitch MCP. For Claude Code users, there's now an MCP server that gives Claude direct access to your Stitch designs, not just the markdown file, but the actual HTML and CSS behind every frame. The design stops being a reference and becomes a live source of truth.

Export to AI Studio. Push your designs directly to Google AI Studio and prompt it to generate a full Next.js app with authentication and a database. The design-to-deployment loop, without leaving Google's ecosystem..

I Rebuilt Spotify’s Design Language With It

To stress-test all of this, I decided to do something ambitious: take Spotify's design DNA and rebuild it as an original music experience, same aesthetic logic, different product. Dark mode, strong typography, album art as the visual hero, clean sidebar navigation.

What I fed into Stitch: Spotify's homepage URL. My prompt asked it to extract the full design system, create a design.md, and then design an original web dashboard carrying the same vibe.

Within two minutes: the near-black background palette pulled cleanly, the signature green accent came through with accurate hex values, a font pairing captured Spotify's Circular feel without using the proprietary typeface, and the card-grid layout logic felt immediately right. The design.md it generated was detailed enough to hand directly to a coding tool and expect a coherent output.

Three screens, three prompts:

Home / Discovery Feed — left sidebar, horizontally scrolling card rows for Recently Played, Made For You, and New Releases. One prompt. Two minutes.

Now Playing — large album art left, song info and progress bar center, queue right. I asked for an ambient color glow behind the album art that pulls from the album's dominant color. First try, it worked. That's the kind of detail that separates a polished product from a generic one.

Library / Playlist page — card grid with a featured hero banner at the top. Clean and done.

For each screen you can Generate Variations, upto three interpretations of the same brief in thirty seconds. This alone is worth the price of admission. You stop agonizing over a single direction and start choosing between real options.

The heatmap check: I ran the attention heatmap on the Now Playing screen. Eyes landed on album art first (correct), then song title, then skipped the progress bar entirely and landed on the queue. Wrong hierarchy for a music player. I prompted a fix and the revised version tested noticeably better.

Taking it to code: I exported the design.md, opened it in my project, and used it as the reference file for Claude Code. The output was noticeably more consistent than anything I had got from AI coding tools previously, about 80-85% color fidelity, fonts needed a manual pass, but the foundation was solid and the direction was unmistakable.

My Honest Take

Real-world users and reviewers have been fairly consistent in what they love and where the cracks show.

What genuinely works: It understands design context: mobile vs web, B2B vs consumer, applies appropriate UI patterns like cards, tabs, and forms, generates realistic placeholder content, and maintains consistent spacing and typography hierarchy. One PM at a fintech startup noted it replaced a $5,000 designer cost for early-stage concept validation. A founder built 15 screen mockups for an investor pitch in two hours.

The designer workflow in practice looks like this: use Stitch to generate 3-5 concept directions in 5 minutes, export the best option to Figma, refine brand colors and fonts in 30 minutes, iterate conversationally back in Stitch for another 10 minutes, and do a final polish for handoff in 20. Total: 65 minutes versus 4-6 hours manually.

Where it falls short: Stitch's outputs often default to a limited set of layout structures, many designs end up looking alike, with only minor variations. It also struggles to meet basic accessibility requirements like color contrast and touch target sizes, so you'll need to review and adjust for anything shipping to real users.

It works well for basic use but lacks deeper integration with existing design systems and structured workflows. Complex multi-step flows are still a weak spot, it's hard to generate more than 2-3 screens coherently, and it's not well-suited for longer user journeys.

And it lives in Google's ecosystem. If your stack is heavily third-party, some of the deeper integrations won't apply to you.

What This Means For You

Product Managers: This is your new best tool for sprint kickoffs. Instead of describing a feature in a doc and hoping everyone imagines the same thing, you can show up to alignment meetings with a clickable prototype you built in forty-five minutes the night before. Stitch removes the "I'll need a designer to visualize this" bottleneck from your workflow entirely.

Designers: The blank canvas problem is solved. Generate five directions from a brief in the time it used to take to open a new Figma file. The real value isn't replacing your craft, it's front-loading exploration so that by the time you're doing detailed design work, you've already pressure-tested the directions that don't work. Stitch does the diverging. You do the converging.

Engineers: The design.md file is built for you. Instead of receiving a Figma link and spending hours trying to reverse-engineer what the designer intended, you get a structured markdown document with exact hex codes, spacing tokens, and explicit rules. Feed it to your AI coding tool and the output will actually look like the design.

Founders and Solo Builders: This is the tool that finally closes the gap between "I built it" and "it looks like something people would actually pay for." If you've been shipping products that work but look like AI slop, Stitch is worth an afternoon of your time this week

What This Means for The Design Landscape

It would be reductive to dismiss what the existing players have built. Figma remains the standard for collaborative, production-grade design, its component libraries, version history, and team workflows are years ahead of where Stitch is today. v0 by Vercel owns the design-to-functional-code space for developers who need React components fast. Framer leads on complete website builders with real interactivity. And tools like UX Pilot have been doing parts of this workflow for longer.

What Stitch is doing differently is the integration play, connecting design generation, design systems, prototyping, coding, and deployment inside one Google-backed ecosystem with an MCP server that ties it to the tools developers are already using. No single competitor currently owns that full loop. Whether Stitch executes on it well enough to matter is the open question. But the direction is right, and the pace of improvement over the past year suggests they're not slowing down.

Try It Yourself

1. Go to stitch.withgoogle.com — free, no waitlist

2. Start a new Web project

3. Drop in a URL or 3-4 screenshots of a design you admire

4. Prompt: "Extract the design system and create a design.md. Then design [your screen] in dark mode / minimal / your preferred aesthetic."

5. Use Generate Variations on each screen — pick the strongest

6. Run a Predicted Heatmap on your most important screen

7. Select 2+ screens → hit Prototype

8. Export design.md and paste it into your project folder — reference it in every AI coding prompt from here

Claude Code users: search "Google Stitch MCP setup" and install the MCP server. It gives Claude direct access to your Stitch frames, not just the markdown.

END NOTE

Design.md is not a finished paradigm. But the problem it's solving — design intent getting lost in translation when it meets an AI coding tool — is one of the most frustrating and universal problems in building products with AI today.

For the first time, there's a tool that creates a living document of your design decisions and puts it directly in the hands of the AI that's building your code. That's the shift. Not "AI can design now." But "your design decisions can finally survive contact with the tools building your product."

Go build something that doesn't look like slop.

Check out the full video of the Spotify like app that I build..

Until next time!

EDITOR’S NOTE

Dear Nanobit Readers,

One fine Wednesday evening, a neuroscientist told a room full of people that we still don't truly understand how brains or AI work. Not as a disclaimer. As a starting point. Prof. Upinder Bhalla, one of India's leading computational neuroscientists, has spent 30 years studying the brain mathematically, and that was his opening position. I found that oddly reassuring. 

This edition is my attempt to think through what he said, starting with the brain, landing on AI, and sitting with the questions neither field has answered yet. Here's what we'll cover:

• Why Turing's 70-year-old argument about AI and human intelligence still holds

• How AI got unreasonably good, then hit a ceiling

• What neuroscience and AI are still teaching each other

Before that, how does the brain work?

Here is one fact worth sitting with. The protein molecules in your synapses⁰ , the physical structures that store your memories, last only a few days. The memories themselves can last a lifetime. Nobody has fully explained how a system built from such temporary parts holds onto something so permanent. That is the kind of problem researchers, like the professor, have spent years on. Hence, we will approach both the brain and AI with the same posture: deep respect for what we don't yet know.

The uncomfortable logic of Turing

I will start with the question: What does it actually mean for something to be intelligent?

Alan Turing answered this in 1950 with uncomfortable simplicity. Have a conversation with “something”. If you can't tell whether it's human or machine, the thing at the other end is intelligent. No qualifications. That's exactly how you and I decide whether another person is worth listening to. We talk to them. We lead them down twisting lines of logic and see if they can follow. Turing just formalized what we were already doing.

His second contribution was the Turing Machine, a proof that any computation can be replicated by a simple rule-following system. And here is the claim: the brain performs computation, so in principle, a computer can do what a brain does.

Descartes had a different answer. The mind, he said, is a thinking substance with no fixed location or size. The body is just matter. They are separate things.

Let’s counter this with a simple thought experiment: if you replace one neuron at a time with a silicon equivalent, at what point does the mind detach? He has never found a satisfying answer in dualism, and neither has anyone else.

John Searle spent 50 years arguing otherwise. 

I have to disagree with Searle here, though: synapses do computation too, and the whole system can be intelligent even when no single part is. A computer on its own isn't intelligent. A program on its own isn't either. But when the program runs on the computer, the whole system might be.

I think Searle's argument is already dead. What replaced it is what we're here to talk about.

How AI got unreasonably good

So if the brain computes, and computers can in principle do what brains do, why did it take us so long to get here?

The first artificial neurons were embarrassingly simple. A perceptron¹, invented in the 1950s, was just an input layer and an output layer with weights² in between. It could play noughts and crosses. That was about it. 

Think of it like estimating a house price. Size and location are your inputs, each carrying a weight that reflects how much it matters. The network combines them, applies one final weight, and arrives at a predicted price. Change the weights, change the answer.

Then in the 1980s, backpropagation³ came along, a training algorithm that let networks learn from their mistakes across multiple layers. Things got interesting. Networks could read English text and produce reasonable phonetic approximations. Not because anyone told them the rules of pronunciation. Because they learned from examples.

This means you don't program the computer with rules. You show it examples, and it figures the rules out itself. That felt almost human. Almost felt human, didn’t it?

But then things stalled. Support vector machines⁴ arrived in the 1990s and did most of what early neural networks could do, more cleanly. The excitement faded.

What changed everything was data. Google and companies like it had accumulated more text, images, and human behavior than anyone had ever seen. Pair that with serious computing power, and you can train networks with dozens, then hundreds, of layers. Deep networks. And then strange things started happening.

Then came style transfer. Take a photograph. Take a painting by Van Gogh. A network can now apply Van Gogh's exact visual style onto your photograph, not as a filter, but by analyzing the correlations between layers of the painting and replicating them onto your image. The content stays yours. The style becomes his.

Image style transfer. The style image from Van Gogh’s Starry Night (b) was transferred to the content image of Golden Gate (a), and the generated image is (c)

These are examples of "unreasonable effectiveness." The phrase is borrowed from a lecture by physicist Eugene Wigner, who once marvelled at how well mathematics describes the physical world. The same logic applies here. These networks were not designed to do what they ended up doing. Nobody built the retinal scan network to detect heart attacks. Nobody taught the style transfer network what makes Van Gogh's brushwork distinct from Klimt's. They found those patterns on their own, buried inside the data.

The military ran into this, too. A neural network was trained to identify tanks in photographs. It worked perfectly in testing. Then someone noticed it was actually classifying sunny day photos as tanks and cloudy day photos as non-tanks because the soldier taking training pictures had gone out on a sunny day for tanks and a cloudy day for everything else. The network had learned the right answer for entirely the wrong reason. It was unreasonably effective at finding a pattern, just not the one anyone intended.

That gap between what we ask these networks to do and what they actually learn to do is both the most exciting and the most unsettling thing about them.

And then, in 2017, everything changed again. The transformer architecture, introduced in a paper that has since gathered nearly a quarter million citations, pushed this further than anyone expected. It gave networks the ability to hold long contexts, focus attention on the relevant parts, and generate language, code, images, and more with a fluency that continues to unsettle people who study this for a living.

We are in a very exciting era right now! The question is how much longer that excitement holds before we hit the ceiling.

Twenty Watts vs. a billion dollars

Here is the number that should bother you. A modern AI data center burns gigawatts of power. Your brain runs on 20 watts. That is roughly the same as a dim bedside lamp. And yet your brain has more synapses than the best AI systems have memory units, learns a new skill from a handful of examples, and has never once needed to ingest the entire internet to hold a conversation.

So what is actually going on?

The brain is not faster than a computer. It is dramatically slower. Electrical signals in neurons fire in milliseconds. Modern chips operate in nanoseconds. The brain loses that race by a factor of a million. And yet it wins almost everything else. It recognizes a face in a crowd, catches a cricket ball mid-flight, recalls a half-forgotten memory from twenty years ago, and does all of this simultaneously, on 20 watts, without crashing.

The difference is not raw speed. It is how the brain uses time. Where computers fight against delay, the brain builds delay into its computation. Timing is not a bug. It is part of the calculation.

But the more noteworthy gap is this one. AI systems have now consumed every book, article, forum post, and webpage that humans have ever put online. The training cost for a single large model has crossed the billion-dollar mark. And still, a five-year-old can learn what a chair is from seeing three examples. An AI needs thousands of labeled images to get close.

Yann LeCun, one of the architects of modern deep learning, has been making this point loudly. We do not need more data. We need smarter ways of learning from less. Humans do not become intelligent by reading the entire internet. We read a handful of textbooks, talk to a few people, make mistakes, and adjust. The internet is a tiny fraction of what humans have ever experienced, and experience itself, touch, smell, movement, and failure are barely represented in any training set at all.

To put it simply, the next frontier is not more data. It is better architecture. Systems that can learn the way a child/human does, quickly, from sparse input, and carry that forward.

AI has eaten everything on the table. The question now is what comes next.

Where the wheels come off

AI has eaten everything on the table, I mean, the internet. So what happens when it starts eating itself?

Researchers have already looked at this. When AI models train on content generated by other AI models, the quality collapses. Not gradually. The models degrade fast, losing the texture and variation that came from genuine human experience. It’s called a death spiral. The internet is already filling with AI-written text, AI-generated images, and AI-summarized articles. The next generation of models will train on that. Then the generation after will train on the generation before. At some point, you are no longer learning from the world. You are learning from a photocopy of a photocopy of a photocopy.

The scaling problem compounds this. Sam Altman and others built their entire bet on a simple idea: more data, more compute, more layers, better results. That held for years. It is holding less now. The latest models are improving, but the returns are shrinking relative to the resources being thrown at them. I believe that we are approaching saturation, not there yet, but close enough to feel it.

So where does that leave us?

The honest answer is that nobody fully knows. But there are directions worth watching. Spiking neural networks⁶ are one. Where standard networks pass continuous numbers between neurons, spiking networks communicate the way biological neurons do, in occasional discrete pulses. They are theoretically far more efficient. On smaller scales, they have already shown stronger recall and higher precision than standard networks for certain tasks. The problem is that they have never been scaled up anywhere near the levels that transformers have. The engineering gap is enormous.

The more immediate bet, and the one I find more promising, is algorithms. Silicon has fifty years of engineering behind it. It is not going anywhere. What needs to change is how we think about learning itself. Not systems that inhale the internet, but systems that read a textbook, ask a question, get something wrong, and adjust. Systems that treat sparse data as a feature, not a limitation.

That is a hard problem. It is also a wide-open one.

The brain and AI spent decades fighting. Now they need each other more than ever.

Here is the strange thing about this whole conversation. Neuroscience and AI have spent decades talking past each other. In the early days, neural network researchers and AI experts were openly at war. Rosenblatt, who built the perceptron, and Minsky, who tore it down, were not colleagues with a disagreement. They were rivals with a grudge. Rosenblatt took it badly enough that he eventually took his own life.

And yet, somewhere along the way, the two fields stopped fighting and started borrowing from each other. What we now call AI is, almost entirely, neural networks. The expert systems and symbolic logic that defined early AI are mostly gone. The thing that won was inspired by the brain.

The borrowing goes both ways, and that is what makes this interesting.

AI gave neuroscientists a new language. The concept of attention, developed for transformers, turned out to map surprisingly well onto how the brain retrieves relevant information from deep memory. The idea that you can build a working model of the world by accumulating enough weighted connections, something neural networks demonstrated clearly, gave neuroscientists a plausible mechanism for how the brain generalizes from experience to things it has never encountered before. Higher mathematics, for instance, is not something the brain evolved to do. And yet it manages. Weighted connections across neurons might be part of why.

Neuroscience, in turn, is pointing AI toward something it badly needs. The brain does not wire every neuron to every other neuron. It uses sparse, structured connections. It builds in timing. It hardwires certain things, like recognizing facial expressions, through millions of years of evolution, and learns everything else quickly from very little data. AI systems that try to replicate this, spiking neural networks, architectures that learn from sparse input, and models that separate hardwired priors from learned experience are still in their early stages. But the direction is clear.

Neither field has the full picture. But the fact that each field keeps finding useful things in the other is itself a signal. The brain and AI are not the same thing. They are more like signposts pointing at each other, each one saying, "Look over here, this might be how it works."

End Note

Professor Bhalla ended the evening with the thought: We are at the point where AI can already beat you on a narrow Turing test on a specific topic. Its grasp of facts is unbelievable. And yet you can still do a bit better than the AIs. Use it while you've got it.

I'm not sure whether that was reassuring or a countdown.

If that made you uncomfortable, here is something about free will. The brain is not deterministic. At the molecular level, individual chemical events are governed by probability, not fixed outcomes. But that does not prove free will exists either. Daniel Dennett [a prominent American philosopher and cognitive scientist known for his materialist views on consciousness, free will, and evolution] calls it an illusion, a story we construct after the fact to convince ourselves that what we did was our own idea. I do not disagree.

But the question I keep turning over is this: if the brain is just computation, and computation can run on silicon, at what point does the difference between the two stop mattering? And if it never stops mattering, what exactly is the thing that makes it matter?

The professor didn't answer that. I don't think anyone can yet. But I suspect the people who sit with that question longest will be the ones who figure out what comes next.

EDITOR’S NOTE

Dear Nanobit Readers,

Can you folks hazard a guess which company’s stock chart this is?

I will give you two hints: 

• ⁠It’s a Japanese company [you would have guessed from JPY].

• ⁠⁠My next hint would be that it is not an AI company, not a chip company; in fact, it's not even a tech company.

It’s Toto, a sanitary ware company from Japan; to put it simply, this company makes toilets!

Very recently, researchers and investors at Toto realized that the type of ceramics used in its manufacturing process plays an important role in semiconductor manufacturing. Ceramics are able to withstand very high temperatures, which makes them well-suited for semiconductor production.

As a result, the stock jumped nearly 1.5x over the past six months. I am showing you this because I want you to consider the bigger point: if a toilet company in Japan can see its stock rise 1.5x in six months by recognizing its role in a small but important part of the semiconductor manufacturing ecosystem, just imagine the influence the world’s biggest semiconductor and AI companies have on our everyday lives.

Factually, over 80% of the global economy directly or indirectly depends on semiconductor-enabled systems. 

Let me give you a hypothetical. Say tomorrow at 8:30 a.m., one of the world’s biggest semiconductor factories goes offline for the next six months. What do you think would happen to us? Any quick guesses?

Tech would slow down first. No more cars. Prices would increase. 

So you get the point, right? A huge share of the economy depends on semiconductors.

It would start with one sector, say automotive, getting hit first. Then defense systems. Then the internet. Then UPI. Then you would not get the next iPhone release or the next MacBook release, and the effects would keep spreading.

If you look around, everything from consumer electronics to computing and AI, to the internet, automotive, and defense systems, all of it directly and tangibly depends on semiconductors as the core foundation of these systems.

In today’s edition of Nanobits, we will walk through the history, science, and geopolitics of semiconductors. Here’s what we will cover:

• We will start with the science and unpack the technical foundations at a high level.

• Then we will move into the history of chips, look at where it all began, and how the industry evolved over time, along with the geopolitical forces that shaped it.

• Finally, we will cover the modern chip war that started in 2020 and trace how it has unfolded into the global story we live through today.

A Special Note for Women's Day

Today is International Women's Day, and it feels like the right moment to flag something worth paying attention to. Women are about 20% less likely than men to use generative AI tools like ChatGPT and Claude. And that gap has real consequences: the less women use these tools, the more AI systems get trained on data skewed toward men, and the wider the divide grows. 

This year, we ran two workshops on the roadmap to becoming an AI generalist for the Women of IIM AI Practitioners and Enthusiasts group, and the energy in both rooms made one thing clear: the will is there, the curiosity is there, and the capability is there. What works is a structured, peer-driven way of learning that gets straight to practical application. If you are a woman reading this and want that kind of structure, reply to this email. We are happy to help.

Sand, Switches, and Silicon

Everything around you is made of atoms. Atoms are made of protons, neutrons, and electrons. When electrons move, that movement is electricity. The entire game of semiconductors comes down to one question: can you control how electrons move?

Silicon sits right in the middle of the periodic table's fourth group, with four electrons in its outer shell. Metals have loosely held electrons, so electricity flows through them easily. Non-metals hold electrons tightly, so electricity does not flow at all. Silicon does neither by default. It can be pushed either way, and that is exactly what makes it useful.

Periodic table’s 4th group is highlighted in red

The way you push silicon either way is by mixing in a tiny amount of another element, a process called doping. Think of it like seasoning. Add the right element and you get extra electrons moving freely through the material. Add a different one and you create gaps that carry charge in the opposite direction. Either way, you now have precise control over whether electricity flows or not. Turn it on. Turn it off. That is a switch. In electronics, that switch is called a transistor.

A transistor has three contacts: a source, a drain, and a gate. Electrons travel from source to drain. The gate controls whether they can. No moving parts. Just a small voltage deciding the fate of billions of electrons across a distance invisible to any microscope you have ever seen. Those electrons are what make your phone, your car, and your airplane work! If you want to learn more about how a transistor works, you should watch this video:

Stack enough transistors together and you get a logic gate. A practical example: a car that will not start unless the seatbelt is on and the handbrake is released. Both conditions have to be true. That is an AND gate. Combine millions of logic gates, and you have a chip, a CPU, a GPU, or the processor running the AI model you used this morning.

To print billions of transistors onto silicon, manufacturers shine light through a stencil onto a wafer, a process called photolithography. 

This is the image of a photolithography machine.

As transistors got smaller, standard UV light became too coarse to print them accurately. The solution was Extreme Ultraviolet light, EUV, with a wavelength five times shorter than standard UV (You should watch the next video if you want to learn more about how chips are printed). One company makes the machine that generates it: ASML, a Dutch firm. Each machine costs upwards of 400 million euros. Why this matters is the subject of the next two sections.

Before we get there, one thing worth knowing about the numbers you read in chip headlines. When a chip is described as built on a "2nm process node," that is not a precise physical measurement. Until the early 2000s, the node number did correspond to the actual distance between transistor contacts. Now it is a generational label, a way of saying this chip is more advanced than the last one. The 2nm chip is not literally 2 nanometers across. But it is more capable, more power-efficient, and harder to make than the one before it.

From a hotel room in Chicago to a trillion-dollar industry

So now you know what a transistor is. But knowing what something is and knowing how to build a billion of them reliably, cheaply, and at the size of a DNA strand are very different problems. The story of how we got there is, more than anything else, a story of ego, defection, and very good timing.

The year is 1947. World War II ended two years ago. One of the clearest lessons from the war was that the vacuum tubes powering navigation systems and defense equipment were catastrophically unreliable. A vacuum tube is roughly the size of your palm, made of glass, and packed with mechanical parts. The first modern computer, ENIAC, used 17,000 of them. Researchers at Bell Labs were tasked with finding something better.

This is a collection of various vintage electronic vacuum tubes.

Three men worked on the problem. William Shockley had mapped out the physics of the transistor on paper but had not managed to prove it experimentally. On a December afternoon in 1947, his colleagues John Bardeen and Walter Brattain proved the theory worked, and Shockley was not in the room. He locked himself in a Chicago hotel room for two weeks and emerged with the design of the first functional transistor. All three shared the Nobel Prize in Physics in 1956.

This image shows a replica of the first working transistor, a point-contact transistor invented at Bell Labs in 1947. 

Shockley's ego did not shrink with the Nobel. He started Shockley Semiconductor Lab in California, handpicked eight brilliant engineers, and promptly made their lives miserable. All eight left, borrowed money from an East Coast investor named Sherman Fairchild, and started Fairchild Semiconductor. Shockley called them the Traitorous Eight. What they actually started was Silicon Valley. Gordon Moore, one of the eight, noticed that transistor counts on a chip were doubling roughly every two years. That observation became Moore's Law. From Fairchild came Intel, AMD, and National Semiconductor.

Meanwhile, in a TI lab in Dallas in the summer of 1958, a new hire named Jack Kilby had no paid time off yet. His colleagues left for summer break. Kilby stayed and solved the integration problem alone. He took a single block of germanium and doped different regions of it to form multiple transistors on one piece of material, no hand-wiring required. That was the first integrated circuit. Robert Noyce at Fairchild later improved the design using photolithography, making it manufacturable at scale. Kilby received the Nobel Prize in Physics in 2000.

This image shows the world's first working integrated circuit, demonstrated by Jack Kilby at Texas Instruments on September 12, 1958. 

The IC proved chips could be mass-produced. But mass demand created a new problem: who would make them consistently enough to supply the world? That question was answered in 1987 by Morris Chang, who founded TSMC with backing from the Taiwanese government. His bet was simple: the factory is the product. Companies should design. TSMC would build. Today, TSMC manufactures over 90% of the world's most advanced chips, all from one island, 180 kilometers off the coast of China.

That last detail is not incidental. It is the entire next section.

The Chip War nobody talks about at dinner

One company, on one island, 180 kilometers off the coast of China. That sentence is the entire premise of modern semiconductor geopolitics. To understand the tension, you need to understand who controls what in this industry and why each piece matters.

Think of the global semiconductor supply chain as a set of chokepoints. Whoever controls a chokepoint controls the flow of chips, and whoever controls the flow of chips has enormous leverage over the rest of the world. There are five players worth understanding.

The US: The Gatekeeper

The United States does not manufacture the most chips. It does something more powerful. It controls the ideas behind them. The biggest chip designers in the world, Nvidia, Qualcomm, Apple, Broadcom, are all American companies. The two firms that make the software engineers use to design chips, Cadence and Synopsys, are American. Key manufacturing equipment suppliers like Applied Materials and KLA are American. And critically, the US supplies intellectual property to ASML that goes into building EUV machines. That last point is the sharpest tool in the box. Because US technology is embedded in ASML's machines, Washington can tell ASML who it is and is not allowed to sell to. If you design a chip, you pass through the US at some point. There is no way around it.

Taiwan: The Factory Floor

TSMC is a $1 trillion company. It manufactures over 90% of the world's most advanced chips. Every iPhone processor, every GPU in every AI data center, and key chips in military systems all come out of fabs on a small island. Taiwan does not compete with its customers. It does not design chips. It builds what others design, and it builds them better than anyone else. That singular focus is its strength and its vulnerability. Taiwan's geopolitical importance is, in large part, a function of TSMC's existence. Without TSMC, the calculus around Taiwan changes significantly.

ASML: The Sole Supplier

One Dutch company makes the only machine capable of printing chips at advanced nodes. Each EUV machine costs upwards of 400 million euros, takes years to assemble, and involves hundreds of supplier components from across the world. No other company on earth makes one. This means every advanced chip, in every device, in every country, depends on a single manufacturer in the Netherlands. The US, by virtue of its IP embedded in the machine, effectively controls who gets access to it. China does not.

China: The Aspirant

China is the world's largest consumer of semiconductors. It has poured over $100 billion in state subsidies into domestic chip firms like SMIC, and its Made in China 2025 policy has pushed hard for self-reliance across the supply chain. But it cannot get EUV machines. Without EUV, it cannot manufacture at advanced nodes. Without advanced nodes, it cannot build the chips that power modern AI, defense systems, or high-end smartphones. China is working around this through parallel supply routes, domestic workarounds, and significant investment in older manufacturing processes. It controls demand but not the chokepoints. It also controls something else: rare earth minerals. These are materials used in magnets and electromechanical components across the supply chain, particularly in automotive and defense. China dominates rare earth mining globally, partly through its Belt and Road investments in countries like Afghanistan and Sri Lanka. That is its own form of leverage.

China also wants Taiwan. Part of why it wants Taiwan is TSMC.

India: The Emerging Player

India's role in this story has two sides. On the design side, India already punches well above its weight. Over 25% of global chip design engineering happens here, concentrated largely in Marathahalli, Bangalore. Qualcomm, Nvidia, Broadcom, and TI all have large design teams in India. IIT Madras has developed the Shakti processor, India's first domestically designed chip architecture.

On the manufacturing side, India is earlier in the journey. The India Semiconductor Mission launched in 2021 with a $10 billion incentive to build local manufacturing capacity. The first wafer fab has been approved in Gujarat, a joint venture between Tata and PSMC from Taiwan. A packaging and test facility, a joint venture between Micron and Tata in Sanand, Gujarat, was inaugurated recently. These are early steps, but they are real ones, and they fit into a broader global push to diversify manufacturing away from Taiwan.

Where does this leave us?

The semiconductor supply chain is one of the most concentrated in the world. A handful of companies, in a handful of countries, control the tools, the knowledge, and the factories that everything else depends on. A toilet company in Japan sees its stock rise 1.5x because its ceramics matter to one small part of this process. MSG, the food additive, is a meaningful input to chip packaging. The supply chain reaches into places nobody expects.

What started in a Bell Labs lab in 1947 as a solution to an unreliable glass tube is now the backbone of the global economy and the most contested industrial terrain on the planet. The next time you read about US export controls, Taiwan tensions, or China's chip ambitions, you will know exactly what is at stake. It is not just technology. It is the switch that everything else runs on.

If you want to go deeper, Chris Miller's Chip War is the single best place to start. It reads like a thriller and covers the full arc from the transistor's invention to the modern chip war. If you want to read something simpler, I would suggest “When The Chips Are Down” by Pranay Kotasthane and Abhiram Manchi. 

As a consumer, the choices you make about technology are not neutral. When you generate an AI image, run a prompt, or stream a video, you are drawing on GPU clusters that consume thousands of amperes of electricity and require enormous volumes of clean water for cooling. That energy increasingly comes from nuclear plants being built specifically to power data centers. The physical cost of AI is real and growing.

Two practical signals worth paying attention to when buying devices. Chips built on ARM architecture are more power-efficient than their x86 predecessors, which means less energy consumed over the life of a device. GaN chargers, now common from brands like Apple and Belkin, are significantly more efficient than traditional silicon chargers. Neither choice is dramatic, but across billions of devices, it compounds.

The next iPhone, the next AI model, the next car you buy: all of it runs on a switch smaller than a strand of DNA, made by a supply chain the whole world depends on and very few people think about.

EDITOR’S NOTE

Dear Nanobits readers,

Last week we covered IndiaAI Summit’s AI Governance & Policy track, the track that told us India is no longer a rule-taker in global AI standards. This week we go into the two tracks that had the maximum topics discussed under those themese: ‘Education & Skilling’ and ‘Society & Social Good’.

A quick reminder on where these came from. We built an AI workflow to parse all 529 sessions from the IndiaAI Impact Summit 2026 using Claude Cowork to categorize and analyze the full dataset, and NotebookLM to synthesize content across batches of sessions. Education & Skilling ran 57 sessions. Society & Social Good was the single largest track at the summit with 124 sessions. Together they accounted for 181 sessions and over 283,000 views in four days (the numbers have increased ever since).

I'll be honest about what surprised me. I went in expecting both tracks to feel like the "soft" side of the summit: inspiring examples, feel-good inclusion stories, the usual. What I found was much sharper than that. The sessions on cognitive colonialism, the AI memory wall, the purple economy, and the end of the IT pyramid are not soft topics. They just tend to get less coverage because they're harder to fit into a policy headline.

Let's jump right into the details.

FIRST, THE NUMBERS (AND WHAT THEY HIDE)

The full summit generated 875,673 views across 529 sessions in four days. Education & Skilling drew 128,814 views and Society & Social Good drew 154,750. That's about a third of all summit views, from more than a third of all sessions.

The most-watched session in Education & Skilling was "AI and the Future of Skilling" at 45,000 views. That's more than four times the next session in the same track. The most-watched in Society & Social Good was "AI Is Your New Teammate: How to Work Smarter, Build Faster, and Think Bigger" at 30,000. Look at those titles carefully: neither is about frameworks or policy architecture. Both are about individual agency. That's the audience signal again, same as in Part 1.

There's a view-count story worth pausing on. Women & Inclusion was a small track: just 14 sessions but drew 71,783 views. That's nearly as much as AI Governance & Policy drew across 92 sessions. If session count reflects what summits choose to programme, view count reflects what audiences actually want to hear. The gap between the two is real and consistent.

Some sessions that probably deserved more eyeballs: the sessions on frugal AI, the AI memory wall, and the purple economy (the $150 billion assistive tech market) each drew a few hundred views. These were among the most technically substantive and practically original ideas at the summit. They got buried in the noise of a 529 session event. That's the same dynamic we flagged in Part 1 with the Nepal Engagement Session at 32 views.

EDUCATION & SKILLING: 57 SESSIONS, ONE UNCOMFORTABLE QUESTION

The uncomfortable question running through all 57 sessions was this: India ranks 1st globally in GenAI course enrollment on Coursera. It ranks 89th in actual skill proficiency. That gap between knowing about AI and being able to use it is the whole problem. And it's a gap no certification is going to close.

The track was not just about classrooms and curricula. A significant portion of it was about the structure of the Indian economy and what happens to 370 million young people when the jobs they were trained for no longer exist. That's not a future risk. For entry-level IT work, it's already happening.

1. THE PYRAMID IS COLLAPSING AND THE REPLACEMENT DOESN'T EXIST YET

The traditional IT services model that built modern India runs on a pyramid. Massive entry-level hiring from engineering colleges. Standardised skilling. Labor arbitrage at scale. That model is now being dismantled from below.

Investor Vinod Khosla said it plainly across sessions: traditional IT services and BPO will effectively cease to exist by 2030. AI can already write 50 to 60 percent of basic code, which means the demand for junior engineers is collapsing. The pyramid is being replaced by what panelists called a "diamond", thin at the bottom, value concentrated in the middle with people who can orchestrate AI agents and apply domain knowledge, thin again at the top.

The flip side is equally disruptive. By 2026, the prediction is we may see the first one-person billion-dollar company. A single individual acting as a "systems architect," directing multiple AI agents, doing what once required an entire corporation. The cost of engineering is "rushing towards zero." What accrues value instead is the ability to understand and frame problems in the first place, not to execute them.

What this means for India's 370 million young people is the real unresolved question. The sessions flagged it honestly. They didn't pretend to have an answer.

2. COGNITIVE COLONIALISM AND THE FIGHT FOR INDIC INTELLIGENCE

The most philosophically charged argument at the summit wasn't about regulation or compute. It was about whose values get encoded into the AI systems that will teach India's children.

Researchers presented findings that current LLMs are trained on Western-centric data that misses fundamental cultural markers. One specific finding: "shame" appears 4.5 times more frequently in Bollywood subtitles than in Hollywood. That reflects a collectivist social structure, shame as community enforcement, that Western models, built on ‘pride-focused’, individualist data, simply don't model. A model trained to "align" to Western norms is structurally misaligned for much of India by design, not by accident.

The response being built is a parallel sovereign infrastructure. Bhashini is working to create small language models trained on India's 22 official languages and 19,000+ dialects. Gyan Bharatam is using AI to decode and "rejuvenate" ancient manuscripts, civilizational knowledge that risks being excluded from the global AI canon entirely if it doesn't get digitized. The Indian Army's sovereign military LLMs, which we covered in Part 1, are the defence application of the same principle. No borrowed brains.

The fear is that the alternative continuing to rely on models trained elsewhere, reflecting values calibrated elsewhere is a form of cognitive colonialism. The word was used by multiple panelists across multiple sessions. It wasn't hyperbole. It was the frame.

3. THE BAZAAR MODEL AND THE 96% MATH OUTCOME IN RAJASTHAN

The most optimistic framing at the summit and the one that felt most distinctly Indian came from MIT and UN experts who described the world moving from a "factory model" of AI to a "bazaar model."

The factory model: four or five giant companies build centralized models that everyone else accesses as a service. Intelligence flows down from the center. The bazaar model: every individual runs a personal, sovereign AI agent, an "always on" autonomic cognitive assistant that learns specifically from and for them. A math teacher in Rajasthan doesn't share the world's AI tutor. She has her own.

The evidence this isn't just theory: an AI-personalized learning programme in Rajasthan schools reportedly raised mathematics outcomes to 96% in just six weeks. That number is striking enough to warrant skepticism, and to warrant investigation.

India's Digital Public Infrastructure: UPI, Aadhaar, Bhashini, is the open rail on which this diffusion model can actually work at population scale, in a way no other country is currently positioned to replicate. And India's trust dividend matters here: digital infrastructure trust sits at 70% in India versus 25 to 30% in the United States. That's not a footnote. That's a structural asset.

A FEW THINGS FROM EDUCATION THAT DESERVE MORE ATTENTION

The Solo Paradox. Despite massive IT investment over decades, productivity gains have often been near zero because digital tools just overlaid old manual processes. Experts suggested AI can finally break this but only if organisations shift from individual productivity (a faster email) to collective productivity (AI agents running entire workflows autonomously). The potential productivity gain is estimated at around 4%. That's only unlocked when humans stop being the bottleneck and start being the architects.

Adalat AI and the "painkiller" sequencing lesson. This startup focused on automating courtroom stenography judges in India were writing depositions by hand, causing physical pain and creating massive backlogs. By solving the literal pain point first, they earned judiciary trust. Then they introduced "multivitamin" improvements like paperless filing. The lesson for any AI implementation trying to enter a slow-moving institution: lead with the painkiller.

India as second-order beneficiary. A compelling strategic argument: just as Walmart profited more from cars than Ford did, India may capture more value by building an application layer on top of foundational models built elsewhere than by competing in the high-capex race to build the foundational models themselves. The 95% of global GDP outside the IT sector — manufacturing, agriculture, informal economy — is the real prize.

SOCIETY & SOCIAL GOOD: THE LARGEST TRACK, THE HARDEST QUESTIONS

124 sessions is a lot to synthesize. What held them together was a question that sounds simple and isn't: who actually gets left out?

If Governance asked "what rules do we need" and Education asked "what skills do we need," Society & Social Good asked something harder. Not just who benefits from AI, but who gets excluded by it, invisibly, because the data that trained it didn't include them, or the connectivity required to use it doesn't reach them, or the language it speaks isn't theirs.

The track ranged from highly technical, biosecurity, the AI memory wall, post-quantum cryptography to very practical, road safety, maternal healthcare, courtroom efficiency. The binding thread was that AI is not neutral. How it diffuses determines whether India's growth story includes 1.4 billion people or concentrates its benefits among those already connected.

4. COMPUTE SOVEREIGNTY AND THE BIOSECURITY BLIND SPOT

The most geopolitically urgent insight across both tracks of the summit and it appeared in the Society sessions with particular clarity is about compute. GPU access has moved from being a supply chain question to a sovereign strategic asset. The numbers: 90% of advanced chips are manufactured in a single location (Taiwan). India ranks first in the world in AI skill penetration and has limited domestic compute infrastructure. That gap between talent and hardware is a strategic vulnerability in a way that matters for every social application being built.

A country that leads the world in AI skills but imports the compute that runs AI is, to use the summit's framing, one geopolitical event away from having its intelligence infrastructure turned off overnight. That's not an abstract risk. API limits, sanctions, and quiet policy changes have already been used as leverage in other technology domains.

The biosecurity dimension got less attention than it deserved, which is its own form of concern. Over 1,500 AI bio-design tools now exist. They have decoupled biological risk from physical containment. Traditional biosecurity relied on inspecting physical labs and tracking material transfers. That model is now outdated. Pathogen modeling and DNA sequence optimization can happen entirely in the digital domain, upstream of any physical lab. The governance infrastructure for this doesn't exist yet. The sessions acknowledged it. They didn't solve it

5. DPI AS THE WORLD'S AI DISTRIBUTION RAIL AND ITS PARADOXES

India's Digital Public Infrastructure is increasingly being positioned not just as a domestic asset but as a blueprint the rest of the Global South can adopt. The DPI-to-AI model uses open, decentralized networks like the Beckn protocol to let individual farmers and local artisans compete on the value they create rather than the platform they use. The Agri-Connect programme in Uttar Pradesh is already being replicated in Ethiopia and Brazil.

The "Blue Dot" revolution makes the most practical version of this tangible. AI makes local jobs, welfare schemes, and services digitally discoverable as location-based points on a map. "Purple dots" for people with disabilities. "Orange dots" for other marginalized cohorts. The idea is that a smallholder farmer in UP can find the scheme she's entitled to through a voice query in her dialect, the same way someone in Mumbai finds a restaurant. That's a deceptively large shift.

But DPI comes with a genuine paradox that the sessions engaged honestly. Aadhaar-powered AI can detect deepfakes and fake biometrics at population scale which is exactly what you'd want for a national identity platform. The same AI capabilities enable industrialized deception through those same tools. The response being built involves Post-Quantum Cryptography to future-proof biometric data against quantum computers, and privacy-enhancing technologies that can verify identity without ever sharing the raw biometric data. This is quiet infrastructure work that rarely makes headlines. It's arguably the most important thing being built.

6. THE PURPLE ECONOMY, PHYSICAL AI, AND THE ROAD SAFETY CRISIS

Some of the most interesting ideas at the summit were the least watched. The "purple economy", assistive technology for persons with disabilities, represents a potential $150 billion market in India alone. The panelists making this argument weren't appealing to charity. They were making a business case: designing for accessibility forces universal design, which makes products better for all users. The fact that this is a $150 billion market that the tech industry has largely ignored says something about whose needs get priced into roadmaps.

"Physical AI", where intelligence moves from screens into the physical world through autonomous vehicles, robots, and smart factories was flagged as the next major wave. India's argument for why it's positioned to lead is interesting: its IT and CS talent pool can treat physical manufacturing as a software-defined problem. Using simulation and digital twins, developers can train robots in virtual environments at near-zero cost before real-world deployment, bypassing the capital-heavy barriers that have historically limited smaller enterprises.

India's road safety numbers are a specific place where this plays out. India has 1.5 to 2% of the world's vehicles and contributes 11 to 12% of global road fatalities. Traditional road signs are subjective and routinely ignored. The proposed solution isn't more signs. It's connected vehicle ecosystems and intelligent infrastructure that automatically reduces a car's speed, or clears a corridor for emergency responders, or routes traffic in real time. India's scale and its severity of the problem make it a natural testbed for this technology in a way that the Netherlands or Singapore is not.

A FEW THINGS FROM SOCIETY THAT DESERVE MORE ATTENTION

The AI memory wall. While the industry obsesses over model size, the actual technical bottleneck is emerging elsewhere. Hardware growth cannot keep pace with the exponential demand for memory and compute. Researchers at the summit suggested the next race in AI is not parameters but context window, the working memory that enables complex reasoning over long conversations. Breakthroughs in mathematical optimization are enabling these tasks to run on CPUs or edge devices like a Raspberry Pi at a fraction of GPU cost. This matters enormously for the frugal AI deployments India is betting on.

Knowledge displacement vs. job displacement. Job displacement gets most of the attention in AI and work discussions. The summit surfaced a subtler risk: knowledge displacement. AI models trained on codified digital data exclude centuries of oral traditions and community-specific practices that have never been digitized. In a country with over 100 languages and dialects, the "compute brain" risks erasing cultural nuances of communities with small digital footprints. Bhashini's language digitization work is the most visible response to this.

The Europe-India third axis. While the US and China dominate five major AI leadership metrics, a proposal emerged for a coalition representing two billion people: Europe's foundational research and capital combined with India's STEM talent and global distribution networks. The goal is strategic autonomy preventing the world from operating inside value systems set by only two countries. This is the first time I have seen it articulated as explicitly as it was at this summit.

Jobless growth as the real policy test. India's GDP is growing. Employment is not growing at the same rate. AI companies like OpenAI have slowed entry-level hiring due to AI efficiency while simultaneously reporting that overall job growth within their enterprises is increasing, because employees are becoming more productive. That tension doesn't resolve cleanly. It's the policy test that will define the next decade.

END NOTE

Across both editions, a few things have come through consistently enough to trust.

India is not one story. It is a country simultaneously first in AI skill penetration and dependent on a single geography for the chips that run AI. It is building sovereign military LLMs and still working out how to give 1.4 billion citizens the connectivity to use them. The summit held that tension honestly, more so than most AI events anywhere.

The frameworks that resonated weren't about restriction. They were about architecture. DPI as the open rail for AI diffusion. Frugal AI as a design philosophy, not a compromise. Sovereignty defined not as isolation but as the absence of someone else's kill switch. The bazaar over the factory. The second-order beneficiary as a legitimate strategic position not a consolation prize.

What the summit couldn't answer and didn't pretend to: is sequencing. India has the infrastructure layer, the talent, the trust, and the political will. What it's still working out is the order of operations when the problems are this large and the window for getting it right is this short.

We built this workflow to catch what a human couldn't watch. Across two editions, 529 sessions, and 875,000 views, I think we got the shape of it right. The texture lives in the sessions that got 83 views. Those are worth watching too.

And if you are interested in learning what workflow we build, check out the workflow below

Until next time!

EDITOR’S NOTE

Dear Nanobits readers,

The IndiaAI Impact Summit 2026 just wrapped up, and most of us could not attend it in person. So in order to learn about all the interesting session that happened, I ran an AI-powered workflow to parse through all 529 livestreamed sessions from the summit's YouTube channel, extract structured insights, and map the entire event from the outside, using from what was publicly broadcast.

We fed all those video sessions through NotebookLM for thematic summaries and used Claude Cowork to analyze the full stream dataset, categorize sessions by topic, and surface patterns in what was discussed, watched, and what wasn't.

The number alone should stop you: 529 sessions across 4 days. That's roughly one new livestream every 11 minutes, for four consecutive days 😲. Whatever you think of the IndiaAI Summit, that is a genuinely staggering volume of content, and it raises a serious question: who is actually synthesizing it?

That's what we tried to do. And what we found was not what I expected.

The summit generated ~875,000 total views across all streams (in just 4 days). The most-watched session was "AI and the Future of Skilling" at 45,000 views, followed by "Her First Algorithm, India's Next Breakthrough" at 36,000, and "AI Is Your New Teammate" at 30,000. The research community showed up too, the AI Research Symposium keynote featuring Demis Hassabis, Yoshua Bengio, and Yann LeCun drew 19,000 views, which is probably the highest-signal session in the entire dataset.

But here is the editorial insight hidden in the view counts: the topics that audiences voted for with their clicks were skilling, inclusion, and practical application, not policy architecture or governance frameworks. People wanted to know what AI means for them, not what it means for nation-states. That gap between what summits talk about and what people actually want to hear is, itself, worth paying attention to.

We organized the 529 sessions into 14 categories. The three that accounted for the most content by volume were:

• Society & Social Good — 124 sessions

• AI Governance & Policy — 92 sessions

• Education & Skilling — 57 sessions

Over the next two editions, we will go deep on these three. Today, we're covering AI Governance & Policy: the largest policy-focused track at the summit, and arguably the one with the most global stakes. In next week's edition, we'll cover Education & Skilling and Society & Social Good, which is where a lot of the more surprising, human-centered stories live.

Nanobits: We generated a word cloud from the 529 session topics

Let's get into it.

INDIAAI SUMMIT: THE SCALE

Before we talk governance, let's look at what the summit was in aggregate, because the shape of the event tells a story of its own. We have aggregated the list of sessions by category and views for you in this excel.

Some sessions that probably deserved more eyeballs: "The Future of Public Safety: AI-Powered Citizen-Centric Policing" (83 views), "Nepal Engagement Session" (32 views). These were not unimportant topics. They just got lost in the noise of a 529-stream event. That's a feature of scale, not a failure of curation.

The Global South thread appeared across virtually every category: governance, healthcare, agriculture, education, diplomacy. It was not a theme, it was the load-bearing wall of the entire summit..

Category Distribution of all 529 sessions across 4 days

AI GOVERNANCE & POLICY: THE STORY IN 92 SESSIONS

The most-watched governance session was "Embedding Trust in AI Innovation: Governance and Quality Infrastructure" at 9,800 views. Second was "India's Intelligence Infrastructure for Sovereign AI" at 6,200. Third: "AI in Public Audit: Driving Transparency and Accountability" at 6,100.

What do those three sessions have in common? They are all about making governance real: not principles, not frameworks, but actual infrastructure, actual audits, actual accountability mechanisms. That's the signal the audience sent. People are done with abstract ethics. They want to know what happens next.

Below we cover the common and most interesting themes that emerged across those 92 sessions.

1. INDIA IS NOT A RULE-TAKER ANYMORE

Perhaps the most striking governance revelation from the summit was about certifications. India is currently second in the world in accredited AI certifications: specifically ISO/IEC 42001, the international standard for AI management systems, trailing only the United States and ahead of the UK.

Axis Bank became the first bank globally to receive this certification. That is not a minor detail. That is an Indian institution setting a pace that European banks haven't matched.

For years, the narrative around India in global AI governance was reactive: wait for the EU AI Act, watch what the US does, adapt. The summit challenged that narrative directly. India is now an active co-author of global AI standards, not a late adopter.

2. SOVEREIGNTY MEANS NO ONE ELSE HAS A KILL SWITCH

A recurring and genuinely clarifying idea across the governance sessions was a new working definition of AI sovereignty. Not "we own our data" or "we have our own LLMs." Sovereignty, as experts framed it, means ensuring that no foreign entity has a kill switch on your AI infrastructure.

That includes: the physical data centers, the "control plane" that orchestrates AI workflows, and the foundational models themselves. If any of those three layers sits outside your borders, it can be shut off: through API limits, sanctions, or a quiet policy change by a company headquartered 8,000 miles away.

The Indian Army's decision to develop its own sovereign military LLMs, and to work toward eliminating dependency on foreign GPUs by training on CPUs, is the clearest expression of this logic in practice. It's a sovereign bet that access to intelligence cannot be rented.

3. THE GLOBAL ASSURANCE GAP AND INDIA'S ANSWER TO IT

Sessions on AI safety repeatedly surfaced a structural problem: the infrastructure for verifying AI safety is concentrated in a handful of nations. The capacity to red-team models, audit systems, run independent evaluations lives almost entirely in the US and Europe. The Global South is at risk of inheriting AI systems it cannot independently verify.

The summit saw the launch of Astra: AI Safety Trust and Risk Assessments — the first AI safety risk database built specifically for the Indian context. The problem it addresses is what was called "contextual blindness" in existing international risk repositories: they don't account for caste bias, they don't account for low-connectivity deployment environments, they don't account for the safety dynamics of a 22-official-language country with 19,000+ dialects.

Astra is a seven-step framework that attempts to localize risk identification. The larger ambition is clear: India doesn't want to inherit a "one-size-fits-all" Western safety narrative. It wants to write its own.

4. COMPUTE IS THE NEW OIL AND INDIA IS IMPORTING IT

One of the governance conversations that generated real tension was around compute. The summit made clear that GPU access has moved from being a technical supply chain question to a sovereign strategic asset, comparable to oil and gas in the 20th century.

The numbers are striking: 90% of advanced AI chips are manufactured in a single location (Taiwan). A small number of companies control chip design globally. India currently ranks first in the world in AI skill penetration but has limited domestic compute infrastructure to back it up.

A country that is first in AI skills but dependent on foreign compute is, in the words of summit panelists, vulnerable to "digital neocolonialism", a situation where a geopolitical conflict or a policy change by a foreign company can restrict your nation's access to intelligence infrastructure overnight.

The summit's answer is not yet fully formed. But the direction is clear: indigenous data centers, diplomatic access to compute, and long-term investment in alternatives to the current GPU monopoly.

5. THE SOFTWARE LIABILITY ARGUMENT NOBODY WANTED TO HEAR

One of the sharper governance arguments came from a comparison most people in AI don't want to make.

In the automotive industry, manufacturers accepted liability for car safety. The result was a revolution in safety standards — seatbelts, crash tests, recall mechanisms. None of that happened voluntarily. It happened because liability created real consequences for getting it wrong.

The software industry has historically rejected liability, typically limiting legal exposure to the cost of a subscription refund. Panelists at the summit argued that this asymmetry is no longer sustainable as AI systems start making consequential decisions in healthcare, welfare, and public services.

Liability is a governance mechanism that has worked for thousands of years. The question being asked, quietly, but seriously, is whether AI developers should be the one industry that gets to opt out of it.

6. AGENTIC AI AND THE GOVERNANCE GAP WE'RE NOT READY FOR

The governance session on Agentic AI, AI systems that don't just assist but act autonomously drew 863 views, which places it in the upper tier for non-keynote governance content. The reason is probably that this is the policy frontier that feels most immediate.

Traditional governance frameworks assume a human makes the decision. The human might use AI to inform the decision, but the human is the actor. Agentic AI breaks that assumption. When an AI agent runs an entire workflow autonomously, procuring, deciding, communicating, executing, who is the responsible party?

The sessions did not have clean answers. What they had was urgency. AGI may be three to seven years away, depending on who you ask. Agentic AI that operates at the edge of current governance frameworks is already deployed. The gap between what AI can do and what governance systems are designed to handle is widening faster than anyone is comfortable with.

WHAT WE HAVEN'T HEARD ENOUGH OF?

The governance track had 92 sessions and ~87,000 views. Robust by any measure. But a few themes felt underrepresented given their stakes:

The biosecurity angle: AI bio-design tools that decouple biological risk from physical containment, got relatively little attention in the governance track despite being, arguably, the most asymmetric risk in the entire AI landscape. Over 1,500 AI bio-design tools exist. Periodic lab inspections are no longer an adequate safety mechanism. This is a governance gap that didn't get the session time it deserved.

Child safety got more traction, "AI and Children: Turning Safety Principles into Practice" drew 3,600 views and "Child-Centric AI Policy" drew 1,100, which reflects real momentum. We are sure the onground reality could have been different in terms of the crowd. But the conversation was still mostly about principles. Implementation frameworks are behind.

HOW WE ANALAYZED THESE MANY SESSIONS: THE WORKFLOW

Since we couldn't attend 529 sessions, we built something to help us process them.

Here's what the workflow looked like: We started with the IndiaAI Summit's YouTube channel and pulled the complete stream dataset: every video title, view count, and stream date across all four days. We then used Claude Cowork to categorize sessions by topic, identify the highest-engagement content within each category, and surface quantitative patterns across the dataset. For the actual content for any one category (in this case AI Governance and Policy) & what was said in those sessions, we analysed 96 videos through NotebookLM (in multiple batches), which synthesized thematic summaries across each set.

The result was a structured, layered view of the summit that would have taken weeks to do manually. The combination of Claude Cowork for structured data analysis and NotebookLM for content synthesis was genuinely powerful. Neither tool alone would have given us this.

We also made a short video walking through the workflow. If you're covering large events, conferences, or any high-volume content scenario, this approach is worth trying.

The honest caveat: this workflow gives you the shape of conversations, not the texture. We did not watch every session. We caught what surfaced at scale. Some of the most important things said at a conference like this happen in the sessions with 83 views, not the ones with 9,800. That's always the trade-off.

END NOTE

If you're building AI products: The governance discussion is not just about regulation, it's about infrastructure. Trust infrastructure, certification infrastructure, safety databases. These are going to become table stakes for enterprise AI deployment, particularly in markets like India that are moving quickly on formal standards.

If you're in policy or government: The liability argument will not go away. And the compute sovereignty question will become a domestic political issue faster than most governments are prepared for. Building indigenous AI infrastructure is not a technology problem; it's a foreign policy problem dressed in a GPU chassis.

If you're thinking about AI safety: The Astra launch is worth watching, not because one database solves localized safety, but because it signals a model for how non-Western countries can produce their own safety infrastructure rather than inheriting frameworks built for different contexts.

Next week, we'll cover what happened in Education & Skilling (the most-watched category) and Society & Social Good (the largest category by volume). That's where the human-centered stories live, the 2,000 students who built real apps in three hours, the AI-personalized math program that reportedly hit 96% outcomes in Rajasthan schools in six weeks, and the "Digital Parliament" that aims to make India's legislative history searchable across 22 languages.

That's the edition I'm most excited to write.

Until then!

EDITOR’S NOTE

Dear Nanobits Readers,

Every week, I hear some version of the same complaint from readers: “I’ve finally found prompts that work…, and now I spend half my life copy‑pasting them into new chats.” One Reddit user put it bluntly: “The solution that comes to mind is to keep the prompts in a notepad and copy them, but this is not a very convenient solution.” If you’re formatting the same weekly report, rewriting the same kind of LinkedIn post in your brand voice, or re‑explaining your product’s ICP to Claude every single time, you’re feeling this pain already.

Claude Skills exist to kill that repetition. They’re not “fancy prompts,” as one r/AI_Agents commenter said, but “saved instruction packages that teach Claude how you work. So instead of re‑explaining, you’re re‑using.” Another community cheatsheet summed it up nicely: “Long prompts break down because context gets noisy. Skills move repeatable instructions out of the prompt. Claude loads them only when relevant.” That’s why people like Simon Willison are calling Skills “awesome, maybe a bigger deal than MCP,” and predicting a “Cambrian explosion” of shared workflows this year.

In this issue, here’s what we will cover: what Claude Skills are in plain English, why they matter if you’re a marketer, product manager, or an operator, how they differ from projects, plug‑ins, sub‑agents, and Cowork, when to use each, and how to build a tiny first skill that saves you from ever re‑typing that perfect prompt again.

What are Claude Skills?

Think of Skills like teaching your favorite barista your exact coffee order. The first time, you explain everything: oat milk, extra hot, one pump of vanilla, no foam. After that? You just say "the usual" and they know exactly what to make.

Claude Skills work in the same way. They are Claude’s way of letting you stop re‑explaining yourself every time you open a new chat. They’re small, reusable instruction packs – like mini playbooks or SOPs – that you save once and Claude can quietly pull in whenever they’re relevant, across chats and projects.

One Redditor described the difference nicely: “Pre‑prepared prompts are conversation starters. Skills are collections of guidelines, scripts, and tools that Claude automatically accesses when needed.” Instead of pasting your “how to write in our brand voice” prompt into every conversation, you turn that into a Skill; Claude can then load it whenever you ask for marketing copy, without you remembering the magic wording.

Another creator compared Skills to company SOPs, finally doing something useful: “They are basically specific Standard Operating Procedures for Claude… built for a very specific reason, where the steps are repeatable.”

Under the hood, Skills use “progressive disclosure", which means they activate only when they're actually useful. If you've saved a "format my meeting notes" skill, Claude won't randomly apply it when you're asking about recipe ideas. It reads what you're working on and thinks, "Oh, this looks like meeting notes. Let me use that playbook."

You can even combine several at once – for example, a persona skill plus a brand‑voice skill plus a “turn this into a newsletter” skill.

Practically, that means you move from clever one‑off prompts to a small library of reusable ways‑of‑working that follow you around wherever you use Claude.

Why is Claude Skill relevant? Why should it be important to you? What does it mean for your work?

Claude Skills solves the “I finally got the prompt right… and now I have to type it again tomorrow” problem. One Reddit user joked that their life had become “a graveyard of half‑remembered prompt recipes in Notion, all slightly different and none reusable.” One Twitter user captured this frustration: "I've been screenshotting my best prompts and keeping them in a Notes app like some kind of digital hoarder. This is not sustainable."

People are excited about Skills because it fixes three annoying problems at once.

• Repetition: No more re‑explaining your brand, product, or formatting rules in every new chat. A content strategist on Reddit shared: "I had a 200-word prompt I pasted into every chat for writing LinkedIn posts. Now it's a skill. I get my time back."

• Inconsistency: Your outputs stay consistent. A marketer on LinkedIn said Skills were “the first time AI consistently wrote like me across channels,” after turning her tone guidelines into a skill.​

• Lost workflows: A creator who tested 30+ community skills said it best: “My favorite prompts graduated into skills so my future self doesn’t forget how I did that thing.”

Simon Willison wrote that “Claude Skills are awesome, maybe a bigger deal than MCP,” arguing that MCP gives models more hands, but Skills give everyday users a way to encode their own reusable logic and standards without writing a line of code.

On Hacker News, commenters echoed this: once your best prompts become portable skills that travel with you across chats, projects, and even teams, the real bottleneck stops being “which API can I hit?” and starts being “what repeatable ways of thinking do I want to teach my AI coworkers?”

How do Claude Skills help different roles/job functions?

Skills land differently depending on your job, but the pattern is the same: you turn a repeatable way of working into something Claude can do on demand.

Marketers
One B2B marketer built a “brand voice + offer matrix” skill so Claude always writes like their company and tailors messaging to different segments; she said it was “the first time I didn’t have to fight the model to stop sounding like a SaaS landing page template.” Others use skills to standardize campaign recaps and weekly performance reports so every slide deck comes out in the same structure.

Product managers
A PM on Reddit shared two real‑world skills: one that turns rough notes into a PRD in their team’s exact format, and another that forces any feature idea through a fixed “problem → users → risks → rollout” checklist before it’s considered. Another uses a status‑update skill so every weekly update has the same sections, which their leadership now expects.

Sales / SDRs
Sales folks use skills as reusable playbooks: one for “research this account and score it against our ICP,” another for “draft 3 outreach email variations for this persona,” and a call‑prep skill that spits out a one‑page brief from a LinkedIn profile and website. One SDR wrote that after moving these into skills, “I stopped hunting for that one good prompt buried in Slack.”​

Analysts / Ops
An analyst posted: "I have a CSV cleanup skill that spots common data errors we see, suggests fixes, and flags outliers. It's like having my own QA checklist built in." Operations teams are building skills for weekly report formatting, pulling the same metrics every time, without explaining what matters

How to create your first Claude Skill?

1. Open Claude App

2. Click on your profile

3. Go to Settings and click on Capabilities

4. Scroll down to the Skills section and click on +Add

5. Upload the zip file named competitive-battlecard-skill (I will share this file at the end of the newsletter).

6. You’re ready to use the new skill to spy on your competitor and gather intel for a deal that you’re both competing on.

How to add a new Skill to Claude

Create a competitive battlecard comparing your offering with the competitor’s using the new Claude Skill

Step 1: Pick One Narrow Task

Don't try to solve everything at once. Pick something you do weekly that follows the same pattern. For nanobits, I could create a "newsletter brand voice" skill. For a PM, maybe "feature spec template." For sales, perhaps "competitive battlecard generator."

Let me show you a real skill I built: the Competitive Battlecard Generator. It creates sales intelligence docs that help reps win against specific competitors.

Step 2: Write Down What Claude Needs to Know

Skills live in a simple document (usually called SKILL.md). Think of it like writing instructions for a really smart intern. Here's what mine includes:

• What it does: "Creates battle-ready competitive docs with feature comparisons, win themes, trap questions, and objection handling"

• When to use it: "Trigger when I mention competitor names or ask for battlecards"

• What format to follow: Sections for competitor snapshot, our advantages, their weaknesses, questions that expose their gaps

• Examples: "Build a battlecard against HubSpot" or "Update our Salesforce battlecard with recent pricing changes"

Step 3: Add Constraints and Examples

Tell Claude what NOT to do. For my battlecard skill: "Never make up competitor features. If you don't know, say so and suggest researching." Then give 2-3 example prompts showing how you'll actually use it.

Step 4: Test and Refine

Use your skill a few times. Does Claude apply it when you expect? Does it miss the mark sometimes? Adjust your instructions based on what happens.

Write a detailed prompt that includes context about your company, what you know about your competitor, and the specifics of the deal.

Here’s the final output.

That's it. You've moved from clever prompts to a reusable capability that works across every chat, every project, forever.

How are Claude Cowork, Skills, Projects, Plug-ins, and Sub-agents connected? When should you use each feature?

Think of Claude’s ecosystem as a small team with different jobs: chat, memory, workflows, and hands. Skills are the playbooks that tie them together.

Here is a list of Claude features that you should know about:

How they connect

A nice way a Redditor framed it: “Projects hold the problem, connectors touch the world, skills define the method, and agents (Cowork + sub‑agents) run the play.”

For example, imagine you’re doing competitive research for a launch:

• You create a Project called “Q2 launch – Competitive Intel” and drop in your docs and notes.

• You install connectors for Google Drive, Sheets, and maybe Notion so Claude can read/save assets.

• You add a Skill like your “Competitive Battlecard Generator” that defines exactly how you want battlecards structured.

• Inside that project, you spin up regular Claude to brainstorm questions and refine your strategy.

• You then hand the heavy lifting to Cowork, which uses your Skill + connectors to generate battlecards as files in a folder.

• Under the hood, Cowork may spawn sub‑agents to parallelize: one pulls G2 reviews, one parses your win/loss notes, one drafts “how we win vs X.”

Same pattern for a marketer or PM: Projects = “this campaign/roadmap,” Skills = your templates & voice, Connectors = access to docs and tools, Cowork/sub‑agents = muscle, regular Claude = conversation.

For most people upskilling in AI, the progression looks like this: start in regular Claude, graduate to Projects for anything important, then add Skills for your repeatable methods. Once those feel natural, you can let Cowork + connectors and, later, sub‑agents turn those saved methods into fully automated workflows.

End note

If you remember one thing from this issue, let it be this: Skills are reusable brains, not just longer prompts. Use them to capture how you do things – your brand voice, your way of structuring a PRD, your personal rules for a good sales email – so Claude can bring that with it into every new project instead of you copy‑pasting from a Notion graveyard.

Before you start experimenting with Claude Skills, here are some things to note:

• Create separate folders/files for Claude Skills and resource files (knowledge base) from SKILL.md). It is a game-changer for keeping things clean.

• Build small, focused "micro-skills" that chain together instead of one giant, monolithic skill. This is more reliable.

• Always hand-edit the skills Claude generates. They're often too verbose and need to be refined to work consistently.

• The real magic happens when you combine skills with hooks and MCP servers to automate complex workflows.

• Do include real examples of what you want. Do test your skill a few times and tweak it. Don't expect perfection on the first try.

Here's your challenge: pick one thing, like planning product launches with workback schedules and RACI matrices, writing weekly status updates, or drafting client emails. Turn that into your first skill.

For example, a marketer could build a "Product Launch Planner" skill that classifies launches into tiers (major, significant, minor) and generates the right planning docs for each. Tier 1 launches get full campaigns with 8-12 week timelines. Tier 3 launches get streamlined 1-2 week plans. One skill, multiple scenarios, zero repeated prompting.

Start small. Build one. See what happens. Then come back and tell me what you created. I read every reply to these newsletters, and I want to hear what you build.

EDITOR’S NOTE

Dear Nanobits Readers,

Claude Cowork dropped like a bomb in the AI community a couple of weeks back, and the internet has been having a collective existential crisis about it.

On X, @cryptopunk7213 asked "how big of a deal is Claude Cowork really?" and the replies ranged from "top 3 most exciting tech moments of my life" to "it just killed my company (and might kill yours too)".

Over on Reddit, one user reported it “deleted 11GB of files accidentally" during a folder cleanup, prompting a wave of nervous jokes about AI agents with delete permissions. The r/ClaudeAI community is split between people building entire research workflows and those treating it like a digital coworker who needs constant supervision.

As @AndrewCurran_ put it, we're all "getting Claude-pilled" - simultaneously amazed by what it can do and terrified of what it might do unsupervised.

Welcome to the agent era, where your AI coworker is brilliant, ambitious, and occasionally needs a babysitter.

What is Claude Cowork?

Claude Cowork is Anthropic's new "Claude Code for non-developers" - a macOS‑only agent that lives inside Claude Desktop and can autonomously execute multi‑step tasks on your computer. Unlike a regular chat where you get suggestions, Cowork actually does the work: it reads files, edits documents, browses websites, and orchestrates complex workflows while you grab coffee [or your choice of drink].

The architecture is impressive. It runs in a sandboxed Linux VM via Apple's Virtualization Framework, mounting only folders you explicitly grant access to. This means it literally cannot see your entire hard drive - just the directories you point it at. The agent uses an Observe‑Plan‑Act‑Reflect loop, breaking down your request into sub‑tasks, executing them, and showing you a live progress dashboard.

Think of it as hiring a very junior but incredibly fast analyst who works 24/7, never complains, but occasionally needs you to double‑check their work before they delete something important.

Claude Cowork Interface

The setup is super simple and takes less than 5 minutes. It’s currently available only on Mac. You need a Pro or Max account, the Claude desktop app, and Claude’s Google Chrome extension.

What are the features of Claude Cowork?

I spent a few days exploring how Cowork works and how it differs from regular Claude chat. Here’s a breakdown of what stood out to me:

1. File Access and Management
You pick a folder on your machine, grant Claude access, and then the AI can read, edit, and organize those files. This means messy folders can suddenly look tidy without you having to touch every file. It can generate spreadsheets from scattered data, create presentations from transcripts, and batch‑rename files based on content.

2. Autonomy on Tasks
Once you tell Claude what you want done, it builds a roadmap and works on it until completion, looping you in only when it needs direction or has results.

3. Multi-Task Queuing
You’re not limited to one thing at a time. Claude can take on multiple tasks at once and work through them while you do other things.

4. Connector Integration
Beyond folders, Claude Cowork can link to other apps via connectors. That means tasks involving web pages, external apps, or connected services become part of Claude’s to-do list.

5. Safety and Control Prompts
Claude will always ask before doing anything that might be risky like deleting or overwriting files. You stay in control at every step.

6. Multi-Platform Automation Potential
Some early experiments out in the world show that Cowork can even automate browser tasks or more complex workflows when paired with tools like browser connectors. For instance, it can visit websites, fill forms, pull data from public pages, and navigate through multi‑step flows - though some sites block automated browsing.

7. VM Isolation 
The sandboxed approach means even if Cowork goes rogue, it's contained within the virtual machine and can't access your main system.

I can already think of four big wins for my workflow, and I’ll share them next.

Four things I actually did with Claude Cowork

1. Scraping LinkedIn saved posts into a structured insight engine

Like most marketers, my LinkedIn “Saved” folder is a graveyard of half‑remembered insights. I had 200+ saved posts about AI agents, GTM engineering, industrial saas, and a bunch of other things – all theoretically useful, practically inaccessible.

So I set up a Cowork task with one simple goal: turn my saved posts into a living Google Sheet I can sort, filter, and mine for ideas. I asked Cowork to pull my recently saved posts, then for each one extract the link, post type (text, carousel, video, PDF), the core CTA, publish date, and a 2–3 line summary. On top of that, I had it tag who the post was really for (marketers, GTM engineers, sales folks, founders, developers, product managers, etc.) and assign a “relevancy to me” score out of 100 based on my LinkedIn profile and the topics I typically save.

The result was a neatly structured sheet where every row is a saved post, and every column is a lever: I can filter for “high-relevance posts for product marketers,” find posts with strong CTAs to model for my own campaigns, or sort by topic to plan Nanobits issues. My “I’ll read this later” pile effectively turned into a personal insights database and content idea backlog, instead of a bottomless scroll I never revisit.

A couple of observations from my run here: 

1. Some saved posts didn’t include their original links. That’s on the prompt design, so be sure to refine the prompt to explicitly pull the source URL.

2. I forgot to set a time range for the analysis, which made the search use more tokens than needed. Always define the date or range upfront.

3. Install the Claude Chrome extension before you start so the agent can crawl the pages you want.

2. Detailed event attendee research for hyper-personalized outreach

I'm also using Cowork as a pre-event SDR [sales development representative] for high-stakes sponsorships.

One of the cybersecurity clients I work with is sponsoring an event to generate a revenue pipeline for Q1 and Q2 of 2026, and instead of generic “looking forward to connecting” emails, I wanted real intel on every attendee so the leadership team could walk in with context. I dropped the attendee list and our sponsorship proposal into a Cowork workspace, then asked it to research each person’s posture relative to the relevant GTM [go-to-market] signals for this industry.

In plain terms: I used Cowork to figure out what each company is worried about, how they currently handle their data problems, and where their likely gaps are, so every outreach and conversation at the event feels specific, relevant, and grounded in their reality, not a generic security pitch.

Cowork scraped public LinkedIn profiles, company websites, press releases, and regulatory filings, then wrote everything into a structured Excel sheet with one row per attendee and columns for each research dimension.

In the second pass, I asked it to draft personalized 4–5 line emails for each attendee, segmented by different pain points. The instructions were specific: no vendor buzzwords like "visibility" or "security transformation," no generic "let's connect" fluff. Instead, paint a realistic picture of how we can solve the problem statements, and make it feel like we actually understand their ground realities, not just pitching another security tool.

The result: a Word doc with tailored outreach for every attendee, each one backed with research, with a clear CTA to book a 30-minute 1:1 consultation at the event. It's the kind of prep work we've always wanted to do but never had time for, now automated, structured, and ready to execute.

Founders can use this same task at investor or founder meetups to map out who to talk to and plan their networking strategy.

3. Monitoring AI Trends on X, Daily

The third experiment was turning Cowork into a lightweight “AI trend desk” for X.

I set up a workspace with a simple config file listing accounts and keywords I care about (AI agents, MCP, industrial AI, etc.). Each morning, Cowork logs in through the browser, pulls recent posts from that slice of X, and writes a short daily brief: top threads, recurring themes, any sharp contrarian takes, and a handful of posts worth saving.

Over a week, this turned into a rolling log of AI discourse that’s much more usable than doom‑scrolling. It surfaces patterns – for example, which aspects of agents people are actually shipping vs. just debating – and it gives me ready‑to‑go links and angles for Nanobits or LinkedIn.

4. Automating content repurposing of Nanobits (newsletters) across platforms

Finally, I pointed Cowork at my own back catalogue.

I copied a set of Nanobits issues into a workspace, along with a small “guide” file that explains how I write: tone, structure, and what I never do. Then I asked Cowork to:

• Break each issue into atomic ideas.

• Propose LinkedIn posts, short X threads, scripts for Instagram reelsm and a couple of Reddit discussion hooks per issue.

• Tag each idea by theme.

Cowork produced a folder of repurposed drafts: LinkedIn posts that preserved my voice, X‑sized riffs on bigger essays, and a backlog of prompts I can reuse when I’m low on ideas. It’s not “auto‑publish” ready, but it’s a very solid first draft machine that keeps Nanobits alive across channels without me rewriting everything from scratch.

What else can you do with Claude Cowork?

Here are some proven workflows based on community use cases and my research:

Competitive Intelligence: Have Cowork monitor competitor websites, LinkedIn pages, and news mentions weekly. It'll generate a living markdown file tracking positioning shifts, feature releases, and messaging changes.​

Customer Interview Synthesis: Drop 30 interview transcripts into a folder and ask for themes, quotes, and product insights. Cowork will identify patterns human analysts might miss.​

Brand Monitoring: Track what people say about your brand across Reddit, X, LinkedIn, and industry forums. It'll synthesize sentiment, highlight recurring complaints, and flag emerging topics.​

Creative Strategy Research: Feed it campaign briefs and have it analyze award‑winning campaigns in your category, identifying patterns in messaging, channels, and audience targeting.

And, the next use case is one of my favorites and pretty different from what one might be used to hearing: ​

Document Organization: One user organized thousands of pages of their deceased grandmum’s manuscripts by theme, chronology, and publication potential, to honour her legacy - a task that would have taken weeks manually. Claude didn’t just sort files; it gave them a path to share their grandmother’s voice with the world.

To get a sense of how big a swing Claude Cowork is: 

Claude Code, the developer‑focused sibling, went from $0 to $1B revenue in less than 6 months and hit around $9B by the end of 2025, largely by quietly becoming the closest thing programmers have to AGI‑on‑the‑desktop. 

Now Cowork takes that same magic and points it at everything non‑developers do on their computers, a market that’s at least an order of magnitude bigger, which is why many people see this as "the software launch of 2026."

How is Claude Cowork different from Perplexity Comet?

People keep asking, “Isn’t this just Perplexity Comet with extra steps?” Not quite.

• Where they live: Cowork runs on your Mac inside a sandboxed VM, with direct access to the folders you mount and your local files; Comet lives in your browser, with deep awareness of your tabs, URLs, and web sessions.

• What they’re best at: Cowork is best at file-heavy, multi-step desktop work – turning folders of docs, transcripts, and spreadsheets into decks, reports, and workflows. Comet is strongest at web-first work – live research, cross-site browsing flows, prospecting, and “do this across my open tabs” tasks with citations.​

• Mental model: Cowork is “Claude Code for non-devs” – a general-purpose agent that works inside your filesystem and connected tools. Comet is an “agentic browser” – a research and workflow copilot that works through the web.

In practice, I’ve found they’re complementary: I use Comet to discover and synthesize what’s happening out in the world, and Cowork to turn my own messy archives, saved posts, and event lists into structured assets and outreach that actually move projects forward.

The Good, The Bad, and The Ugly

The Good

It actually works: For file‑based knowledge work, Cowork delivers on the promise. Multi‑step research, synthesis, and document generation tasks that would take hours happen while you're in meetings.

Architecture is serious: The VM isolation and sandboxing aren't marketing fluff. Technical users confirm it genuinely can't access unmounted folders, which is the right foundation for an agent with file permissions.​

Developer‑Grade Power for Non‑Developers: The UX makes Claude Code's capabilities accessible to marketers, PMs, and founders who don't live in terminals.​

The Bad

It eats tokens for breakfast: A single session can burn 200K+ tokens. Running this weekly on a Pro plan ($20/month) is feasible; daily use requires Max ($100–$200/month).

Platform limited: Mac‑only for now. Windows is "planned," which excludes most enterprise users.​

Stability issues: Users report workspace startup failures, flaky browser automation, and occasional connector timeouts. It's research preview quality, not production‑ready.

The Ugly

Data loss is real: The infamous "11GB deleted" incident wasn't a hallucination. When Cowork deletes files, there's no Trash recovery - it's gone from the mounted folder. The community consensus: never point it at original files, only copies in dedicated workspaces.

Security is unsolved: Prompt injection vulnerabilities exist. A responsibly disclosed bug showed how hidden instructions in documents could exfiltrate local files. The sandbox helps, but the combination of internet access, file access, and powerful tools creates attack surfaces that aren't fully mitigated.​

Human factor risk: The UI is friendly enough that non‑technical users might approve destructive actions they don't understand. One wrong "yes" on a cleanup plan can vaporize a project folder.

End note: The Agent era is here, but keep your guard up

Claude Cowork is the clearest signal yet that AI agents are moving from demos to daily work. For content marketers, competitive researchers, and founders, it compresses days of manual labor into hours of autonomous execution. The playbook is simple: copy, don't point; read, don't write; approve, don't assume.

Start with isolated folders, read‑only connectors, and tasks you can afford to lose. Think of Cowork as a brilliant intern who needs training wheels, not a fire‑and‑forget autopilot.

The infrastructure is sound. The use cases are real. The economics are... pricey. But if you're strategic about what you automate and paranoid about what you expose, Cowork can be the force multiplier that justifies its token appetite.

Welcome to the era of digital coworkers. Choose your projects wisely, back up your data religiously, and keep the human in the loop.

EDITOR’S NOTE

Dear Nanobits readers,

Last week, I visited an event in San Francisco for "Vibes Don't Scale: Building Production Systems with AI Evals." I will be honest, I went in thinking I knew something about evals as we have written about AI tooling, read papers, and used some of it at work. But two hours later, I walked out realizing I knew practically so little from what the industry is doing.

The panel brought together Neel Kapse (Engineering Manager for Evaluations at OpenAI), Niko Grupen (Head of Applied Research at Harvey), Sam Crowder (Head of Core Platform at LangChain), and Iz Shalom (Head of Product at Cartesia). These are not people theorizing, they are building the evaluation systems that keep production AI from breaking.

Every panelist emphasized that evals aren't just a nice-to-have. They are the only thing standing between your working demo and a production nightmare.

As Sam put it bluntly: "Do you want your product to work?" The room laughed, but he wasn't joking. That's the entire eval conversation in one question.

Vibes Don’t Scale event in San Francisco

So today, I am sharing the insights of what I captured, which is the honest, messy reality of how the best teams actually build eval systems. The shortcuts they take when resources are tight. The expensive mistakes they made so we don't have to. And the unsolved problems they are still wrestling with. Let's dive in.

WHY EVALS MATTER: THE FUNDAMENTAL SHIFT

Traditional software has a simple promise: write code, write tests, ship with confidence. The behavior of your app is defined in the code itself. You can write unit tests and integration tests that prove your application works exactly as specified.

But AI broke that model completely.

"In the world of agents, the behavior of your app is defined in the agent itself," Sam explained. "Whereas in the prior paradigm of traditional software, the behavior of the app is defined in the code and you can write integration tests and unit tests to test that code. But until your agent is actually doing something, you have no behavior, you have no definition of your application. The evals are the only thing really that can ensure that your agent performs as you want it to."

This is the foundational problem: with traditional software, your tests verify the code. With AI, your code is just scaffolding. The real behavior emerges from the model itself, and that behavior is probabilistic, context-dependent, and changes with every model update or prompt modification.

Think about it: your traditional test suite gives you a binary pass/fail. But with AI, you are testing something that might give you slightly different outputs each time, even with the same input. The model might hallucinate. It might follow an inefficient path to the right answer. It might be correct but inappropriate in tone.

Evals aren't just testing. They are your only definition of what your application should do. Without them, you are literally shipping vibes and hoping for the best.

THE CORE PRIMITIVES: WHERE TO START

If you are building an AI product from scratch, what do you actually need? Sam broke down two entry points that most successful teams use:

First Principles Eval Development

Build a golden dataset of example questions and template inputs. Take your prompt, plug in a model, run it over that dataset, and see how it scores compared to reference outputs or some feedback criteria you define. This is your baseline: does the model do what you expect on known inputs?

The key word here is "golden." These aren't random examples. They are carefully curated cases that represent the core behaviors your product needs to handle correctly. Think of them as your contract with the model: if it can handle these well, it can probably handle production.

Trace-First Approach

Many teams actually start with tracing, which captures what the agent actually does in practice. As Sam described: "Tracing for agents tells you what that behavior is. To perform X task, this model called these three tools, here's the latency, here's the total cost, here was the process that followed, that's the trace."

Traces are your window into reality. They show you the real behavior of your agent in action, then you build evals from there. You are evaluating the trajectory the agent follows to get to the end result, whether it answered the user's question, if the user got frustrated in a conversational flow.

Sam noted: "We find for most of our customers, starting from the trace as the foundation to understand final behavior is where they can then work on building eval sets of all kinds."

But here's the critical insight from Neel that changes everything: "Evals are kind of living things that need to change as you discover new issues in production. You will discover that oh this thing is broken, that thing is broken, or a new model releases and those failure points are different than before. So another part of this process is how do you actually take your starting eval set and then adapt it over time."

Your eval system isn't a one-time build. It's living infrastructure that evolves with your product, your models, and your understanding of what matters.

THE DYNAMIC EVAL PROBLEM

Niko from Harvey dropped what might be the most important warning of the evening

Think about what this means. You build evals for GPT-4. You ship. GPT-4.5 comes out with better reasoning but different edge cases. You swap it in. Your evals say it's better. You ship again. But you never updated the evals to catch the new ways the newer model might fail.

Model capabilities improve rapidly. New models have different strengths, weaknesses, and failure modes than their predecessors. What worked as an eval for one model might completely miss the problems in another.

Your eval system needs to be dynamic and updateable in real time, not a one-time exercise you run before launch and forget about.

QUALITY OVER QUANTITY: THE DATASET SIZE DEBATE

This is where the conversation got intensely practical. How many examples do you actually need? Should you aim for 100? 1,000? 10,000?

The panelists were unanimous: quality matters infinitely more than quantity.

Iz from Cartesia laid out their thinking: "The first thing to think about is what is necessary to simulate as best as possible what your customer's interaction is going to be. So for us it's looking at what are the transcripts that are indicative of whether this model is going to work well for the user or not." Then they expand until hitting cost constraints, whether that's running costs or the strict upper bound of human evaluation budgets.

For voice AI, they also need to expand datasets whenever they add new languages or create new model behaviors, while keeping everything else for regression testing.

But Niko's perspective from Harvey was even more striking. Working in legal AI, they face a unique constraint most teams don't: they cannot look at production data. Prompts, queries, documents, even model responses, all of it is considered highly sensitive data.

"We can't look at them," Niko said. "The best we can do is try to create an offline data distribution that mirrors or kind of approximates our online production distribution. And in those instances, it's really about what is the specific use case that really matters for this firm, and then how do I come up with even 10 really good examples of work they produce for this. I'd take that over you know a hundred or a thousand just medium rules."

Ten examples over a thousand. Let that sink in.

Neel reinforced this with hard-won experience: "Scale is what makes the problem particularly insidious because everyone tells you you need a lot of data, and you do, the more data you have the better it is, but it's really hard to maintain a large dataset. I've seen teams where they'll have like 600 data points of something. But the problem is over the weeks it's not possible for them to staff maintaining that, making sure that their graders are still doing what they want them to over those data points. And so ultimately that's less productive."

Less productive than what? Than having 10 high-quality, well-maintained examples that you truly understand.

The honest but helpful answer? It should be as big as it needs to be and as small as it can be. If 10 works for that particular customer and use case, that's good enough. But it's not always going to be enough for every situation.

And critically, as Niko emphasized: "If you're going to reduce quality to increase quantity, you should do that intentionally." Don't accidentally trade quality for scale. Make that choice deliberately, knowing the tradeoffs.

What Makes a High-Quality Row?

Sam described it as multi-dimensional thinking: "If you think about one row in a reference dataset, human labeled expected reference output, it's not just a simple input-output completion type interaction. It's other dimensions of annotation like toxicity if you care for that, or humor if you care for that, boolean categorizations of like did the model answer a person's question."

Multiple dimensions per example, that's what creates a robust eval that captures the full picture of model behavior..

SYNTHETIC DATA: WHEN YOU CAN'T ACCESS PRODUCTION

Niko outlined Harvey's three-tier approach:

Public Data: Case law, public filings. Take a reference NDA and create synthetic variations between different parties, tweaking terms to trigger various aspects of their workflows.

Private Data: Highly constrained due to sensitivity.

Human Process Data: The most interesting category. "In many ways, it's data that doesn't yet exist or is in the process of existing," Niko explained. Best practices for work aren't in a CSV, they're conversations in hallways. "You actually need the product interface to facilitate workflows to start to extract that data."

This ends up looking like process traces, capturing the actual flow of work, not just outputs.

THE HUMAN VS. LLM-AS-JUDGE DEBATE

The reality is more nuanced than "humans good, LLMs bad." The panelists described a funnel approach:

Niko's Three-Tier System:

Tier 1 - LLM as Judge: Directional signal when testing model swaps. A smoke screen to see if changes are better.

Tier 2 - Human Side-by-Side: Large-scale comparisons with in-house or external domain experts.

Tier 3 - Traditional A/B Test: Usage metrics and engagement in the product. Run a three-week experiment before full rollout.

Iz's Approach at Cartesia:

Synthetic evals during training, manual transcript review for release candidates, then multi-turn evaluation where they pit agent versions against each other. "That is very high touch, high cost, but very effective in measuring what customers truly feel."

Sam's Three Tiers of Involvement:

Low: Out-of-the-box LLM-as-judge prompts that auto-evaluate traces.

Medium: Custom LLM-as-judge evaluators tuned to align with human preferences.

High: Annotation queues where humans review production traces.

Sam's honest take? "I'd love to say all customers do the highest tier. That's where you get the best results, but given time and resource constraints, that's still a minority.".

MAKING LLM-AS-JUDGE WORK

Neel offered two critical insights:

First, LLM-as-judge is under explored. "If you're willing to commit to figuring out how to use LLM-as-judge, there's probably a lot of stuff that can be done that none of us know about yet." (A business idea, maybe?? 🤔 )

He shared a fascinating example: a consulting firm building an investment recommendation agent. Instead of grading outputs as "good" or "accurate," they had another agent debate the first agent. The grader acted as a moderator determining who won the debate. Costly, but potentially breakthrough results.

Second, this is non-negotiable: "The best LLM-as-judge graders we built were calibrated against human data." Humans create rubrics and baselines, then models are measured against those.

Niko emphasized mixing objective and subjective criteria. For a legal brief: objective checks (Did you cite this case? Does this overrule another case?) combined with subjective ones (Is this compelling? Would this be persuasive?). "At least that gives you part of the rubric yourself, and for directional signal, models can do a reasonable job on subjective data too."

THE RUBRIC DILEMMA

Iz captured the core tension: "For us, the tension is always being too granular or not granular enough. You can create tens of different metrics for every question, but then some are better and some are worse. It's like finding that Goldilocks zone of the right amount of rubrics that truly drive decision making."

It's like having too many dashboards, if you have too many, it's as if you have none.

Niko's framework: High-fidelity rubrics (detailed, point-by-point) give verifiable outcomes. But they impose constraints. "Rubrics can become so rigid that they're actually robust to model improvements. You miss the model's innate ability to do subjective aspects better."

His mantra: "A rubric is only as good as you can measure via calibration with something else, whether it's ground truth, a human golden response, or a human calibration test.".

GUARDRAILS VS. QUALITY EVALS & MONITORING AFTER SHIPPING

Guardrails are concrete evals that shouldn't change model-to-model (like preventing the model from saying "sorry I apologize" or "oh great question"). Quality evals need to be flexible to let better models shine.

And a critical warning from Sam: "We make it possible to reuse evaluators between agents, but we don't advise doing that in every instance, because even if you've tuned an evaluator for agent A, that doesn't necessarily translate to agent B."

Also Evals don't stop when you ship. Niko broke down their approach:

Developer Experience: Local iteration gets you to ship, then observability in production. They taxonomize data (query categories, document metadata) since they can't look at raw content. This enriched data helps recreate problematic traces offline.

Lawyer Experience: Map usage to practice areas and task types, benchmark against internal eval sets for specific use cases.

Iz emphasized about regression evals: binary checks to ensure you are not regressing when shipping new models. The key is standardization and sampling production data to verify it matches offline testing qualities, avoiding data drift.

THE MULTI-TURN CHALLENGE

Evaluating single LLM calls is hard. Multi-turn agent interactions? Much harder.

Sam explained LangChain's structure: runs (single tool calls), traces (collections of runs), and threads (multiple traces in a full conversation). For multi-turn, they use thread-level evaluators that run after threads go silent for a set period, testing outcomes and conversation trajectories.

But Neel was honest: "We don't have a solution we're very happy with yet. Things we've tried are either not practical at scale or very hard to calibrate."

The Credit Assignment Problem

Niko highlighted a challenge from RL research now hitting production: "Say your agent takes 100 actions to produce output. Your eval says it's suboptimal. To which of the 100 decisions do you attribute that lower quality? Is it action 47? Action 63?"

Neel's concrete example: "I built an agent to pull GitHub PRs. It made a single API call per PR. None of us would develop that, right? But the agent was like 'I need this PR so I'll fetch it. I need that PR so I'll fetch it.' Each step was correct (did it pull needed information? Yes), but the approach was completely wrong."

The atomic steps can all be correct, but the total result wrong. Sam noted another issue: "Users stop talking halfway through because they got busy, and the agent has no idea." You can't control for that, but it muddies evaluation.

Iz's solution: Have raters accomplish a task, then verify on the backend if the thing was generated successfully. "It's easily verifiable and more helpful because otherwise it becomes so subjective the longer the interaction is."

END NOTE

As the panel wrapped up, each person offered their core takeaway. Here is what the people building production AI want you to remember:

Sam (LangChain): "Traces can and should form the foundation of your eval set. Until you have them, you do not know any sort of behavior of your product."

Neel (OpenAI): For vertical companies or any team building on AI models, there are two primary hard-to-replicate differentiators: distribution strategy and the quality of what you are doing with the model. Most people in the room won't affect distribution as much, so "evals is actually a very big component of what gives you that extra 3 to 5% of quality sometimes. And that might be all that matters to beat your competition."

And perhaps the most direct:

"Evals, all that matters."

WHAT THIS MEANS FOR YOU?

If you are building AI products, here is what you need to do:

Engineers: Start with tracing, even if it's just local experimentation. You cannot optimize what you cannot measure. Build a small, high-quality eval set before you build a large, mediocre one. Treat your evals like living code that evolves with your product.

Product Managers: Your AI product's reliability doesn't come from the model alone, it comes from the eval infrastructure around it. Ask your team: How are we versioning our evals? What happens when we swap models? How do we know if we have regressed?

Leaders: The teams winning in AI aren't the ones with the best models, they're the ones with the best eval systems. This isn't a one-time investment, it's continuous infrastructure that needs dedicated resources and constant iteration.

The gap between demos and production isn't magic. It's discipline. It's eval systems that evolve. It's the willingness to measure, calibrate, and improve continuously.

As the title of the event reminded us: Vibes don't scale. Evals do.

EDITOR’S NOTE

Three sessions, one underlying tension

Dear Nanobits Readers,

Last Saturday, I walked into an eChai Ventures meetup expecting three separate conversations. A founders meet. A few fireside chats. Some networking over coffee. The usual weekend rhythm.

One session on AI agents in growth and customer support. One on how builders are actually putting agents into production. One on how investors are thinking about AI, SaaS, and deeptech right now.

In practice, it felt like one conversation unfolding in layers.

The first layer stayed close to customers. What happens when AI stops living in demos and starts replying to real users. What breaks first. What earns trust. What gets rejected quickly.

The second layer moved under the hood. How agents are designed, constrained, evaluated, and improved over time. Why prompting is only a small part of the work. Why most failures have little to do with models and a lot to do with systems.

The third layer zoomed out to capital and market reality. What investors now look for once AI capability becomes widely available. Why labor arbitrage alone no longer works for enterprise AI. Where India still has structural advantages, and where it does not.

This edition of Nanobits is a guided walk through those three layers:

Detailed session summaries from builders and investors working at the edge of production AI. Aniket Bajpai from LimeChat on where agents succeed in customer-facing roles. Pramod Kalipatnapu from Revefi on the engineering discipline required to ship agents that work. Vardhan Dharnidharka from Stellaris Venture Partners on how money thinks about AI companies now.

If you are a founder building AI products who need clarity on what actually works, an engineer shipping agents into production who want practical frameworks, or a business leader evaluating AI investments who needs honest assessments of value, this newsletter is for you. 

The sessions did not promise shortcuts. They offered something more useful: clarity on what works, what does not, and why the next phase of AI will look far less flashy and far more consequential.

The same questions echoed across all three conversations. Where does AI belong inside real work? Who trusts it enough to rely on it? And what changes once AI stops being a demo and starts owning a workflow?

Agents meet customers, and the demo breaks fast

The first session set the tone for the entire evening by grounding AI in the messiest place possible: real customers.

Aniket Bajpai, Founder of LimeChat, sat with Somya Sinha to discuss where AI agents actually work in customer-facing roles. LimeChat builds AI systems for customer support and growth, focused on understanding brand conversations at scale.

His core point landed early and stayed consistent. AI agents work only when they stay narrow. Not narrow in ambition, but narrow in responsibility.

Generic chatbots that try to answer everything tend to disappoint. They miss context, drift in tone, and fail under edge cases. Agents designed for specific workflows behave very differently. When an agent is trained on real customer conversations, scoped to a defined task, and aligned to a brand’s voice, it earns trust quickly.

India makes this distinction impossible to ignore. Aniket described Indian customers as a forcing function. They expect fast responses. They switch platforms without hesitation. They move across languages and channels in the same conversation. 

Those constraints force better design. Building for demanding users creates products robust enough to work anywhere. Serving them well forces systems to handle complexity from day one.

Growth and support teams feel the impact immediately. These functions sit close to revenue and even closer to customer memory. A single bad interaction lingers. A good one compounds.

Somya pushed the conversation into a tension many teams feel but rarely articulate. Engineers often feel more productive using AI tools. Business teams often feel underwhelmed. The reason is simple. Engineers adapt tools to fit their workflows. Business users judge AI by outcomes.

Trust appears only when an entire slice of work disappears. Not a draft. Not a suggestion. Not a reply that needs fixing.

Aniket gave a concrete example from social media workflows. The mechanical parts can be automated. Even the first draft copy can be automated. That is when value becomes obvious to non-technical teams.

Key takeaways:

For business teams: Narrow agents outperform broad ones. Generic chatbots attempting to handle any query tend to fail. Agents designed for specific brand workflows, trained on actual customer data, and scoped to well-defined tasks perform far better. Success comes from depth, not breadth.

For technical teams: Workflow integration matters more than model choice. A simpler model with tight process integration beats a sophisticated model bolted onto existing systems. The wins come from removing manual work completely, not adding chat interfaces to dashboards.

The discipline required: Start with repeatable workflows where agents can own the entire process. Learn what good responses look like for your brand. Know when to escalate. Build evaluation loops, not just launch systems.

This was the first hinge of the day. AI starts as a product story. It becomes a workflow story once it ships.

And once it owns a workflow, the next question follows fast.

What does it actually take to build these agents right?

Agents meet systems, and the prompt stops being the main event

This session pulled the conversation under the hood.

Pramod Kalipatnapu, Founder of Revefi, spoke with Piyush Vijay about what makes agents work in production. Revefi builds AI systems for data operations, focused on cloud cost anomalies and infrastructure monitoring.

Pramod spoke about agents not as chat interfaces, but as systems that do work. He contrasted traditional software, built around fixed flows and dashboards, with agent-driven systems that adapt to user intent and take action.

The strongest use cases are repetitive, high-effort workflows that people perform again and again. At Revefi, each cloud cost anomaly triggers the same investigation cycle: detect the spike, trace the cause, assess impact, and recommend fixes. That predictable repetition makes it perfect for agents.

This led to the most practical mental model of the afternoon: Think of an agent like a junior teammate.

Dump everything on them at once, and they fail. Give them structure, clear responsibilities, and limited permissions, and they succeed.

This framing shifts how teams build. Prompting matters, but orchestration matters more. Memory management, tool access, feedback loops, and evaluation decide whether an agent works in production.

Pramod was clear that many failures have little to do with models. They come from unclear boundaries. Agents with broad permissions and vague responsibilities break trust quickly.

Safety entered the discussion not as policy, but as design. The risk is not intelligence. The risk is access. Databases. APIs. Actions. Context windows tempt teams to pass everything in. That rarely helps.

Pramod echoed what Aniket had said earlier from a customer-facing angle. Agents cannot be static. They need constant testing, learning from usage, and refinement. Treating deployment as a one-time launch guarantees decay.

Defensibility emerged as a quiet theme here. Startups cannot win by breadth. Large platforms already own that game. They win by going deep into one painful problem, understanding it better than anyone else, and building tight systems around it.

That depth is hard to copy.

This naturally led into the final session, which asked a different question.

If agents are systems, and systems touch outcomes, how does money think about them?

Key takeaways:

For business teams: Look for work that repeats with minor variation. If a workflow has clear boundaries and known inputs/outputs, an agent can own most of it. The value becomes visible when automation removes mechanical work completely.

For technical teams: Orchestration beats prompting. Memory, context, tool access, and feedback loops determine whether agents work in production. Most failures come from unclear boundaries. Safety is about constraints, not compliance theater. The risk is giving agents too much access, not the models themselves.

The discipline required: Start with a very clear problem, not a vague goal. Build evaluation frameworks and continuous testing. Treat agent deployment as an ongoing process, not a one-time launch. Static systems fail over time.

Agents meet money, and trust becomes the product

This session reframed everything that came before it.

Vardhan Dharnidharka, Investor at Stellaris Venture Partners, spoke with Sushil Kumar about how capital thinks about AI companies. Stellaris backs early-stage tech startups in India across SaaS, deeptech, and consumer categories.

Vardhan described enterprises moving from experimentation to real decisions, but slowly. Excitement leads to pilots. Pilots stall. Enterprises worry about risk, compliance, and accountability. No one wants to lose their job over unpredictable system behavior.

What has changed is clarity. Buyers now understand where AI fits into workflows, not as magic, but as a specific tool solving concrete problems.

This clarity reshapes the old India SaaS playbook. Labor arbitrage alone no longer works for enterprise AI. Build cheaper in India, sell software that replaces existing tools in the US. That model is harder now. Buyers are not just replacing software. They are trusting systems that affect pricing, decisions, and business outcomes. That requires proximity, trust, and deep problem understanding.

Vardhan pointed to areas where India still holds structural advantages. Consumer products. Fintech infrastructure. High-volume transactional markets. He described examples from recruiting and financial services, where large teams repeat the same work daily.

If an enterprise can reach only ten percent of its base, an agent that runs outreach work changes the math.

The investment lens here was blunt. Model access is widespread. Technology is commoditized fast.

Capital flows to teams that show depth, not demos. Pricing power, trust, and workflow ownership matter more than model choice.

Categories like “AI-first” or “SaaS-first” miss the point. Strong companies start with problems. AI becomes part of the substrate over time.

Key takeaways:

For business teams: Narrow agents win in the market for the same reason they win in product. They create predictable outcomes. Trust and workflow ownership matter more than technology sophistication.

For founders: Technology alone creates no moat. Access to models is widespread. Insight into real pain points is rare. That gap determines which companies attract capital. Start with problems, not technologies. Go deep into one painful use case.

The discipline required: Pricing power, trust, and workflow ownership matter far more than model choice. Shallow problem discovery kills more AI startups than technical limitations.

The three sessions converged in the end. Narrow agents win. Systems beat prompts. Trust beats speed. Learning beats static sophistication.

END NOTE: NANOBIT’S TAKE

The three conversations never used the word "hype," but they spent two hours dismantling it.

What stood out was not optimism or skepticism. It was specificity. The room talked about agents that resolve customer queries in brand voice, systems that investigate cloud cost spikes, and enterprises that can only reach 10 percent of their target audience. That grounding in real work made the afternoon feel different from most AI discussions.

One thread connects everything: learning speed matters more than starting knowledge. Pramod described AI as compressing feedback cycles that used to take days into minutes. Aniket spoke about building, observing customer usage, and feeding that learning back into systems. Vardhan pointed at adaptation as the real competitive edge. The teams winning are not those with the fanciest models. They are the ones learning fastest from production data.

This has implications for builders in India. The old advantages around cost arbitrage are fading for enterprise AI. But new advantages are emerging. High complexity customer environments force better design. Consumer and high-volume transactional markets offer strong unit economics. The ability to build for demanding users creates products that travel well globally.

The discipline required is clear. Start with a problem, not a technology. Go narrow, not broad. Integrate deeply into workflows, not superficially into interfaces. Build evaluation loops, not just demos. Ship with boundaries, not limitless permissions. Earn trust through outcomes, not promises.

AI will disappear into software the same way databases and APIs did. Long-term winners will not sell AI. They will sell results. Customer support that actually resolves issues. Data systems that catch anomalies before they cost money. Outreach that reaches more people without hiring more humans.

The shift from experimentation to production is happening now. The companies that survive this phase will be the ones that understood one thing clearly: the technology is commodity, the problem understanding is moat, and the workflow ownership is product.

That clarity showed up in every conversation at the meetup. It is worth paying attention to.

EDITOR’S NOTE

Dear Nanobits readers,

Happy New Year 2026! 🎉

This is our first edition in 2026 and we wanted to take a moment to reflect on the incredible journey we have had together last year. What started as a passion project 1.5 years back has grown into something truly special, and it's all because of YOU.

In 2025 we:

→ Published 44 posts with an average open rate of 36.4% (well above industry standards!)
→ Grew our subscriber base by 63%
→ Reached readers across the globe: 77% from the US, 16.4% from India, 1.6% from the UK, and 4.3% from the rest of the world
→ Covered the full AI landscape: from practical AI tools and MCP servers to AI agents, policy developments, breakthrough product launches, AI events, smart glasses, wearables, and everything in between.

Thank you for making this possible. Your engagement, feedback, and curiosity fuel everything we do.

Now, as we enter 2026, we started pondering where is AI actually heading this year? Not the hype, not the buzzwords, but the real shifts that will change how we live and work. A few weeks ago, a16z dropped their Big Ideas for 2026 report. We spent some time going through all of them, and nine predictions stood out for us. These aren't just incremental improvements, they represent fundamental rethinks of how we build and use technology.

So today, we are diving into these nine ideas. Not just what a16z's partners said, but what these shifts actually mean for how we will be using AI in the coming months. We also provide a video explanation for these ideas linked within some idea sections. Check those if you’d like to listen instead of read. Let's jump in.

THE FOUNDATION IS SHIFTING

Before we get into the specific predictions, here's what struck me the most: every single one of these ideas challenges a core assumption we have held about technology for decades.

We have spent years optimizing for average users, maximizing screen time, designing for human eyes, building single-player tools. But 2026? It's when all of that (maybe!) gets flipped.

The winners won't be the companies serving the most people, they'll be the ones serving each person the best. The most valuable products won't keep you glued to screens, they'll work while you're not looking. And the best interfaces won't wait for your prompts, they'll anticipate what you need before you ask.

This is the year AI stops being a tool you use and starts becoming infrastructure you barely notice.

1. The Year of Me: When Mass Production Dies

Products stop being mass-produced and start being made specifically for you.

For decades, companies succeeded by finding the average customer and serving that persona. You were a demographic, a segment, a target audience. But AI is flipping that model completely.

In fitness, we are already seeing this shift. Apps don't just give you generic workout plans anymore. They adjust your routine in real-time based on how you are recovering, your stress levels, even your sleep quality from last night. It's like having a personal trainer who knows everything about you without you having to explain anything.

Here's the deeper insight: The winning companies of the next decade won't be the ones serving the most people. They'll be the ones serving each person the best. That's a fundamental shift in business strategy, and it changes everything from product development to customer acquisition to pricing models.

2. The End of Screen Time as a Success Metric

Screen time is dying as the primary metric for measuring value.

A fascinating observation that breaks a 15-year-old assumption in tech: engagement metrics are becoming meaningless. For years, tech companies obsessed over how long users stayed on their platforms. How many clicks? How many hours watched? But AI is breaking this model because the best AI tools do their work while you are NOT looking at the screen.

Imagine an AI assistant that monitors your email, automatically handles routine requests, schedules meetings around your preferences, and only surfaces the 5% of messages that truly need your attention. The value is massive, but your screen time? Nearly zero.

This creates a real challenge for companies: How do you measure ROI when traditional engagement metrics don't apply? The answer is outcome-based pricing and measuring actual results. Did the AI save you time and reduce stress? Did the developer ship features faster? Did the analyst make better decisions? These are harder to quantify than screen time, but they are what will actually matter in 2026. If your company is still optimizing for "time spent" as a north star metric, you are already behind.

3. Creating for Agents, Not Humans

People will interface with the web through AI agents, and this changes everything about content design.

We will stop designing for human eyes and start designing for machine readability. For years, SEO meant catchy headlines, beautiful photos, bullet points for easy scanning. But AI agents don't care about any of that. They can read your entire 50-page document in seconds and extract exactly what's relevant.

Imagine you're a real estate agent. Instead of designing listings with sunset photos and compelling descriptions for human buyers, you will need to structure your data so AI home-buying agents can quickly assess if a property meets their user's 47 different criteria. The agent doesn't care about your staged living room, it cares about precise square footage, energy efficiency ratings, school district API scores, and flood zone data.

The uncomfortable truth: Visual hierarchy will matter less. Data structure and machine-readable metadata will matter infinitely more. This isn't some distant future. If you're creating content or building products in 2026, you need to think about how AI agents will consume and evaluate what you're offering, not just how humans will perceive it.

4. Vertical AI Goes Multiplayer

Industry-specific AI tools are evolving from solo work to multiplayer collaboration.

A trend that most people are missing: vertical AI is about to get network effects. Right now, AI tools work in isolation. Your AI helps you draft a contract, but it doesn't talk to the other party's AI to negotiate terms. 2026 is when that changes: AI agents will start collaborating with each other across organizational boundaries.

Picture this: You are buying a house. Your AI agent is analyzing properties, but now it can directly communicate with the seller's AI agent. They negotiate back and forth within pre-set parameters: your max price, their minimum price, contingencies, closing dates, and only flag the deal for human review when they have reached the best possible agreement or hit a sticking point that needs human judgment.

Here's why this matters: When multiple stakeholders' AIs work together within the same platform, it creates massive switching costs. Once your business processes are deeply integrated with your partners' AI systems, moving to a competitor becomes exponentially harder. This is how vertical AI companies build moats in 2026.

5. Consumer AI Shifts from 'Help Me' to 'See Me'

AI moves from productivity tools to connection and self-awareness tools.

The first wave of consumer AI was all about "help me do this task faster." But the bigger opportunity? "Help me understand myself and connect with others better."

Think about an AI that analyzes your communication patterns. It notices you always text your mom on Sunday mornings but forgot the last two weeks. It gently reminds you. Or it detects that your messages to your partner have become shorter and less frequent when you are stressed at work, and suggests you might want to check in with them.

These "see me" products have completely different economics than "help me" products.

They typically have lower willingness-to-pay per transaction, but much higher retention because they become part of your daily self-reflection and relationships. You might pay $50 once for an AI to write a report, but you will pay $10 every month for years for an AI that helps you understand yourself better. If you are building consumer AI in 2026, don't just think about tasks. Think about identity, relationships, and self-awareness. That's where the defensible businesses will be built

6. ChatGPT Becomes the AI App Store

ChatGPT becomes the new distribution platform for AI applications.

ChatGPT is becoming the App Store for AI, and this will trigger a consumer tech gold rush in 2026. Here is why this matters. Every successful consumer product cycle needs three things: new technology, new consumer behavior, and new distribution. We have had the first two with AI, but distribution has been the missing piece. Most AI products grew through Twitter virality or word of mouth.

But now with OpenAI's Apps SDK and ChatGPT's 900 million users, developers have a massive, built-in audience for the first time. Imagine you build a specialized AI for meal planning. Instead of spending a year and a million dollars on user acquisition, you can launch it as a ChatGPT mini-app and instantly access hundreds of millions of potential users.

The report compares this to previous once-in-a-decade opportunities: the web browser in the 90s, the iPhone App Store in 2008, and now ChatGPT in 2026. If you are a developer or entrepreneur in the AI space, this is the distribution channel you need to be thinking about. The companies that figure out how to build for this platform early will have a massive advantage.

7. Voice Agents Take Up Space

Voice AI agents expand from handling single calls to managing entire customer relationship lifecycles.

Voice agents are about to graduate from simple tasks to complex, multi-step workflows. We are past the proof-of-concept phase. Thousands of businesses are already using voice AI for appointments and basic inquiries. But we are about to see voice agents handle much more sophisticated operations.

Here is what this looks like: Instead of just answering your call to schedule a dentist appointment, the voice agent becomes your ongoing dental health coordinator. It calls you for appointment reminders, follows up after procedures to check on your recovery, coordinates with your insurance company when there are claim issues, and even proactively schedules your next cleaning based on your dentist's recommendations and your calendar availability.

The key is that these agents need deep integration with business systems: CRMs, scheduling tools, payment processors, inventory systems. They are not just having conversations; they are taking actions across multiple platforms. As the underlying models improve, there's no technical reason why every business shouldn't have voice-first AI handling significant portions of their customer operations in 2026.

8. Prompt-Free and Proactive Applications

The death of the prompt box for mainstream users.

The chat interface is training wheels we are about to outgrow. The real future is AI that observes what you are doing and intervenes automatically. Right now, using AI means opening a chat window, typing a prompt, waiting for a response, then copy-pasting the result. But that's not the end goal. The end goal is AI as invisible scaffolding woven through every workflow.

Imagine you are writing an email to decline a meeting invitation. Before you even finish typing, your email client suggests a professionally worded response that includes proposed alternative times based on your calendar. You didn't ask, it just knew what you needed.

The uncomfortable insight: The chat interface was necessary to teach us what AI could do, but it was never the destination. The next wave of AI will be activated by your intent rather than explicit instructions. It will feel less like using a tool and more like having an invisible assistant who just knows what you need.

9. Data Crusade in Critical Industries

The race to capture data from manufacturing, energy, construction, and transportation.

While 2025 was about compute constraints and data center buildout, 2026 will be defined by data constraints, specifically in our most critical industries. Here's what most people miss: our most important industries, manufacturing, energy, construction, transportation, are sitting on goldmines of unstructured data that's never been properly captured for AI training.

Think about a power plant operator. Every decision they make, when to ramp up production, how to respond to equipment vibrations, which maintenance issues to prioritize, represents valuable data about operating complex systems. But traditionally, none of this gets recorded in a format useful for training AI.

Will predicts that industrial companies will start exploiting their comparative advantage: They have the infrastructure and labor forces to collect this data at near-zero marginal cost. They can either use it to train their own AI systems or license it to tech companies hungry for real-world data. We will see startups emerge to help with this coordination: tools for data collection, annotation, and consent management; sensor hardware to capture physical processes; and eventually, training pipelines to turn industrial expertise into AI capabilities.

The companies that figure out how to systematically capture and monetize their operational data will have a major competitive advantage in 2026 and beyond.

END NOTE

So there you have it: 9 ideas that paint a picture of where AI is actually heading in 2026. From hyper-personalization to invisible AI. From human-focused design to agent-focused design. From single-player tools to multiplayer collaboration. To see the full video explanation of these ideas, check out this link.

What strikes us the most is that these aren't just incremental improvements. Each represents a fundamental rethinking of how we build and use technology.

If you are building products: Ask yourself which of these shifts applies to your space. Are you still designing for screen time when you should be optimizing for outcomes? Are you building for human eyes when you should be structuring for machine readability?

If you are investing in AI: The companies that understand these shifts early will have massive advantages. Look for founders who aren't just building better chat interfaces, but who are rethinking the fundamental assumptions of their industry.

If you are just trying to keep up: The good news is that most of these changes will feel natural as they happen. The prompt box will disappear gradually. Your apps will become more personalized without you noticing. Voice agents will just work better.

But understanding the direction helps you prepare. It helps you ask better questions of the tools you're using. It helps you spot opportunities before they become obvious.

So here's the question for you: Which of these predictions do you think will have the biggest impact on your work or life in 2026? And which one are you most skeptical about? Hit reply and let us know.

Here's to an incredible 2026. Let's build the future together.

EDITOR’S NOTE

Two rooms, one question

Dear future-proof humans,

Last to last weekend, I walked into the Bangalore Literary Festival expecting two unrelated conversations about AI. One was a panel called Aye, Aye, AI. The other was a discussion around Karen Hao’s book Empire of AI. Different rooms. Different tones.

By the end of the weekend, it was clear they were asking the same question, from opposite ends.

The first room stayed close to ideas. What do we mean when we say artificial intelligence? Why does AGI keep changing its definition? Why do we confuse scale for intelligence? Why do narrow systems quietly work while sweeping promises dominate headlines?

It was technical and reflective, the kind of discussion that makes you realize we may not even agree on what problem we are trying to solve.

Then I walked into the second room.

Karen Hao was not talking about what AI might become. She was talking about what it already is. Who funds it? Who builds it? Who absorbs the costs? Where the data comes from. Where the labor sits. Where power concentrates.

The language shifted from models and benchmarks to empires, extraction, and belief systems.

One session showed how the idea of AI gets stretched, blurred, and marketed. The other showed what happens when that blur is weaponized by capital, geopolitics, and myth-making.

We spend a lot of time asking whether AI is intelligent. We spend far less time asking who decides what gets built, at what scale, and for whose benefit.

This edition of Nanobits asks one question. Not to argue that AI is good or bad. Not to predict doomsday futures. But to slow the conversation down just enough to ask a more uncomfortable question.

What are we actually building, and when did we stop choosing?

TL;DR: What’s in it for you

• The two sessions at the Bangalore Literary Festival said the same thing about AI: AI looks very different when you stop listening to promises and start tracing impact.

• Much of today’s AI progress comes from scaling known techniques, not from a breakthrough in understanding human intelligence.

• AGI remains deliberately vague, shifting meaning across research, business, and marketing to justify continued expansion.

• The modern AI industry increasingly behaves like an empire, extracting data, labor, energy, and legitimacy at scale.

• India is not just a market for AI, but a stress test where the environmental and civic costs of infrastructure become visible.

• The idea that AI’s current trajectory is inevitable is a narrative, reinforced by capital, not a law of technology.

• The real question is not what AI can do next, but who gets to decide what should be built and at what cost.

What AI claims to be?

The Aye, Aye, AI panel began where most public conversations about AI eventually land, with a definition that refuses to stay put.

As Anil Ananthaswamy explained, AI has never been a single idea. Historically, there were two broad approaches. One tried to encode human knowledge into machines using symbols, rules, and logic. It worked in controlled settings and failed once the world became messy. The other approach, machine learning, flipped the problem. Instead of telling machines how the world works, it asked them to learn patterns directly from data.

Most of what we rely on today comes from this second path. Systems that recognize faces, transcribe speech, or recommend routes are extremely good at one task and poor outside it. This is narrow intelligence.

The recent surge in attention comes from generative AI. Once systems learn statistical patterns at scale, they can produce text, images, or audio that resemble what they have seen before. The behavior feels new, but the underlying logic has not changed as much as the scale has.

This is where AGI enters, and where clarity dissolves.

AGI is usually described as a system that can match human capability across many tasks. The problem is that we do not agree on what human intelligence actually is. Depending on whether we emphasize reasoning, learning, creativity, or adaptability, AGI can feel either close or impossibly distant.

That ambiguity makes AGI a powerful narrative. It shifts meaning depending on context, research, business, or marketing. It becomes a moving horizon that justifies constant expansion.

The panel did not try to resolve this tension. It simply named it. When definitions stretch, accountability does too.

What AI is actually becoming

If the panel discussion stayed with ideas, Karen Hao’s book discussion shifted the focus to incentives.

Her account of the AI boom begins well before ChatGPT, in a period when ambition ran far ahead of clarity. OpenAI positioned itself as a moral alternative to Big Tech. Open research. Shared benefits. Humanity first.

What Hao observed early on was a familiar pattern. Grand claims paired with vague answers to basic questions. Why this technology. Why this scale. Why now. When pressed on the risks they were racing to prevent, executives gestured toward abstract futures rather than concrete harms.

That gap shaped everything that followed.

Once scale came to be seen as destiny, OpenAI stopped functioning like a research lab and started operating as something else. A capital aggregation engine. Success became less about scientific breakthroughs and more about raising unprecedented amounts of money to fund unprecedented compute.

This is where Hao’s central frame comes into focus. Empire is not a metaphor. It is a description of behavior.

AI companies extract resources they do not own, drawing training data from public and private work without consent or compensation. They rely on invisible labor, with large numbers of workers performing difficult moderation and annotation tasks so systems appear seamless. They also concentrate knowledge production, with most advanced research now housed inside or funded by the same firms building these models.

Like all empires, they justify expansion through moral narratives. We must build it first. We must move fast. Humanity depends on it.

What makes this unsettling is not malice. Many involved genuinely believe they are doing good. But belief combined with unchecked power carries its own risks.

In this room, AI stopped feeling abstract. It became physical and political.

And the earlier question grew heavier. It is one thing to debate what AI might become. It is another to confront what it is already becoming.

India as the quiet test case

The point where both sessions quietly converged was geography.

India appeared only briefly in the panel discussion, almost in passing. In Karen Hao’s session, it became impossible to ignore. Not because India dominates AI headlines, but because it sits beneath the infrastructure that makes large-scale AI possible.

As AI systems scale, they demand three things relentlessly. Compute. Energy. Water. In the United States, those limits are already visible. Land is constrained. Power grids are stretched. Water tables are under stress. Expansion, inevitably, looks outward.

India enters this story less as a design partner and more as a hosting ground.

This is not a future risk. It is already playing out.

You can read more about India’s water crisis due to data centres in Indulekha Aravind’s ET article.

When hyperscale data centers arrive, they compete directly with local needs. The costs rarely appear on corporate balance sheets. They surface instead in water access, air quality, and public health.

What makes this uncomfortable is how absent this context is from celebratory narratives about AI investment. Jobs and growth are highlighted. Tradeoffs remain off stage.

Here, AI stops being theoretical. It becomes civic.

India is not just a market or a talent pool in this story. It is a stress test. And how we respond to that role will say far more about the future of AI than any model benchmark ever could.

The illusion of inevitability

One of the most persuasive stories in the AI moment is that what is happening cannot be stopped.

If systems keep improving, if compute gets cheaper, if competition intensifies, then surely someone will build artificial general intelligence. If not one company, then another. If not one country, then a rival. The conclusion feels obvious, so obvious that it rarely gets questioned.

Both sessions challenged that assumption.

From the panel came a technical reminder. Recent breakthroughs are not the result of a sudden leap in understanding intelligence. They come from scaling known techniques. Bigger models, more data, more compute. The results look dramatic, but scale is a strategy, not proof of destiny.

Karen Hao added the political and economic lens. Scale did not win because it was the only path forward. It won because capital made it the easiest one.

The contrast with China makes this clear. Faced with limits on advanced chips, Chinese firms were forced to optimize. Models like DeepSeek reached comparable performance using far fewer resources, not through magic, but through efficiency techniques that already existed.

The implication is unsettling. The waste was optional.

US companies could have pursued efficiency earlier. They did not, because abundance rewards size and speed. Restraint looks weak when money is easy and narratives celebrate dominance.

This reframes the AGI debate. If most researchers do not believe current systems are on a path to general intelligence, inevitability begins to look less like fact and more like a story we tell to avoid responsibility.

Inevitability is not physics. It is choice.

The question we keep avoiding

Across both sessions, one question kept surfacing without ever being asked directly.

Do we actually need this?

Not in the abstract. Not as a thought experiment. But in the concrete sense of what we are choosing to build, fund, and normalize.

During the panel, a tension lingered. On one hand, these systems are described as brittle, narrow, and far from human intelligence. On the other, they are framed as forces powerful enough to reshape labor, culture, and geopolitics. We move between dismissal and awe, rarely stopping to ask why both narratives coexist.

Karen Hao’s work sharpens this contradiction. When companies market systems as universal problem solvers, they invite misuse they cannot govern. When they frame themselves as humanity’s last defense, they demand trust without accountability. And when they insist that progress requires ever more scale, they quietly move the costs onto communities that never agreed to carry them.

The question, then, is not whether AI can do more. It is whether this particular version of AI, built around concentration and opacity, aligns with what we actually want.

Both sessions pointed toward a quieter alternative. Narrow systems. Clear boundaries. Accountability by design. Tools meant to assist, not replace.

This is not a rejection of ambition. It is a demand for choice.

Because when we avoid the question, someone else answers it for us. And by the time the answer becomes visible, it may already be embedded in infrastructure, contracts, and habits that are hard to undo.

END NOTE

Walking out of the event that weekend, I did not feel alarmed. I felt recalibrated.

Both sessions stripped away a convenient illusion. That AI is something happening to us, rather than something being built through a series of very human choices. Choices about money. About speed. About who gets heard and who absorbs the cost.

What stayed with me was not a fear of machines becoming too intelligent. It was a discomfort with how quickly we outsource judgment. When we accept narratives of inevitability, we stop asking who benefits, who decides, and who pays. We stop noticing when abstraction hides impact.

Neither session argued for rejecting AI. In fact, both suggested the opposite. That care, constraint, and specificity are signs of seriousness, not resistance. That tools designed with limits can be more powerful than systems designed to do everything. That progress does not always look like acceleration.

I keep coming back to a simple idea from the panel discussion. Intelligence is not just about doing more tasks. It is about knowing which ones matter. That applies to humans as much as it does to machines.

If there is a takeaway from holding these two rooms together, it is this. The future of AI will not be decided by benchmarks or roadmaps alone. It will be shaped by what we normalize, what we question, and what we quietly allow to pass as inevitable.

Slowing down to ask better questions is not anti-technology. It is how we stay involved in the story rather than becoming footnotes to it.

That, to me, feels like the real work ahead.

EDITOR’S NOTE

Dear Nanobits readers,

Welcome back. In Part 1 of why AI solutions break in production, we covered behavior patterns, the foundation that makes models predictable. Structured prompts, N-shot examples, context framing, and versioning. These patterns give you stability at the prompt level.

But here's the thing: behavior patterns alone can't solve the hard problems.

They can't stop hallucinations when the model simply doesn't know the answer. They can't keep your system current when information changes daily. They can't catch unsafe outputs before they reach users. And they can't coordinate complex multi-step workflows where different models and tools need to work together.

That's what we will cover today.

We are diving into retrieval patterns that ground models in real information, governance patterns that keep systems safe and observable, and the real power move: how all these patterns compose into production-grade AI systems.

This is where AI engineering stops being experimental and starts being a discipline. Let's get into it.

RETRIEVAL PATTERNS: GROUNDING MODELS IN REALITY

Behavior patterns give structure, but prompts alone can't carry all the information a model needs. When models lack context, they fill gaps by guessing. That's exactly how hallucinations appear.

Retrieval patterns solve this by grounding the model in real information at inference time. Instead of relying on what the model learned during training, we pull relevant facts from documents, databases, and knowledge stores. This keeps systems current as information changes and dramatically reduces hallucinations for domain-specific tasks.

Pattern #1: RAG (Retrieval-Augmented Generation)

RAG replaces keyword search with semantic understanding. We embed documents into vectors and use semantic search to find content actually relevant to the user's query. The top matching chunks get passed into the prompt as context, giving the model specific factual grounding right before generation.

This is especially effective for large knowledge bases. It also keeps systems flexible, as you can update underlying documents without retraining the model, essential when information changes over time.

RAG Enhancers: Freshness and Ranking

Once you introduce retrieval, the next challenge is ensuring the model sees the right information: current, relevant, high-quality.

Freshness keeps the retrieval index aligned with reality. Documents change, numbers update, policies shift. If embeddings don't update, the model hallucinates because it's retrieving outdated truth. In production, this means scheduled re-embeddings, incremental updates, and detecting stale content automatically.

Ranking solves the opposite problem: too much information. Vector search returns a mix of relevant and noisy chunks. Ranking re-scores candidates using heuristics, hybrid search, metadata, or custom scoring to ensure the model sees only the highest-value context.

Together, freshness and ranking act as quality control for your retrieval pipeline. Freshness keeps inputs current. Ranking keeps them meaningful. When both are in place, the LLM receives clean, focused context that reduces hallucination, often more than upgrading to a larger model.

Pattern #2: Memory

LLMs don't remember anything on their own. Every call is stateless unless we manage context explicitly. The memory pattern stores relevant pieces of past interactions and feeds them back when needed.

Memory can include conversation history, user preferences, prior decisions, or any state that improves coherence. It reduces repetitive questions and makes systems feel consistent and aware.

In production, memory is selective. We store only what matters, not entire conversations. This keeps context windows manageable while maintaining continuity. Done well, memory makes systems more helpful, personalized, and contextually stable across sessions.

GOVERNANCE PATTERNS: KEEPING SYSTEMS SAFE AND OBSERVABLE

Retrieval grounds models in facts. But grounding alone doesn't guarantee safety, compliance, or reliability. Governance patterns are the control layer that keeps AI systems stable in production.

LLMs are probabilistic, they drift, vary, and fail in unexpected ways. Governance makes failures detectable, reversible, and controlled. Without governance, you cannot ship AI into real production environments.

Pattern #1: Guardrails & Escalation

Guardrails define what the model cannot do. They're not about making models smarter, they're about making systems safe, predictable, and compliant, regardless of what the model generates.

The first job: Enforce boundaries. Safety rules, policy constraints, brand guidelines, compliance requirements. Guardrails ensure the model stays within acceptable bounds.

The second job: Detect uncertainty. If the model is low-confidence, contradictory, or unsure, we don't force it to guess. Guardrails catch weak spots through confidence scores, content classifiers, and rule-based checks.

When violations occur, we escalate. Switch to retrieval, run a more reliable model, fall back to deterministic rules, or hand off to human review. Escalation keeps the system moving instead of failing silently.

Guardrails protect users, protect systems, and ensure the next step is always safe.

Pattern #2: Tracing & Feedback

If guardrails define what shouldn't happen, tracing tells us what actually happened. This is the observability layer: visibility into model decisions, failures, patterns, and blind spots.

Tracing starts with logging: Capture the full story of every request: prompt version, model used, retrieved context, latency, output, retries, escalations. Without this, debugging is guesswork. With it, you trace bad answers to root causes in seconds.

The other half is feedback: User reactions, correction signals, thumbs up/down, or automated judges that score outputs. These signals show where models struggle, where retrieval failed, and where prompts need tuning.

THE REAL POWER: COMPOSING PATTERNS

We have talked about individual patterns. But real AI systems never rely on just one. They only become reliable when patterns work together.

Prompting gives structure. Retrieval provides grounding. Governance stabilizes with rules, safety checks, and monitoring. Each pattern solves one specific problem. None is enough alone.

The Journey of a Single Query

When we talk about AI systems, it's easy to imagine the model answering in one step. But a real production system does far more than call an LLM.

Let's take a customer support bot for a department store. Here's what a single query actually touches:

Offline: We construct system prompts with behavior patterns and test against various models and retrievers.

Online: The query arrives:

1. Intent classification using structured prompts determines what the user wants

2. Routing decides which model or workflow to use based on intent

3. Retrieval pulls relevant context and ranks the best pieces so the model gets clean, focused information

4. Generation produces the initial output

5. Schema validation ensures structure is correct

6. Guardrails check confidence, safety, policy, and correctness

7. Tracing logs everything for debugging

8. Feedback collection captures user reactions for system improvement

Even though the user sees one answer, that query touched eight different patterns behind the scenes.

This is what AI-native really means. Not one clever prompt. Not one powerful model. But a composition of patterns working together where each handles one responsibility and the overall pipeline is testable, versionable, and monitorable.

END NOTE

The future of AI-native development is about attaching structure. Instead of large monolithic prompts, we need to assemble systems from modular patterns that plug together like building blocks.

We are moving from single-model systems to model ecosystems where different components specialize and collaborate. Instead of one-off hacks or clever tricks, we need to rely on architectures that are predictable, maintainable, and scalable.

Composable AI means building systems like we build software today: through reusable components, clear boundaries, and well-defined interfaces. This shift is what will make AI-native product and engineering a real discipline rather than experimental practice.

The gap between demos and production isn't about finding better models. It's about engineering discipline. These patterns are how we close that gap.

AI systems fail in ways traditional software doesn't. They drift. They hallucinate. They vary unpredictably. But with the right patterns, we can wrap probabilistic models in enough structure that the overall system behaves reliably.

So what can you do next?

If you're building: Start with one pattern. Add structured prompting to one feature. Version one prompt. Implement basic tracing. Build incrementally.

If you're leading: Invest in AI infrastructure now. Prompt management systems, evaluation frameworks, observability tools. These aren't nice-to-haves anymore, they're requirements for shipping at scale.

If you're still experimenting: Good. Keep experimenting. But when you're ready to ship, come back to these patterns. They are the difference between systems that work in demos and systems that work in production.

The engineers who presented at GDG Seattle ended with this thought: "AI-native systems aren't about making models smarter. They're about making systems predictable." I totally loved that statement. Not better models. But better patterns.

EDITOR’S NOTE

Dear Nanobits readers,

Last week, I found myself in a packed room at the Google Developer Group meetup in Seattle. Two senior engineers from big tech were presenting on something I had been struggling with for months: why do AI features that work in demos fall apart in production?

I have shipped a few AI features this year. Two broke in ways I couldn't explain. One hallucinated confidently. Another became inexplicably slow. The third just drifted: same prompts, different behavior few weeks later.

What frustrated me most? No playbook. No structured guidance. Just vibes, copied prompts, and developers quietly dealing with chaos. We have been treating AI product development in a very unscientific way.

That presentation changed everything. For the first time, I saw a coherent framework treating AI product development as actual engineering. Design patterns for probabilistic systems. Reusable solutions that work.

So I planned to write a two-part series to cover everything I learnt. Today we are covering why traditional patterns fail and the behavior patterns that form the foundation. In Part 2, we will tackle retrieval, governance, and composition.

Let’s get started.

THE FOUNDATION HAS CHANGED

Traditional software assumes determinism. Give a function the same input, get the same output. Every time. That consistency makes systems testable, scalable, predictable. Our entire toolkit from unit tests, monitoring, failure analysis, all assume that once you define a rule, the system follows it.

AI broke that assumption.

Models are probabilistic. Behavior depends on context, phrasing, retrieval results, temperature, and variables we never considered in classical architecture. The variation breaks mental models we have relied on for decades.

A system that shifts behavior based on context means:

• Tests aren't proofs of correctness

• Edge cases are infinite

• Failures have no clear boundaries

The goal isn't to fight probabilistic behavior, it's to wrap LLMs in enough structure that the overall system behaves predictably, even when the model doesn't.

Deterministic vs Probabilistic

Why Now?

78% of companies globally use AI daily. But most teams build without shared vocabulary or structure. That creates chaos.

And the cost of no patterns:

Prompt sprawl. Prompts copied around, modified, no one knows what's running.

Inconsistent outputs. Different answers to different users. Hallucinations appear randomly.

Escalating costs. Every request hits the expensive model. No intelligent routing.

Impossible to test. Can't version prompts, isolate errors, or monitor quality.

Stuck at prototypes. Demos break under real user inputs.

Developers wasting weeks trying to debug the impossible

The real cost? Systems fail in ways you cannot detect or recover from. Patterns turn AI into engineered products, not unpredictable demos.

WHAT ARE AI-NATIVE DESIGN PATTERNS?

Traditional design patterns have assumed structured functions and classes. AI-native patterns are different. They are model-centric, operating at the system level.

They address:

• How LLMs behave with context

• How outputs drift over time

• How to manage uncertainty and variability

These are architectural patterns for probabilistic systems.

Today we will cover Behavior Patterns. Retrieval, Governance, and Composition will be covered in our Part 2 next week.

BEHAVIOR PATTERNS: THE FOUNDATION

Behavior patterns shape how models think before adding external context. They give structure, reduce variability, and make systems predictable.

Without stable behavior at the prompt level, everything else including retrieval, orchestration, and safety become exponentially harder.

Pattern #1: Structured Prompting

When models follow consistent formats like JSON schemas, fixed fields, predictable layouts, the behavior becomes far less chaotic. Every downstream component depends on structured output.

How it works:

Instead of "What is my store policy for XYZ?", divide prompts into sections:

Role: "You are a store policy assistant."
Task: "Answer customer questions about store policy."
Context: "Use the ABC Policy document."
Format: "Output as JSON: {category, urgency, next_action}"
Constraints: "Abstain when unsure."

Most models now support structured output natively. But even without API support, explicit instructions improve consistency dramatically.

Don't let models improvise structure. Define it upfront. Enforce it consistently.

Pattern #2: N-Shot Prompting

Show, don't tell. Models learn by imitation. High-quality examples, especially covering edge cases, help anchor reasoning and formatting.

Example:

Input: "I can't believe this happened!"  
Output: {"mood": "surprised", "intensity": "high"}

Input: "It's fine, I guess."  
Output: {"mood": "neutral", "intensity": "low"}

Now classify: "Well, that was unexpected."

Use for complex classification, nuanced tone requirements, and edge case handling. Select examples that span the decision space.

Pattern #3: Context Framing

LLMs respond to framing, not just tasks. Vague frames force guessing. Explicit frames create predictability.

Three components needed to ensure this:

1. Reduce ambiguity: Tell the model the audience, tone, constraints, business rules. Don't let it improvise.

Example: "Summarize this contract for non-technical executives. Focus on financial obligations and termination clauses. Plain language. Under 200 words."

2. Set identity and boundaries: Define the model's role and what it should avoid.

Example: "You are a compliance assistant. Never provide investment advice. Only reference approved regulatory documents."

3. Right context window: Add only what supports the task. Don't overload with irrelevant information.

Context framing improves reliability without model changes or fine-tuning. When framing is tight, reasoning focuses, outputs stabilize, failures become predictable.

Pattern #4: Prompt Versioning & Experimentation

A prompt has behavior, side effects, and can break production. Treat changes accordingly.

Three components to keep in mind:

1. Explicit Version IDs: Track which version produced which output. Debug regressions. Compare performance. Roll back safely.

2. Controlled Experimentation: Small edits cause big behavioral shifts. Run A/B tests, shadow tests, canary deployments. Never just replace prompts.

   Compare versions against real traffic or evaluation judges. Ask: "Is this measurably better?"

3. Lifecycle Management: Update prompts as retrieval, memory, or guardrails evolve. Iterate, revert, ship improvements with confidence.

   

   Versioning creates feedback loops. You see what breaks, understand why, fix systematically, improve continuously. It's the difference between shipping AI and staying stuck in prototypes..

END NOTE

These four behavior patterns: structured prompting, N-shot prompting, context framing, and prompt versioning are the foundation for AI native design. These are no longer optional. Not nice-to-haves. This is where the difference is between demos and production.

So what can you do immediately?

Engineers: Pick one production prompt. Version it. Add structure. Test variations. Measure the difference.

PMs: AI reliability comes from better patterns, not better models. Ask: "How are we versioning prompts? What happens when something breaks?"

Leaders: Invest in prompt infrastructure now. Versioning, evaluation, observability. These are the foundation of shipping AI at scale.

But behavior patterns alone can't solve everything.

They make models predictable but can't solve hallucination when models don't know answers. Can't handle dynamic knowledge. Can't keep systems safe from adversarial inputs.

So in Part 2, we will cover:

Retrieval Patterns: RAG, memory, and freshness that ground models in real information

Governance Patterns: Guardrails, tracing, and evaluation loops that keep systems safe and observable

Composition: How these patterns work together in production, and what happens when a single query touches eight patterns behind the scenes

The gap between demos and production isn't model quality. It's product and engineering discipline. These patterns close that gap.

See you in Part 2.

EDITOR’S NOTE

Dear future-proof humans,

Welcome to another edition of Nanobits. Finding the right topic each week takes time and lots of time. Writing it takes even more. So once in a while, we team up with people who live and breathe this work. It helps us bring you ideas that feel current and useful. It keeps the newsletter grounded in real practice, not theory.

For this newsletter, I worked on this newsletter with a dear friend and ex-colleague, Virendrasingh Suryavanshi, who has spent many years in the PM seat. He has a patient way of asking sharp questions that unsettle easy ideas. Each time we talk, he challenges my first thoughts and helps me see what sits beneath them. I walk in certain. I walk out, curious again.

This felt like the right moment for a conversation like that. The market is tense. The tools keep changing. New PMs feel lost. Experienced PMs wonder how much of their craft will hold. Everyone is trying to figure out what the next version of the role looks like.

So we sat down and stripped away the noise around AI and product work. We wanted to share something clear and steady. Something you can read, use, and return to.

This issue is about one question. How to become an AI product manager in 2026 and beyond. Not the title. The practice. The skills that matter. The roles that are real.

Let us begin.

Will AI replace Product Managers, or should I be worried about my career?

No, but it will replace PMs who refuse to adapt.  

I know. I know. You have read this many times. So, reading this one more time should not be a big deal. Because no matter how many lines of code it generates, AI can not carry the full human judgment, vision, and relationship-building that the role of a product manager demands.

At its core, product management remains about discovering problems, being the customer’s voice, and aligning business goals with product ambition. No AI can feel the frustration of a user whose workflow is broken, nor can it negotiate a tricky alignment between engineering and sales.

Research from Egon Zehnder finds that while AI automates data analysis and forecasting, the human PM’s role shifts toward “crafting strategic vision, driving user-centric innovation, guiding organisational alignment”. Egon Zehnder

Here are two ways the expectations are changing:

The human moat: soft skills & strategy

AI handles ambiguity poorly. A model might propose “build feature X because data shows growth”, but it won’t gain buy-in. The PM still needs to influence teams, steer conflicting agendas, and make judgment calls based on timing, context, and market nuance.

The force multiplier: AI as a tool, not a rival

Treat AI like an “ultimate intern”. It can summarise meeting transcripts, automate Jira tickets, and extract patterns from support logs. That frees you from the execution trap and lets you focus on vision and direction. One of my early use cases of AI was:

Your career advantage doesn’t come from resisting AI, but from embracing it. According to DeepLearning AI, “writing software, especially prototypes, is becoming cheaper. This will raise demand for people who can decide what to build.” DeepLearning.ai

Here’s how the divide is shaping up:

Efficiency & productivity (the speed advantage) AI saves both time and the mental load from context switching. 

At my organization, "we now leverage transcriptions from Gemini in every meeting. There is no longer the need for an APM to multitask, making notes, and listing action items. They can be completely engaged in the meeting, focusing on asking relevant questions to customers or stakeholders, while still receiving instant, accurate action items assigned to each stakeholder.”

Moderna (the biotech giant) didn't fire its staff; it bought every employee subscriptions to ChatGPT Enterprise version, resulting in 750+ custom GPTs created internally. These "agents" now handle contract reviews and regulatory drafting, automating 40% of the operational load so their experts can focus on science, just like you are focusing on the customer.

Enhanced decision-making (the data advantage). Traditional PMs waited for analysts to write SQL. AI-enabled PMs ask natural-language queries and get insights instantly. Less risk, faster direction.

In one of my previous companies, we trained an AI assistant with a comprehensive README note on the data storage structure and complete table schema. Despite the initial effort, this assistant eliminated the need to manually identify the correct table schema, formulate queries, or locate specific data. Now, by simply using a natural language query, I could access precise data with minimal error risk. This dramatically sped up tasks that PMs often deferred or that previously required us to chase analysts for days or even weeks; now, the answer was instantly available via text.

Adaptability & strategic influence (the career moat) As AI handles execution, your value shifts to adaptability and influence. 

AI provides the "what" (data arguments); you provide the "so what" (persuasion). PMs who use AI to draft data-backed PRDs get buy-in faster because their arguments are bulletproof. 

When a company like Airbnb shifted the PM function from “product management (coordination)” to “product marketing (strategy & vision)”, they were adapting to an AI-first world.

In fact, I'm not sure how much of this is actually true, but Netflix claimed that they will pay an exorbitant amount of money to the PM who can use AI to do their work.

The Bottom Line: The PM who ignores AI is competing with a PM who has an infinite team of interns (AI tools). That is a losing battle!

What exactly is an AI Product Manager, and is it just marketing hype?

Is it hype? Mostly, yes. 

Unless you are working on optimizing foundational models at companies like OpenAI or Anthropic, or fine-tuning internal models for your organization, I don’t believe the title "AI Product Manager" is necessary.

Instead, the industry is seeing the rise of the AI-Native PM. How is it different from AI PM?

Why the "AI PM" title is trending (and when it’s real). While often used as a marketing buzzword to attract talent, the role becomes legitimate when the product is the AI.

Core Responsibilities: It involves defining product strategy based on AI capabilities, setting goals for model performance, and prioritizing features that rely on complex data pipelines.

The Skill Set: It requires a deep understanding of technical constraints (latency, cost, hallucinations) combined with traditional customer empathy.

My takeaway is that: Don't stress about the title. The goal isn't to become an "AI PM" by name, it's to become an AI-Native PM by practice. The former is a niche; the latter is the future of our entire profession.

How do I break into Product Management in the AI age without technical experience?

Stop trying to be just an "Idea guy" and start being a "Builder."

Because the market is tough. In top-tier organizations (especially in Bangalore, India, and the Bay Area in the US), the ratio of Product Managers to Developers is roughly 1:6. "Real" product roles are scarce, and competition is high. In fact, in many large organizations like Amazon, about 23-27 engineers are mapped to one senior PM.

However, the definition of "technical experience" has fundamentally changed in the last 24 months. You no longer need to know how to write code to prove you can build software.

So, what’s your alternative, and how can you break into PM using the AI advantage: 

1. The New Essential Skill: Critical Thinking > Coding

Today, syntax is cheap, but logic is expensive. You don’t need to know Python or JavaScript to be a PM anymore, but you do need to master Problem Decomposition.

Hiring managers aren't looking for someone who can write a for loop; they are looking for someone who can:

• Take a vague user problem.

• Break it down into logical steps.

• Orchestrate AI tools to solve it.

Your Advantage: If you come from a non-technical background (Sales, Support, Marketing), you likely understand the customer better than the engineers do. Your "hard skill" is translating that customer empathy into a logical solution.

2. The Strategy: "Demo > Deck"

Gone are the days of the 10-page slide deck. If you want to stand out in a pile of 500 resumes, do not send a document. Cold DM founders a working prototype over X (Twitter).

source post

Because AI has lowered the barrier to entry, "I don't know how to build it" is no longer a valid excuse. Showing a functional MVP proves you possess the ability to adapt, learn, and execute, the three most important traits of a modern PM.

3. Internal Transfer & Networking: Permissionless Innovation

If you are currently in a non-PM role, don't wait for permission to act like a PM.

Send a message to a product leader saying: "I noticed customers struggling with X. I used AI to mock up a potential solution/prototype here. Would love your 2 cents on the approach."

You are no longer asking for a job; you are demonstrating the value you bring to the table. That is how you get the interview.

The extent of technical knowledge required today is literacy, not fluency. You need to know what is possible, how systems connect, and how to prompt an LLM to do the heavy lifting.

Leverage the power in your hands. Transform your thoughts and creativity into working demos.

What AI skills should I actually learn to become competitive as a PM?

The goal here is not to become a Machine Learning Engineer, unless that’s what you want. The goal is to become a PM who understands the "Architecture of Feasibility", knowing what is easy, what is expensive, and what is impossible.

1. The Core AI Concepts (Your New Technical Literacy) You don't need to know how to code a neural network from scratch. You need to understand the concepts of AI; without it, you cannot prioritize effectively:

We built a document intelligence agent on n8n using RAG principles

2. The "New" MVP: Prototyping (Vibe Coding)

Is knowing how to code important? No, writing production code is not your job. But Prototyping is. You should be able to use tools like Replit Agent, Claude Project, or Lovable to build a working "ugly" version of your idea. In the time it takes to write a ticket explaining a feature, an AI-Native PM has already built a working prototype to show the engineers. This is the new standard for “technical”.

3. The Most Critical Skill: "Evals" (The New QA) In traditional software, a button works or it doesn't (True/False). In AI, a button might work "mostly." You should learn how to design Evals (Evaluations). This means creating a dataset of "good answers" and "bad answers" to automatically test your AI product. If you can't define what a "good" response looks like, you can't launch an AI product.

You don't need a PhD in Math. You need a PhD in Curiosity.

How is AI changing the PM hiring and interview process?

The "First Round" is no longer human, and your preparation shouldn't be either.

1. AI interviewers are the new gatekeepers. Companies are drowning in applications. To handle the volume and filter out candidates, many are deploying AI interviewers (like HireVue or Veloxhire); these conduct 30-minute voice or text chat to screen for communication clarity and core competencies (initial video screening).

2. Don't be the "Teleprompter Candidate." I recently interviewed an APM candidate, and I could see his eyes moving left to right, reading ChatGPT in real-time. Experienced hiring managers can spot this instantly. The delay in audio, the unnatural eye movement, and the "generic perfection" of the answer are dead giveaways. 

3. Instead of cheating during the call, use dedicated AI Mock Interview Platforms (like Final Round AI) before the call. Unlike standard ChatGPT, these platforms record your video and audio to analyze your delivery, not just your content. They will flag your filler words ("um," "like"), measure your speaking pace, and even track your eye contact. It’s a safe space to fail and refine your pitch so that when you meet the real Human (or AI) interviewer, you are polished and confident.

4. Expect questions that test your ability to manage uncertainty (probabilistic products) vs. certainty (deterministic software).

"How would you evaluate if we should swap our internal search algorithm for an LLM?" (Tests Cost vs. Quality judgment). 

"How do you handle a user complaint about an AI hallucination?" (Tests Risk Management). 

These are some questions you can expect during your interview. 

5. Your resume is likely being read by an AI (ATS) before a human. Use AI to speak its language. Paste your resume and the specific Job Description (JD) into an LLM.

You will get a highly tailored resume that passes the automated screen, increasing your odds of getting shortlisted.

AI can get you the interview (by optimizing your resume), and it can help you ace it (by mock interviewing you). But if you bring it into the interview, it will cost you the job. Authenticity is the only thing that can't be automated.

End note

The role is shifting. The outcome you deliver now matters more than the steps you take. Leaders care about retained users, new revenue, and sharper focus. Not the number of hours you spent inside Jira or the tools you used along the way.

A new path is emerging. Some PMs are becoming “Super ICs” who work with the force of a small team. They use AI to clear the routine work and then spend their time on direction, experiments, and customer depth. They shape ideas, test fast, and move with speed that used to need five people.

This shift brings pressure. Everyone feels the need to use every new tool. The truth is simple. Use AI where it makes your work lighter. Stay rooted in the core problem. Your job is not to do everything with AI. Your job is to decide what matters.

If you plan to pivot, start now. Growth in this field is fast. Do not wait for a perfect course or a new title. Build experience inside your current work. Automate one task. Then another. Close the gap between idea and prototype. Turn saved hours into real progress.

The real curriculum is quiet and practical. Watch the people who ship real products. Follow builders who share how they test, break, rebuild, and learn. They will teach you more than any certificate.

Do not treat “AI Product Management” as a niche. Treat it as the new way to work. The PM who moves ahead will be the one who says, “I shaped the idea. I built the first version. I tested it with real users. Now this is what we should take to market.”

The job is not disappearing. It is expanding. And this is your moment to grow into it.