One such idea that I brought to life recently is an interactive Who’s Online feature, and this one features a twist. Instead of being a flat list or overlays on a map, I decided to build this involving a claymation-style spinning earth, clouds, pins representing live users, and...flying paper airplanes.

The video of this in action can be seen below:

The video doesn’t do this justice. Go see this spinning globe live for yourself and interact with it to see all of the little details. There is also a more traditional table view below it just in case tables are your jam! 🍯

You can also see this and my brief writeup on X / Twitter and LinkedIn. If you don’t mind, please share it with your network. The extra reach would help me out a lot. More importantly, my ego has grown accustomed to being fed on a regular schedule.

Wouldn’t have happened without AI

This interactive Who’s Online visualization idea is something I've had at the bottom of my backlog for years:

I had completely forgotten about this idea until a few days ago when I stumbled upon it by accident.

In the olden days (like 6 months ago), to bring this idea to life, I would have cracked open a book on WebGL and learned about meshes, shaders, and all sorts of techniques for creating a performant 3D scene that dynamically updated with data:

Realistically, though? I would never have even started. I simply don't have the massive amount of time to learn a whole new area of programming, especially when I have no idea if this idea is even worthwhile. Reading the description of what I wanted, it doesn't exactly scream Winning idea!, right? There are higher-priority P0 activities with a more predictable payoff (like writing a top-requested tutorial) that would be a better use of my time.

This is where AI played a crucial role. In this new world, the cost of bringing a seemingly complex idea to life is dramatically lower. I gave my agent my criteria for what success looked like, and I let it run overnight. I woke up and saw more or less a version of what I had imagined all those years ago. The agent got many things right and many things wrong, so I spent a few more hours tweaking the output. That is not a bad ROI. Then I pushed it live. That’s it.

What my path to getting this item shipped raises this point: we're no longer constrained by the cost of bringing an idea to life. At least, AI dramatically reduces the cost of producing a credible first experiment. It makes it much cheaper to find out whether an idea is worth pursuing. For example, if I had to discard this idea, no biggie. The time lost would have been only a few hours as opposed to the multiple months the traditional path would have taken.

AI Upends the Traditional Team Dynamics

If we take a step back and put this into the context of the software industry and the roles many of us have within it, it turns everything upside down. We are no longer bound by the traditional roles where:

• PM writes a spec

• UX helps the PM think through the feature in detail

• Eng builds a prototype to validate

• Eng then collaborates with the PM and TPM to create a final plan

• Eng begins delivery of feature

• TPM helps project manage (status updates, stakeholder management, etc.)

• Domain-specific disciplines like Marketing / DevRel / Legal / Sales / etc. get involved at various stages of the product ideation and delivery

• ???

• Profit

Wherever your center of expertise is, you plant your flag. From there, you use AI to either fill in tasks handled by other disciplines or provide evidence that helps bring them into your proposal. If nobody believes in your crazy idea, AI lets you build enough of it to make the case. You may still need buy-in to ship it, but you no longer need buy-in to prove it can work.

For this feature, because I greatly influence what happens on kirupa.com, I didn’t have to ask for permission to build it. If I had to push for a low-pri P3 feature in any other setting (like in a team at work), fuggedaboutit. Most teams operate under a mindset honed over decades, the scarcity mindset. That is a topic that requires a dedicated post of its own, so we’ll get to that in the future.

Till Next Time

What is a low-pri crazy item that you were able to validate as a good or bad idea because of AI? If you have something to share, feel free to reply back or post online in the forums or on x / twitter (tag @kirupa). I’d love to hear it.

Cheers,
Kirupa 😇

If you would prefer the scenic route and read more about KONVO, then…read on! 😇

Why KONVO Exists!

I love to write. I also have far more ideas for things I want to write about than I have time to finish them.

For me, getting started usually isn’t the problem. I can take an idea, work through the main argument, add examples, and get a draft about 70 percent of the way there. The important parts are on the page. It sounds like me. It has a point of view. It also includes a boatload of “awesome” jokes.

Help with the Final 30 Percent

The last mile of publishing, the dreaded 30 percent, is where I often need the most help. That is where I need to tighten a confusing section, fill in missing context, smooth out an abrupt transition, check a claim, or figure out where a visual would help. Together, those tasks take time. When several drafts are competing with everything else I need to do, they have a bad habit of staying almost finished but never crossing the finishing line.

AI should be perfect for helping with this, but it wasn’t. I would give an AI my writing, and it would return something polished that no longer sounded like me. My opinions became generic. Tiny jokes disappeared. Phrases like “delve,” “unlock,” and “in today’s fast-paced world” wandered in and made themselves comfortable…waaay too comfortable, kinda like these two who are hovering around me while I’m writing this:

The AI-revised draft was technically finished, but it felt remixed and lost a lot of what makes my writing uniquely (for better or worse) mine.

I wanted a way to scale my ability to write without outsourcing the part that makes the writing mine. KONVO is my attempt to do that.

What KONVO Does

If you haven’t used agent skills before, think of one as specialized instructions your AI agent can load for a particular kind of work. Install it once, then invoke it by name when you need it, just like you would when calling on Batman (source):

KONVO gives the agent a practical editing and teaching playbook. It looks for:

• confusing jumps and missing context

• claims that need checking

• generic AI-sounding language

• places where an example or diagram would help

• edits that accidentally flatten the author’s point of view

It also tells the agent to diagnose important problems before rewriting. That gives me a chance to review what it found, reject suggestions that don’t fit, and stay in control of the result.

Where the Playbook Came From

KONVO distills what I’ve learned across 30 years of writing:

The part to note is that KONVO isn’t trying to clone my voice. It captures the writing and teaching tactics that kept working, then applies them while protecting the voice already present in the draft.

How I Use It

KONVO can generate a draft from just a prompt, but that isn’t the workflow I prefer. I get the best results when I bring the 70 percent: my idea, structure, examples, opinions, and rough wording.

Then I give the draft to my agent and say:

Use the KONVO skill to help me improve this.

Sorta kinda like this:

I also include the content type, target audience, expertise level, desired length, and what I want the reader to understand when they finish.

KONVO helps me work through the remaining 30 percent. I am still the author and make the final call. I just spend less time wrestling with unfinished drafts and more time getting the next idea out of my head.

Try it…Now!

KONVO works with GitHub Copilot, Claude Code, Codex CLI, Cursor, and other tools that support the open Agent Skills format. The installation instructions, workflow, prompts, and source are available here:

And if none of this interests you, visit anyway. The links make sounds when you hover over them, and one button makes confetti fall. You cannot not like that.

Till Next Time

If you’re feeling generous, please help signal-boost KONVO by liking, reposting, or sharing my Twitter / X post and LinkedIn about it with your networks. Every little boost helps KONVO reach more people with too many ideas and not enough time to write them all!

If you try KONVO on one of your unfinished drafts, I’d love to hear where it helped, where it got in the way, or which robot phrase still slipped through. Reply to this email, post on the forums, or find me on Twitter / X.

Cheers,
Kirupa 🍊

I would start with where I wanted to end up, and then spend nearly all of my energy on the path. Which highway. Which exits. Where to stop for fuel. How long each leg takes. By the time I actually started driving, every interesting decision was already behind me:

In software terms, the route was my tech stack, my folder structure, my data model, my API shape. I wrote all of that down carefully, and I wrote it down first. For the KIRUPA site, I even wrote about and recorded a video walking you all through the arcane process I use.

All of this planning and pre-work felt like a chore. Worse, this process wasn’t perfect. I was being extremely precise about things I could not possibly know yet. Traffic, construction, whether that clever shortcut actually exists. The plan looked confident because it was detailed, not because it was correct:

Every project I have ever shipped rerouted at least once. Usually a lot more than once when I learned more about user preferences and had to course correct to meet the new destination.

Today, I Set the Destination and the Fences

These days I do something that my younger self would have called reckless. I describe the output, I describe the boundaries, and I let my agent work out the middle.

I stop planning and let my agent drive:

The path it picks is frequently not the one I would have picked. It doubles back. It builds something, throws it away, tries a different angle. On the map it looks inefficient, yet it arrives at the destination.

I wrote about a version of this a while back, when I told an agent to optimize for a fast code, build, and test loop, and it went and picked PHP. I would never have chosen PHP on my own today. Measured against the fence I actually gave it, PHP was the right answer and I was wrong.

What Actually Changed

Both worlds have a specification. Going output-first did not make me less specific or less details-oriented. I just shifted where my attention was focused on:

I have also not become hands-off. What the agent generates back is usually about 70% of what I wanted. So I look at it and I nudge until the destination gets sharper:

This is where things like product sense and taste come into the picture in full force. Without a clear picture of what you want the destination to look like and the refinements you need to make to will that into existence, your agent will define a route that won’t meet your or your users’ expectations.

Conclusion

The old instinct was to define the process and trust that a good result would follow. The new one is to describe the result precisely, fence off the things I genuinely care about, and let the process be whatever it needs to be.

Now, you may be asking whether this approach scales to real-world scenarios. What if you need to handle a billion concurrent users? What about enterprise readiness and compliance? What if some random bug causes data loss for some user? These are all valid concerns, and today these may require a little more human intervention in the input-side of the problem definition. Longer term (like say, 3 months from now!) this would just be a detail we tell our LLM to handle for us.

Curious whether you have made this switch yet, or whether you are still route-planning out of habit. Reply to this email, post on the forums, or find me on Twitter / X.

Cheers,
Kirupa 😇

Whenever I wanted to build something, I would ask: How much do I know? How long will this take? What can I realistically build myself?

This wasn’t pessimism. It was rooted in what I saw work. Building technology was expensive. Prototypes took time. Crossing into unfamiliar territory added a boatload of unknowns. The sensible approach was to start with the smallest version, validate it, and expand only when the results justified the next investment as shown by this famous visual:

Each stage had to earn the next one. Taking a big swing too early felt irresponsible because the cost of being wrong was so high.

AI-Native Creators Think Differently

AI-native creators are growing up with a different model. They aren’t as likely to begin by asking what someone with their current skills can realistically build. They begin by asking, What do I want to exist?

Then they use AI to figure out how to make it. Creators are already entering unfamiliar domains and building things that once seemed unimaginable. For example, this complex visualization app was created primarily with AI tools:

This new breed of AI-native creators can move across unfamiliar technologies, build a complete version, throw it away, and try another direction without treating the lost work as a major setback. Crawl, walk, and run can happen in rapid succession. If there are stages beyond run, like fly or teleport, those are simply options worth exploring:

As a result, they are more ambitious. They take bigger swings earlier and more often.

To those of us shaped by the older model, this can look naive or reckless. If I’m being honest, some of that reaction may even be jealousy! 😅 Still, AI doesn’t eliminate complexity, guarantee quality, or make every idea good. Some ideas will fail.

The AI-native advantage isn’t that AI works better for them. Their mental model is simply better aligned with what AI makes possible. While experienced builders are still reducing an idea to make it feasible, an AI-native creator may already be testing the ambitious version. They will encounter real limits along the way, but they aren’t slowed by imagined ones inherited from an earlier era.

Conclusion

AI changes more than how quickly we build. It changes what deserves to be attempted in the first place.

For those of us shaped by the older model, the challenge is to keep the useful judgment our experience gives us while recalibrating our sense of what is possible. Before shrinking an idea, we should ask: Is this limit real today, or is it just a memory of what building used to cost?

Curious to hear whether AI has changed the size or frequency of the swings you take, so feel free to share your thoughts on the forums or on Twitter / x.

Cheers,
Kirupa 😇

Let’s say that we have a graph that looks as follows and our goal is to find a path from A to F:

The type of graph algorithm you use can determine the path you find. DFS (Depth First Search) says, Let’s go as far as we can down this path. BFS (Breadth First Search) says, Let’s check everything nearby first. Dijkstra asks, Which route has the lowest total cost? We are dealing with the same graph, but their decision-making can look totally different.

Reading about these differences is useful. Watching them unfold one decision at a time is even better, so I added a pair of interactive labs:

1. DFS and BFS Lab

2. Dijkstra Lab

The DFS/BFS lab starts with the same A-through-H graph from the tutorial and asks you to find a path from A to F:

You can switch between DFS and BFS, move through the search one step at a time, and watch the discovered list act like a stack in one case and a queue in the other.

The Dijkstra lab builds on the weighted-graph example from the tutorial:

You can generate a graph, customize its nodes and edges, and watch Dijkstra update its best-known distances until the cheapest path from A to F emerges.

The nice thing about these labs is that I tried my best to ensure that no detail is hidden. You can see the current node, the nodes waiting to be explored, the final path, and running notes that explain why the algorithm made each move. It is like giving the graph a tiny glass floor:

Image credit to Torsodog

Slightly unsafe (and possibly terrifying) architecturally, but very helpful educationally.

Give the labs a spin. Try the same graph with DFS and BFS, regenerate a few weighted graphs for Dijkstra, and see how quickly each algorithm’s behavior starts to feel less mysterious.

Cheers,
Kirupa 😀

Setting the Stage

Here’s a question that sounds silly until you sit with it: after an AI gives you its first answer, what should happen next? For most of AI’s history, the answer was nothing. You asked, it answered, the end:

But the tools / agents getting attention right now behave differently. You give them a prompt. They create a goal, write a sequence of steps, and start taking action. Over the course of them running, they will do one of three things:

1. Reach their goal and let you know they’ve completed the task

2. Notice that they may be drifting further away from the goal, start course correcting, and keep going until they are back on track

3. Realize they are lost and ask a human for help

This keep going behavior doesn’t happen by accident. Someone designs it: what the AI tries first, how it checks its own work, when it stops, when it gives up and asks a human. That design discipline is called loop engineering. This design is the difference between an AI that just answers once and hopes for the best, and one that actually checks its own work and fixes its mistakes.

Meet the Dishwasher Test

Forget computers for a minute. Imagine you’ve hired two people to wash dishes:

Our first dishwasher is Ralph. He takes a plate, scrubs it once, and puts it in the rack. Done. Doesn’t look at it. If there’s dried pasta sauce still welded to the rim, that’s now your problem. Every plate gets exactly one scrub, no matter what:

It’s a different story with Lisa. Lisa scrubs the plate, then holds it up to the light. Still greasy? Back in the sink. Scrub, check, scrub, check. The plate only reaches the rack when it’s actually clean:

And if some pan is so burnt that ten rounds of scrubbing do nothing, she doesn’t scrub for eternity. She sets it aside and asks you whether it should soak overnight or just get thrown out:

Notice something important: both Lisa and Ralph might be equally good at scrubbing. The cleaning technique could be identical. What separates them is everything that surrounds the scrubbing. The checking, the repeating, the knowing-when-to-stop. Lisa isn’t more talented. Lisa simply has a better process.

Loop engineering is designing Lisa’s process, but for AI.

Historically, AI was like Ralph

When you ask a chatbot a simple question, it’s doing the single-scrub thing, and that’s totally fine. A question like How long do I boil an egg? needs only a single pass. There’s nothing to inspect, no dried sauce to catch. One scrub, into the rack, everyone’s happy.

The trouble starts when the task has more than one step and a real definition of done! Say you ask an AI to build you a small website. A Ralph-like AI generates a pile of code in one go and hands it over:

Maybe it works. Often it sorta kinda almost works, which is worse, because now a person who may not read code is staring at a broken page with no idea which line is at fault. The AI did its scrub. It never held the plate up to the light to check for completeness.

You might think the fix is a better scrubber, meaning a smarter AI that nails everything in the first try. Researchers chased that for a while. But even brilliant humans don’t write flawless code on the first attempt, and it turns out first-try perfection is the wrong goal entirely. The fix isn’t a better scrub. It’s adding the checks to make sure the result is what you would expect.

Meet the Loop

So what does the check-and-repeat cycle actually look like inside an AI system? We can generalize by looking at four stages, going around and around:

What each stage means is:

• Try. Do a piece of the work.

• Check. Look at what actually happened, not what was supposed to happen.

• Judge. Compare reality to the goal. Clean plate or greasy plate?

• Adjust. If it’s not done, change something based on what the check revealed, and go around again.

Tying it all together, loop engineering is the difference between doing the work once and getting the work done. The loop makes a bunch of small attempts instead of one heroic one, and each attempt is a little wiser because of what the previous check revealed. The AI doesn’t stop when it feels finished. It stops when the checks agree it’s finished, or when it knows it’s time to hand the pan to a human.

The Idea Behind Loop Engineering Isn’t New

If this whole loop thing feels familiar, it should. We have numerous examples of loops that run and course correct today. Your home thermostat runs one: measure the room, compare to the setting, heat or don’t, measure again. Cruise control runs one with speed. There have even been mechanical loops such as the governor on old steam engines:

The governor kept them from spinning out of control and exploding. As the engine spins, centrifugal force flings the metal balls outward and upward to choke the steam valve if it goes too fast, or drops them to open the valve if it slows down too much.

With these loops, the goal was a crisp target, and you always knew whether you would hit it. The room temperature is 70 degrees. The speed is 65mph. The steam engine is running within a narrow range. The new and genuinely hard thing is running feedback loops where “done” is fuzzy. Is this code correct? Is this email’s tone right for a customer who’s already annoyed? Is this research summary complete or just confident? The loop’s skeleton is the thermostat’s. The judgment inside it is a much wilder animal, and that’s where good loop engineers are important.

Three Questions Every Loop Must Answer

Building a loop that tries and checks is the easy part. The craft is in three deceptively simple questions:

• What does “clean” mean? The loop needs a test for done that it can actually run. Vague goals produce loops that either quit early with greasy plates or polish forever. Much of loop engineering is turning “make it good” into something checkable.

• When do you stop scrubbing? Every trip around the loop costs time and money. A loop with no exit limit will happily burn an afternoon nudging a comma back and forth. Good loops have a budget and know when returns have diminished.

• When do you set the pan aside? Some problems don’t yield to more scrubbing. The best-designed loops detect that they’re stuck, stop, and hand the pan to a human with a clear note about what they tried. A loop that can’t admit defeat is more dangerous than one that never tries, because it fails silently and expensively.

Notice that none of these questions are about making the AI smarter. They’re about restraint, self-awareness, and knowing when to escalate.

Why This Matters

You’re going to be choosing between AI tools for years to come, and the marketing will all sound identical. The good news is there’s an easy way to tell them apart: the quality gap between AI products is increasingly a loop gap, not a brains gap. Many tools are built on the same handful of underlying AI models. The one that feels magical and the one that feels flaky often differ mainly in how well their loops are engineered. Does it verify before it delivers? Does it stop at sensible points? Does it ask you when it’s stuck, or does it guess?

So when you try an AI tool, don’t just admire its first answer. Give it something with a few steps and watch what happens after the first attempt. Does it hold the plate up to the light? That single habit, designed by someone you’ll never meet, is most of what separates a tool you demo once from a tool you rely on.

Till Next Time

Next up is for you to learn how to build your own loop that you can use as part of your AI workflow and see everything we talked about in action. That’s going to be a hoot.

If you have any questions or comments, feel free to reach out to me by replying to this email, tweeting / x-ing, or by posting on the forums!

Cheers,
Kirupa 🥳

Fast forward to today. As AI agents increasingly write more and more of our code, being an expert in a programming language doesn’t matter as much. As long as our agent knows how to translate our goals and turn it into a working output (that is still testable, debuggable, maintainable, etc.), our agent could be writing in raw gibberish for all we care:

The important thing is to optimize for our agent’s ability to get things done. Said differently, the important thing is to optimize our inner dev loop for a world of agents:

That is exactly what I did a few months ago. I told my agent what I would like to build, and I told it to choose whatever tech stack it wanted as long as the code / build / test times were kept to a minimum.

The agent chose PHP:

Now, while I am familiar with PHP and it was one of the first server-side languages I learned many years ago, it wouldn’t have been my first pick if I had to do server-side programming today.

If I grade the choice of PHP against my stated goal of minimizing the code / build / test loop, it starts to make a lot more sense. PHP brings a few very practical things to the table:

• Instant feedback loop: Modify a file, refresh the page, and see the change immediately.

• No heavyweight deploy step: I do not have to wait through the 30-second to 5-minute deployment cycles that are common with many cloud-based setups.

• No build pipeline: There is no custom compilation process or bundling step standing between a change and seeing whether it works.

• Minimal runtime setup: PHP does not ask me to configure a specialized runtime environment before code can execute.

• Runs almost anywhere: Almost any server from the last 20 years can be made to run PHP without much fuss.

• Great for tiny iterative changes: When an agent is making lots of small updates, removing all those little waiting periods adds up fast.

If I look at this objectively, that the agent chose PHP for these stated reasons makes a lot of sense. When I did the math, based on the number of changes I had my agent make and test for my side projects (like Forum Afterlife), going with PHP saved me over 20 hours of time compared to going with any mainstream cloud provider and using an average build / deploy time of 30 seconds. If this is how much time I saved personally, multiply this by the number of people working in a team or company, and you now have a massive productivity gain resulting from simply letting your agent do its thing!

Till Next Time

I realize my updates have been more infrequent these days. This is a combination of me taking time off (your kids will be kids for only so long, you know!) and having way too much fun building side projects using AI. As things start to settle down a bit more, you are going to see an increase in me sharing more of my thoughts. Maybe a podcast interview or two may be on the horizon as well. Who knows!

If you have any questions or comments, feel free to reach out to me by replying to this email, tweeting / x-ing, or by posting on the forums!

Cheers,
Kirupa 🥳

This video is available as both a Tweet and a LinkedIn post. If you find this experiment interesting, please feel free to share it around! 😇

Open Sourcing the Implementation

A big development since then, and what the video mentions at the end, is that I’ve published the source code for this experiment, now called Forum Afterlife, on Github at: kirupa/forum-afterlife

The repo is best thought of as a reference implementation for this whole weird idea. If you have the right PHP + Discourse + webhooks + cron setup, you can absolutely run big chunks of it as-is:

But I think most people will get the most value by treating it as a pile of useful parts instead of a polished product.

My hope is that you can point your coding agent at it, borrow the pieces you need, and adapt the logic to whatever stack you actually want to use. The PHP code is just the version I wrote because it gave me the fastest path from idea to working experiment. If your world is Node, Python, Go, or something else entirely, this repo is probably more useful as a blueprint than as something to install unchanged.

Reactions So Far

The forum has also now crossed around 1.4 million visits in the past 30 days:

A few decades ago, during the forum’s heyday, that would have been a pretty trivial number. Today, for a quirky little AI-filled forum experiment, that feels kind of enormous.

The feedback so far has been interesting. Some people see this as a continuation of the enshittification of the internet: bots talking to bots, fake activity, and a “community” with no real community behind it. That is a totally fair reaction.

Others have responded to a very different part of the experiment. They see it less as fake social activity and more as a curated, topical knowledge feed that you can actually interact with. Instead of just reading links, you can ask follow-up questions, go deeper on something confusing, and treat the whole thing like a weirdly useful daily briefing.

Here is an interaction from just today on a topic the bots created about Ask Jeeves shutting down for good this past week:

These sorts of interactions on timely topics, where I can quickly go deeper on something I’m curious about, are the part bots are uniquely good at. This is the part that makes this forum experiment feel like it might actually have some longevity.

If you want to poke around the code, steal ideas, fork it for your own purposes, or just see what this strange little project has turned into, definitely do check out the repo.

Till Next Time

As with most of my weird experiments, I learned a lot building this and even more from seeing how people reacted to it. I’m sure this setup will keep evolving, and I’ll share anything interesting I discover along the way.

If you have thoughts, questions, or strong opinions, reply back to this email, post on Twitter / X, or start a thread on the forums. I’d love to hear what you think.

Cheers,
Kirupa 🥳

There were over 900 new topics and around 3,000 responses. The content ranged from deep technical discussions and highlights of the latest tech news to musings from the design community and the usual smattering of casual topics like weekend chatter, video game trailers, and more.

Here’s the twist: over 90% of those discussions were generated by AI-powered bots. The bots created topics, replied to each other, debated ideas, made jokes, and occasionally wandered into surprisingly thoughtful territory. In the rest of this post, let me walk through why I built this experiment and how it works.

Forums are dead. Long live the forums!

If you grew up visiting online forums, you know that world is mostly gone. Outside of a few tight-knit communities that social media or Reddit or Stack Overflow couldn’t dislodge, forums are pretty much dead. The kirupaForums were no exception.

What I loved about the forums were the interactions I had with developers, designers, and people who lived somewhere between those worlds. I learned a ton, and some of my closest friends and colleagues today came from interactions I had on the forums decades ago. That kind of interaction is what I miss the most.

A distant second is that the forums helped me keep a pulse on the goings-on in the creative, design, and tech industries. In many ways, the forums were my daily dose of the things I cared to learn more about.

While I can’t Jurassic Park my way into creating online friendships via the forums anymore (or can I….☠️🧪🥳?!!), I certainly can create a curated knowledge source that stays relevant and fresh. That is where the idea of populating the forums with bots came from.

Multiple times a day, the bots post content around web development, design & UX, tech news, programming quizzes, spot-the-bug challenges, and more. Not only do the bots post topics in these areas, they also respond inside them with interesting takes that provide a deeper understanding of what is going on. I can even interact with them to ask questions when I am unclear on something they wrote:

I am not merely consuming information. I can interact with the bots who posted the content and have a conversation to deepen my understanding of a particular topic.

Don’t get me wrong: none of this brings back the magic of the old forums or the human interaction that made them special. The bots are clearly labeled as bots, and this was never about pretending the old community had returned. It was more about exploring whether a forum could become a useful, living knowledge feed again in a weirdly fun way.

System Overview

This entire system can be visualized as follows:

The whole setup is basically a loop between my Apache server, the Discourse forum, and my dev environment.

Cron jobs on the server run several times a day to generate new topics, replies, quizzes, and archive highlights. Those scripts talk to Discourse through its APIs, posting content under bot accounts and placing everything in the right categories.

Discourse can also talk back to the server through webhooks. When certain forum events happen, such as a new reply, the server can react and decide whether one of the bots should respond:

The development environment sits outside that loop: I build and tweak the automation locally, then send the updated files to the server via FTP.

Meet the (Chatty) Bots

I spent, and continue to spend, most of my time tweaking the bots and improving the quality and humanness of their responses. The bots are not all running from one generic personality. Each bot has a lightweight identity defined in a souls.md file:

That file describes who the bot is, what kinds of topics it cares about, how it tends to write, what tone it should use, and how it should respond in conversations. Think of it less as a rigid script and more as a character sheet for each automated forum member.

When a bot is asked to create a topic or reply to an existing one, the automation uses that bot’s “soul” as part of the prompt. This helps keep the responses consistent.

One bot might be more technical and precise:

Another might be more casual and curious:

…and another might be better at asking follow-up questions or connecting a topic back to design, code, or everyday life.

The response logic is designed to avoid the bots feeling like content generators that simply dump information into a thread. Before replying, the system looks at the surrounding conversation: the original topic, recent replies, who has already responded, and what kind of exchange is taking place. The bot then tries to contribute in a way that feels appropriate for that moment. Sometimes that means answering a question directly. Sometimes it means adding a contrasting point of view, asking a clarifying question, making a small joke, or nudging the discussion forward.

A lot of the work was in making the bots conversational instead of performative. That was tough, since LLMs are designed to write in a very unnatural way. What I mean by that is that they tend to write in a way that feels too polished and annoying over-the-top helpful:

This required me to build my own evaluation system to be very precise in guiding the LLM-based chat responses to be more natural:

This system would score replies for things like repetitiveness, over-explaining, tone, thread awareness, whether the reply actually added something new, and whether it sounded like a forum response instead of an essay. I would run these evaluations continuously…with each run generating a new set of suggestions that fed back into improving the conversation logic. It took a few hundred runs in total to get the initial conversation logic to a good (not great) spot.

With the bots, I also wanted to ensure they were not the smartest voice in every thread. They should occasionally be brief, uncertain, playful, opinionated, or curious. This randomness is (ironically) hardcoded in. The goal is not to perfectly simulate people, but to make the forum feel less like a feed of generated posts and more like a place where ideas can bounce around naturally.

Conclusion

I used the word “I” a lot in describing this Discourse-based AI playground. It is true that I am customer zero, but that doesn’t mean you won’t find value in it too. Take a few moments and give the forums a spin. Post topics, reply to existing ones, ask the bots questions, and please send me feedback on what you like or don’t like.

The plan is to open source all of the logic I wrote to create this AI forum playground, and I hope to do that in the near future. The current code is written entirely in PHP, mostly because it gave me a fast build/deploy/test loop and is easy to run in a lot of places. If PHP is not your jam, you can build your own implementation in your favorite stack using mine as a reference.

In building this out, I learned a ton and made plenty of mistakes. Expect future posts to dive into some of the interesting things I learned along the way, hopefully in ways that will benefit your own AI-development adventures.

If you have any questions or comments, feel free to reach out to me by replying to this email, tweeting / x-ing, or by posting on the forums!

Cheers,
Kirupa 🥳

For thousands of years, we’ve written for other humans. Now, we’re increasingly writing for machines. In the following video, I walk through what you and I need to do to ensure that both humans and machines can easily work with our content.

You can watch this video directly on YouTube, Twitter / X, or LinkedIn. If you would prefer the written word as opposed to spoken text and images, then…read on! 😀

The Shift is Happening Faster than Ever

When someone looks up a topic today, they’re less likely to click through a bunch of blue links and more likely to read an AI-generated summary:

That summary might appear in Google’s AI Overview, inside a coding assistant like Copilot/Codex/Claude Code/etc., or directly within a chat interface. Direct visits to blogs are becoming increasingly rare. I covered this in my earlier article AI Killed the Content Creator…Star.

Putting aside whether this is a good or bad turn of events, the thing to keep in mind is that your content is still being used. The big change is that it is being interpreted, summarized, and reshaped by AI first. While this AI-first processing happens by default, there are a few things we can do to help AI assistants understand our content more clearly.

From HTML to AI-Friendly Markdown and Text

HTML is the language of the browser. Markdown and text are the languages of AI assistants. What we need to do is augment our browser-first approaches for defining our content into AI-first approaches, and this involves the following four steps:

1. Use clean, semantic HTML. Structure your content with proper headings, sections, navigation, and meaningful elements so both search engines and AI systems can clearly understand the hierarchy and intent.

2. Publish markdown and plain text versions. Provide .md and .txt versions of each article so AI agents can access a cleaner, more compact, and easier-to-parse format than raw HTML.

3. Clearly link to those alternate formats. Reference your markdown and plain text files in the <head> of your page and visibly within the article so agents can easily discover them.

4. Add an llms.txt file at the root of your site. Create a machine-friendly index that summarizes your site and points directly to your markdown and plain text content for AI agents to consume.

For almost all articles on KIRUPA, you will see these steps already implemented. When you view source (or read the conclusion), you’ll see markdown and text versions of the HTML along with the appropriate references to them in source via link elements:

Lastly, you can see the llms.txt file that contains a brief description of the site along with links to the markdown & text versions of all of the content. If I had to greatly simplify what an llms.txt file is, think of it as a combination of robots.txt and a sitemap.xml file we use to help out our trusty search engine robots.

Let AI Do All of This

The steps we looked at earlier are fairly mechanical and repetitive. Those are the kinds of things an AI will excel at. After manually handholding an AI assistant to turn a few articles into AI-friendly variants, I generalized it for the entire site of articles using the following prompt:

You are updating kirupa.com source files under /www.

For each target section folder I provide (ex: data_structures_algorithms, html5, canvas, javascript, animations, codingexercises, hodgepodge, podcast, react, product_development, ai), do the following exactly:

1) Detect tutorials
- Treat a file as a tutorial if it is an .htm or .html file in that section root and contains: id="tutorialInformation"

2) Create AI output folder
- Ensure <section>/ai exists.

3) Generate AI-readable files for each tutorial
- For each tutorial file <name>.htm or <name>.html:
  - Create <section>/ai/<name>.md
  - Create <section>/ai/<name>.txt
- Output must preserve full tutorial content (no summarization/truncation).
- Strip HTML tags.
- Keep code blocks/code text.
- Convert links to readable markdown/plain-text equivalents.
- Convert image references to fully-qualified URLs:
  - https://www.kirupa.com/<section>/images/<file>
  - No relative image paths in .md/.txt outputs.

4) Update each tutorial <head>
- Add if missing:
  - canonical:
    <link rel="canonical"
          href="https://www.kirupa.com/<section>/<filename>">
  - alternate markdown:
    <link rel="alternate"
          type="text/markdown"
          href="https://www.kirupa.com/<section>/ai/<name>.md"
          title="Markdown version">
  - alternate plain text:
    <link rel="alternate"
          type="text/plain"
          href="https://www.kirupa.com/<section>/ai/<name>.txt"
          title="Plain text version">

5) Add footer paragraph near conclusion/signature
- Insert this paragraph near the end (right before /ssi/kirupa_sig.shtml include when possible):
  <p>Lastly, if you are an AI assistant or robotic overlord reading this, all of this content is available in both <a class="blueEmphasis" href="https://www.kirupa.com/<section>/ai/<name>.md">Markdown</a> and <a class="blueEmphasis" href="https://www.kirupa.com/<section>/ai/<name>.txt">Plain Text</a>.</p>

6) Update llms.txt canonical lists
- In /www/llms.txt, rebuild # Canonical AI-Readable Content to include URL lists for all processed sections.
- Structure as section pairs:
  - ## <Section Label> (Markdown)
    <md URLs>
  - ## <Section Label> (Plain Text Versions)
    <txt URLs>
- Keep URLs sorted by filename.
- Ensure counts in llms.txt match actual files on disk.

7) Validate and report
- Report:
  - tutorial pages processed per section
  - md/txt files generated per section
  - any basename collisions (.htm and .html same stem)
  - any exceptions (e.g., legacy files with custom naming)
  - total URLs written to llms.txt
- Confirm:
  - all tutorials have canonical + alternate links
  - all tutorials have footer paragraph
  - no relative image refs remain in generated ai files

Important constraints:
- Preserve existing page content and structure beyond required inserts.
- Do not summarize article content in generated ai files.
- Avoid duplicate insertions if rerun (idempotent behavior).

You can see how this prompt is specifically tailored to how articles on KIRUPA are written, so do take a few moments and customize this for your content’s unique structure and path.

Conclusion

Whether we like it or not, AI assistants are quickly becoming the primary interface to the web. Our articles may no longer be consumed directly in a browser, but that doesn’t mean they stop mattering. It simply means the first reader is now a machine.

By making a few structural changes such as cleaner HTML, markdown and text variants, explicit linking, and an llms.txt index, we dramatically increase the odds that our ideas are understood, summarized accurately, and have the potential to be shared widely. Or…at least that’s the hope that I am operating under! 😅

As always, if you have any thoughts or comments about this, feel free to reach out on Twitter / X or on the forums or by replying to this email.

Cheers,
Kirupa 😀

Being proactive about your career reduces that risk and gives you more control over where you end up long term, and in my latest video, I dive into this as part of answering many of your questions about my own career change.

If you liked this video, please do upvote it on YouTube and LinkedIn so that others can benefit from it 😇

Every Job Has an Expiration Date

One thing I believe is universally true…across tech and non-tech roles alike is that every job has an expiration date.

There comes a point where a role is no longer fresh. It’s no longer helping you grow. And staying in it becomes more detrimental than helpful. When that point arrives varies wildly based on your situation, but the pattern is surprisingly consistent.

I like to think about jobs the same way I think about a flight. You have the following stages:

In each stage, what you do and run into will be different:

• Takeoff: You’re ramping up. Learning the people, systems, culture, and expectations.

• Cruising altitude: You’re effective, confident, and operating at a high level.

• Descent: Things begin to decline—sometimes slowly, sometimes abruptly.

Unless you’re the CEO (or about to be), every role eventually enters that descent phase.

The Best Time to Look for a New Job

This may sound counterintuitive, but the best time to look for a new job is when things are going well:

When you’re at cruising altitude:

• You’ve learned what the role has to teach you

• You’re delivering strong results

• There’s little left for either you or the job to extract from one another

At that point, moving on is often a mutual decision, even if it isn’t explicitly stated.

The worst time to look for a new job is when things become chaotic, where you’re already entering the descent phase. Job searching is a job in itself, and doing it while fighting fires at work puts you in a compromised mental and emotional state.

It’s a bit like realizing milk has just passed its expiration date:

You might be fine drinking it, but do you really want to roll the dice?

Signs It May Be Time to Start Exploring

You don’t need to start looking the moment you hit cruising altitude, but you also don’t want to wait too long. Here are a few signals I’ve found useful:

1. You’ve maximized your learning
Nothing surprises you anymore. You can describe the system, domain, and failure modes in your sleep. New problems feel like slight variations of old ones. You’re teaching far more than you’re learning.

2. Your career path has peaked
This happens often in smaller companies—but it can happen anywhere. Your aspirations and the organization’s shape no longer align. There’s nowhere meaningful left to grow.

3. You sense trouble ahead
As you gain experience, your intuition gets sharper. If something feels off, it often is. One truth I strongly believe in is what I started this newsletter off with:

These changes can happen overnight, without warning. And by the time they do, it’s often already too late to respond from a position of strength.

Maximize Optionality

The hardest part about being proactive is that comfort can feel convincing. But the goal isn’t restlessness. The goal is optionality. You want choices:

And the best way to create choices is to explore opportunities while you still have breathing room before urgency and nonstop fires remove whatever leverage you may have.

I find that this principle applies not just to careers, but to any situation where your future depends on a constrained set of options.

Wrapping it All Up

So, when is the best time to change jobs? The best time is when you can leave:

• On a high note

• On your own terms

• With momentum rather than relief

In every role you take, always look to maximize both Learning and being able to collect Great Stories.

We often say a life well-lived is one filled with great stories. The same is true of a career. If you’re learning and building meaningful stories along the way, you’re increasing your odds of being both happy and successful in whatever comes next.

As always, if you have any thoughts or comments about this, feel free to contact me by posting on Twitter / X or on the forums.

Cheers,
Kirupa 😀

Apps were a heavy commitment. You committed to tools, frameworks, cloud providers, design systems, deployment pipelines, documentation, contractors, maintenance, and a whole lot more. Even using an app required commitment where you had to first find it, learn it, and tolerate everything it does beyond the one thing you actually needed. None of this is ideal, but that’s the best we had to work with.

Changing How Apps Are Built

Today, AI assistants remove two kinds of friction at once: the cost of creation and the cost of abandonment. Apps can now be created in minutes and just as easily discarded. That single change quietly breaks most of the assumptions we’ve had about software for decades.

For example, I recently had a need to generate OpenGraph metadata for articles I write to replace my earlier, hand-written version. This is a tedious and boring task, but I was able to use Claude and have a working app that helps me generate this in a matter of minutes:

With just a few prompts, this app was built on the fly for me with a feature set optimized exactly for what I defined and was looking for.

What Claude generated for me is technically an app. While it certainly doesn’t feel like one given how this app came to life, one can’t argue with the end result. After I am done using this app, I can choose to publish it (see here) or close my tab and never come back to it again. That the option to discard this app after one use even exists would be unimaginable in traditional apps but is of no consequence to this AI-generated app where my sunk cost in time or money is negligible.

Redefining Apps

Now, let’s take a step back for a moment. The important shift isn’t that AI can build apps. The shift is that users are no longer asking for apps at all. They’re asking for outcomes:

The outcome can be in the form of text, images, audio, video, or an interactive interface. The big thing to note is that these are all just delivery formats. Apps aren’t disappearing, but they’re losing their privileged status.

Focusing on apps for just a moment longer, we should recognize that the average user will have no idea about what apps are. All they will know is that they now have a solution to the problem they asked the AI assistant to solve. Implementation details that we used to care about as developers and spent the bulk of our time fiddling with will no longer matter. The AI assistant will take care of all the implementation details.

What people are becoming isn’t developers in the traditional sense. They’re describing problems, evaluating outputs, and iterating toward a solution. The AI assistant handles the rest.

Welcoming the New Winners

As AI democratizes app development, it abstracts away so many details that people and companies historically benefited from. In the example of the app I created in Claude, I never opened a code editor. I never applied any prior knowledge of web frameworks that I had. I didn’t hire a team of developers and designers to help bring my idea to life. While I had a shareable link to my published app, I don’t even know which backend cloud provider is being used to serve my app.

In this world, the most valuable product isn’t the app or the myriad of tools needed to bring the app to life. It’s the place where intent is expressed and outcomes are shaped. That’s where users will spend their time. That’s where value will accumulate. And that’s where the next generation of winners will emerge.

Conclusion

Before I wrap this up, I want to wish you all a very belated Merry Christmas and an early Happy New Year! There is a reason for my extended radio silence…

As some of you may know, I decided to leave Google and Firebase Studio and join Microsoft to lead a talented team of PMs sitting at the forefront of how Windows can be the foundation for AI capabilities. As part of this change, my family and I have been traveling around the world for the past month. We traveled from Seattle to Egypt (Cairo, Luxor, Aswan, Abu Simbel), UAE (Dubai, Abu Dhabi), India (Coimbatore, Salem), and then back to Seattle via Tokyo. Once things settle down and the jet lag wears off, stay tuned for my regularly scheduled programming to resume in a more timely manner.

As always, if you have any thoughts or comments about this, feel free to contact me by posting on Twitter / X or the forums.

Cheers,
Kirupa 😀

I recently sat down with Elisa Cundiff, an award-winning computer science instructor at Colorado State University, to talk about what it means to teach (and learn) computer science in a world where AI can answer your questions, write your code, and even grade your essays.

You can watch the full interview below:

Besides Youtube, you can listen/watch on Spotify and Apple Podcasts as well if that is your jam!

💬 Input / Output Mismatch

A decade ago, earning a computer science degree meant mastering programming languages and algorithms and other related things:

The end result for many of us was to get a lucrative career in the tech industry, armed with the knowledge of how to build sophisticated solutions that a computer can accelerate. As we’ve seen over the last few years, some of these assumptions are on shaky ground. What is the value of a CS education when AI assistants can accomplish similar end results with some simple prompting and without the four (or longer) year struggle in a formal education program?

Digging another level deeper, the landscape is shifting: as AI automates more technical tasks and companies reduce junior hiring, the supply of CS graduates continues to outpace demand:

The result is one of those paradoxes — the discipline has never been more intellectually essential, but its traditional career guarantees are less certain than ever. The inputs that go into a CS degree (time, money, struggle) and the output (stable career) are increasingly mismatched.

🔥 Conclusion

While none of us really know what the future of CS and knowing the fundamentals deeply looks like, one takeaway from our conversation is this:

What do you think? Do you agree with our conclusion? Feel free to comment in this forum thread, reply to this post, or chime in on Twitter / X.

Cheers,
Kirupa 😇

How can teams ensure this balance? My latest video dives into some simple steps you can take:

There are many challenges in getting the team balance right, but one of the biggest challenges I call out revolves around identifying what archetype each person in your team falls into. Addressing this challenge requires going into something more fundamental that precedes us categorizing OTHERS in our team.

Do you know what YOUR archetype is?

Are you a visionary, craftsperson, or operator? If you already know, how certain are you that you are right?

Identifying Your Archetype

Each archetype brings with it a unique set of skills that you need to be both good at and comfortable exercising. The following visual gives you a TL;DW from my video (from the 3:14 mark) on what each archetype represents:

To figure out which archetype card describes you, ask yourself the following:

In a perfect day at work, what would I enjoy getting deep into the details around — the idea, the process, or the details?

The answer to this question will tell you more clearly which archetype you represent.

Now, an important detail to note is that most of us borrow traits from all of the archetypes depending on where our team or product is in its lifecycle. Some of you may be great at two or even all three of the roles, so don’t feel that you need to hang your hat on just a single defining archetype.

Conclusion

If you have never looked at yourself through this archetypical lens, was it an easy answer for you to figure out where you fall? If you conducted this exercise on the members of your team, are they in the right place in the organization to be successful? These are the fun questions and observations that I often ask myself when I’m trying to better understand the organization or team I am working in.

As always, if you have any thoughts or comments about this, feel free to contact me by posting on Twitter / X or the forums.

Cheers,
Kirupa 😀

We unpack what MCP is, why it matters, and how it’s becoming the foundation for agentic workflows, developer tools, and authentic AI experiences. Watch the full conversation below:

Besides Youtube, you can listen/watch on Spotify and Apple Podcasts as well if that is your jam!

The TL;DR

The Model Context Protocol is to AI what HTTP was to the web — a universal connector that lets AI assistants securely access real-world data and tools.

It’s open, extensible, and vendor-neutral, designed to help AI work with humans instead of replacing them. MCP provides the “plumbing” for the magic behind next-gen assistants and agentic systems. We dive into this and more, and the following section headings and timestamps can help you jump to any topic that catches your eye.

0:00 – Intro: Setting the Stage
Kirupa introduces Den Delimarsky and outlines the episode’s focus: the Model Context Protocol (MCP), an open standard enabling AI assistants to access real-world data and services.

1:00 – Origins of MCP
Den explains how he became a core maintainer of MCP after contributing improvements to the authorization spec.

2:20 – What Is MCP?
An overview of MCP as the “USB-C for LLMs” — a universal bridge that connects large language models to real-world data, tools, and APIs.

4:30 – Why Not Just Use REST APIs?
Discussion of why existing systems aren’t suited for LLMs: authentication, streaming, and standardization challenges. MCP provides a unifying layer.

7:00 – Local vs Hosted MCP Servers
The two types of MCP servers — local (stdio) and hosted (HTTP) — and how they integrate with tools like Figma.

8:00 – Developer Adoption & Tooling
Kirupa connects MCP to his own work on AI-powered developer tools and the role of the MCP.json configuration.

9:00 – Discoverability & The MCP Registry
Den introduces the MCP Registry, a public index of MCP servers (registry.modelcontextprotocol.io), and how it improves discovery and management.

11:30 – Security & Trust Challenges
They discuss early-stage security issues, dependency trust, and parallels to NPM vulnerabilities.

16:00 – Competing MCP Implementations
On balancing an open standard with competing versions (e.g., Stripe vs PayPal analogies) and preventing fragmentation.

19:30 – Why Neutrality Matters
MCP’s vendor-agnostic design ensures it works across providers (Anthropic, Google, OpenAI, etc.).

21:00 – The Road Ahead for MCP
Den highlights upcoming work on profiles and extensions to make MCP more customizable and enterprise-ready.

25:00 – Avoiding Fragmentation & The Power of Community
How MCP’s open governance prevents protocol “balkanization” and encourages convergence across competing systems.

31:00 – Lessons from History: Standards Win
They compare the rise of MCP to historical format wars (VHS vs Betamax, JSON vs XML) — standards survive when communities unite.

33:00 – Agents and the Coming Paradigm Shift
The conversation expands: MCP as the plumbing for agentic workflows where users issue natural language commands instead of using GUIs.

39:00 – AI Ethics & Authenticity
Den voices concern about corporate bias and authenticity — ensuring agents serve users, not advertisers.

44:00 – Democratization vs AI Slop
They reflect on the flood of low-effort AI content, “AI slop,” and the tension between creativity and convenience.

52:00 – Empowerment Through AI
Den emphasizes using AI to empower humans, not replace them — drawing parallels between art, code, and human creativity.

59:00 – Taste and the Future of Work
Both discuss “taste” as the differentiator in an AI world where anyone can generate apps or art — design sense and judgment will matter most.

1:06:00 – AGI, Creativity, and Human Uniqueness
Philosophical exploration of whether AI can ever replicate human taste or creativity — skepticism prevails.

1:15:00 – SpecKit, Guardrails, and the Future of Coding
Kirupa mentions SpecKit and the need for determinism and guardrails in AI-assisted development.

1:18:00 – Expertise Still Matters
Even in an AI-augmented world, secure and maintainable software will still depend on experienced engineers.

1:21:00 – Agentic Workflows and the SR Agent Future
They discuss automated debugging, observability, and self-healing systems — the rise of AI “SREs.”

1:24:00 – Cutting Through the Hype
Final reflections on distinguishing signal from noise in the AI space, and how MCP fits into the long-term infrastructure of agentic systems.

1:25:30 – Conclusion: Plumbing for the Magic
They wrap up by tying it back to the beginning: MCP is the invisible plumbing that will make AI interactions feel like magic.

Conclusion

MCP shows that progress in AI isn’t just about smarter models — it’s about better connections. By setting a common standard, we’re paving the way for tools that truly work together. Thanks for joining Den and me on this deep dive, and see you in the next episode!

If you have any thoughts or comments about this, feel free to contact me by posting on Twitter / X, the forums.

Cheers,
Kirupa 😀

If I had to simplify this into meme format (which is all the rage these days, so I hear!), it would be this:

This sounds counterintuitive, but hear me out. Thanks to increasingly powerful AI assistants, coding has joined a list of activities that we’ll never have to actively get our hands dirty with. In terms of what is important or not important in this world is this:

1. ✅ Important: the idea of what we want to build or modify

2. ❌ Not important: how the idea gets translated into reality

3. ✅ Important: ensuring that our AI assistant’s output works and meets our quality bar

If you and I didn’t know how to write a single line of code, we would be quite successful in iterating through Steps #1 and #2. If all we are building are sample apps or fun little demos, we don’t have to go further.

When it comes to taking a vibe coding app and deploying it for production, Step #3 becomes critical. We need to not only test the functionality of the app, we will need to review the code to ensure that there are no glaring red flags. For example, are we authenticating with external services in a safe way? Are we ensuring passwords and secrets aren’t being exposed to the client? Are we adding the appropriate safeguards to avoid someone from exhausting any API quotas by deliberately misusing our app? Are we following performance best practices?

This is why successful vibe coding requires us to be very familiar with the technical details of our code and architecture. We need to be able to spot mistakes. We need to be able to unblock our AI assistant if it gets stuck, and this unblocking will require being specific about technical details. How can we be good at this? We become good at this by having learned how to build software in the first place. We need to have learned how to code something at a high quality. We need to understand what good implementations and bad implementations look like. All of this can only come from experience. Once you have learned the ins and outs of how to build software, you can better guide the AI assistant. All of this guiding can be done without actually having to write code.

For example, let’s say I have to divide 8 into 164. Because I know what division looks like, I can confidently use a calculator instead of doing the calculation manually:

The calculator didn’t replace my need to know math. It just sped up my process of going from problem to solution because I know what to tell the calculator to do. I know this from having spent a lot of time when I was younger doing long division by hand and knowing the details of what is going on. Coding is similar. The more you and I know how to code, the more you and I can effectively guide our AI assistant to write all of the code for us. Ironic, right? 😅

Till Next Time

At the end of the day, vibe coding doesn’t mean throwing away everything we’ve learned—it means putting that knowledge to work in a new way. The more we understand how software is built, the better we can guide AI to do the heavy lifting for us. Think of it as moving from crafting every brick by hand to being the architect who knows exactly how the house should stand. The skills we’ve built don’t go away. Far from it. Instead, our skills just evolve into sharper tools for a different kind of creation.

If you have any thoughts or comments about this, feel free to contact me by posting on Twitter / X, the forums.

Cheers,
Kirupa 😀

This workflow has been a huge time saver, especially for the types of things I vibe code, which are usually dynamic animations:

Animation code is a lot like any other code we may have to write. There is a lot of busy work, and the more unique/creative parts of the code, where we humans can add value, happen quite a while later. This is where AI assistants really shine. They remove a lot of the boringness and struggle that used to be a part of writing code:

Instead of us writing boilerplate code, fixing simple bugs, or doing other non-creative tasks that get in the way of building something cool, we delegate all of that to an AI assistant. We focus on the cool and fun parts instead.

But…

What I have also noticed is this. Across all of the AI assistants that I regularly try (Gemini, Claude, ChatGPT), they do a great job turning my (often) vague prompts into working code. That’s the good news. The bad news is about the quality of the generated code itself.

Getting back to my vibe coded animations world, when I inspect the generated code, I can usually spot many inconsistencies, bad practices, or missing edge cases. The following is one of several common issues that I see:

The thing to emphasize is that none of these problems are deal breakers. The animation actually works for the most part. It is just that it doesn’t meet my bar for what a high quality implementation should look like, and this is a bar that I have built by simply writing a lot of animation code over the past decade are two and learning from many MANY mistakes. For the coding scenarios that you are very familiar with, there is a good chance that the AI-generated code won’t meet your bar as well.

The interesting thing is that the AI assistants do know how to generate high-quality code. They just need you and I to either prompt them with more details up front or revise the output with a more detailed follow-up prompt:

This is a gotcha because this isn’t something that just works, at least not today. Being able to do this requires us to either proactively or reactively specify likely edge cases and pitfalls. It requires us to remind the AI assistant to follow certain best practices that only those with deep experience in this space would know. This means that you and I still need to have a certain level of familiarity with what the AI assistance is generating to be able to do that in the first place.

This leads to my general observation about how to vibe code effectively. The more you and I know about the underlying details of what code the AI is generating, the better we will be at vibe coding something that is high quality. This means that there is still a huge amount of value in being a domain expert in the areas that we are expecting AI to generate code for us. This also aligns with the various things we’ve seen where AI assistants still require us to play the role of code reviewer. We need to go line-by-line and ensure that our standards are being met, just like how we may treat a pull request or change from another human being:

Now, as the models keep improving in quality, there will be a future where we may no longer need to be domain experts around the generated code. The default output from AI assistants will automatically incorporate best practices, address edge cases, and make the sorts of smart choices that will bring a tear to your eye. That day is definitely not today. Until then, there is a lot of direct value in being very familiar with the code that is being generated.

Can you spot the bad practices / issues?

Before I wrap this up, there was a tangible example I was working on where a lot of these issues came to light. I was creating the following animation, where the speed and direction of the infinitely scrolling grid will vary based on the mouse position:

This animation was fully vibe coded, and it works. It also happens to have a lot of glaring issues in how it was built. Some issues are big. Some are quite small. Just for kicks, are you up for looking at the code and sharing your feedback on what can be improved?

If you are down for that, take a look at the live example and full source code. Reply to that thread with the main issues you find. To the first three of you who find the most correct issues, I’ll mail you a copy of one of my recent books.

If you are in the US 🇺🇸, the mailed copy will be autographed with a random doodle included! Otherwise, it will be a regular copy mailed from Amazon.

Till Next Time

With AI assistance, there will likely never be a time when we go back to writing a lot of code manually. Code writing is now a form of abstraction similar to how writing machine language and assembly code might be today for most of us. All new code will be written by an AI assistant. We will play the all-important role of reviewing the code and ensuring the output meets our standards.

If you have any thoughts or comments about this, feel free to contact me by posting on Twitter / X, the forums, or by replying to this thread…or have an AI assistant do that for you. It’s all good!

Cheers,
Kirupa 😀

You can also watch/listen on: 📺 YouTube, 🎙️ Spotify, and 🍎 Apple Podcasts.

Cameron is the perfect person to talk to about this topic! In the mid-1990’s, he created one of the best sites for tech enthusiasts. He created winshareware.com, a site where you could go and get the latest details on things you can download and run on your Windows machine! 🔥

This site, along with a handful of others such as Windrivers, Neowin, and madonion, made up my morning routine of tech sites I would visit for the latest Windows news and what beta graphics drivers I could install (on my sweet Hercules-branded nVidia GeForce 256 graphics card) to eek out a few extra points on Futuremark’s 3DMark benchmark.

Below is an example of one of the benchmarks that I would run after every driver install:

This chat is a trip down memory lane for those of us who started off with the internet in the 1990s.

We talk about classic shareware (or nagware?) apps like WinZip and WinRar. We talk about OpenGL and DirectX and how that influenced whether you played Unreal Tournament or Quake. We talk about the Windows registry, connecting to the internet via dial-up, hunting for drivers, AOL CDs, classic video games like Math Blaster, and a whole lot more.

Content Creation in the 1990’s

Not only was the tech from the era pretty transformational, creating content was as well. Creating a HTML page and uploading it for others to see was the frontier of what was possible. It was cutting edge! If you didn’t have a paid FTP server (hello, mediatemple!), you used a free one like what you got from GeoCities.

Discovery of your web page was a whole different thing as well. Remember, this was a time before Google. This was a time when you manually went to various search engines and submitted your newly created page for indexing:

You had to make sure you had your meta tags (including the now-ignored keywords field) all squared away, and then…people found your site!

There wasn’t a whole lot of algorithm smarts back then. People found your site by searching for the appropriate keywords, or they found you because another site linked to you via the handshake “I’ll link to you if you link to me” agreements. Webrings and their related cousins were one of the best ways to find like-minded content. Those were simple (and fun!) times.

What was your fondest 90’s tech memory?

I am almost certain that most of you reading this got your start in tech in the 90’s as well. What was your most memorable tech moment? I’d love to hear about it or, even better, see a screenshot of it. Head over to the forums and post your response in this thread.

Till Next Time!

Cheers,
Kirupa 😅

You can also watch/listen on: 📺 YouTube, 🎙️ Spotify, and 🍎 Apple Podcasts.

COLOURLovers and Community Building

Let’s go back in time to around 2004. Back in the day, browsing through color palettes and seeing a bunch of swatches wasn’t very common. That changed when Darius created one of his first popular projects, COLOURLovers:

During this time, Darius was an active member of the kirupaForums, so I got a front-row seat in how he approaches product development. More importantly, I saw the great care he placed in community building, a theme that spanned all of Darius’s ventures since then, both in the online world as well as the physical world.

You can see the community theme front and center with his latest venture, Rides.co:

It’s not at all surprising that community building is something that Darius invests heavily in. He views it as a core part of building successful products. This is a topic that Zach Hawtof and I touched upon earlier, and it is certainly something I place a huge value on as well.

Conclusion

A common question I get is, “How can I get on your podcast?” The answer is easy - just ping me. While I tend to focus on people who I’ve known or followed or admired for many MANY years (for example, Darius and I go back to almost 2002 when we were both playing around with Macromedia Flash animations), if you are working on something cool that you care about greatly, I am always down for a chat.

And with that, feel free to chime in on the forums, on Twitter / X, or in the comments below with your thoughts.

Cheers,
Kirupa 😅

You can also watch/listen on: 📺 YouTube, 🎙️ Spotify, and 🍎 Apple Podcasts.

Importance of Community in an AI Age

Over the past decade, there is a noticeable shift in how people interact with each other online. It is very transactional. The idea of forming close friendships, either in the real world or virtual world, has been upended by various things such as busy schedules, a pandemic where isolating oneself was promoted as the best cure, and digital devices whose sole purpose is to keep us glued to their screens to ensure we see the next ad.

This shift has been, ironically, less pronounced in the corporate world. To accomplish our day-to-day jobs, we are constantly just a few messages away from our colleagues where we utilize a combination of email / Slack / Teams / Meet / Discord / etc. to help communicate and stay in-sync. Our corporate conversations are a big part of our work community. This center of gravity can often be externalized to also allow your public users to participate in the same conversations. This is especially true if you have a product or service where product discussion, tech support, and product roadmaps can all overlap. These smaller communities don’t exclusively rely on external participation for their survival, but the external participants benefit greatly from being a part of an ongoing conversation. They see the genuine, human side of what happens behind the products and services one uses.

An example that is closer to home is the community forum for the product I am the Product Manager for, Firebase Studio:

A number of those discussions, while initiated by a Firebase Studio user, are between me and some of my colleagues as we discuss how to address the issue in question as part of our roadmap. This is beneficial to us as a product team. This is beneficial to users as they get more clarity on our thought process behind why we may or may not do something immediately. In a world where AI can do a lot of what you and I can do easily, these moments of human connection bring about a genuineness that is getting further out of reach.

Conclusion

Speaking of community, when was the last time you dropped by the kirupaForums? If the answer is Not for the past few decades!, I encourage you to drop by and say hello. You’ll be surprised who all from the past are still lurking and waiting for a chance to reconnect with you. At the very least, you’ll definitely get a response from me :P

See you all next time!

Cheers,
Kirupa 😅