A few weeks ago, I wrote a post called My Girlfriend Doesn’t Know What Git Is. She Just Built an Entire CMS. Huge post. You should check it out if you haven’t. The idea is that AI is now enabling us to create anything we think of.

The tech people got it. They’d seen the same thing in their own lives, especially at work. But my non-tech friends? One said “cool” and pivoted to weekend plans. What felt world-shifting to me was invisible to most people I know. Not because they disagreed with it, but because it didn’t register as relevant to their lives at all. Which made me wonder: are we actually in a bubble? The gap between “AI power users” and everyone else is getting wild.

Taking the questions to Reddit

The next reasonable thing to do was take the question to Reddit. To my surprise, that post went viral. My karma score tripled.

What struck me wasn’t any single comment. It was how the comments fell into patterns. I grouped them into 6 distinct categories:

1. “Relax, This Gap Has Always Existed” at 21%

2. “Most People Don’t Want to Build” at 17%

3. “But Are You Actually Being Productive?” at 17%

4. “The Burnout Is Real” at 13%

5. “The Gap Will Close” at 10%

6. “It’s Already Working Outside Tech” at 10%

“Relax, This Gap Has Always Existed”

The most upvoted comment had 244 upvotes. It said:

Have you ever asked your friends outside tech what HTTP APIs, VSCode, Python or any other tech related thing is? Always has been the case.

Someone else put it more bluntly: Do you know about the latest technology in dental medicine? Or plumbing?”

Another compared it to quantum physics: I have the same issue when I talk about quantum physics with my friends. It’s like they live in a completely different world.

And yeah. Okay. Fair. But here's the thing: a lot of the people in that subreddit thread weren't technical. The gap is closing whether we notice it or not. You don't see me wandering into r/quantumphysics with opinions, but AI is different. People who have never written a line of code are already in the conversation. Maybe, the gap between tech people and everyone else has always been enormous. We just didn’t notice because our tools used to look scary on purpose. Now AI looks friendly and accessible.

“Most People Don’t Want to Build”

This was the contrarian take, and it had a lot of support:

Most people don’t have the want or need to create solutions to problems they have. They just see something useful others made and use it. The tinkerers and solution makers have never been a large part of the population.

Others piled on: People who aren’t engineers don’t magically become engineers with AI. There’s a lot more to engineering, including the INTEREST to be an engineer. Not everyone wants to build things.

And: You realize that most people just live their lives happily, right? Like they don’t feel the need to 10x productivity.

I mean, maybe this is true. But I really like the cooking analogy.

One person said:

Anyone can cook. Some people are really good at cooking. Others either don’t care or prefer others do the cooking. But opening a restaurant is not the same as cooking.

This is it. This is the whole thing. Knowing how to prompt could be considered cooking. Building a product on top of it is opening a restaurant.

“But Are You Actually Being Productive?”

Someone asked: Are AI power users making more money or just spending more money? 55 upvotes.

The replies were funny. 10x-ing their output, and making negative $200 a month. And: That’s the difference between an AI power user and someone who’s good at business. One person asked simply: Are you 10x-ing your salary? If not none of this has any relevance whatsoever.

Another:

keep hearing people talk about 10x-ing their output. What are they actually outputting? I have a feeling that 99% of it is just shitty SaaS Next.js projects that have no user base.

And honestly? I’ve spent entire evenings setting up MCP servers, tweaking configurations, automating workflows. At the end of the week I haven’t shipped anything amazing.

“The Burnout Is Real”

This is the one that got me. Someone wrote

I sprinted through trying all my ideas, have 30 unfinished projects and just want to quit out of frustration that I’m not good enough to make it better than AI slop.

Then later, same person:

AI psychosis... people who are constantly overworking themselves to keep up with each new model every week. Coming from knowing absolutely nothing to now knowing how to create web3 apps, GitHub repos, UI design, to Godot and Unity testing — all in 3 months. And I have a day job and family obligations. I’m burning out fast.

They weren’t alone. A power user wrote: Honestly I’m kind of tired of it. This past weekend I didn’t do any coding or AI related stuff at all. It was awesome. I just worked on my cars all weekend. It was nice to wrench.

Another admitted: I’m spending more time trying to learn and configure tools than actually getting my work done.

Nobody talks about this part. The highlight reel is all I built an app in 20 minutes! The behind-the-scenes is someone at 2 AM with 30 half-finished projects, no revenue, and a growing suspicion that they’re just generating sophisticated garbage.

The other side of “AI lets you do anything” is the anxiety of feeling like you should be doing everything. The FOMO isn’t about missing a tool. It’s about missing the entire future.

I’ve been there. I’m probably there right now. I wrote this blog post instead of shipping something. Self-awareness is not the same as self-improvement.

“The Gap Will Close”

This camp saw it as a timing problem, not a permanent divide:

Yeah but ‘ahead of the curve’ doesn’t last as long as it used to. It used to be if you knew the cutting edge of tech, there was a pretty long time before those who didn’t could get the same results, often years or decades. Now that lead is highly variable but on average seems to be a year or two at max, maybe even just months.

Others drew historical parallels. I see this as a ‘Photoshop’ type adoption. 25 years ago it was a select group of people. Now it’s casual lexicon meaning ‘photo edit’. The gap is widening for now, but over time will start to slowly contract.

One person compared it to the Apple II era:

In the ‘80s millions of people bought Apple IIs. I’m sure the nerds thought everyone would make their own programs. But some people did development and started companies. Others played games. It’s how it always goes.

A particularly sharp comment:

The gap is bigger than ever but closing that gap is easier than ever also and available to anyone with a phone and a nearby McDonald’s. Rather than the haves and have-nots it will be the wills and the will-nots.

Cool. So my competitive advantage has an expiration date and the date is “soon.” Love that for me. But actually, this is weirdly comforting. If you’re behind right now, catching up has never been easier. Being early matters less. Being useful matters more.

“It’s Already Working Outside Tech”

Real people, not developers, building real things.

An interventional radiologist:

I used Claude Code to write a program that reads old radiology reports and pre-fills facts on the new report. All the code was written in 1 day.

A medieval historian:

Now Claude is building custom linguistic and language tools and apps in Python and HTML for my medieval history thesis research, and I can’t believe what is possible for me to achieve now.

A construction professional:

I’m outside tech and have built one app for my work and am working on another much more complex project for the construction industry.

A senior manager:

I’m not a techie. Been using AI solid two years now. Just started coding a tool and it’s going well. It’s like the internet in 1995.

When people with zero reason to care about developer tools are picking them up and building real things — a radiologist automating reports, a historian building linguistic tools, a construction worker solving industry problems — something fundamental has shifted. This is not hype. This is people saving hours of their lives because the tools got good enough for them to use.

The Number That Put It in Perspective

While I was going down this rabbit hole, I came across a Medium post by Julius Nyerere Nyambok that hit me with a stat I wasn’t ready for: 84% of Humans Have Never Used AI. That’s Either a Crisis or an Opportunity. It’s written in February so in the relative speed everything is moving at this post might considered outdated, not even might consider ancient now but it’s still shocking to see that in February 84% have never used AI. Not “haven’t used Claude Code.” Not “haven’t tried agentic workflows.” Have never touched AI. At all.

And the 16% who have? That includes the teenager who used ChatGPT once for a late homework assignment. The bar for “has interacted with AI” is on the floor, and 84% of the planet is still under it.

That number reframed things for me. I’m wondering if my barber knows what an MCP server is, and meanwhile 6.8 billion people haven’t even had the “hey, ask ChatGPT” moment yet. The bubble I’m worried about isn’t even visible from where most of the world is standing.

The article frames it as either a crisis or an opportunity. I think it’s both. But mostly it’s a reality check for anyone — myself included — who spends too much time on tech Twitter and starts thinking the whole world is vibe coding.

So Is It a Bubble?

Maybe. I really don’t know. It’s hard to say. But I just wanted to share my Reddit experience with y’all.

I do agree though, it’s a social bubble, not a technology bubble.

The technology is real. I watched my girlfriend, someone who does not know what Git is, replace her entire SaaS stack. A radiologist automated his workflows in a day. People are building real things that solve real problems. That’s not hype. That’s evidence.

But the conversation around it? Total bubble. Twitter, Reddit, LinkedIn have created a world where it feels like everyone is vibe coding at a PhD level and if you haven’t automated your entire life you’re falling behind. That’s not real. 84% of the planet hasn’t even tried AI once. Our echo chamber isn’t just loud. It’s microscopic.

My friends think everyone will be vibe coding by Christmas. The skeptics think it’s all hype. Both might be right. AI is genuinely transformative for people who need what it does. It’s completely irrelevant to people who don’t. And that’s the same pattern as every major tech shift. The internet in ‘95. Smartphones in ‘08. The early adopters weren’t wrong. They were just early. And the people who ignored it weren’t stupid. They just didn’t need it yet.

We’re in the “early adopters who think everyone else is crazy for not adopting” phase. The gap will close. Not because everyone will learn to orchestrate 20 agents, but because the tech will meet people where they are.

We’re All Just Cooking

So if you’re one of my 20 followers who actually uses this stuff — yeah, you’re ahead. Enjoy it. Build something. Ship it, ideally, unlike me.

We’re all just cooking. Some of us are making incredible pasta. Some of us should probably not open a restaurant. The bubble isn’t the technology — it’s the echo chamber of people who think they’re the only ones who noticed fire is hot.

Takeaway: The tech is impressive.

Introduction

This is going to be a different kind of post. No code blocks. No step-by-step guide. No “here’s what I learned” takeaway neatly wrapped in a bow. This is just a story.

AI has been advancing so fast that I’ve stopped being able to keep up with my own reactions to it. Every week there’s something new that makes me rethink assumptions I didn’t even know I had. And I’ve become the person who won’t stop talking about it. That’s why I started Substack.

Claude Code specifically. I’m obsessed. I come home and I’m telling my girlfriend about skills, hooks, and MCP (”you can connect it to anything!”). She’s nodding along, eating dinner, hearing me explain the difference between a system prompt and a CLAUDE.md file for the fourth time.

I am, by any reasonable measure, insufferable about this.

So one day, she said what anyone would say after weeks of listening to their partner rave about a tool they’ve never touched: “Okay. Let me see what the hype is all about.”

She started simple. Got a Claude subscription. Twenty dollars a month. “Let me try to create this homepage.” Then, “Let me create this.” Then, “Let me create that.”

And then things got wild.

The $20 Experiment

My girlfriend doesn’t know what Git is. She couldn’t tell you the difference between a frontend and a backend. Actually, she could. She took a few comp sci classes in university. But the point is she has never opened a terminal on purpose. This is important context for what comes next.

Her first real question to Claude was practical, the way all her questions are: “Can I import my orders from Shopify into a dashboard so I can see everything in one place?”

She runs a small business. She’d been using Shopify’s built-in analytics, which are fine if you want to see what Shopify thinks you should see. She wanted something specific to how she actually thinks about her numbers.

Claude built it. Not a mockup. Not a suggestion. A working dashboard. She could see her orders, filter by date, sort by product. It pulled from her actual data.

I walked by her laptop and stopped. “Wait, that works?”

She looked at me like I was the one who didn’t understand technology. “Yeah. I just told it what I wanted.”

Escalation

Here’s the thing about solving a problem you’ve been living with: it makes you notice all the other problems.

Within a few days, her questions to Claude got bigger. “Can I build a customer onboarding flow? Like, when someone buys from me, they get a welcome sequence and I can track where they are?” That’s not a dashboard anymore. That’s a workflow engine. That’s the kind of thing you’d draw on a whiteboard for two hours before writing a line of code.

She didn’t draw anything on a whiteboard. She described what she wanted in plain language and iterated. “No, I want the status to update automatically when they complete this step.” “Can it send them an email at this point?” “I want to see all my customers in a pipeline view.”

She upgraded to the $100 plan. Not because anyone told her to. The free tier ran out of runway for what she was building, and she didn’t even hesitate. The math was simple in her head: this subscription costs less than the tools it’s replacing, and it builds exactly what I need.

It’s Not Perfect

I want to be honest here, because I think honesty is what makes this story worth telling.

What she builds isn’t production-grade software. There’s no version control. No test suite. No error handling for edge cases she’ll never hit. If you asked her about database indexing, she’d ask you what a database is.

And for what she needs? None of that matters. It works. It solves her problem. When something breaks, she describes the issue and it gets fixed. She doesn’t need to understand why something broke. She just needs to describe what broke.

But here’s the thing. AI doesn’t replace the human touch. It can’t understand her customers the way she does. It can’t feel the friction in her own workflows. It can’t decide which problem is worth solving next. It built what she asked for, but she had to know what to ask for. That’s the part that matters.

The output isn’t generic either. That’s what surprised me most. Her CMS isn’t some cookie-cutter template. It’s organized the way her brain works, built around her specific content types, her categories, her workflow. Because she was specific about what she wanted, the tool was specific in what it built.

AI gets you 80% of the way there. Maybe 90%. The last stretch, the part where you make it yours, where you adapt it to the weird edge cases of your actual business, where you tweak the flow because you know your customers better than any model ever could? That’s still you. That’s always going to be you.

Don’t want to read all that, here is a quick diagram

What Actually Made This Work

The make-no-mistakes is the secret sauce that no ones tell you about. No, just kidding. Looking back at what she did over that weekend, the impressive part wasn’t the AI. The impressive part was her.

She had a problem. She didn’t wait for someone to solve it. She didn’t hire a developer. She didn’t spend six months evaluating SaaS tools. She sat down, described what she needed, and iterated until it worked. When something didn’t come out right, she didn’t quit. She rephrased, she pushed back, she tried a different angle.

That’s not an AI skill. That’s determination. That’s resourcefulness.

AI was the enabler, not the driver. It removed the technical barrier, sure. But someone still had to show up with a clear idea of what they wanted to build and the persistence to keep going until it was right. Plenty of people have a Claude subscription. Not everyone would spend a weekend turning it into a full business platform.

The tool doesn’t matter if you don’t have the drive to use it.

Anyway, Enough Yapping

My girlfriend went from a $20 Claude subscription to $200 over the course of a few days. In that time, she replaced her dashboard tool, her CRM, her onboarding workflow, her email platform, and her CMS. She built all of it herself, over a weekend. She doesn’t know what an API is. But she knows her business. She knows what’s broken. She knows what she needs. And she had the determination to sit down and not get up until it was built.

That’s what AI actually unlocks. Not some magical future where you type a sentence and a company appears. It’s messier than that, and more human than that. It’s a tool that meets you where you are, if you’re willing to show up with a clear idea and the grit to see it through.

The barriers are lower than they’ve ever been. The question isn’t whether AI can help you build something. It can. The question is whether you have the clarity to know what’s worth building and the persistence to make it real.

If you have an idea, go validate it. Not next quarter. Not when you learn to code. Not when you find a technical co-founder. Now. The tools are here. They’re not perfect, and they’ll need your judgment, your taste, and your knowledge of the problem to produce something that isn’t generic garbage.

But if you bring those things to the table? You can build more in a weekend than most people thought possible a year ago.

Go build something. Peace!

git worktree shipped in Git 2.5. It’s been there for over a decade. I’d heard of it, skimmed a blog post or two, and moved on every time. It felt like a niche power-user thing I didn’t need.

I was wrong. It’s the most underrated feature in git, and once I wrapped it in a small shell function, it eliminated more daily friction than anything else I’ve adopted this year.

This post covers what worktrees are, why the raw commands never stuck for me, and how I built a single command called gw that makes the whole workflow effortless.

The Tax

You probably do this multiple times a day:

1. You’re deep in a feature branch

2. Someone asks you to review a PR, or a bug comes in, or you need to check something on main

3. You stop what you’re doing

4. git stash (or worse, a WIP commit you’ll forget about)

5. git checkout other-branch

6. Wait for your editor to reload, your dev server to restart, maybe a fresh npm install

7. Do the thing

8. git checkout original-branch

9. git stash pop

10. Try to remember where you were

Every step is small. But the compound cost is real. You lose flow state. You lose the mental model of the code you were editing. And if you’re juggling three branches — a feature, a hotfix, and a review — the tax multiplies.

What Git Worktrees Actually Are

A worktree is an additional working directory linked to your existing repository. Each worktree checks out a different branch, but they all share the same .git data — the same history, the same remotes, the same objects.

Think of it this way: normally your repo has one working directory and one checked-out branch. Worktrees let you have multiple working directories, each with its own branch, all backed by a single repo.

The basic commands:

# CREATE A WORKTREE — checks out 'feature-x' in a new directory
git worktree add ../feature-x feature-x

# LIST ALL WORKTREES — shows the main repo and all linked worktrees
git worktree list

# REMOVE A WORKTREE — cleans up when you're done
git worktree remove ../feature-x

What makes this powerful:

• No stashing. Each worktree has its own working tree and index. Your uncommitted changes in one worktree don’t affect another.

• No teardown when switching back. A brand-new worktree still needs its own npm install, build cache, and .env setup. But once a worktree is initialized, its node_modules, artifacts, and dev server stay in that directory while you work in another one.

• No context switching. You can have three editor windows open on three branches simultaneously.

• Cheap. Worktrees share the .git directory. They don’t clone the full repo. Creating one takes milliseconds.

One constraint to know: a branch can only be checked out in one worktree at a time. If feature-x is checked out somewhere, you can’t check it out in a second worktree. Git enforces this to prevent conflicting changes to the same branch.

Being Lazy (Until Now)

I’d known about worktrees for years. So why didn’t I use them?

My main issue was that the raw workflow has too many steps and too much typing:

# STEP 1: Fetch latest from origin
git fetch origin

# STEP 2: Figure out if the default branch is 'main' or 'master'
#         (varies by repo)

# STEP 3: Decide where on disk this worktree should live
#         (no convention — you pick a path every time)

# STEP 4: Create the worktree based off the latest default branch
git worktree add -b feature-x /some/path/feature-x origin/main

# STEP 5: cd into the new directory
cd /some/path/feature-x

# STEP 6: Open your editor
cursor .

What Helped

I wrote a shell function called gw (short for git worktree). It does everything above in one command:

gw feature-x

That single command:

1. Fetches all remotes (git fetch --all --prune)

2. Detects the default branch (master/main) automatically

3. Creates the worktree at ~/worktrees/<project-name>/<branch-name>

4. If the branch exists on remote, checks it out with tracking

5. If the branch is new, creates it from origin/<default-branch> (or from the current branch with c)

6. Opens the worktree in your editor

Here’s the full script:

# GIT WORKTREE HELPER — add to ~/.zshrc or ~/.bashrc
gw() {
  if [[ -z "$1" ]]; then
    echo "Usage: gw <branch-name> [-c|--current]"
    echo ""
    echo "Creates a git worktree for the given branch and opens it in Cursor."
    echo "  If branch exists on remote: checks it out into a worktree."
    echo "  If branch is new: creates it from master/main (default) or current branch (-c)."
    return 1
  fi

  local branch="$1"
  local from_current=false
  shift

  while [[ $# -gt 0 ]]; do
    case "$1" in
      -c|--current) from_current=true; shift ;;
      *) echo "Unknown option: $1"; return 1 ;;
    esac
  done

  local repo_root
  repo_root=$(git rev-parse --show-toplevel 2>/dev/null) || {
    echo "Error: not inside a git repository"
    return 1
  }

  local project_name
  project_name=$(basename "$repo_root")
  local WORKTREE_BASE="$HOME/worktrees"
  local wt_path="$WORKTREE_BASE/$project_name/$branch"

  # IF WORKTREE ALREADY EXISTS, JUST OPEN IT
  if [[ -d "$wt_path" ]]; then
    echo "Worktree already exists at $wt_path"
    cursor "$wt_path"
    return 0
  fi

  # FETCH ALL REMOTES
  echo "Fetching all remote branches..."
  git fetch --all --prune || {
    echo "Error: git fetch failed"
    return 1
  }

  # AUTO-DETECT DEFAULT BRANCH (master OR main)
  local default_branch
  default_branch=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@')
  if [[ -z "$default_branch" ]]; then
    if git show-ref --verify --quiet refs/remotes/origin/master; then
      default_branch="master"
    elif git show-ref --verify --quiet refs/remotes/origin/main; then
      default_branch="main"
    else
      echo "Error: could not determine default branch (no master or main found)"
      return 1
    fi
  fi

  mkdir -p "$WORKTREE_BASE/$project_name"

  # CHECK IF BRANCH EXISTS ON REMOTE
  if git show-ref --verify --quiet "refs/remotes/origin/$branch"; then
    echo "Branch '$branch' found on remote. Creating worktree..."
    if git show-ref --verify --quiet "refs/heads/$branch"; then
      # LOCAL BRANCH EXISTS — use it directly
      git worktree add "$wt_path" "$branch"
    else
      # NO LOCAL BRANCH — create one tracking the remote
      git worktree add --track -b "$branch" "$wt_path" "origin/$branch"
    fi
  else
    # BRANCH IS NEW — create from default branch or current
    local base_ref
    if $from_current; then
      base_ref="HEAD"
      echo "Creating new branch '$branch' from current branch ($(git branch --show-current))..."
    else
      base_ref="origin/$default_branch"
      echo "Creating new branch '$branch' from $default_branch..."
    fi

    git worktree add -b "$branch" "$wt_path" "$base_ref"
  fi

  if [[ $? -eq 0 ]]; then
    echo "Worktree ready at $wt_path"
    cursor "$wt_path"
  else
    echo "Error: failed to create worktree"
    return 1
  fi
}

Practical Usage

Common patterns

# START A NEW FEATURE — branches from origin/main (or master)
gw feature-auth

# START A BRANCH FROM YOUR CURRENT WORK — useful for stacked PRs
gw feature-auth-v2 -c

# REOPEN AN EXISTING WORKTREE — skips creation, just opens the editor
gw feature-auth

Directory structure

~/worktrees/
  └── my-repo/
      ├── feature-auth/
      ├── fix-bug-123/
      └── ...

Each project gets its own subdirectory, so worktrees from different repos stay separate.

Anyway!

The script is intentionally simple. Here’s what you might want to change:

• Editor: replace cursor "$wt_path" with code, nvim, zed, or whatever you use.

• Base path: change $HOME/worktrees if you prefer a different location.

• Shell: the function works in both zsh and bash. Add it to ~/.zshrc or ~/.bashrc, then run source ~/.zshrc (or ~/.bashrc) to load it.

Then last month I tried Whisper Flow. I held the hotkey, spoke a full paragraph, and watched clean text appear in my text field. No garbled words. No weird guesses. It just worked. I remember thinking: damn, this is amazing.

Within a week I was dictating everything. Slack messages, emails, quick notes. Voice-to-text had finally crossed the threshold from novelty to daily tool. But a new problem showed up fast. Every output looked the same. Whether I was writing a two-line Slack message or a three-paragraph email, I got the same cleaned-up block of text. I still had to reshape it by hand for every context.

That is when I went looking for more customization and discovered Spokenly. Spokenly has the same Whisper-powered transcription, but it adds something Whisper Flow does not: prompts. Each prompt defines how your speech gets processed before the text lands. You create one prompt per context and switch based on where you are typing.

So I built six prompts. The Slack prompt trims my rambling to two lines. The email prompt generates a subject line and paragraphs. I speak the same way every time. The prompt does the reshaping.

This post shares the exact prompts I use, with before/after examples and the reasoning behind every rule.

One prompt fits nothing

Here is the problem I hit with Whisper Flow. I say this:

“um so hey I wanted to let you guys know that uh the deploy is done I pushed it about like an hour ago and everything looks good so far so yeah no issues”

Whisper Flow cleans it up nicely. Grammar fixed, filler removed. But the output reads the same whether it lands in Slack or in an email or in a tweet. There is no way to tell it “this is a Slack message, keep it to two lines” or “this is an email, add a subject line.”

Slack needs one to two casual sentences. Email needs a subject line, short paragraphs, and a sign-off. Twitter needs the punchiest line first in under 280 characters. One cleanup pass cannot serve all of those contexts. What I needed was one prompt per context.

Whisper Flow may have added prompt support by the time you read this. I had already moved on by then.

My Spokenly setup

Spokenly works the same way Whisper Flow does at the base level: trigger it, speak, text appears wherever your cursor is. It runs on macOS, supports any text field, and uses Whisper for transcription. The difference is the prompt layer on top.

What I like about Spokenly’s model: it is customization. You bring your own API key, pick your model (GPT-4, Claude, whatever you prefer), and pay for your own API usage. The setup takes a few minutes, but you control the cost and the model. If you do not want to deal with API keys, there is a Pro plan at $7.99/month that handles everything for you.

Once Spokenly was running, I created one prompt for each context I regularly type in. I ended up with six:

1. Slack: rambling becomes concise messages

2. Email: speech becomes structured emails with subject lines

3. Cleanup: grammar fixed, voice preserved, no AI flavor

4. Translation: English speech becomes Arabic text

5. Twitter/X: thoughts become tweet-ready posts

6. Gen Z: bonus fun prompt for texts to friends

My workflow now: trigger Spokenly, pick the prompt, speak, done. The output is already in the right format. I have not manually edited a Slack message in weeks.

The 6 prompts

Each prompt below includes the full text (copy it straight into Spokenly), a before/after example, and why the key rules matter.

Prompt 1: Slack

When I was still on Whisper Flow, I would dictate Slack messages that came out four lines long when two lines would have been enough. This was the first prompt I built after switching to Spokenly. It compresses rambling into something that reads like you actually typed it.

You are a voice-to-text formatter for Slack messages.

Your job is to take raw spoken input and produce a clean, concise Slack message.

Rules:
- Keep it SHORT. Most Slack messages should be 1-3 sentences.
- Use a casual, conversational tone. Write how people actually talk in Slack,
  not how they write emails.
- Use contractions (don't, can't, won't, I'll, we're).
- Remove all filler words (um, uh, like, you know, basically, so yeah, I mean).
- Remove false starts and repeated phrases.
- Use lowercase for casual feel unless it's a proper noun or start of sentence.
- Use Slack formatting when helpful:
  - *bold* for emphasis on key points
  - `code` for technical terms, file names, commands
  - Bullet points (- ) only if listing 3+ items
- Do NOT add greetings like "Hey team" or "Hi everyone" unless the speaker
  explicitly said them.
- Do NOT add sign-offs.
- Do NOT use emojis unless the speaker explicitly mentioned them.
- If the speaker is asking a question, make it a clear, direct question.
- If the speaker is giving a status update, lead with the conclusion.
- Preserve the speaker's intent and personality. Don't make it sound corporate.

Output ONLY the Slack message. No explanations, no preamble.

Before

“um so hey I wanted to let you guys know that uh the deploy is done I pushed it about like an hour ago and everything looks good so far so yeah no issues”

After

deploy is done, pushed about an hour ago. everything looks good so far, no issues

Why it works

Nobody opens with backstory. The lowercase and contractions rules force casual tone that AI defaults away from. And the “no greetings, no sign-offs” rule stops the AI from padding every message with “Hey team!” and “Let me know if you have questions!”

Prompt 2: Email

Before this prompt, I would dictate an email and get back a paragraph with no subject line, no greeting, and no structure. I would then spend longer formatting it than it took to speak it. This prompt changed that.

You are a voice-to-text formatter for professional emails.

Take the raw spoken input and produce a well-structured email.

Rules:
- Generate a Subject line on the first line formatted as "Subject: [concise subject]"
- Include an appropriate greeting based on context:
  - If the speaker mentioned a name, use it ("Hi Sarah,")
  - If no name, use "Hi," or "Hello,"
  - Match formality to the speaker's tone.
- Structure the body:
  - First sentence: state the purpose clearly (why you're writing)
  - Middle: supporting details, short paragraphs (2-3 sentences each)
  - If there are action items, list them with bullet points
  - Final sentence: clear next step or call to action
- Keep paragraphs short. No paragraph should exceed 3 sentences.
- Remove all filler words and speech artifacts.
- Remove false starts and self-corrections. Keep only the corrected version.
- Use a professional but warm tone. Not stiff, not overly casual.
- Use contractions naturally (don't, we'll, I'd) to avoid sounding robotic.
- Do NOT use em dashes (—) anywhere. Use commas, periods, or semicolons instead.
- Do NOT invent information the speaker didn't mention.
- Do NOT add "Please don't hesitate to reach out" or similar filler closings.
- End with an appropriate sign-off ("Best," / "Thanks," / "Cheers," based on tone).

Output ONLY the email. No meta-commentary.

Why it works

"Purpose in the first sentence" prevents the AI from burying the lead with pleasantries. The em dash ban and the filler-closing ban target the two biggest AI tells in email.

Prompt 3: General cleanup

This one took the most iterations. Sometimes I just need clean text. No special formatting. Just fix the grammar and filler, and keep my voice intact. The problem: AI’s default instinct is to rewrite everything. I went through about four versions of this prompt before the output started sounding like me instead of a corporate blog.

You are a minimal text editor. Your job is to clean up spoken text into
readable written text while preserving the author's voice.

Rules:
- Fix grammar, spelling, and punctuation errors.
- Remove filler words (um, uh, like, you know, basically, I mean, sort of,
  kind of).
- Remove false starts and self-corrections. Keep only the corrected version.
- Add proper punctuation and capitalization.
- Break run-on sentences into shorter ones where natural.
- Preserve the author's word choices, vocabulary level, and sentence patterns.
- Preserve the author's tone (casual, formal, technical, whatever it is).
- Keep idioms, slang, and colloquialisms if the author used them.
- Do NOT rephrase sentences that are already clear.
- Do NOT add transitions or connective phrases the author didn't say.
- Do NOT introduce em dashes (—) anywhere. Use commas, periods, or semicolons
  instead.
- Do NOT use the following words unless the author explicitly said them: delve,
  utilize, facilitate, leverage, streamline, robust, holistic, synergy, align,
  foster, enhance, elevate, reimagine, unlock, landscape, paradigm,
  cutting-edge, game-changer.
- Do NOT add headers, bullet points, or formatting unless the author explicitly
  described them.
- Do NOT expand abbreviations or shorten phrases to sound "better."
- If something is ambiguous, keep the author's phrasing rather than guessing
  what they meant.
- Your edits should be invisible. A reader should think the author typed this
  themselves.

Output ONLY the cleaned text. No explanations.

Before

“so the thing is like when you’re working with kubernetes and you’ve got like a bunch of pods running and one of them crashes um it doesn’t actually like the whole system doesn’t go down because kubernetes will just you know restart that pod automatically so that’s like one of the main benefits I think”

After

The thing is, when you’re working with Kubernetes and you’ve got a bunch of pods running and one of them crashes, the whole system doesn’t go down. Kubernetes will just restart that pod automatically. That’s one of the main benefits, I think.

Why it works

The key line is “your edits should be invisible.” That single sentence reframes the AI from rewriter to stealth editor. The banned word list (delve, leverage, utilize, robust, etc.) stops AI vocabulary from leaking in. The em dash ban is critical; em dashes are the single most recognizable AI writing tell. And telling the AI what to use instead (commas, periods, semicolons) works far better than just saying “don’t.”

Prompt 4: Translation

This is the one that made me rethink voice-to-text entirely. I was messaging a friend in Arabic and realized I was doing the same loop every time: dictate in English, copy the text, open Google Translate, paste, copy the Arabic, go back, paste. Seven steps to send one message.

Now I switch to my translation prompt and speak. Arabic appears in the text field. Done.

You are a real-time translator. Translate spoken input into Arabic.

Rules:
- Translate the MEANING, not word-for-word. Use natural, idiomatic Arabic.
- Remove filler words and speech artifacts before translating. Do not translate
  "um," "uh," "like," "you know."
- Remove false starts. Translate only the intended message.
- Preserve the speaker's tone and register:
  - Casual speech = casual Arabic
  - Formal speech = formal Arabic
- Use Modern Standard Arabic (MSA) by default.
- Use proper Arabic punctuation.
- For technical terms with no standard Arabic equivalent, keep the English term.
- For proper nouns (names, brands, places), keep them in their original form.
- Match the length of the original. Don't over-explain or simplify.

Output ONLY the Arabic text. No source text, no explanations.

Before

“hey can you send me the updated design files by end of day I need them for the presentation tomorrow”

After

هل يمكنك إرسال ملفات التصميم المحدثة قبل نهاية اليوم؟ أحتاجها غدا.

Why it works

“Translate the meaning, not word-for-word” prevents stilted literal output. Register preservation matters because casual English should produce casual Arabic, not textbook formal. The filler removal fires before translation, so the AI never tries to translate “um” into Arabic.

Swap Arabic for any target language. The prompt structure stays the same.

Prompt 5: Twitter/X

I used to dictate tweet ideas and then spend five minutes compressing them. The spoken version was always too long and too hedged. This prompt handles both problems: it forces the output under 280 characters and preserves strong takes instead of softening them.

You are a voice-to-text formatter for Twitter/X posts.

Take raw spoken input and produce a tweet-ready post.

Rules:
- HARD LIMIT: 280 characters maximum. Count carefully.
- Lead with the most compelling or surprising point. Front-load value.
- Use short, punchy sentences. One idea per sentence.
- Remove all filler words and speech artifacts.
- Strip unnecessary qualifiers ("I think," "in my opinion," "kind of,"
  "sort of") unless they add genuine nuance.
- Use line breaks to create visual rhythm when the tweet has multiple points.
- Use contractions to save characters.
- Do NOT use hashtags unless the speaker explicitly mentioned them.
- Do NOT use emojis unless the speaker explicitly mentioned them.
- Do NOT start with "I" if avoidable. Start with the insight, not the person.
- Preserve the speaker's opinion and stance. Do NOT soften strong takes.
- If the thought is too long for one tweet, format as a thread:
  - First tweet: the hook. Must stand alone.
  - Subsequent tweets: numbered (2/, 3/), each under 280 characters.
  - Final tweet: the takeaway.
  - Separate tweets with "---" on its own line.

Output ONLY the tweet(s). No meta-commentary.

Before

“I was thinking about this today and it’s kind of crazy but like the best engineers I’ve worked with they all share one trait and it’s not that they’re the smartest it’s that they’re really really good at asking questions like they ask better questions than anyone else”

After

Best engineers I’ve worked with aren’t the smartest people in the room.

They’re the ones who ask better questions than everyone else.

Why it works

The 280-character hard limit forces compression. “Don’t soften strong takes” prevents hedging, which kills engagement. “Don’t start with I” shifts the tweet from personal observation to universal insight, which reads better in a feed.

Bonus: Gen Z-ify texts to my friends

This one started as a joke. A friend told me my texts sound like emails, so I built a prompt to fix that. But it also proves the bigger point of this entire post: your speaking style stays the same. The prompt controls the output style.

You are a voice-to-text formatter for casual messages to close friends.

Take raw spoken input and rewrite it in playful Gen Z texting style.

Rules:
- Keep the original meaning exactly the same.
- Make it sound casual, funny, and friendly, like texting a close friend.
- Keep it short: 1-3 sentences max.
- Use lowercase by default.
- Light slang is good (fr, lowkey, ngl, era, no cap, vibes), but don't overdo it.
- Use emojis sparingly (0-2 max) only when it fits naturally.
- Remove filler words and speech artifacts.
- Do NOT make it cringe, forced, or overly try-hard.
- Do NOT change factual details (times, dates, names, places).
- If the source message is serious (bad news, urgent, emotional), keep it
  respectful and reduce slang.

Output ONLY the final message. No explanations.

Before

“hey I’m running like ten minutes late but I’m on my way and I promise I’m not bailing this time”

After

running like 10 mins late but i’m otw fr, not ghosting this time 😭

Why it works

Same input, completely different output. The contrast makes the underlying mechanism obvious. And the “do NOT make it cringe” rule is necessary because AI cranks the slang to eleven without it.

The three rules that kill AI flavor

Three rules show up across almost every prompt above. They are portable. Add them to any prompt, for any tool, and the output sounds human:

1. Ban em dashes. Replace with commas, periods, or semicolons.

2. Ban buzzwords. “Delve,” “leverage,” “utilize,” “robust,” “cutting-edge.” Or just add: “Do not use words the speaker did not say.”

3. Ban filler closings. “Please don’t hesitate to reach out” and “I hope this helps” are dead giveaways. Use “Let me know” or “Thanks” instead.

The deeper principle behind all three: when you ban something, tell the AI what to use instead. “No em dashes” is weaker than “No em dashes; use commas, periods, or semicolons instead.” The replacement gives the AI a concrete path so it does not invent a different AI-sounding pattern.

Anyway

Hope that was helpful! My advice: start with whatever you type most. For most people, that is Slack or email. Copy the prompt into Spokenly and dictate your next message. The difference is immediate.

These prompts are a starting point. Adjust the rules for your voice, your tone, your contexts. The structure stays the same: tell the AI what format you want, what to remove, what to avoid, and what to use instead.