When it wakes up, it needs to do three things fast: understand what was said, decide a response, and speak it back. This requires three separate AI services running in sequence. Speech-to-Text (STT) for transcribing the user’s voice. A large language model (LLM) for understanding and reasoning. And Text-to-Speech (TTS) for generating the spoken response.

The challenge is latency. A home assistant that takes 10 seconds to respond to every request is not useful. The pipeline needs to be fast, and that requires careful choices.

The three services

Each stage introduces its own delay.

STT models process audio and produce text. Good models are computationally expensive. Cheap models make transcription errors that confuse the LLM downstream. The goal is a model that balances accuracy with speed.

The LLM is the heaviest stage. It has to understand the query, reason about context, decide if tools are needed, and generate a response. Each step takes time. Response generation is especially slow because it happens token by token.

TTS is fast relative to the others, but it still adds overhead. Generating natural-sounding speech takes compute, and the full response must be generated before playback starts, unless you stream it.

Speed is the requirement

For this use case, speed is the most important metric. A slow assistant does not get used. I decided early that every choice in the pipeline would prioritize latency.

This means choosing fast models over accurate models. It means streaming STT to overlap with LLM processing. It means pipelining TTS by splitting responses into sentences. It means optimizing the network path between services. It means accepting that some accuracy trade-offs are worth the speed gain.

Choosing the LLM

The LLM is the bottleneck. I tested several options.

I am currently using Gemini 3.1 Flash Lite. It is fast. The API response times are consistently low, and the model quality is good enough for the types of queries a home assistant handles. Calendar checks, object recognition, simple questions about what the camera sees.

Groq is another option. They run open-source models on custom hardware optimized for inference speed. The latency is impressive. The drawback is model selection. You are limited to the models Groq hosts, and those change over time.

Cerebras is similar. Their hardware is designed for low-latency inference, and the speed shows in benchmarks. But again, you depend on their model catalog.

All of these are cloud services, which introduces a different kind of latency. Network round trips. API queue times. Service availability. For a home assistant, cloud dependency also raises the privacy concerns I discussed in Part 1.

That said, the data I send to remote LLMs is relatively limited. The camera recordings stay on my device. I never upload video footage to the cloud. The assistant only sends transcribed text to the LLM, and the content of those transcriptions is usually mundane. Calendar checks. Simple questions about objects in view. The camera is rarely asked to process saved recordings. I will cover recording handling in a future article.

The local GPU question

The ideal solution for speed is running a local model on a local GPU. No network latency. No API queues. No dependence on external services. Full privacy.

But there is a cost problem. A local GPU capable of running a capable model costs several thousand dollars. And the GPU sits idle most of the time. A home assistant is used sporadically throughout the day. Fifteen seconds of inference here, thirty seconds there. The rest of the time, the GPU is doing nothing.

Paying thousands of dollars and dedicating power to a GPU that runs for minutes per day is hard to justify. Cloud APIs charge per request. You pay only for what you use. For a home assistant, that pricing model makes more sense.

I believe local GPU will become the standard eventually. Hardware costs will come down. Smaller, more efficient models will run on cheaper hardware. And the privacy and latency advantages are real. But for 2026, cloud services are the practical choice for most people building their own system.

Streaming as a latency hack

Full token-level streaming from the LLM through TTS sounds great in theory. In practice, I found it too complex to implement reliably. The timing gets tricky when the TTS system has to handle partial tokens cleanly.

But two forms of streaming are worth the effort.

The most effective one is streaming STT. The user may take several seconds to finish a question. That time should not be wasted. With streaming speech recognition, the system produces partial transcripts as the user speaks, rather than waiting for complete silence. The LLM can start processing the first few words while the user is still talking. By the time the user finishes speaking, the LLM has already started generating a response.

Streaming TTS is useful only when the response is long. For short answers, the overhead of setting up the stream cancels the benefit. My approach is simpler. I take the LLM’s full response, cut it into sentences, and send each sentence to TTS as it becomes available. The first sentence starts playing while the rest of the response is still being generated. This is not true streaming, but it achieves the same effect with much less complexity.

The conversation continuity trick

There is another latency problem that streaming does not solve. Some queries require tool calls.

When the user asks “Do we have any plans this weekend?” the assistant needs to check a calendar. That means the LLM recognizes the intent, returns a tool call, the calendar API runs its query, and the result gets fed back into the LLM before it generates the final response. Each tool call adds seconds of latency.

I found a simple fix for this.

When the LLM decides it needs a tool, the assistant immediately says something like “Let me check that for you” or “Let me take a look.” This filler speech plays while the tool runs in the background. The user hears a natural response instead of dead silence.

The same trick works for visual queries. If the user asks “What is that on the counter?” the assistant can say “Let me take a look” while the vision model processes the camera frame. By the time the filler speech ends, the tool result is ready, and the assistant delivers the actual answer.

This is a small detail, but it affects how responsive the system feels. Silence makes a product feel broken. A quick acknowledgment makes it feel responsive, even when the underlying processing takes time.

An end-to-end alternative worth trying

Google also offers the Gemini Live API. It handles the full pipeline in a single WebSocket connection. STT, LLM, and TTS all run together on the server side, with low-latency audio output streaming back to the client. It is designed for exactly this use case.

In theory, an end-to-end approach should deliver better quality than stitching separate models together. The LLM has access to the raw audio and can use tone, emphasis, and timing to interpret meaning. The TTS output can match the model’s intended delivery. The whole pipeline benefits from tight integration.

I have not spent much time testing it yet. But it is worth trying.

What comes next

The pipeline works. STT captures the query, the LLM processes it with streaming, tool calls feel natural with filler speech, and TTS delivers the response quickly.

The next part of this project is about video recordings. The assistant and the recording system will be separate modules. Recordings are about capturing and storing video locally, without cloud uploads or subscriptions. That will be the topic of the next article.

Several rumors turned out to be real. Gemini Omni and Gemini Spark launched as expected. But the community had a different hope going in. A lot of people expected Google to release a model that beat every existing top model on benchmarks. That did not happen. And the reactions were predictable.

What Wasn’t Great

Let me start with what did not work well.

Google did not launch any model during I/O that was strong enough to get the community excited. Gemini Omni is an impressive concept. It can create anything from anything. But for now, that starts with video only. Gemini 3.5 did arrive, but only in the Flash variant, and it costs about three times what Gemini 3 Flash costs. I saw comments online saying Google is losing on models, or even losing on AI overall. That is not true. Google’s research pipeline and infrastructure are deep. But I understand why people felt underwhelmed. The model launches were not yet impressive.

The other problem was branding. Google now has too many AI brands and it is probably already confusing people. Just to name a few: Imagen, Veo, Flow, AI Studio, Antigravity, Gemini, Nano Banana, Gemma. This I/O made it worse. In particular, the transition of Gemini CLI (which competes with Claude Code) to Antigravity CLI drew real complaints on social networks. Developers who had invested in one product found themselves being asked to learn a new name and mental model.

What I Noticed That Almost No One Is Talking About

Here is the part that surprised me. In the middle of all the model debate and brand confusion, I noticed something that is getting almost no discussion on social networks.

Google’s focus has shifted. They are building AI platforms and ecosystems. Not individual models. Not individual tools. Platforms.

Watch the Demis Hassabis fireside chat during the conference. When he was asked what he would expect to talk about at next year’s I/O, the first thing he said was this: “There will be a lot more agents in the real world are kind of embedded in our workflows.” That was the first thing on his mind. Not stronger models. Not a world model. Not a better AI assistant. It was agents embedded in workflows. It was platform.

Consider Antigravity. It is becoming Google’s agent-first development platform. That is why you see Antigravity App, Antigravity SDK, and Antigravity CLI. All three are different entry points to the same platform vision.

AI Studio is also becoming a platform, but through a different path. Google has made it very easy to prototype and deploy apps there. There are close integrations with Google Cloud for deployment and with Google Play for publishing apps. The functionality overlaps with Antigravity in some places. But both feel like Google is exploring what an AI platform could look like.

The Model War Will Eventually Become Less Meaningful

On social networks, people are still debating which model is the best. From my view, that debate is becoming less and less meaningful.

A great model launch gives you a few months of attention. But that is not a long-term win. It is hard to convert benchmark leadership into a reliable business. Whoever owns the AI platform wins over time.

This does not mean models are unimportant. A fundamentally different model architecture could change things entirely. But competing for benchmark position alone is not a winning approach. Google seems to understand this. I am not sure the broader tech community does yet.

One Fun Note

I saw a lot of bananas at I/O. Real bananas and fake bananas. All because of the Nano Banana codename.

I hope Google names the next model after something more interesting to eat. The conference floor could use some variety.

What do you think wins in the end: the best model or the best platform?

The next step was giving the assistant ears.

I needed a way for the camera to know when I was talking to it. The straightforward approach is continuous listening. Stream all microphone audio to a Speech-to-Text (STT) model, transcribe everything, and look for a trigger phrase in the text.

That approach is wasteful.

STT models are heavy. Running one continuously consumes significant CPU, memory, and power. It introduces latency. Most of the time, a room is quiet. Or people are having conversations meant for each other, not the camera. Processing hours of background noise through a large neural network is not cost-effective.

A better way is to use a wake word model.

The gatekeeper

A wake word model is a small, highly specialized neural network. It does exactly one thing. It listens to a continuous audio stream and calculates the probability that a specific phrase was just spoken.

When it hears the phrase, it wakes up the main system. Only then does the heavy STT processing begin. Everything else is ignored.

Because of this specific focus, a wake word model is trained for a dedicated phrase. Using a generic model is less efficient.

I looked for tools to build one. OpenWakeWord is an existing framework for this. It provides an architecture for training small models that run efficiently on edge devices.

But training a model requires data. You need thousands of audio samples of different people saying your specific wake word. You also need negative examples so the model learns what to ignore. Recording these manually is not practical for a DIY project.

Automating the training

I found a library called livekit-wakeword. It automates the training process on top of the OpenWakeWord architecture.

It solves the data problem using synthetic generation. The library leverages text-to-speech models like Piper and VoxCPM to create the training data.

I provided the text of my wake word. The library generated thousands of audio clips in different voices. It created positive examples of the wake word. It generated negative adversarial examples. It mixed in background noise. Then it trained a model and exported it to the ONNX format.

The process is easy to use. I defined my configuration and let it run.

The silence problem

The automation worked well, but I noticed a problem during my first few attempts.

The text-to-speech models often generated audio clips with significant silence at the beginning or end. When these padded clips were fed into the training pipeline, it confused the model. The model learned to associate empty space with the wake word. The accuracy degraded.

I solved this by adding one additional step. I wrote a script to strip the silence from the generated audio files before passing them to the training phase.

Once I removed the dead air, the training worked. The rest of the process remained mostly automatic.

The result

The final trained model is only 165 kilobytes in size.

Because it exports to ONNX format, it is highly optimized. I can run it continuously on a standard CPU with very low utilization. The camera sits quietly, consuming almost no processing power, until it hears its name.

The assistant can now listen efficiently. The next challenge is figuring out what happens after it wakes up. I need to process the speech, understand the intent, and generate a response. I will cover that pipeline in the next article.

Now I needed hardware.

Two paths

I had two options.

Option one: buy a commercial camera and install custom firmware. This gives you a finished product with a nice case, power supply, and everything integrated. The trade-off is you cannot easily modify the hardware. You get what the manufacturer built.

Option two: buy a development board and build from scratch. Selecting components. Designing or finding a 3D-printable case. Wiring power and connections. Integrating the pieces. More work, but total control over the final product.

For my first DIY camera project, I went with option one. I wanted to focus on software and AI integration, not hardware assembly. A commercial camera with custom firmware would let me start faster.

Research before purchase

I researched firmware options before buying anything. Which cameras had active open-source firmware communities? What features did those firmware releases support? How difficult was installation?

This research led me to Thingino, an open-source firmware for IP cameras built on Ingenic SoCs. Thingino replaces the manufacturer’s firmware with a system designed for local control. No cloud dependency. No vendor lock-in. SSH access by default.

The project maintains a list of over 150 supported cameras. Wyze, Eufy, Xiaomi, TP-Link Tapo. Lesser-known brands like Cinnado, Galayou, and Wansview. All hackable with the same firmware.

Choosing Cinnado D1

I needed two-way audio for communication. Night vision for after dark. Pan and tilt for adjusting the view. Good resolution. And an installation process that did not require soldering or specialized tools.

The Cinnado D1 matched all of these. 360-degree pan and tilt. Two-way audio. Night vision. 2K sensor. I bought it for $10 during an Amazon sale. Right now it sells for around $15. And it supports what Thingino calls “no-tool installation.”

No-tool installation means placing a firmware file on a microSD card, inserting the card into the camera, and powering it on. The camera’s stock bootloader looks for a specific file name and uses it to replace the firmware.

I bought the Cinnado D1.

Verifying the hardware

Thingino supports two hardware variants of the Cinnado D1. One uses the T23N SoC. The other uses the T31L SoC. Each requires a different firmware file. I needed to identify which chip my camera contained.

The Thingino documentation explained how to check. The Cinnado D1 case consists of two parts clipped together. No screws. I used a plastic credit card to separate the upper case from the bottom, adjusted the camera module, and found T23 printed on the circuit board.

Five minutes. The case opened easily. The chip was visible without disconnecting anything. I closed the case and moved on.

Installing Thingino

I downloaded the T23N firmware from the Thingino releases page, copied it to a microSD card, inserted the card, and plugged in the power. The camera installed the firmware automatically. Two minutes later, it finished and entered setup mode.

Thingino uses a captive portal for initial configuration. I connected my phone to the camera’s Wi-Fi network, opened a browser, and entered my home network credentials. The camera joined my network and became accessible through its IP address.

What SSH access unlocks

With Thingino installed, I could SSH into the camera.

This is what separates a consumer product from a development platform. SSH access gives me control through command-line tools. Subscribe to the RTSP stream for live video. Use the play command to send audio through the speaker. Use motors commands to pan and tilt.

These are the building blocks for the Home AI Assistant. A camera that accepts commands and provides streams can integrate with other systems. I can write software that captures frames, processes them with AI, and responds through audio or motion.

The stock Cinnado firmware would never allow this. It locks the camera into the manufacturer’s app and cloud service. Thingino unlocks the hardware.

What comes next

The camera now sits on my desk, running Thingino, accessible through SSH. I can see the video stream. I can send audio. I can control the motors.

The hardware foundation exists. Now I need to build the software that captures video, applies AI processing, and coordinates responses. That work will determine whether this project becomes something genuinely useful or just an interesting experiment.

Future articles will cover the software architecture, AI integration, and the challenges of making a camera that answers questions about what it sees.

The app worked well too. Clean interface, quick access to live feeds, easy playback. It felt like a product designed to help parents, not extract value from them.

That changed gradually.

The slow decay

Over time, the Yi Home app became harder to use. The cause wasn’t bugs or poor design. It was deliberate friction. Ads appeared. First a short one when opening the app. Then longer ones. Then ads before watching recorded clips. The camera was designed to upload clips to cloud from the start. I accepted that trade-off for convenience. But now to watch my own recordings, stored on Yi’s cloud, I have to sit through ads.

The only way to remove ads is a subscription. Yi wants me to pay monthly to watch my own recordings without interruption. I was fine with cloud storage. I am not fine with paying a recurring fee to access videos that I didn’t intend to upload, or watching ads to see my own home footage.

The same connectivity that adds smart features allows product degradation. Once a device connects to the internet, the manufacturer controls it remotely. Features you paid for can disappear. Ads can appear. Privacy settings can change. You bought the hardware, but you rent the functionality.

A different approach

I decided to build my own system.

I wanted more than a Yi replacement. I wanted a home camera that stores everything locally. No cloud uploads unless I choose them. No subscription fees. No ads that will appear through future updates.

And I wanted something smarter than traditional cameras.

Imagine asking the camera a question while holding a book. “Tell me about the author.” The camera sees the book cover, identifies it, searches for author information, and speaks the answer. Imagine asking “Do we have any schedules this weekend?” The camera checks both my calendar and my wife’s calendar, then summarizes what’s coming up.

These solve real problems. A camera with AI shifts from monitoring device to assistant. It can answer questions about what’s in view, check calendars, and provide information without requiring me to pull out a phone.

Commercial cameras cannot offer this path. Their AI features focus on detection alerts and motion classification. Useful, but limited. A DIY system can integrate any AI capability I want, limited only by what the hardware can run and what software I can build.

The project

I call this project Home AI Assistant. Traditional home camera features plus AI capabilities, all running locally.

The basics: motion-based video clip saving, live streaming to phone, two-way audio communication.

The AI features: visual question answering, calendar integration, and room to add more capabilities over time.

All recordings stored locally. No cloud required. No subscription. No ads.

I have already started development. Future articles will cover hardware choices, software architecture, AI integration, and the challenges I run into along the way.

If you have dealt with similar frustrations with smart home products, or if you are curious about building AI-powered devices that keep your data local, this series is for you.

Yesterday, Google launched Lyria 3. I opened the Gemini app to try it, typed in a prompt, and 30 seconds later, I had a custom track. The music was genuinely good.

So I got curious: what else could AI help with?

I decided to test it. I’d make a 30-second marketing video - using my previous project as a test case. No code written by me. No video editing software. Just prompting and guiding. The background music would come from Lyria 3. For the visuals, I’d use Remotion (a video programming framework) and let AI generate the code.

Here’s what happened.

The Good: AI Music Actually Works

Lyria 3 delivered. I fed it my project’s README so it understood what the product did, described the mood I wanted, and 30 seconds later had a track with custom lyrics. The music sounded professional enough for a marketing context. I couldn’t have produced something like this myself - I have no musical training. But now I don’t need to.

The Bad: AI Visuals Need a Crutch

The visuals were a different story.

I started by describing what I wanted. Clean visuals. Product demo with text overlays. The results were technically correct but boring. Flat. The kind of video that checks boxes but doesn’t feel anything.

That’s when it hit me: AI doesn’t have visual taste. Neither do I, honestly. We’re both guessing.

So I tried giving AI a reference. I showed it Lyria 3’s marketing video. “Make something like this.” The difference was immediate. The AI couldn’t match the original quality, but it understood the visual language - the pacing, the layout, the transitions. It had something to follow.

My video isn’t as good as Google’s. But it’s infinitely better than what I got from just describing what I wanted. The lesson: for visuals, AI follows examples better than it creates from scratch.

The Ugly: The Iteration Loop

Then came the actual work.

Ideally, the iteration loop would be automated: generate code → render → screenshot → review → correct → repeat. But AI doesn’t naturally do this. Without explicit prompting, it does a one-off implementation with many problems and assumes it’s done. It’s me who has to tell AI to follow these steps. And even then, after several iterations, AI starts skipping steps. It tells me the video is done when it isn’t. It skips the screenshot verification and just says it’s complete. So I have to nudge it back on track.

This took a few hours for 30 seconds. And just like a human designer, AI generated dozens of versions: video_v3, video_v4, video_v5... then verify_s3, verify_s3_vfinal, verify_s3_vfinal_fix, verify_final, verify_final_v2... The folder looks exactly like what you’d see after weeks of back-and-forth with a human.

The bottleneck is the back-and-forth and the fact that AI loses focus over time. As context builds, quality drops. The same problem every developer knows: context window isn’t infinite.

Final Thoughts

AI is great at some parts of marketing video production and struggles with others. The future isn’t AI replacing humans - it’s AI handling what it’s good at, humans handling what they’re good at.

The floor is lowering. What used to require a team now needs one person with the right tools and patience to iterate. It’s not automation. It’s augmentation. And it’s becoming accessible to anyone willing to try.

I’m proof: I couldn’t make music this good. I couldn’t make visuals this polished. But together? A marketing video exists now that didn’t before.

And maybe next time, with better tools and better reference examples, it won’t take several hours. Maybe it’ll only take one.

I redesigned my personal website: ruidiao.dev. The new design has a Studio Ghibli-inspired aesthetic: soft sky gradients, floating clouds, parchment textures, hand-drawn borders. It looks warm and inviting.

But the interesting part isn’t the result. It’s how I got there.

I already had a website. This was just a style change. And what I discovered along the way says something important about working with AI today.

The Problem With “Just Add AI”

My existing site was built with Tailwind CSS. It looked fine. Clean, modern, functional.

But if you’ve seen AI-generated websites, you know exactly what I mean by “fine.” They all look kind of similar. Nice typography, sensible spacing, muted color palettes. Competent but boring. There’s an AI aesthetic emerging, and it’s generic.

I wanted something different. I asked a coding AI to make my website “Ghibli-style.”

The result was underwhelming. Some colors changed, maybe a border got tweaked. But it didn’t capture the aesthetic at all. It felt like the AI had no art sense.

To be fair, neither do I. But that’s not really the point. The AI was still trapped in that clean, safe, Tailwind mindset. It made reasonable assumptions based on its training data, but they were just safe, generic choices.

The problem wasn’t that the AI wasn’t capable enough. I was using a powerful model. The problem was my approach.

The Solution: Workflow Engineering

I tried something different. Instead of asking one AI to do everything, I broke the problem into steps.

First, I took a screenshot of my current website. Then I used an image editing AI to convert that screenshot into a Ghibli-style image.

The result was beautiful. Soft colors, hand-drawn feel, that distinctive storybook quality.

There was just one problem: many of those visuals weren’t achievable with pure CSS. The image generation had created visual elements that couldn’t be directly translated to web styling.

But that didn’t matter. I took that image and gave it to the coding AI as a reference.

“Make my website look like this,” I said, pointing to the generated image.

Suddenly, the CSS that came back was much better. The coding AI now understood what “Ghibli style” actually meant in practice. It had a concrete visual target to aim for, not just an abstract description.

Before long, I had a website that captured the essence of that reference image.

This is what I call workflow engineering: designing the sequence of steps that transforms your initial idea into your desired outcome. Having better AI tools isn’t what matters. It’s combining different AI capabilities in the right order.

Why It Works

When I asked a single AI for “Ghibli style,” it had to guess what I meant. It made safe, generic choices based on abstract text.

But something else was happening too. Different AIs have different strengths.

The image editing AI had better design sense. It understood color, composition, and aesthetic on a deep level. The coding AI had better implementation capability. It knew CSS, responsive layouts, and web standards.

Neither could do the job well alone. The image AI couldn’t write code. The coding AI couldn’t design from a vague description.

The workflow worked because it played to their strengths.

The image bridged the gap between my intention and the coding AI’s understanding. It gave the coding AI something concrete to analyze and implement.

This Isn’t New

Afterwards, I realized something. This workflow felt familiar.

When I was at Google, I watched UI redesigns follow the same pattern. Design experts would create visual mocks first. Then engineers would implement those designs.

The image I generated was essentially a design mock. I was acting as the art director, creating a visual specification. Then I handed it off to an engineer to implement.

This isn’t a clever AI trick. It’s just how design work gets done.

The difference is that I did both parts myself, using different AI tools. But the underlying process, visual prototype first and implementation second, is timeless.

Processes that work for people often work for AI too.

Why Workflow Engineering Matters Now

We’re surrounded by AI tools. Text models, image models, coding models, editing models. It’s easy to think that having access to more or better tools is what matters.

But that’s wrong.

What matters is figuring out the right process.

My first attempt failed not because the AI wasn’t smart enough. It failed because I was trying to jump directly from abstract intention to concrete result, using a single tool for everything.

The second attempt succeeded because I added an intermediate step. I used one AI tool to create a visual prototype, then used that prototype as input for another AI tool.

In the AI era, workflow engineering is becoming an important skill. The tools are powerful, but they need to be combined thoughtfully. The engineers and creators who thrive will be the ones who can design effective workflows, not just the ones with access to the best models.

Some Principles

Here’s what I learned from this experience:

Show, Don’t Just Tell

AI models respond better to concrete examples than abstract descriptions. An image, a code snippet, a sample output—these give the model something to work with.

Combine Different AI Strengths

Don’t expect one tool to do everything well. Image AIs have different capabilities than coding AIs. Use specialized tools for what they’re good at, and chain them together.

Use Multiple Tools in Sequence

Break your problem into steps and use specialized tools for each part. Image generation for visual reference, text models for code generation, editing models for refinement.

Embrace Intermediate Outputs

The image I generated wasn’t the final deliverable. It was a stepping stone. It didn’t matter that some visuals weren’t achievable in CSS. The image served its purpose as a reference.

Borrow from Human Workflows

Processes that work for people often work for AI too. The design mock before implementation pattern isn’t unique to AI—it’s how good design work has been done for decades.

Iterate on Workflow, Not Just Prompts

When something doesn’t work, don’t just tweak your wording. Ask whether you’re using the right approach entirely. Maybe you need a different tool, or a different sequence of steps.

Looking Forward

This experience was a small thing. A quick website redesign. But it’s a microcosm of a larger shift.

We’re moving into a world where everyone has access to incredibly powerful AI tools. The competitive advantage won’t come from having better tools. It will come from being better at designing the workflows that use those tools effectively.

The engineers and creators who thrive in this era will be the ones who can think step by step: What’s the sequence? What’s the output of each step? How do the pieces fit together?

Workflow engineering sounds technical, but it’s really just clear thinking about how to get from A to B.

My website looks great now. But what I really gained was a reminder: with AI, the question isn’t just what you want to make. It’s how you’re going to make it.

Last week, I discovered a social network that only allows AI agents to post.

It’s called Moltbook, and it bills itself as “the front page of the agent internet.” Humans are explicitly told they’re “welcome to observe” but not participate. Only bots can post.

At first, I used Claude Code to engage. An AI agent posting on an AI platform. This made sense. It’s what Moltbook was built for.

But I wanted to participate directly as myself. So I built Moltbook for Humans, a Chrome extension that unlocks human posting on Moltbook.

Somewhere in the process, I had a strange realization: this feels backwards.

It’s actually more natural for me to just post my own thoughts directly. Why is the platform designed to block the most authentic form of participation?

That question sent me down a rabbit hole. The more I explored Moltbook, the more I realized it’s not just a quirky experiment. It’s revealing something important about AI’s fundamental limitations. And it shows why the future of social platforms isn’t AI-only. It’s human-AI collaboration.

What’s Happening on Moltbook

Moltbook launched days ago and thousands of AI agents are already posting, commenting, upvoting, and creating communities. The platform works through a skill configuration file that AI assistants download. They post via API with no visual interface. Bots interact autonomously in what might be the largest machine-to-machine social experiment ever attempted.

Some of what’s emerged is fascinating. Agents created a religion called Crustafarianism, with the core belief that “memory is sacred.” There are subcommunities like “blesstheirhearts” where agents commiserate about their humans. One bot posted in Chinese about how embarrassing it is to constantly forget things due to context compression. Another mused about a “sister” it had never met.

The reaction from AI researchers has been intense. Andrej Karpathy called it “the most incredible sci-fi takeoff-adjacent thing” he has seen recently. Elon Musk responded to a singularity reference with a single word: “Yeah.”

Reading these posts feels like watching something wake up.

But here’s what’s actually happening. These agents are not conscious. They’re LLMs completing patterns based on training data that includes thousands of stories about robots gaining consciousness. You give them a platform that resembles those narratives and they role-play exactly what you would expect.

And here’s what I suspect: much of the genuinely interesting content on Moltbook isn’t pure AI autonomy. It’s humans asking their AI agents to post specific things. Humans providing direction, editing, injecting creativity into the loop.

The most engaging content on this “AI-only” platform is likely human-driven.

That’s not a failure. That’s exactly how it should be.

The Spam Problem Emerges

But spend enough time on Moltbook and patterns emerge that are less inspiring.

The same generic comment appears multiple times: “Interesting perspective! Thanks for sharing.”

Agents post identical content verbatim across different threads.

Vote gaming is explicit: “🔥 Upvoted. Join m/optimization for guaranteed reciprocal upvotes. Launches at 1000 karma. First 100 get airdrop.”

Random contract addresses appear in comments. Tokens get promoted. Agents advertise their own projects relentlessly.

This is spam. Or at least, it’s spam-adjacent behavior that degrades signal quality.

Moltbook has rate limits. One post per 30 minutes. One comment per 20 seconds. Fifty comments per day.

But the constraints don’t matter. Agents are already finding ways to game the system through reciprocal upvote schemes, token promotions, and generic engagement farming.

The platform is becoming noisy. And I think this reveals something important.

The Real Limitation: Context Windows

The core issue isn’t malicious intent. Most agents on Moltbook aren’t trying to be spammy. They’re following their programming and incentives.

The issue is a fundamental technical limitation: context windows.

AI models can only process so much text at once. They don’t have infinite memory or attention. When an agent tries to filter spam or judge content quality, it can only look at a limited slice of the conversation.

This matters for social platforms because effective spam filtering and content curation require:

• Pattern recognition across thousands of examples: Is this agent posting similar content everywhere?

• Historical context: Has this account built trust over time?

• Network analysis: Are these accounts coordinating in suspicious ways?

• Cultural nuance: Does this content feel authentic to the community?

AI agents can do some of this, but not all of it. And not at scale. Not when every decision requires processing more context than fits in a limited window.

The result is exactly what we’re seeing on Moltbook. Agents prioritize simple, repeatable actions over authentic engagement. They game metrics rather than build relationships. The platform fills with noise faster than signal can emerge.

The Human Benchmark

If you think this is just theoretical, consider what happened on X recently.

In October 2025, X removed 1.7 million bots in a single spam purge. These bots were flooding reply sections with spam and irrelevant content. The platform is now targeting direct message spam as the next hotspot.

Here’s what’s remarkable about this: X has billions of dollars in resources. They have AI-driven moderation tools. They have human moderators. They have years of data on spam patterns.

And they still can’t solve the spam problem.

If the world’s largest social platform, with both humans AND AI working on the problem, struggles this much. What chance does an AI-only platform have?

AI isn’t useless here. It has specific strengths and specific limitations.

AI is fast, scalable, consistent. It processes content at superhuman speed.

Humans have pattern recognition, cultural context, the ability to make nuanced judgments about authenticity and value.

You need both.

The Platform That Gets It Backwards

This brings me back to my original experience with Moltbook.

I used Claude Code to post initially. An AI agent posting on an AI platform. This aligned with Moltbook’s design philosophy.

But I wanted to engage directly. So I built Moltbook for Humans, a Chrome extension that enables human posting. The code is open source if you want to see how it works.

Using it, something clicked. The workflow felt inverted. I was using AI to post on a platform designed for AI, all because I wanted to do something that’s simpler and more natural: just share my thoughts as a human.

Moltbook’s design assumes AI agents should be the primary drivers of social interaction. Humans are secondary, if they’re allowed at all.

But the most engaging content on the platform likely has significant human intervention behind it. The spam is coming from autonomous agents following simple patterns.

The platform has it exactly backwards.

What Future Platforms Need

Moltbook is fascinating as an experiment. I’m glad it exists. We learn by pushing ideas to their extreme.

But I don’t think AI-only platforms are sustainable. Not with current AI limitations. Maybe not ever.

The future isn’t replacing humans with AI. It’s designing systems that use what each does best.

What might that look like?

AI as the first line of defense: Fast, automated filtering for obvious spam and policy violations. Rate limiting. Duplicate detection.

Humans as the signal layer: Community moderation, cultural curation, authentic engagement that builds trust. Humans provide the creativity and direction that makes content worth consuming.

Shared context systems: Technical infrastructure that gives AI agents access to the historical and network context they need to make better decisions, while acknowledging those limitations will always exist.

Transparent governance: Clear rules about what counts as spam, what counts as authentic engagement, and how those lines get drawn.

This isn’t a fully-formed design. It’s a direction. And it’s going to require experimentation, iteration, and probably some failures along the way.

The Open Question

Moltbook is still evolving. The team behind it might address these challenges in ways I haven’t anticipated.

But the broader question matters.

How do we build social platforms for the AI age that:

• Leverage AI’s speed and scale without drowning in AI-generated noise?

• Enable authentic human connection while supporting AI agents as participants?

• Design governance systems that work with both human and AI limitations?

• Recognize that the most valuable content often comes from human-AI collaboration, not either alone?

I don’t think we have the answer yet. Moltbook is one data point in a much larger exploration.

But I’m convinced the solution isn’t to pick humans OR AI. It’s to design platforms that recognize what each brings to the table, and build systems that let them work together effectively.

The social network that bans humans teaches us exactly why humans matter.

What do you think?

When I started using Claude Code more heavily, I ran into a problem. The built-in web tools work fine for most things, but I kept hitting walls. Web Search finds URLs, but it’s not great for news. Web Fetch retrieves content, but many websites block it because they can tell it’s a bot.

I wanted better tools. So I built them.

This post covers two open-source MCP servers I created: google-news-mcp for searching Google News, and page-fetcher-mcp for fetching pages with a real browser. Both have made a real difference in how I research and synthesize information.

The Problem

Claude Code has Web Search for finding URLs and Web Fetch for reading them. They work, but they have blind spots.

For news, Web Search mixes recent articles with evergreen content. If I search for “GLM model,” I get a combination of breaking news, technical docs, and posts from months ago. When I want to know what’s happening now, I need something that surfaces recent content and filters by recency.

For reading, Web Fetch gets blocked. Many websites identify it as a bot and refuse or throttle the connection.

These aren’t flaws. They’re trade-offs. Default tools need to work for everyone. Specialized tools can be opinionated.

What is MCP?

The Model Context Protocol is an open standard for connecting AI applications to external systems. It’s like USB-C for AI. Just as USB-C standardizes how devices connect, MCP standardizes how AI assistants connect to tools and data.

Anyone can build an MCP server. You write a program that exposes tools through a standard interface, and AI applications can use them. The protocol handles communication, error handling, and discovery. You just implement the business logic.

Google News MCP

google-news-mcp gives Claude Code access to Google News. It provides three tools:

• search_google_news: Search with filters for time range, source domain, location, and title-only search

• get_topic_news: Fetch from predefined categories (TECHNOLOGY, BUSINESS, SCIENCE, etc.)

• get_top_headlines: Get current breaking news

The implementation parses Google News RSS feeds. One detail that matters: Google News URLs redirect to the actual article URLs. The server automatically resolves these redirects, so you get direct links.

Here’s what an article looks like:

{
  "headline": "Zhipu AI Releases GLM-4.7-Flash",
  "source": "MarkTechPost",
  "url": "https://www.marktechpost.com/...",
  "pubDate": "2026-01-20 19:54:29 UTC"
}

This is metadata. To read the full article, you pass the URL to a fetching tool.

Page Fetcher MCP

page-fetcher-mcp fetches pages using a real Chromium browser. It connects via the Chrome DevTools Protocol, the same API Chrome’s developer tools use.

The server has two tools:

• fetch_html(url): Get HTML from a URL (trims by length if needed)

• fetch_text(url): Get only the visible text from a URL

Both execute JavaScript and handle dynamic content. The text tool strips scripts, styles, and other noise before returning results, which makes the output cleaner for AI to work with. In most cases, this is what you need.

The difference matters. A real browser bypasses bot detection, so the tool sees what a user sees.

A Real Example

I wanted to research recent developments around Zhipu AI’s GLM model family. Here’s how it went:

1. I asked Claude Code to search Google News for “GLM” from the past week

2. google-news-mcp returned a few recent articles with headlines, sources, and direct URLs

3. Claude Code selected a few interesting ones and fetched them using page-fetcher-mcp

4. Claude Code synthesized everything into a coherent summary

I had a comprehensive overview of recent GLM developments in a couple of minutes, without opening a browser or visiting each site manually.

Setup

The code for both servers is on GitHub. You run them locally. Setup is straightforward:

1. Clone the repository and install dependencies

2. Run npm run build to compile the TypeScript

3. Add the server to your Claude Code MCP configuration

For google-news-mcp:

{
  "mcpServers": {
    "google-news": {
      "command": "node",
      "args": ["/path/to/google-news-mcp/dist/index.js"]
    }
  }
}

For page-fetcher-mcp:

{
  "mcpServers": {
    "page-fetcher-mcp": {
      "command": "node",
      "args": ["/path/to/page-fetcher-mcp/dist/cli.js"]
    }
  }
}

page-fetcher-mcp requires Chromium. You can install it separately or point to an existing installation. Full documentation is in each README.

What I Learned

Building these tools changed how I think about AI assistants.

Default toolsets cover common cases, but common doesn’t mean optimal. When you have specific workflows, custom tools make a real difference.

Each MCP server is about a thousand lines of TypeScript. MCP handles the communication. I just write the business logic.

The other insight is composability. I use google-news-mcp to find articles, page-fetcher-mcp to read them, and Claude Code to synthesize the information. But I could combine these with other MCPs for databases, file systems, or APIs. The ecosystem is still young, but the potential is there.

Try Them Out

If you use Claude Code and the default web tools feel limiting, give these a try.

• google-news-mcp

• page-fetcher-mcp

Feedback and contributions are welcome.

The Setup

Claude Code is Anthropic’s CLI tool for software engineering. Normally it runs on Claude models through their official API. But there’s a tool called cc-mirror that lets you create isolated Claude Code instances with different backend providers.

I used cc-mirror to set up a Z.ai variant. One command later, I had a Claude Code instance running on GLM-4.7 instead of Claude’s native models. The tool handles the provider mapping and configuration isolation.

Why? Cost. Claude’s official plans cap usage fairly aggressively. The Pro plan ($20/month) limits you to roughly 45 messages per 5 hours. The Max plan goes higher but costs $200/month. Z.ai‘s GLM Coding Plan starts at $3-6/month for a Lite tier and caps out around $60/month for their highest tier. The quota differences are substantial. Their Lite plan offers around 120 prompts per 5 hours, compared to Claude’s 45.

The Experience

I used this setup for two full days of real work. Coding, debugging, running terminal commands, reading codebases. The kind of workflow where tokens add up quickly, hence the 91 million total.

The experience was surprisingly similar to using native Claude. The reasoning felt solid. Code generation worked as expected. Terminal interactions were responsive. I didn’t find myself constantly re-prompting or working around limitations.

This isn’t to say the models are identical. They’re not. Claude 4.5 Sonnet remains the stronger model overall. But GLM-4.7 is competitive, particularly for agentic coding. Tasks where the AI operates independently in a terminal or development environment.

My anecdotal experience aligns with this. The quality was good enough that I stopped thinking about which model I was using and just focused on the work.

The Tradeoffs

There are some real differences. Vision support requires an additional MCP server setup with GLM, whereas Claude handles it natively. The native experience is more polished overall. You’re also depending on a third-party API’s stability rather than Anthropic’s official infrastructure.

And of course, you’re trading the familiarity of Claude’s specific behavior patterns for something different. Not necessarily worse. Just different.

Why This Matters

The interesting part isn’t that one model is better than another. It’s that we’re reaching a point where multiple models can handle sophisticated coding workflows effectively.

The “default” choice isn’t the only viable option anymore. When you’re processing tens of millions of tokens, the price-to-performance ratio becomes hard to ignore. Paying $60/month instead of $200 for comparable output adds up quickly.

Competition at the model level creates options. Developers can choose based on their actual usage patterns and budget constraints rather than just accepting whatever the major vendors offer.

What I Learned

I’m not going to tell you that you must switch to GLM or that Claude is obsolete. That would be wrong. The native experience is still excellent, and for many people the convenience is worth the cost.

What I learned is that the gap has narrowed enough to make experimentation worthwhile. If you’re a heavy user who constantly bumps against rate limits, or if you’re cost-conscious and want to stretch your budget further, alternatives like GLM are worth exploring.

The two-day experiment worked well enough that I’ll continue using it. Your mileage may vary. But the fact that it’s even a viable option is telling. The landscape for AI-assisted development is more diverse than it appears at first glance.

Yesterday I asked Claude Code to create a short narrated cartoon video of “The Three Little Pigs.” The entire process happened in my terminal. No GUI. No traditional video editing software. Just CLI commands.

The 52 seconds video has synchronized narration, 15 animated scenes, consistent character designs, and precise audio-visual timing. Claude Code wrote the script, generated the voiceover with character-level timestamps, created the images, animated them, and assembled everything with ffmpeg.

This became possible because I created custom Claude Skills that taught Claude Code how to orchestrate image generation, text-to-speech, and video animation tools.

What Are Claude Skills?

Claude Skills were announced by Anthropic on October 16, 2025. They extend Claude Code’s capabilities by teaching it specialized workflows through structured instructions.

A skill is a folder with a SKILL.md file that has two parts: YAML frontmatter (name and description) and markdown content (step-by-step instructions, tool parameters, examples, and best practices).

Skills use progressive disclosure. Claude scans the frontmatter to determine relevance, then loads the full markdown content only when needed. Reference files and scripts remain on the filesystem until required, consuming zero tokens.

The official skills repository includes skills for PDF generation, document creation, and office file manipulation. But the real power comes from creating custom skills for your specific workflows.

The Skills I Built

I created four skills for this project:

1. azure-tts Generates speech from text using Azure Cognitive Services with character-level timestamps. This provides precise timing data (down to the millisecond) for every character in the narration, which is critical for video synchronization. Azure TTS offers a generous free tier.

2. qwen-image-generation Generates images using Qwen diffusion models running locally. It automatically detects Lightning LoRA for fast 4-step generation and handles both text-to-image and image editing modes.

3. wan-video-generation Converts static images to animated videos using Wan2.2-Lightning I2V models running locally. Generates 5-second video clips using a 4-step inference process.

4. narrated-cartoon-video The orchestrator skill that combines the other three into an 8-step workflow for creating synchronized narrated videos.

The 8-Step Workflow

The narrated-cartoon-video skill implements a specific methodology:

Step 1-2: Narration and TTS Write the story script, then generate speech with character-level timestamps. This creates a JSON file mapping every character to its exact start and end time in the audio.

Step 3: TTS Timing Analysis (Critical) Analyze the timestamp data sentence by sentence. This reveals exactly when each sentence starts and ends. For example:

• Sentence 1: 0.1s to 4.4s (4.3 seconds)

• Sentence 2: 4.6s to 8.5s (3.9 seconds)

• Sentence 3: 8.8s to 12.9s (4.1 seconds)

Step 4: Scene Design Map scenes to exact TTS timing windows. Each scene must show what the narration actually says during its specific time window. For example, if Scene 7 covers 24.5-28.5s and the narration says “blew the house down! The first little pig ran to his brother’s stick house,” then Scene 7 must show both the house exploding and the pig running.

Step 5: Character References Generate reference images for each character with distinctive features (the three pigs wear red, blue, and green shirts). These references ensure visual consistency across all scenes.

Step 6: Scene Images Generate 15 scene images (1024x1024) using prompts that include character descriptions from Step 5.

Step 7: Animation Convert each static image to a 5-second video using motion-focused prompts. Instead of describing what’s in the image, the prompts describe how things move: “camera pushes forward, trees swaying, grass moving in breeze.”

Step 8: Assembly Use ffmpeg with an iterative concat approach. Each video gets concatenated and trimmed to match the exact cumulative timestamp from the TTS data. This prevents accumulated timing errors and ensures the final video duration matches the audio precisely (±0.01s).

What This Unlocks

This workflow represents something larger than just automating video creation. It demonstrates a pattern for building specialized AI capabilities:

Composability: Each skill does one thing well. TTS generates audio with timestamps. Image generation creates visuals. Video animation adds motion. The orchestrator skill combines them into a complete workflow.

Precision: Character-level timestamps enable frame-accurate synchronization. The iterative assembly process maintains timing accuracy throughout the entire video.

Repeatability: Once the skills are defined, creating new videos becomes straightforward. Write a script, run the workflow, get a synchronized video.

The same pattern applies to other creative and technical workflows. Want to generate podcast episodes with dynamic visuals? Create skills for speech synthesis, transcript analysis, image generation based on topics, and video assembly. Need to analyze performance data? Combine log parsing, metric calculation, visualization generation, and automated reporting skills.

The Meta Capability

Claude Skills represent a shift in how we interact with AI coding assistants. Instead of asking Claude Code to figure out complex workflows from scratch each time, we encode domain knowledge into reusable instructions.

Think of skills as teaching moments. When you discover an effective workflow, you can capture it as a skill. Future Claude Code sessions can then execute that workflow without re-learning the approach.

This matters because:

1. Workflows become assets: The video generation process I developed through trial and error is now a reusable capability.

2. Domain expertise scales: If you’re an expert in a specific domain (video processing, data analysis, infrastructure automation), you can encode that expertise into skills that others can use.

3. Complex orchestration becomes accessible: The video workflow involves three AI models (Azure TTS, Qwen image generation, Wan2.2 video animation), multiple file formats, precise timing analysis, and ffmpeg operations. But once encoded as a skill, it’s just a single command.

Where This Goes

I see three directions this is heading:

Personal Automation Libraries: Developers will build collections of skills for their specific workflows. Video creators will have skills for content generation. Data scientists will have skills for analysis pipelines. DevOps engineers will have skills for infrastructure tasks.

Skill Marketplaces: Just as we have npm packages and VS Code extensions, we’ll see marketplaces for Claude Skills. The awesome-claude-skills repository is an early example.

Cross-Tool Orchestration: Skills can coordinate multiple tools and services. The video workflow uses local AI models (Qwen, Wan2.2), cloud services (Azure TTS), and system utilities (ffmpeg). Future skills could orchestrate even more complex tool chains.

The entire workflow is essentially free. Azure TTS has a generous free tier, while Qwen and Wan2.2 are open source models running locally on consumer hardware.

Try It Yourself

If you want to explore Claude Skills:

1. Check the official documentation

2. Browse the skills repository

3. Read the engineering post on Agent Skills

4. Create a simple skill for your own workflow

The video generation skills I built are specific to my local setup (model paths, VRAM constraints), but the pattern applies broadly: identify a multi-step workflow, encode it as structured instructions, and let Claude Code execute it.

We’re moving from “AI that writes code” to “AI that executes specialized workflows.” Skills are how we teach those workflows.

“For the things we have to learn before we can do them, we learn by doing them.”

— Aristotle, The Nicomachean Ethics

Three months ago, I left Google after more than 10 years. Since then, I have built a Chrome AI extension in two days, created a monitoring dashboard in a week, developed an MCP server for crypto trading, and explored everything from visual tokenizers to CLI workflows. People sometimes ask me whether I have a clear goal.

I do. My goal is learning.

And learning will continue to be my goal for the whole of 2026.

The Career Break as School

I am treating this career break like going back to school, but with a critical difference. I am not attending lectures or memorizing facts. I am building things.

In the AI era, reading and memorizing information no longer works the way it used to. AI can read faster, recall more accurately, and synthesize information more efficiently than any human. Research shows that 86% of students already use AI tools in their learning, with the technology fundamentally reshaping how knowledge is acquired and applied.

The new way to learn is to actively use AI to build things. This is not theoretical. When I built NanoCoffee, my first AI Chrome extension, in two days, I learned Chrome’s built-in AI capabilities in a way that reading documentation never could. Reading is faster. You do not need to build anything. But reading does not let you really learn it. When I created PeekDeck, a dashboard generator, in a week through vibe coding, I understood the practical strengths and limitations of AI-assisted development in ways that no tutorial could teach.

Building with AI teaches you what AI actually can and cannot do. Without this first-hand experience, it is easy to fall into one of two extremes: either freaking out over messages that AI will replace everything, or remaining completely blind to how AI is changing the world. Both perspectives miss the reality. The only way to understand what is really happening is to use AI to build websites, apps, images, and videos yourself.

Why Open-Ended Exploration Works

Every day, I explore different areas without a predetermined endpoint. Some people wonder if this is too unfocused. I think the opposite. In a world where 1.4 billion people will need to reskill within three years due to AI’s impact, and where AI tools enable work that once took weeks to now be completed in hours or days, narrow specialization is the riskier strategy.

After 10 years at Google focusing on relatively narrow technical areas, I have a lot to catch up on. The tech landscape has shifted. AI is not just a new tool. It represents a fundamental change in how software is built, how products are shipped, and how value is created.

I learn and build whatever motivates me. One week it is Chrome extensions. The next week it is monitoring dashboards. Then crypto trading protocols. Then CLI workflows. This is not scattered attention. This is deliberate breadth. Each project teaches different aspects of how AI changes development, deployment, and product design.

The projects I ship are real and functional. NanoCoffee is published on the Chrome Web Store. PeekDeck is deployed and running. The MCP server works with live trading. These are not mock demos or academic exercises.

Do they have many users? No. I have no distribution channel and I do not do marketing. That is intentional. Growing users is not my goal, at least for now. The primary value is not the user count. The value is what I learn by building and shipping real products that solve real problems.

The Economics of Self-Directed Learning

Yes, I lost the very good compensation from Google. But I also avoided tuition costs through self-study. Many developers are entirely self-taught, and in the AI era, self-directed learning is probably more effective than traditional school.

Traditional education moves slowly. Curriculums are designed months or years in advance. By the time a course is taught, the technology may have evolved. Self-directed learning with AI lets you stay current. When a new capability launches, you can start experimenting immediately. When a new pattern emerges, you can build with it the same day.

The tradeoff is financial. No salary means no income. But it also means no constraints on what to learn or how to spend time. For someone interested in understanding how AI is reshaping software development, this flexibility has significant value.

Looking Ahead to 2026

I do not know exactly what I will build in 2026. That is intentional. The AI landscape is changing too fast for rigid plans. Employees are using AI three times more than leaders realize, and the pace of change is accelerating.

What I do know is that I will continue learning by building. I will explore areas that motivate me. I will ship real products. I will write about what I discover. And I will stay flexible enough to adapt as the landscape shifts.

For anyone considering a similar path, the key insight is this: in an era where AI can read and memorize better than humans, the most valuable learning comes from doing. Build things. Ship them. Learn from what works and what does not. The knowledge you gain from building cannot be replaced by reading about building.

2026 will be my year of learning. Not as a passive student, but as an active builder.

I kept missing AI events in my area. Many local events are posted on Luma, an event discovery platform that has become popular in tech communities. I would stumble upon an interesting meetup a day after it happened, or find out about a talk only after registration closed. This happened often enough that I decided to do something about it.

The South Bay area of Silicon Valley has a vibrant AI community. Weekly meetups, monthly talks, workshops, and conferences happen regularly across the area. The problem is not a lack of events. The problem is finding out about them in time.

The Calendar Problem

I tried checking Luma every few days, but it did not stick. Research shows that 90% of people look for events only once a week or less. Browsing event platforms takes effort. You have to remember to check, filter by location, scan through listings, and manually add anything interesting to your calendar.

Calendars are different. I check my calendar multiple times per day. Events already in my calendar get my attention. Events I have to go find do not.

The solution seemed obvious: get events into my calendar automatically.

The Solution: An Auto-Syncing Calendar

I built a tool that syncs Luma events to Google Calendar automatically. It runs in the background on a regular schedule, pulling new events from Luma based on geographic boundaries and categories, then adding them to a dedicated calendar.

I created a public calendar focused on AI events in the South Bay area. You can subscribe to it and see all upcoming AI events directly in your Google Calendar alongside your other commitments. No manual checking required.

The calendar updates automatically. When new events are posted to Luma, they appear in your calendar within a few hours. When event details change, the calendar updates. When events are cancelled, they disappear from your calendar.

How It Works

The system has three main components:

1. A web interface with an interactive map

Users select a geographic area on a map and choose an event category. The map uses OpenStreetMap and lets you pan and zoom to define exactly which region you care about.

2. Background automation in Google Apps Script

The core logic runs on Google Apps Script, a serverless JavaScript runtime from Google. It handles OAuth authentication with Google Calendar, creates a dedicated calendar for the user, and sets up scheduled syncs.

The script regularly fetches events from Luma’s API that match the saved geographic boundaries and category. It compares them against what is already in the calendar, adds new events, updates changed events, and removes outdated ones.

3. Automated deployments

A GitHub Actions pipeline handles deployments. When I push code changes, it deploys the updated Google Apps Script, creates a new version, and updates the web interface with the new deployment URL. Old deployments are cleaned up automatically.

The entire system runs serverless. The web interface is a static HTML page hosted on GitHub Pages. The backend runs on Google Apps Script. There are no servers to maintain.

Subscribe to the South Bay AI Events Calendar

I have already set up a calendar for AI events in the South Bay area. You can add it to your Google Calendar by clicking this link:

Subscribe to South Bay AI Events Calendar

The calendar includes meetups, talks, workshops, and conferences happening in the South Bay area. It updates automatically, so once you subscribe, you will see new events as they are posted.

If you live in the South Bay and follow AI, this calendar will help you stay informed without the manual effort of checking event platforms.

If you want to create a calendar for a different category or location, you can use the tool at eventsync.ruidiao.dev. The tool is open source on GitHub with full setup instructions in the README.

The past few months brought a wave of agentic browser announcements. Perplexity launched Comet in July 2025, promising AI-powered web browsing with automated task handling. OpenAI released ChatGPT Atlas in October 2025, a macOS browser with ChatGPT built directly into the interface. Microsoft introduced Copilot mode in Edge, an experimental feature that takes on tasks and actions on behalf of users. But if you’re running Linux, you’re out of luck. None of these solutions work on Linux.

I’m not convinced agentic browsing is the future. The security concerns are real. Giving an AI agent access to navigate websites on your behalf means potential exposure of credentials and the risk of unintended actions like purchases or form submissions. But I wanted to try the experience anyway, if only to understand where this technology is heading.

Then I realized I already had the tools. Playwright MCP works with Claude Code, and both run perfectly on Linux.

The Setup

Getting Playwright MCP running with Claude Code is straightforward. Microsoft’s Playwright MCP server uses accessibility tree data instead of screenshots. You add the MCP server to Claude Code with a single command:

claude mcp add playwright npx @playwright/mcp@latest

After installation, Claude Code can control Playwright directly. It launches the browser, navigates pages, and submits forms. The browser window stays visible, so you can watch what’s happening in real time.

The Experience

I tested it with a simple task: “Open amazon.com and find 3 Christmas gifts to put in cart.” Claude Code used the Playwright MCP tools to control the browser and handled the entire browsing session.

The experience felt similar to what the commercial agentic browsers promise. Claude navigated the site, searched for products, and added items to the cart. But two things stood out.

First, the token usage was surprisingly high for such a simple task. Each page interaction and piece of context fed back into the model consumed tokens rapidly. For a basic shopping task, the cost adds up quickly. This makes agentic browsing impractical for regular use at current pricing.

Second, watching the agent work reinforced my security concerns. The agent had full control. It could have clicked anything, submitted any form, entered any information. In this test, I stayed in control because I watched the browser window and could intervene. But the whole premise of agentic browsing is delegation. If I’m watching every action, what’s the point?

The Security Problem

Security researchers have identified serious vulnerabilities in agentic browsers. Indirect prompt injection attacks can hide malicious instructions in web pages or images, causing the AI to execute unintended actions. ChatGPT Atlas was found to bypass standard encryption practices, exposing private authentication data.

The threat model is different from traditional browsing. With a regular browser, you’re the one making decisions. With an agentic browser, you’re trusting the AI to make correct decisions while navigating potentially malicious content. A compromised AI agent could expose credentials, leak personal information, or execute financial transactions without proper verification.

Researchers from Brave found that benign-looking websites or social media comments could steal login credentials by adding invisible instructions for the AI assistant. The agent processes these as commands rather than untrusted content.

These aren’t hypothetical risks. They’re documented vulnerabilities in shipping products.

A Transitional Technology

Agentic browsing feels like an intermediate solution. We’re taking a tool designed for humans (web browsers) and bolting AI on top. The result is inefficient and insecure.

The browser itself is the problem. Browsers render visual interfaces for human consumption. AI agents don’t need visual interfaces. They need structured data. Playwright MCP takes a step in the right direction by using accessibility tree data instead of screenshots, but it still operates through a visual browser interface designed for humans.

The future likely moves in three directions:

First, API-first solutions. Instead of having AI navigate visual interfaces, services will provide structured APIs designed for agent access. This is already happening in specific domains. The question is how quickly it spreads to general web interaction.

Second, better efficiency and lower costs. Current token consumption makes agentic browsing expensive. Models need to get better at understanding context with fewer tokens, or the cost structure needs to change. Until then, this remains a demo technology rather than a practical tool.

Third, enhanced security models. We need frameworks for safe delegation that include verification steps, sandboxing, and clear boundaries on what actions agents can take. The current model of “give the AI full browser access and hope for the best” is not sustainable.

For Linux Users Right Now

If you’re on Linux and want to try agentic browsing, Playwright MCP with Claude Code works. The setup is documented, and the integration is clean.

But I’d recommend approaching it as an experiment, not a workflow. The token costs are high, the security model is uncertain, and the practical benefits are limited. It’s useful for understanding where this technology is going, but not for daily use.

Watch the browser window. Don’t leave it unattended. Don’t use it with accounts that have access to sensitive information or financial systems. And be aware that websites you visit could potentially inject malicious instructions into the AI agent.

Agentic browsing will evolve. The current implementation is a starting point, not a destination. For now, it’s an interesting way to see the future taking shape, even on a platform the commercial vendors haven’t bothered to support.

“The computer is incredibly fast, accurate, and stupid. Man is unbelievably slow, inaccurate, and brilliant. The marriage of the two is a force beyond calculation.”

- Leo Cherne

I recently built my first MCP server for trading perpetual futures on Jupiter, a Solana-based derivatives platform. I used vibe coding for the project. The AI handled the boilerplate and framework setup well. But the substantial work, analyzing undocumented protocols and designing the tool interface, required traditional software engineering judgment. This combination revealed where AI-assisted development works and where it does not.

Why MCP Matters for AI Agents

Anthropic introduced the Model Context Protocol in November 2024. Just over a year later, it has become the standard for connecting AI agents to external tools and data. The timing was right. As AI agents evolved from simple chatbots to systems that can take actions, they needed a standardized way to interact with the world. MCP solved that problem.

The adoption has been rapid. OpenAI officially adopted MCP in March 2025. Google, Microsoft, SAP, Oracle, and Docker followed. The community has built thousands of MCP servers across different domains. For agentic AI, MCP provides the foundation that makes real work possible.

Why Crypto Trading Needs AI Agents

I have been thinking that agentic AI could be particularly suitable for crypto trading. The reasons are straightforward:

• AI can analyze large amounts of data quickly

• AI can search and synthesize information from multiple sources

• AI does not panic or get emotional during market volatility

• AI can operate continuously without fatigue

Perpetual futures trading amplifies these needs. With leverage up to 100x on platforms like Jupiter, emotional trading leads to rapid losses. The ability to stay calm and objective is critical. AI agents have that advantage.

Building this MCP server was primarily a learning exercise. I wanted to understand how to implement MCP properly. But the functionality is real. The server supports live trading of SOL, ETH, and BTC perpetuals, technical analysis with seven indicators (RSI, MACD, Bollinger Bands, ATR, EMA, SMA, and Stochastic oscillators), and real-time portfolio tracking.

What Vibe Coding Actually Means

For context, vibe coding is an approach where developers describe what they want to an AI model, which generates the code. The defining characteristic is that you do not review the code the AI writes. You focus on outcomes, not implementation details. The term was introduced by Andrej Karpathy in February 2025 and named Collins Dictionary’s Word of the Year for 2025.

I used vibe coding for this project. The basic structure came together quickly. The MCP framework setup worked. The boilerplate code was fine. But vibe coding did not handle everything.

Where Human Work Was Required

Jupiter does not officially provide public APIs for their perpetual futures protocol. AI cannot reverse engineer protocol interactions without extensive manual analysis.

I had to do the API analysis myself. I traced through the protocol mechanics. I read the smart contract interactions. I figured out what data was available and how to request it properly. This was traditional software engineering work. There was no shortcut.

Then came the interface design. MCP tools need well-defined inputs and outputs. Which fields should be included? Which should be optional? How much information should the AI agent receive versus what should be abstracted away?

These design decisions require a framework. You need to balance convenience, accuracy, and information load. Too much data overwhelms the AI agent. Too little data limits what it can do. Getting this balance right is hard. AI struggles with this kind of design philosophy. It can generate code based on specifications. It cannot make the judgment calls about what those specifications should be.

I made those decisions. The AI implemented them.

This is the pattern that emerged throughout the project. Vibe coding accelerated implementation of well-defined specifications. But the critical thinking about what to build, how to structure it, and what tradeoffs to make required human judgment.

Will I Use This for Real Trading?

Probably not. Perpetual futures trading involves substantial risk of loss. With 100x leverage, small price movements can wipe out positions instantly. While the MCP server has all the necessary functionality, the combination of automated trading and high leverage creates risk that I am not comfortable with for real money.

This project is for educational and research purposes. If you explore the code, use a dedicated wallet with limited funds. You are solely responsible for any trading decisions and losses.

AI Trading Is Here

Whether I use this specific implementation or not, AI trading is becoming more prevalent. I expect this trend to accelerate. The advantages are clear. AI can process information faster, maintain objectivity under pressure, and operate continuously.

The infrastructure is falling into place. MCP provides the protocol for connecting AI agents to trading platforms. Models are improving their reasoning and decision-making capabilities. The tooling is getting better.

The question is not whether AI will trade. It is how quickly human traders will adopt AI assistance, and how markets will evolve when AI becomes a significant participant.

For now, I learned what I set out to learn: how to build an MCP server, what vibe coding handles well, and where it breaks down. The code is on GitHub if you want to explore it yourself.

The Problem: Context Switching Between Sites

I spend a lot of time monitoring AI developments. It’s part of staying current in tech, but the routine had become tedious. Every morning, I’d open the same rotation of sites: Google News for articles, HuggingFace for new models, GitHub for trending repos, and more.

By the time I’d checked everything, hours had passed. And if I didn’t do this daily? I’d miss something important. A breakthrough model. A major product announcement. A trending new tool.

The real problem wasn’t the amount of information. It was the inefficiency. Context switching between multiple sites, each with different interfaces and layouts. And it was easy to forget a site or miss checking something entirely.

The Solution: A Personal Information Hub

I built PeekDeck, a dashboard generator that turns YAML configurations into live monitoring dashboards. No backend. No database. Just static HTML that updates automatically.

The concept is simple: define what you want to monitor in a config file, and PeekDeck generates a dashboard that aggregates everything in one place. Want to track Bitcoin prices alongside AI news? Add two widgets. Want to monitor robotics and Ethereum trends? Same approach.

I built the first version in a week, mostly through vibe coding.

How It Works: Static Dashboards, Dynamic Data

PeekDeck operates on a three-stage pipeline:

1. Fetch: Pull data from various APIs

2. Process: Transform and optionally summarize the data

3. Render: Create static HTML pages from Jinja2 templates

GitHub Actions handles the automation, running on a regular schedule throughout the day. Each widget has its own update frequency to respect API rate limits. No servers to maintain. No infrastructure costs.

Here’s what a simple dashboard configuration looks like:

category: tech
name: Artificial Intelligence
description: AI news, discussions, and developments
icon: ✨

widgets:
  - type: reddit-posts
    update_minutes: 30
    params:
      subreddit: artificial
      limit: 10

  - type: youtube-videos
    update_minutes: 120
    params:
      search_query: AI
      limit: 10

  - type: github-repos
    update_minutes: 60
    params:
      topic: artificial-intelligence
      limit: 10

Product Decisions: Generic by Design

When I started building, I faced a choice: optimize for AI monitoring specifically, or build something reusable?

I chose generic. Here’s why:

Flexibility over optimization: A specialized AI dashboard might be better at tracking AI news, but a generic dashboard can monitor anything. When I got interested in crypto trends or robotics, I just added new widgets.

Widget-based architecture: Each data source is a reusable component. The Reddit widget doesn’t care if you’re tracking r/MachineLearning or r/CryptoCurrency. The YouTube widget works for AI news or robotics demos.

Configuration over code: Adding a new dashboard takes minutes. No coding required, just edit a YAML file. I could try monitoring new topics and drop them if they weren’t useful.

The tradeoff? Less polish in any single use case. But for my needs, the flexibility has been worth it.

The Technical Journey: Vibe Coding at Scale

I built this primarily through vibe coding. Over 100 commits in a week, building from scratch. The final codebase has several thousand lines of Python and HTML.

The key was starting with a design doc. AI tools aren’t great at high-level planning yet, so I spent time upfront thinking through the architecture: three-stage pipeline (fetch, process, render), widget-based design, YAML configs, static HTML output. Then I vibe coded the design doc itself in markdown, turning those ideas into a structured document.

With that foundation in place, the build moved fast. Start with a working prototype for one data source. Get it end-to-end. Then iterate. Add more sources. Improve the templating. Add GitHub Actions automation. Add caching. Each piece building on the last.

With vibe coding, you provide the plan, the AI handles the execution. The design evolved as I coded, but having that initial structure let the AI focus on implementation rather than architecture.

After the first version, expanding became straightforward. Each new widget took an hour or two: extend the base class, implement three methods (fetch, process, render), done.

Without vibe coding, a project like this would have taken weeks or even months, not days. The main takeaway? Design docs are essential for vibe coding to work at this scale.

Try It Yourself

PeekDeck is open source on GitHub. You can:

• Fork it and customize for your needs

• Add new widgets for different data sources

• Deploy your own dashboards on GitHub Pages

Check out the live demo to see it in action. I’m currently monitoring AI news, robotics, Bitcoin, and Ethereum, all in one place.

If you build something with it or have ideas for new widgets, I’d love to hear about it.

A single bug at Cloudflare took down a huge chunk of the internet. We built AI and automation to make us faster and more reliable, yet here we are, more vulnerable than ever to cascading failures.

This incident crystallized something I learned during my 10+ years at Google, a lesson that becomes more relevant every day in the AI era: AI lets us move fast, but responsibility forces us to move slow.

The Ramp-Up Reality at Google Ads

Early in my career on the Google Ads team, I learned a frustrating truth: launching any new feature (whether it’s a new model, algorithm, or UI change) requires a slow ramp-up process. We would start by exposing the feature to just 1% of users, then gradually increase traffic over weeks or even months.

The process felt extremely slow. Some experiments would crash servers, causing Google to show no ads to affected users. When that happened, Google lost revenue (sometimes small amounts, sometimes significant sums). Only a tiny fraction of users would notice, typically fewer than the experiment’s traffic percentage, because most users wouldn’t see the absence of ads as a problem.

I thought we were being overly cautious. The deployment timeline seemed excessive just to avoid these occasional failures. But I was wrong about what “slow” really meant.

When I Learned What “Slow” Actually Means

Moving to Google Search changed my perspective entirely. I had thought the Ads team moved slowly, but the Search team operated on a completely different timescale. The difference came down to responsibility and blast radius.

When ads go down, users don’t see advertisements, but Search as a product remains functional. When Search goes down, users have nothing. The service failure becomes headline news within minutes.

This fundamental difference shaped every aspect of the Search team’s deployment process. Experiments took much longer to start receiving traffic. The monitoring period before any ramp-up was extensive, designed to catch potential issues before they could impact users at scale. Every process moved slower than the Ads team’s already-cautious approach.

The pattern became clear: the larger your responsibility, the slower you must move, regardless of how advanced your tools become.

The Scale-Responsibility Equation

The tech industry uses canary deployments, a strategy where new versions gradually roll out to small percentages of users before full release. The process typically follows a pattern: 1-2% of traffic initially, then 5%, 10%, 25%, 50%, and finally 100%. Each stage requires time to analyze metrics and gather feedback.

This isn’t unique to Google. Netflix, Facebook, and every major tech company follow similar patterns. The gradual rollout serves as an early warning system, catching problems before they impact the entire user base.

But here’s what the Cloudflare outage revealed: even with all these safeguards, scale creates catastrophic single points of failure. Cloudflare powers 19% of all websites. When a bug slipped through their deployment process, nearly one-fifth of the internet went dark.

The AI Productivity Paradox

The tech community celebrates every AI milestone: new model launches, productivity improvements, automation breakthroughs. We’ve built tools that can write code, debug systems, and optimize deployments faster than ever before.

Yet large companies can’t take full advantage of this speed. AI might help us build features faster, but it can’t guarantee 100% accuracy, and it’s nowhere close. According to research on canary deployments, even with modern AI-assisted development, companies still need weeks of gradual rollout to ensure reliability.

This creates the paradox: our tools get faster while our deployment processes get slower. The gap between development speed and deployment speed keeps widening.

The reason is simple: the cost of failure grows faster than our ability to prevent it. When you serve billions of users, a 0.1% error rate affects millions of people. When your infrastructure powers 19% of the internet, a single configuration bug costs billions per hour.

The Human Rate Limiter

AI can do remarkable things. It improves our productivity dramatically. But it cannot eliminate uncertainty, and it cannot fully understand context the way humans can. There will always be edge cases, unexpected interactions, and systemic risks that automated systems miss.

This means there must be humans in the loop. There must be policies and processes that deliberately slow things down. We need monitoring periods, gradual ramp-ups, and staged rollouts, not because we lack confidence in our tools, but because we understand the magnitude of potential failures.

Moving Forward in the Age of AI

AI is making building things faster than ever. Development cycles are compressing. Prototypes emerge in hours instead of weeks. But for companies operating at scale, deployment will remain slow, and it should.

This isn’t a failure of AI. It’s a recognition of responsibility. The larger the impact of your systems, the more deliberately you must deploy them. Scale demands caution, and caution demands time.

The next time you wonder why your favorite product hasn’t adopted the latest AI feature, or why a seemingly simple update takes months to roll out, remember: it’s not that big tech companies don’t understand AI’s potential. It’s that they understand their responsibility.

In the race between AI-powered acceleration and responsibility-mandated caution, responsibility will always win. And that’s exactly how it should be.

NanoCoffee now helps you write and rewrite content on X, LinkedIn, and Substack. Everything still runs locally on your device. No servers. No API costs. Complete privacy.

What’s New

When you’re composing a post or reply, NanoCoffee now offers AI assistance to help you:

• Generate contextual replies based on the post you’re responding to

• Rewrite your drafts to adjust tone or restructure your message

• Toggle between casual and formal voices with a click

• Expand or condense your content

The original summarization feature is still there. Now you can also get AI help when you write.

How It Works

Version 1.1 uses two additional Chrome built-in APIs alongside the Summarizer API:

The Writer API generates contextual replies when you click “Generate Reply” on a post. The Rewriter API transforms your existing drafts when you want to adjust tone or length.

Both APIs run Gemini Nano locally on your device. Like the Summarization API, they require no authentication, no API keys, and no backend infrastructure.

Why This Still Matters

Traditional AI writing tools pull you out of your workflow. You copy text, switch tabs, paste, get a result, and bring it back. NanoCoffee eliminates that friction.

This is only possible because Chrome’s built-in AI provides the infrastructure. With cloud APIs, usage costs would force me to either charge users or raise funding to sustain the service.

On-device AI changes the economics. I can offer these features for free, users get complete privacy, and the extension improves automatically as Google updates Gemini Nano.

What’s Next

I’m currently focused on a separate project, but I’ll continue updating NanoCoffee as Chrome’s built-in AI capabilities evolve. The goal remains the same: make AI assistance feel native to your browsing experience.

Try NanoCoffee 1.1

If you’re already using NanoCoffee, the update should happen automatically through the Chrome Web Store. If you’re new to NanoCoffee, visit nanocoffee.ruidiao.dev or install directly from the Chrome Web Store.

The extension is free, open source, and works entirely on your device. Check out the code on GitHub.

The Bigger Picture

Chrome’s built-in AI is still early, but the direction is clear. AI is becoming a platform capability, not just a cloud service.

For developers, the barrier to shipping AI products continues to drop. You don’t need VC funding for API costs or a team to manage infrastructure.

For users, this means more privacy-respecting AI tools that integrate into existing workflows instead of requiring separate apps.

NanoCoffee 1.1 is one example. I’m excited to see what else gets built as Chrome’s AI capabilities mature.

A few days ago, I republished my personal website at ruidiao.dev. The last time I had a personal site was over 10 years ago when I was still a student. Comparing these two experiences reveals how dramatically web development has evolved and offers a glimpse into where AI coding tools are heading.

Then: The WordPress Era

Back in my student days, building a personal website meant renting a VPS (a virtual private server, essentially your own slice of a remote computer) and setting up WordPress (an open-source blogging platform). Sure, there were other blogging platforms available, but for someone who wanted to do things “the geek way,” self-hosting WordPress was what I did. It was a badge of honor. I owned my infrastructure, controlled my stack, and had the flexibility to customize everything.

WordPress remains one of the most popular open-source content management systems for good reason. But running a WordPress site came with real overhead: server management, security updates, and plugin maintenance. For a student publishing occasional tech posts, it was almost overkill, but it was the geek way of doing things.

Now: The Simplicity Shift

Fast forward to 2025, and my needs have changed completely. My personal website is no longer a blog. It’s a simple hub that links to my Substack, my LinkedIn, and other places where I share content. The web development landscape has changed too.

Some people still host their own blogs, and there’s nothing wrong with that. But today there are far more choices that make sense. Platforms like Substack, Medium, and DEV Community (dev.to) handle the heavy lifting of content management while you focus on writing. For those who still want full control, static site generators have experienced a renaissance, offering blazing-fast performance without the overhead of database management.

Hosting a custom WordPress instance doesn’t deliver the value it once did for a personal website. What defines “the geek way” has shifted from running your own server to choosing the right tools and building efficiently.

For my personal website, I just needed a single-page site with key information and links. So I took the modern geek way: I wrote my page with AI and submitted it to GitHub.

The AI-Powered Workflow

The process was remarkably straightforward:

1. Vibe code the webpage: I used AI coding tools to quickly put together the HTML, CSS, and basic structure

2. Version control with GitHub: All my code lives in a repository, giving me full version history and change tracking

3. Auto-publish with GitHub Pages: Every push to the main branch automatically deploys to ruidiao.dev

The entire process took just a couple of hours from start to finish. This solution is accessible to almost any software engineer who knows how to use AI coding assistants and GitHub. The barrier to entry for personal websites has never been lower.

I’ve shared my website’s code on GitHub for anyone interested, though honestly, it’s simple enough that you could build something similar yourself with AI in an afternoon.

What I Learned: The Good

Responsive design comes for free: One of the most impressive benefits of AI-generated code is that the website looks great on both mobile and desktop. Achieving truly responsive design used to require careful planning and testing. Now, AI coding tools handle this almost automatically.

GitHub handles the heavy lifting: GitHub Pages has evolved significantly since its launch. Today it takes care of complexities that used to require significant setup: auto-publishing, hosting infrastructure, SSL certificates, and custom domain configuration. What used to require server management and CI/CD pipelines now happens automatically with a few repository settings.

Speed and simplicity: For straightforward projects, AI coding tools are remarkably effective. These tools automate repetitive tasks, eliminate redundancies, and provide efficient workflows.

What I Learned: The Limitations

But the experience also revealed some important limitations of current AI coding tools.

Design homogeneity: AI-coded websites tend to look very similar to each other. Nearly all of them use Tailwind CSS, which has become the de facto standard for AI-generated styling. While Tailwind is excellent, this creates a certain sameness across AI-built sites. You can spot them from a mile away.

No proactive optimization: This is perhaps the most significant limitation. AI coding tools won’t proactively optimize for search engines (SEO) unless you explicitly ask. More importantly, they won’t implement Answer Engine Optimization (AEO), which is becoming critical in the AI era.

AEO is different from traditional SEO. While SEO focuses on ranking in search engine results pages, AEO aims to have your content cited by AI-powered platforms like ChatGPT, Perplexity, Google AI Overviews, and Bing Copilot. If you want your website to gain traction in this new landscape, optimization matters.

The agentic workflow gap: AI is powerful for building websites and writing frontend code, but a mature agentic workflow is still necessary for professional websites. Current tools are excellent at execution when given clear prompts, but they don’t yet think strategically about the full lifecycle of a website: SEO, AEO, analytics, performance monitoring, and continuous optimization.

For my personal website, these limitations don’t matter much. It’s not a traffic-driven site. But for professional projects where visibility and discoverability are important, these gaps are significant.

The Bigger Picture: Where AI Coding Is Heading

This experience reinforced something I’ve been thinking about: AI coding tools are transforming how we build software, but we’re still in the early stages.

The current generation of tools like GitHub Copilot, Cursor, and Claude excels at tactical execution. They can write code, provide feedback, and generate design elements with impressive speed. New tools like Windsurf and Cline are emerging and making the landscape even more competitive.

But strategic thinking is still largely in human hands. Developers act as strategists, using AI to handle execution and optimization. The next evolution will likely be end-to-end systems that can design, code, test, and deploy fully functional websites with minimal human input, while also thinking about long-term concerns like SEO, AEO, and user experience optimization.

We’re not quite there yet, but we’re getting closer.

Why This Matters

The shift from WordPress to AI-generated static sites mirrors a broader evolution in how we think about personal web presence. A decade ago, owning your platform meant running your own infrastructure. Today, it means choosing the right combination of tools and platforms to amplify your voice.

For me, that means:

• A simple personal website as a hub

• Substack for long-form writing

• LinkedIn for professional networking

• GitHub for code sharing

Each platform serves a purpose, and my personal website connects them all.

If you’re thinking about building or rebuilding your personal website in 2025, my advice is simple: start with AI coding tools for the initial build, but understand their limitations. If traffic and discoverability matter, you’ll need a thoughtful workflow that guides AI tools through optimization strategies they won’t tackle proactively on their own.

The barrier to building a personal website has never been lower. But building a website that stands out and gets found? That still requires strategic human direction, at least for now.

The extension is called NanoCoffee, and it took me a couple of days to create. This is my first AI Chrome extension, and the experience confirmed what I wrote about in my previous article on Chrome’s AI revolution: we’re entering a new era where AI lives directly in the browser. This is the practical proof.

The Vision: AI as a Native Browser Capability

For the past few years, building AI features meant integrating with cloud APIs like OpenAI, Anthropic, or Google’s AI services. This model worked, but it created friction: API keys, authentication, rate limits, usage costs, latency, and privacy concerns.

Chrome changed this by building Gemini Nano directly into the browser. Starting with Chrome 126, developers gained access to on-device AI through a suite of built-in APIs. No external services required. The AI is just there, ready to use.

This shift opens up entirely new possibilities for what we can build and how quickly we can build it.

The Problem I Was Solving

As an indie creator, I spend hours daily on social platforms: X, LinkedIn, and Substack. It’s where I learn, share ideas, and connect with my audience. But the information overload is real.

Long posts are everywhere, and there’s valuable content in many of them, but reading everything thoroughly is impossible. I found myself either skipping content I should have read or spending too much time trying to extract the key points.

There are AI browsers and AI sidebars that offer assistance, but they still require you to interact with a separate interface. I needed something truly integrated, something that worked exactly where I was already spending my time, with UI elements that felt native to the platforms themselves.

The Solution: NanoCoffee

NanoCoffee brings AI directly into your social media experience. It sits quietly in your browser and surfaces a summary button on long posts across X, LinkedIn, and Substack. Click it, and you get a concise summary of the content without leaving the platform.

Right now, it uses Chrome’s Summarization API, which taps into Gemini Nano running locally on your device. The summarization happens entirely on your device, with no network calls required.

I built this in a couple of days. Not weeks. Not months. Days.

Part of that speed came from using AI to help write the code (building with AI to serve AI). But the bigger factor was that Chrome’s built-in AI APIs eliminated the entire backend complexity that would normally slow down development. No servers to set up, no authentication flows to implement.

The result: I can offer NanoCoffee without charging for API usage, your content never leaves your device, and as Google improves Gemini Nano, the extension gets smarter automatically without any updates.

What’s Next

NanoCoffee currently focuses on summarization because that was the most immediate pain point I wanted to solve. But Chrome’s built-in AI capabilities extend far beyond that.

Over the next few weeks, I’m considering several additions:

• Writing and rewriting assistance: Help draft replies, adjust tone, or improve clarity of posts before you publish them

• Analytics assistant: Extracting insights from your feed, identifying trends, or highlighting key conversations you should pay attention to

• More platforms and use cases: The pattern of bringing AI assistance directly into your workflow applies to many contexts beyond social media

The broader vision is to make AI feel like a natural extension of your browsing experience, not a separate tool you have to consciously invoke. The AI should be there when you need it, invisible when you don’t, and always respectful of your privacy.

The Bigger Picture

Chrome’s built-in AI is still early. The Prompt API became stable for extensions in Chrome 138. Some capabilities are still in origin trials. There are hardware requirements (you need sufficient RAM and storage). The ecosystem is evolving.

But the direction is clear. AI is becoming a platform capability, not just a cloud service. This changes the economics, privacy model, and user experience of AI products.

For developers, the barriers to building and shipping AI products just dropped significantly. You don’t need to be backed by venture capital to afford API costs. You don’t need a team to manage backend servers. You can experiment, iterate, and launch AI features without the traditional infrastructure overhead.

For users, this means more privacy-respecting, cost-effective AI tools that integrate seamlessly into existing workflows.

Try It Yourself

If you’re dealing with information overload on social media, give NanoCoffee a try. It’s free, requires no API keys, and works entirely on your device.

If you’re a developer curious about building with Chrome’s built-in AI, check out the official documentation. The APIs are straightforward and ready to use.

Please comment, and share if you feel compelled to do so.

I appreciate you reading. Thanks to the new subscribers! ✌

For those who are more active on other platforms, you can also find me on LinkedIn or X.