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 😅

const PERMISSIONS = {
  READ:     1 << 0, // 0001 => 1
  WRITE:    1 << 1, // 0010 => 2
  EXECUTE:  1 << 2, // 0100 => 4
  DELETE:   1 << 3  // 1000 => 8
};

function hasPermission(userPermissions, permission) {
  return (userPermissions & permission) !== 0;
}

function addPermission(userPermissions, permission) {
  return userPermissions | permission;
}

function removePermission(userPermissions, permission) {
  return userPermissions & ~permission;
}

Here is where things got interesting. The approach the AI assistant suggested involved using binary values and using bitmasks instead of boolean flags. This is certainly not my default approach for solving this, and my attempts at nudging it to not use binary values didn’t work too well. It insisted on using this approach.

I felt a bit like Frank Whaley being lectured at by Samuel L. Jackson in the classic Pulp Fiction scene where…similar stuff happens:

The bigger point is this. As we rely on AI assistants to write more and more of our code, they will generate solutions that are optimized for it as opposed it being optimized for us humans. To describe differently, if we put the AI in the driver’s seat, it may take routes to get to the destination that might be different from ones we’d take:

The solution sometimes isn’t to fight the AI assistant. The solution is to better understand what the AI assistant is doing so that we can continue collaborating effectively with it. This specific binary/not-binary situation was the inspiration for my latest content drop where I explain how to work with both binary and hexadecimal decimal values:

You can view the video by clicking the YouTube thumbnail above, but if you prefer to read this content instead, you can go to my Counting in Binary and Hexadecimal article.

Till Next Time

Cooperating with AI assistants was not on my bingo card, but here we are. While I haven’t gotten to saying Please and Thank You as part of my interactions, the following comic will certainly make me think otherwise:

What are your thoughts? Feel free to chime in on the forums, on Twitter / X, or in the comments below with your thoughts.

Cheers,
Kirupa 👾

The big takeaway about bloom filters is that they are used in most situations where we have a large amount of data and need to quickly know if something we are looking for exists in that large amount of data.

Taking a step back, this touches upon a bigger question that many of us are grappling with. In a world of AI, what is the point of learning about these technical concepts?

It’s always been about abstractions

The chances of you and I having to implement a data structure like a Bloom filter have always been quite low. Outside of programming or system design interviews, the time we would spend even thinking about Bloom filters and how they work is close to zero. With the rise of AI assistants that handle a lot of this system design thinking for us, does it even make sense to know about Bloom filters at all?

From the earliest days, working with computers has always revolved around abstractions. Most of us do not write logic in 0’s and 1’s. We write in higher-order languages that make it easier to express ideas in casual English-like phrases:

The many years of optimizations used to make programs work at a low level are lost to us. Our assumption is that when our higher-level code is compiled/transpiled, those optimizations come along for free. Knowing about their existence or not is a moot point. For many of us, we don’t even know what we don’t know when we dig deeper down into the lower-levels of how computers work.

Just like we no longer need to think about how memory is managed behind the scenes when creating a loop in JavaScript, with AI assistants, we are fast reaching a moment where we no longer need to know how the overall system is built. We describe the idea using natural language (text, visuals, voice, etc.) and iterate at the level of results:

AI becomes yet another abstraction to the many layers of abstractions we have been adding over the decades since the first computers were invented. As abstractions go, it is natural for us to lose awareness of crucial details lower layers may provide. What makes AI a bit different is the depth of abstraction it provides. We could argue that each abstraction we added over the years was incremental, but the abstraction provided by AI is a giant leap. By relying on AI, more of us are becoming quite successful in building apps without knowing the computing fundamentals that we would have needed in the past. Forget about Bloom filters and all the other famous data structures and algorithms! Even programming basics may no longer be needed.

What’s the point in learning the fundamentals?

When learning to read and write, we don’t really learn Latin or Sanskrit or Greek or any of the more ancient languages first. Why should app building be any different? Today, relying exclusively on an AI assistant to help us build apps that are scalable, performant, and secure is still a bit iffy. It is still important for us to be able to spot potential trouble areas and guiding the AI assistant appropriately. This is a moment-in-time problem, though. As the underlying AI models get more sophisticated, their ability to do the right thing without any human guidance on the implementation will only increase. We can assume that in the near future when AI generates an app, the app will have implemented all the right details and safeguards that would be on par with the most experienced app developers.

When we get to that point, knowing the details of how underlying computing primitives work won’t really be needed. To take it further, there would be no need for a site like KIRUPA or a book like my Algorithms: Absolute Beginner's Guide to exist, at least not catering to a large audience as it aims to today.

What are your thoughts? Feel free to chime in on the forums, on Twitter / X, or in the comments below with your thoughts.

Cheers,
Kirupa 😅

So…vibe coding seems to be all the rage these days! 🔥

If you haven’t heard the phrase vibe coding before, it is a term coined by Andrej Karpathy where he describes writing code based on the "feel" of the problem rather than strict planning:

I'm building a project or webapp, but it's not really coding - I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.

The secret sauce to all of this are AI assistants (backed by large LLMs) that have the power to actually turn our ideas and feels into working-ish apps.

Now, to see what all the hubbub is about, I decided to dive head first into the vibe-coding pool. In the following video, I used Project IDX to build a full-stack app powered by a HTML/CSS/JS frontend and a Go backend…all without writing a single line of code (view directly on YouTube or on Twitter / X):

The only coding I did I was describe what I wanted to do in casual English.

While I did need to have a basic understanding of technical concepts to guide the AI assistant on the next steps in some situations, one could imagine that we’ll see increasingly less human intervention in the future.

Vibe Coding will just become Coding

Why do we extensively plan, prototype, and detail out software engineering projects before we start on them? The reason is that the cost of being wrong is often quite high. This cost is paid in money, time, people hours, opportunity, or a combination of all of them. What if this cost goes essentially down to 0? Would this change how we approach software development?

For a lot of us, the answer is a resounding…

When we can go in with a partially formed idea and have a working prototype in a matter of minutes or hours without requiring anyone but yourself and an AI assistant, the cost for just trying things out and seeing what sticks becomes very low. This completely changes all the equations that go into how software is built.

More importantly:

With all of this said, we can safely argue that AI-generated apps aren’t great for productionizing more complicated scenarios. The apps could have poorly structured schemas that slow database calls. They may have environment/secrets/keys and related details exposed to the client. They may even have other unwanted side-effects:

For the moment, AI assistants are just that…an assistant. You and I are still responsible for being in the driver’s seat and ensuring the right things happen across all parts of how our app gets built.

In the long term, our AI assistants will become more capable. They will be able to better understand more complex application scenarios and system design them in a way that would match what a more seasoned developer would prescribe as the right architecture. This is why I’m very optimistic that vibe coding is here to stay. It is inevitable.

Till Next Time

As always, thanks for taking the time to read this content. What you've seen here is freshly baked content without added preservatives, artificial intelligence, ads, and algorithm-driven doodads. A huge thank you to all of you who bought my books, became a paid subscriber, watched my videos, and/or interacted with me on the forums.

Subscribe now

Your support keeps this whole long-running, family-friendly educational circus going! 😇

Cheers,
Kirupa 🥳

You can watch the full episode below:

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

Public Speaking is Feared More than Death

No, I’m not exaggerating this claim. The fear of public speaking is known as glossophobia, and it is right up there at the top of what people are terrified of:

You’ve probably heard that public speaking is feared more than death itself. It sounds crazy, but that’s what people say. Is there any truth to this? Certainly the vast majority of people rank fear of public speaking as number one – 75% according to the National Institutes of Mental Health.

On the other hand, you then have people like Dan who love public speaking so much, they have decided to make it their full-time profession.

In our nearly hour-long conversation, we discussed Dan’s transition from training to be an architect to entering the world of technology and product management and ultimately deciding to be a public speaker.

Personally, this was one of my favorite conversations because I had minimal context on what Dan’s day-to-day looks like and the challenges. I learned a ton. For example, how does one even become a public speaker? How do you come up with topics to talk about? What is the right balance between sharing content and ensuring attendees have something unique to hear in real life? What is your preference on having walk-up music vs. not?

What is your dream venue to speak at? There are a bunch of questions similar to this that Dan was gracious enough to answer. At the end of this, I felt like I learned a lot about a whole new career path that I had never thought about before. Hopefully, you’ll feel the same.

Till Next Time

As always, I hope you found this content interesting for you, your friends, and your enemies. To get in touch with me, reply back to this email, ping me on X, or post on the forums.

Cheers,
Kirupa 😎

Freedom and Impact

In my years of interviewing talented and highly motivated individuals, there are two things they always highlight as their top motivators for choosing where to work:

1. Freedom in being able to do their best work

2. Having their work make an impact

Let’s say that you are this LEGO figurine:

We can represent freedom as this box that wraps your work persona at all times:

The size of this box determines the amount of freedom you have in accomplishing your job. The bigger the box, the less constraints you have. The smaller the box, the more constraints and restrictions you have:

Now, freedom by itself isn’t enough. You can be free to do whatever you want if nobody cares what you do. Otherwise, everybody would just be a founder! The important related question is this:

Within our constraints, we can visualize impact as arrows, and the size determines the amount of impact:

A detail to emphasize is that impact and freedom aren’t directly correlated. You can have a lot of personal freedom but be in a job where your work has little impact to the overall team or business. This could be you working very successfully in a role that is not critical to what your company is focusing on. On the flip side, you can be heavily constrained but have a tremendous amount of impact. An example of this is you working in a heavily regulated company with a large customer base where small improvements can lead to outsized positive results.

Of Startups and Big Companies

Tying all of this together, conventional wisdom is that if you want freedom and impact, you go to a startup. If you want stability with more constraints, big companies are where the action is at. On average, this observation is likely true. The problem with averages is that it also assumes we are talking about an average individual. Capable, ambitious, and high-agency people are far from average. For these individuals, they can get exactly what they are looking for in any environment.

Further making generalizations tough is that every organization (big / small / fast / slow) is a collection of multiple working cultures. You can have fast teams in a slow company. You can have slow teams in a fast company.

Impact is equally hard to bucket into a consistent set of heuristics. The only thing that is easier to predict are the outcomes of high-agency individuals. They will almost always find (or engineer!) themselves in a situation that matches exactly what they are looking for. This is true even if that situation isn’t the norm for the type of organization they are in. They will always find a way.

Till Next Time

I hope you found this post helpful, especially if you are looking for your next role and are unsure what company or industry to focus on.

As always, I like to hear from you on what you like or don’t like. To discuss this further or to contact me, feel free to continue the conversation on my Twitter / X or on the forums.

Cheers,
Kirupa 😀

What's it like to navigate startup life after having a lot of experience working at large tech companies?

As always, we cover a range of topics beyond just this question, so watch the full conversation below:

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

Also, feel free to participate in the conversation for this on LinkedIn or like/share with your network! I would highly appreciate it 😊

Cheers,
Kirupa 😀

There is a vertical format version of the above video on Twitter / X, Tiktok and Youtube if you would like to see it better on your mobile device! 📱

Take Execution Time into Account

The important follow-up question to ask is whether the problem is still worth solving by the time you get your MVP out. A problem worth solving today may not be worth solving 6 months from, 1 year from now, or whenever your team is able to get something out into the hands of users.

This is where a team’s ability to quickly make decisions and execute comes into the focus:

This is also where the historical winds tend to favor small companies with tightly focused teams over larger ones, where large teams often have many cooks without a strong bias for action.

As a product leader, it is your job to balance the value of a solution today with the value of the solution in the future. While nobody likes to hear this, sometimes the pragmatic answer is to acknowledge that our team will not be able to address the market need. This can be balanced by making requests such as faster turnaround times for decisions, bringing in the right people for the core team, more resources (though that is dangerous, more on that in the future! 💀), and so on.

A Quick Note on Membership

All of the content in this newsletter is free, but the content does get put behind a paywall after two weeks. You can become a premium member of this newsletter to not only have full access to all of my historical content, but you will also get a handwritten/note or sketch as well.

For the ultimate experience, the Super Exclusive 3000 👾 tier gets you a 30-minute video call with me on a topic of your choosing. If you have burning questions about business, design, product strategy, or development, I highly suggest you give this option a shot.

Till Next Time

As always, I hope you found this content interesting for you, your friends, and your enemies. To get in touch with me, reply back to this email, ping me on X, or post on the forums.

Cheers,
Kirupa 😎

There was a moment, though, that inspired this post:

While I was chatting back and forth, I noticed something interesting about the code the AI assistant was generating. It looked a lot like something that I had created years ago, for it had an edge case that I created specifically to address something on kirupa.com. Nobody else on the planet would have a need for that block of code.

Out of curiosity, I decided to just ask the AI assistant for the source, and it happily had the following to say:

Because the AI assistant had properly summarized several of my articles and code snippets to answer my question, it was no surprise why some of the quirks from my code spilled out into the answer as well. Funny, right?

Now, why am I telling you this? I am telling you this because this interaction is a precursor to the kind of pain content creators (maybe sorta like us?) will encounter in the near future.

The Times They Are A-Changin'

In the old days (like 6 months ago), if I had a coding task that I wanted to get some help on, I would have used a search engine and landed on an answer someone would have created. Let’s say that I do want to go with the article I wrote almost 13 years ago:

That this answer is from a known entity is obvious. Notice that I see KIRUPA in the search results. The URL and logo very clearly indicate that this content is something that I created. When you click on the link, you are taken to my blog, where you see everything exactly the way I intended for you to see things:

From here, you can browse through some of my other content. Interact with others on the forums. Choose to buy my books. Because you are on a destination that I fully created, you have the opportunity to explore and do things that would be mutually beneficial to both of us.

Let’s contrast this behavior to using an AI assistant today:

When using an AI assistant, I got the answer directly. I didn’t even have to sift through various results and/or visit some strangely named pixel-art-inspired site to figure out the answer myself. The AI assistant gave me the answer directly.

As a content creator, this entire AI-assisted workflow is downright devastating:

Each time someone asks an AI assistant a question, your content (and likely a mixture of content from other creators) gets summarized and presented without any easily discoverable link or reference back to the original sources:

This means that a consumer will never visit the content creator’s blog, never explore the content, never help them monetize, etc. The age-old social and business relationship between those who create content and those who consume content is getting broken.

Do we even need (human) content creators?

As Generative AI continues to make fast progress in creating high-quality text, images, audio, and video, is the unique value content creators bring to the table even needed?

For the longest time, we had an arrangement that looks as follows:

We had the content consumers, we had the intermediaries (aka the search engines and social networks), and we had the content creators. Each group was reliant on the other for its survival. The content creators created the content the content consumers were looking for. The intermediaries helped connect the content consumers with the content creators and found clever ways to monetize this connection. There was an uneasy alliance between all parties involved, but mostly everybody was happy.

Now, imagine you are an intermediary in this world. In this legacy arrangement, you are nothing more than a highway that collects tolls usually in the form of advertising revenue. You do all the hard work to hand over a content consumer to the content creator. The content creator gets all the glory (aka valuable data 🧮 and money 💰) from the content consumer.

With AI, the intermediary is no longer relegated to just being a highway. They can be both the highway and a desirable destination. They now have the ability to entice content consumers to stay fully in their ecosystem without ever having to send them off elsewhere to a 3rd party content creator.

In this AI-driven world, content creators still play a role:

AI systems are only as good as the data they are trained on, and guess who creates the data? That’s right - it is our content creators!

There is a problem here, though. The incentives that drove content creators in the past no longer exist. Why create content to throw into a void with limited reach and monetization opportunities? To avoid this chicken-and-egg problem, the intermediaries have incentivized certain content creators like Reddit, StackOverflow, and others by paying them for their data to be used for training the AI models. This ensures the models have access to up-to-date new information in addition to the massive amount of historical data they already have from content created digitally and non-digitally over the centuries.

As a content consumer, your life goes on as always. You have questions. You get answers. Whether the answer comes from a human creator or an AI-generated creator, it doesn’t really matter to the average user:

As videos and images get more photorealistic, even the most discerning of us will be unable to distinguish real from unreal. In the near future, one could imagine that everything we read, all the images we see, and any videos we interact with are powered by AI models created entirely by an intermediary in real-time to personalize the content for what we are looking for.

For content consumers, AI will bring in a pretty awesome age where they have access to highly personalized and engaging information. For content creators, the path is unclear. There isn’t a class of unique content or topics that AI won’t eventually be able to match and exceed a human at creating. Even originality can be faked, so whatever content pivots creators make is likely to be a temporary relief.

So, what is a content creator to do?

As a content creator, the old ways of creating and distributing content will likely no longer work. What you need to do is find ways to connect with your audience directly:

What this means is going to vary depending on the type of content you are creating. Something to try include:

1. You can try to negotiate your way to be seen as a special data provider that gets compensated for helping train AI models

2. Create a newsletter, for they are having a renaissance these days as being one of the last remaining mediums where an intermediary is not involved in dictating access.

3. Focus on activities in the physical world that AI can’t quite replicate - at least not until the humanoid robots enter the picture in full force! 🤖

4. ???

5. Profit

The gist of it is that I really don’t have a good answer here. When in doubt, just try stuff and see what sticks. Even if you don’t succeed, you’ll have learned a ton along the way.

Till Next Time

If we take many steps back, the world tends to gravitate towards solutions that provide a good user experience.

Having a unified chat window where an AI assistant takes care of getting me answers is arguably a much better experience than digging through links (many of which could be spammy) and finding the answer yourself. The technology landscape is filled with many examples of creative destruction where large groups of solutions where displaced by better things, often at great pain to the existing players.

It is a bitter pill to swallow that the creative destruction wrecking ball may be coming squarely at content creators like myself, but what it does mean is that I need to figure out a way to evolve and stay relevant. Until then, I have no plans of slowing down my content creation activities. I enjoy it far too much, and I constantly keep learning a lot of interesting things along the way 👾

If you have any questions or comments, post on the forums or ping me on Twitter / X.

Cheers,
Kirupa 🐙