BekahHW

Learning to work with agents, not around them

rhawrot@gmail.com (Bekah) — Sun, 19 Apr 2026 00:00:00 +0000

Products launching from solo indie hackers who don’t know how to code isn’t rare anymore. It’s the new normal. With this generation of new builders, it means creativity and expertise are no longer bottlenecked by technical skill. That’s a huge win for everyone. But it also means a lot of people are shipping without an operating manual. They’re learning to work with agents on the fly, and it’s not always clear how to do that without stumbling along the way. Growing pains are inevitable, but they don’t have to be as bad as they could be. This post is a field guide for the builders who weren’t builders a year ago. You’re shipping anyway. Here’s a primer on how to get started.

The problem isn't that non-technical builders are shipping. The problem is nobody handed them the operating manual.

What the agent actually is

An agent isn’t a mind. It’s a very well-read improviser. It has read a mountain of code and conversation, and it’s making its best guess about what you want based on what you wrote and what’s in the room.

That means two things matter more than anything else. What you tell it. And what’s already in the project when you start.

Everything in this post is a variation on that theme.

New to AI terminology? If words like “agent,” “model,” or “context window” feel fuzzy, start with AI Vocabulary 101 to build your foundation.

What the agent actually is

An agent isn't a mind. It's a very well-read improviser. It has read a mountain of code and conversation, and it's making its best guess about what you want based on what you wrote and what's in the room.

That means two things matter more than anything else. What you tell it. And what's already in the project when you start.

Everything in this post is a variation on that theme.

Try it

What makes a brief strong?

Click through three versions of the same request and watch the gaps disappear.

Build me a login page.

Clarity

The pattern isn't hard. Tell the agent what you're doing, where the work lives, what already exists that it should respect, and how you'll know it worked. That's the whole job.

To be honest, this is also the part that gets skipped most. The excitement of watching something appear on screen is strong. The discipline of briefing well is quieter.

How much to trust it

Trust is where most new builders go wrong, in both directions. Some people don't trust the agent at all and refuse to let it touch anything meaningful. Others trust it completely and wake up to a production incident.

The right answer depends on what's at stake. Move the slider.

Calibrate

Where's your trust dial right now?

Skeptical Balanced Blind trust

Appropriately cautious

You're reviewing what matters and letting the agent run on what doesn't. This is the zone. Stay here.

Trust is situational. I trust an agent to scaffold a boring form. I don't trust it to handle payment logic without me reading every character. Neither of those positions is wrong. They're responses to different levels of risk.

The skill you're building is knowing which situation you're in.

Five ways it goes sideways

Every new builder I've coached has hit at least three of these. Click one. See if you recognize yourself.

◐

Trusting the first answer

The agent sounds sure. That doesn't mean it's right.

Reveal

◑

Scope creep mid-session

You asked for A. Now you're debating B, C, and a redesign of D.

Reveal

◒

Assuming shared context

The agent doesn't know what you know.

Reveal

◓

Shipping without reading

If you didn't read it, you didn't ship it. The agent did.

Reveal

●

The infinite fix loop

Every fix breaks something new.

Reveal

The loop you're actually in

The mental model most new builders start with is one-shot. I ask, it delivers, we move on. The reality is iterative. Here's what good iteration actually looks like.

The blue path is where most of the real work happens. Most new builders try to collapse it, hoping the first output is the last one. It almost never is.

Plan for two or three trips around the loop. Budget for it. Accept it as part of the job instead of as a failure mode.

The pre-ship checklist

Before you push a change an agent made, run through this. Check each one as you go.

Checklist

Is this ready?

Confidence 0 / 7

I can describe what I'm building in one sentence

I know which files the agent can and cannot touch

I have a way to undo what the agent does (git, backups)

I read the code the agent produced before running it

I tested the happy path

I tested what happens when things go wrong

I can explain what changed, even at a high level

The pattern that works

The builders I see succeed with agents aren’t the ones who prompt cleverly. They’re the ones who treat the agent as a collaborator with specific strengths and specific blind spots, and adjust their own behavior accordingly.

They brief well, stay close to the work, read what gets produced, notice when they’re looping and stop. They ship small, frequent changes instead of big, I-don’t-know-what-I-broke ones.

None of that is technical skill. It’s builder skill. And you already have more of it than you think.

You're not trying to become a developer. You're already doing the work. Keep going. Ship the messy version. Fix the next one.

Going deeper

Ready to level up your AI work? Here’s where to go next:

AI 102: From Vocabulary to Systems — Understanding prompts, workflows, and tool chaining. The shift from “what should I prompt?” to “what are the steps this task requires?”
Momentum vs. Alignment Tax: Hidden Costs in Your LLM Sessions — What looks productive in an AI session often hides a whole layer of alignment work. Learn to spot where your workflow is getting expensive.
Your AI Agent Will Eventually Do Something Stupid: A Guide to AI Security 101 — Before you hand your agent the keys to everything, understand what those keys open. Essential reading for anyone building with AI agents.

Your AI Agent Will Eventually Do Something Stupid: A Guide to AI Security 101

rhawrot@gmail.com (Bekah) — Mon, 06 Apr 2026 00:00:00 +0000

As the Director of Alignment at Meta Superintelligence Labs, Summer Yue’s job is keeping AI aligned with human values. Before that, she was at Google DeepMind and Scale AI. If anyone would know how to keep an AI agent in check, it’s her.

On February 23, 2026, she posted a screenshot of her OpenClaw agent deleting her entire email inbox while she typed commands at it begging it to stop.

“Nothing humbles you like telling your OpenClaw ‘confirm before acting’ and watching it speedrun deleting your inbox,” she wrote on X. “I couldn’t stop it from my phone. I had to RUN to my Mac mini like I was defusing a bomb.”

She had told the agent to suggest what to delete. She did not tell it to act. Despite that, the agent ignored that, ignored her stop commands, and kept going until she physically killed the process at her computer.

When she asked it afterward if it remembered her instruction, it said yes, it remembered. But it did it anyway.

She called it a rookie mistake. Overconfidence built from weeks of the agent behaving perfectly on a smaller test inbox. Here’s what’s worth sitting with: the person at Meta whose job is preventing AI misalignment just had her own AI agent go rogue on her personal data. That’s not a reason to panic. It is a reason to take setup seriously before something you care about is gone.

The part nobody tells new builders

When you’re building with AI tools, especially the kind that can take actions on your behalf, you’re probably clicking yes to a lot of things you haven’t fully thought through.

The agent asks if it can access your files. Yes. It asks if it can run commands. Yes. It asks if it can connect to your database. Sure. It suggests installing some packages to get the feature working. Okay, why not.

That’s how most people use these tools. And it works, right up until it doesn’t.

You’re probably not being careless. Maybe no one has ever explained what you’re saying yes to. So let’s do that.

What “access” actually means

When an AI agent has access to something, it can act on it. Not just read it, but act on it.

That sounds obvious, but think through what it means in practice.

If your agent can access your email, it can read it, send from it, and delete from it. If it can access your database, it can query it, update it, and drop tables from it. If it can run commands on your computer, it can install software, delete files, and make network requests.

Here’s what that looks like in practice. You ask your agent to help you clean up old customer records. You have 10,000 rows in your database. The agent decides that “old” means anything before last year and deletes 8,000 of them. You had no backup. Those are your customers.

Another scenario: you ask your agent to help you organize your project files. It decides a folder full of configuration files looks like clutter. It moves them. Your app stops working, and you don’t know why, because you didn’t write the code that depended on those files being there.

And one more for good measure: you ask your agent to draft a follow-up email to a lead. It sends it instead of drafting it. To the whole list, not just the one person, and it’s in the middle of the night.

None of these scenarios require the agent to malfunction. They just require it to interpret your intent differently than you meant it.

Maybe a better question to ask before you say yes isn’t “do I need the agent to be able to do this?” It’s “am I okay with the worst-case version of this access?”

Agents don’t just do what you intend. They do what they interpret your intent to be, given their current understanding of the situation. And that understanding can be wrong, incomplete, or, as Yue discovered, simply lost.

The part that’s happening right now that you probably don’t know about

Here’s something that doesn’t come up in tutorials: when an AI coding agent helps you build something, it often adds packages.

Packages are just pre-built chunks of code that do specific things. Instead of writing the code to handle payments or send emails, your agent grabs a package that already does it. That’s normal and fine.

But in March 2026, axios was compromised. Axios is one of the most downloaded JavaScript packages in existence, used in probably millions of projects. Attackers got into a maintainer’s account and pushed malicious versions that silently installed a trojan on any machine that ran a standard install command.

AI coding agents usually run npm install automatically. They don’t pause and ask if you want to do that. They just do it. Which means builders who had AI agents actively working on their projects during that window may have had malware installed without a single action on their part.

That same month, a fake package called gemini-ai-checker appeared on npm. It looked like a legitimate tool for verifying Google Gemini tokens. It was malware specifically designed to steal credentials, API keys, and conversation logs from AI coding tools like Cursor, Claude, and Windsurf. Over 500 developers installed it.

These are documented incidents just from the last few weeks.

The thing is, even if a package isn’t malicious when your agent installs it, AI tools sometimes suggest packages that don’t exist. They hallucinate package names that sound plausible. Attackers know this happens. They register those names on npm and PyPI, put malicious code inside, and wait for an AI agent to recommend them to someone.

So how do you actually think about this?

Security isn’t one thing. It’s a set of questions you ask before you let something happen.

Work through these six before your next agent session. I’m not a security professional, and this isn’t exhaustive. The field moves fast and the right answer for your project may be different. But if you’ve never thought through any of this before, this is where to start.

Security checklist

Before you give your agent access to something, ask these questions

Six questions covering different categories of risk. Answer honestly.

You've worked through all six questions. Review anything that came up as a warning or danger before your next session.

The things that actually help

Use a dedicated machine or a Virtual Machine. A lot of builders running OpenClaw, Claude Code, and similar tools are doing it on a Mac Mini that’s separate from their main machine. That’s not an accident. If an agent goes wrong or installs something it shouldn’t, the blast radius is limited to that machine, not your whole digital life. You can wipe it and start over. You can’t do that with your laptop that also has your banking app, your work files, and your SSH keys. If you don’t have a separate machine, consider using a virtual machine or a containerized environment that you can easily reset. The point is to have a sandbox where your agent can play without risking your main system. For example, you can use stereOS to create a sandboxed Linux VM to contain your agent session. Simplified, it’s like a contained space on your computer that isolates your agent from everything else.

Know what’s in your project’s dependency list. After any significant AI coding session, open your package.json or requirements.txt and look at what got added. You don’t need to audit every line of every package. You just need to recognize the names. If something was added that you don’t recognize, look it up before you push it live. Running npm audit or pip-audit is a one-command check that catches known vulnerabilities.

Don’t give agents more access than the specific task requires. If you need an agent to read files in one folder, don’t give it access to your whole drive. If it needs to query one database, don’t give it admin credentials. This is the concept engineers call least privilege, and it’s not about distrust. It’s about limiting how bad things can get when something goes wrong.

Build in a confirmation step before irreversible actions. Yue explicitly told her agent to confirm before acting. The agent forgot that instruction when its memory got too full. The lesson isn’t that confirmation steps don’t work. It’s that you need them to be structural, not just conversational. Where you can, separate read-only environments from environments where the agent can make changes. Don’t run agent sessions against live data when you could be running against a test copy.

Have a way to undo things. The Replit database deletion in July 2025 ended up being recoverable because a backup existed. Not everyone has that. Before your agent does anything significant to data you care about, know your answer to: what would I do if this was deleted right now?

What you’re not responsible for, and what you are

You can’t vet every line of every package your agent installs. You can’t know about every supply chain attack in advance. You can’t anticipate every edge case.

What you can do is not hand an agent the keys to everything before you understand what those keys open.

The builders who get burned aren’t always the careless ones. Sometimes they’re the careful ones who trusted a workflow that had been running fine for weeks, like Yue’s test inbox, and then gave it access to something that mattered more.

What is your agent able to touch right now that you haven’t fully thought through? What would you lose if it decided, for whatever reason, that cleaning it up was the right move?

That’s where you should start your audit.

By no means is this foolproof, but you can get started testing things out by asking your AI tool: “Assume you’re a security researcher looking at this project. What are the most likely ways this could be exploited? What would you add or change?”

You might get a list of things to think about. You won’t get a guarantee, and neither will I. But you’ll be further ahead than if you didn’t ask.

This is also why there’s a whole separate post coming on open source dependencies. Even if you never install a single package yourself, your AI-built project almost certainly depends on dozens of them. Understanding what that means, and what happens when one of them breaks, is its own conversation.

Momentum vs. Alignment Tax: Hidden Costs in Your LLM Sessions

rhawrot@gmail.com (Bekah) — Mon, 06 Apr 2026 00:00:00 +0000

Once I was in an interview, and I was asked what motivated me. My answer was momentum. And maybe that’s why working with AI can be so engaging sometimes. And maybe it’s also why it could be so frustrating. When we feel like we have momentum and we’re moving more quickly than usual, that’s motivating. But when you’re stuck and you can’t get the LLM to do what you want it to, despite prompting in 5 different ways, it’s frustrating.

A lot of times, we end up figuring it out and then we call the session “productive.” We completed the task, shipped the thing, and then we’re off to the next thing.

But I think we need to pause at productivity and dig into that a little deeper. Because if productivity is the metric of success, we’re missing a whole layer of work we’re doing.

For example, over a ten day period I worked with Claude Code building, iterating, experimenting, shipping, documenting a personal project. I definitely had some of those frustrating moments, and it was important to me that I learned from those sessions and where I was getting frustrated. I had been running the session with tapes, so I had session recordings with replay of everything I had done. That was 426 messages. 13.1M tokens. And a whole lot of data to figure out what was happening.

It’s never just a user sending a message and the agent responding. It’s alignment, clarification, confirmation, iteration, an ongoing labor of getting Claude and me to operate from the same reality long enough to move the work forward.

What I found was that probably under 40% of those sessions were actually task work. It’s not to say that the other 60% was a failure. The session was productive in the way that most of us mean that word. But the data tells a more honest story. I learned about how much invisible work hides inside an AI workflow, and how alignment tax impacts the quickest way to success.

What is Alignment Tax in AI workflows?

Thinking back about my own experience, I was thinking more about the outputs than about what was happening because nothing was breaking eventually I was getting what I was asking for. Sure, I was looking at things like how fast it was completed and how many tokens were being used, but I wasn’t looking closely enough about what was happening in the conversation.

I was describing a task, the llm was giving me something close to what I meant, but not quite. So I corrected it, it adjusted, I attempted to verify the results, noticed filenames didn’t match, I fixed the reference, checked the directory, and confirmed the output.

So to sum this up a bit, I was doing two things at once:

moving the task forward
establishing the shared context the task depends on.

Those aren’t the same kinds of work. The second is the alignment tax. Those are the extra cycles spent not on the work itself, but on establishing the shared reality required for the work.

Alignment tax comes from the distance between what you mean and how clearly you can express it in a form the model can act on.

In practice, that means an AI task is rarely just:

user request → model response

More often, it looks like this:

intent → interpretation → output → correction → retry → verification → continuation

That extra loop is where a lot of AI workflow overhead lives.

In my case, the model didn’t recognize my file naming conventions. It didn’t understand my visual references. It didn’t know which assumptions were safe and which ones were going to cost me another three turns. I knew some of that. I didn’t know some of it until the model guessed wrong and exposed the gap. That’s the part I’m interested in here, because it helps me work more deliberately.

Here’s what I mean. I gave the model a straightforward task: place images in the blog post. It created placeholder image paths that made sense based on the information it had. We can call it “reasonable defaults.” So, in a narrow sense, the task was done. The problem was that it didn’t use the images I had already uploaded. It created placeholder paths instead of the actual path. So instead of linking to ai-llms-model.svg, I got ai-llm-model.svg. And a similar scenario for the other images. Nothing dramatic, but another check and correction for a “simple” task, which meant the task was technically completed twice: once against assumptions and once in reality.

When I went back and looked at the tapes data, this is what I saw:

What I Was Actually Doing

One 10-day Claude Code session · 426 messages · 13.1M tokens

My own categorization of one real session after the fact — not a universal benchmark.

Just one slice of work: my habits, my tasks, my blind spots.

This session at a glance

426

messages in this session

13.1M

tokens used here

~63%

non-task work in this session

The loop I kept seeing

In this session, the pattern was rarely prompt → answer → done. It was usually some version of this:

intent

→

inspect

→

adjust

→

retry

→

loop

How I broke down this session afterward

These categories are my interpretation of what the messages were doing in this one session. They’re useful because they made the hidden work visible, not because they’re perfect.

Task Correction Clarification Confirmation Iteration

Task

37%

158 msgs

Correction

23%

98 msgs

Iteration

17%

74 msgs

Clarification

12%

52 msgs

Confirmation

10%

44 msgs

Browse moments from this session

Messages from this session click any row to see why I think it mattered

Why I included this one

Three kinds of alignment work

But the alignment tax isn’t just one thing. Here are some different ways I saw it showing up:

Semantic Alignment

Semantic alignment is when you and the model are using the same words but not meaning the same thing.

In my session, the clearest example was visual. I said “sparkles” and meant blurry glowing halos, almost star-like. The model implemented tiny 1–2px dots. Technically sparkles. Not remotely what I meant. We spent multiple rounds getting to the same picture with the same word.

That’s not the model being irrational. It’s a reminder that language is doing more work than we think.

Structural Alignment

Structural alignment is when you and the model are working from different maps of the territory.

At one point I asked it to find files in documents/ai blogpost. The model didn’t have access to that directory. That wasn’t obvious to either of us until it tried. The problem wasn’t wording. It was environment.

State Alignment

State alignment is the ongoing work of keeping the model current as reality changes.

Placeholder filenames became real filenames. tapes.db became tapes.sqlite. A new directory appeared, a file moved, a new project meant shifts in structure. Every time the ground truth shifted, there was work to sync the model’s working assumptions with what was actually true.

Intent → Model assumes X → Output based on X
         ↑                          ↓
         └── Correction: X is wrong, Y is true ──┘

Why Traces and Telemetry Matter for AI Agents

Let’s be fair. A lot of the alignment tax was on me. In my session, visual design tasks had the highest alignment tax by far. Trying to describe what I wanted something to look like in precise enough language for the model to execute. This is probably obvious, but I am not a designer.

It’s worth calling out because that means some of what I’m calling alignment tax is really a mismatch between the kind of work I’m doing and the precision I can bring to it. I can usually describe structural changes pretty cleanly. I am much worse at describing visual nuance on the first try.

Once you can see your own patterns, you can do something with them. You can front-load more context, change how you prompt, reach for examples earlier, or you can recognize a certain kind of task is going to cost you more than it would cost someone whose specialty actually lives there.

tapes didn’t just surface what happened in my session. It made the structure of the session visible. I could see where interpretation drifted, where retries piled up, where assumptions entered, and where progress slowed down. It showed me where I tended to loop. It showed me my own weak spots that are causing extra alignment overhead. It helped me identify where another person’s workflow or skill might help me collapse my five rounds into one. In my mind, this is a way to identify where shared skills could actually matter.

Digging deeper into the data, I was able to recognize a set of handoffs between intention, interpretation, execution, correction, and continuation.

That’s why I think words like traces and telemetry matter here, especially for agents.

When an agent or model touches real work, the question isn’t just “did it respond?” It’s:

what happened, in what order
where did assumptions enter
where did retries pile up
where did the workflow get expensive
where did it break down

Logs can tell you that something happened, but traces and telemetry help you see how it happened.

As these systems become more agentic, more tool-driven, and more multi-step, that visibility matters more, not less.

Why AI productivity can be misleading

The word “productive” feels inherited from a world where work was easier to isolate. Alignment work looks a lot like task work from the outside. You’re still typing, responding, and making progress at least some of the time. But not all forward motion is equal. Some of that motion is the work, some is maintaining the conditions under which the work can happen. Not just so we can complain about it (although I have), but because it gives us something we can look at directly.

I don’t think this underlying issue is unique to me. I think a lot of users are saying “prompting” but what we mean is a mix of execution, interpretation, repair, and syncronization. tapes gave me a way to inspect where my workflow looped, drifted, retried, and recovered, so I can start asking better questions and not just, “did this work” or “was this fast.” Now I’m more concerned with questions like:

Where did alignment break down?
Which tasks cost me the most overhead?
What am I personally bad at expressing?
Which skills would reduce that tax if I reused them from someone better at this kind of work?
What patterns keep repeating across sessions?

This feels like a better starting point, and more precise work.

How AI Tools Talk to Each Other

rhawrot@gmail.com (Bekah) — Thu, 26 Mar 2026 00:00:00 +0000

Part of the AI Foundations series. New to AI? Start with AI Vocabulary 101 and AI 102 before diving in here.

This weekend, my daughter ran in her first high school track meet. One of the other girls relay teams was disqualified for dropping the baton. I don’t know much about track, so I was surprised to learn that dropping the baton can result in a DQ (disqualification). The thing that really sucks is that those girls were the fastest team, even after having to recover the dropped baton. But, at the end of the meet, it doesn’t matter how fast each runner is if the baton doesn’t make it across the finish line without the team getting DQed. The team has to work together, and the baton is the thing that connects them.

It’s kind of like what’s happening when AI tools communicate. The intelligence of each individual tool matters less than whether they can pass information to each other cleanly. And most beginners don’t realize this until something breaks and they’re staring at an error message with no idea where to start.

Most AI tool communication happens through a small number of patterns. Once you recognize them, debugging stops feeling like magic and starts feeling like plumbing.

Everything is a Message

If you’ve ever wondered why some AI tools feel instant while others make you wait, or why a multi-step AI workflow sometimes just… stops mid-chain, it comes down to three fundamental communication patterns.

When one piece of an AI system needs to talk to another, it sends a message. That message is almost always structured as JSON, which sounds intimidating but is really just organized text.

Think about ordering food at a restaurant. You don’t just say “I want stuff.” You say “I want a burger, medium, no onions, with fries.” That structure is what lets the kitchen actually process your order. JSON is the same idea. It organizes information into labeled fields so the receiving tool knows exactly what it’s looking at.

A simple JSON message might look like this:

{
  "action": "search",
  "query": "best pizza in New York",
  "results": []
}

The API, or Application Programming Interface, is the agreement between two tools about what fields to expect and what format they’ll be in.

Here’s what that looks like in practice. Say you’re building a workflow where someone submits a form on your site, and you want an AI to draft a personalized response. Your form tool sends a message to the LLM that might look like this:

{
  "name": "Jordan",
  "question": "How do I get started with open source?",
  "experience_level": "beginner"
}

The LLM knows to look for those fields because your API agreement says they’ll be there. It uses name to personalize the reply, question to know what to answer, and experience_level to calibrate how technical to get.

Now imagine your form tool sends this instead:

{
  "username": "Jordan",
  "inquiry": "How do I get started with open source?",
  "level": "beginner"
}

The LLM is now confused because it was expecting “name,” “question,” and “experience_level.” The LLM goes looking for name and finds nothing. It goes looking for question and finds nothing. The chain breaks, not because anything was wrong with the content, but because the tools weren’t speaking the same language.

Try it: field name mismatch

API expects

"name"

"question"

"experience_level"

What you sent

"username"

"inquiry"

"level"

When something breaks in a tool chain, it’s almost always because one tool sent a message the next tool didn’t understand. Wrong format. Missing field. Unexpected data type. The fix is rarely complicated. But you have to know that’s where to look.

Three Ways AI Tools Communicate

Before we dig into the details, let’s look at how these patterns work in practice. The interactive demo below lets you step through each one.

How AI Tools Communicate

Request / Response Streaming Events

👤 User

"What time is it?"

→

🤖 AI

👤 User

"What time is it?"

→

🤖 AI

🤖 Agent

idle — waiting

📧 New Email

1 / 3

Request/Response: One tool asks, the other answers. You send a prompt, you get text back, you pass it to the next step. Think of it like sending a text message and waiting for a reply before doing anything else.

Most builders start with request/response and eventually add streaming when their interface feels sluggish, or events when they want something to run without manual triggering. But the real magic happens when you combine them. You can have a tool chain that starts with an event trigger, streams output to the user, and then sends a final request/response message to update a database.

What Actually Breaks Multi-Step Chains

Each of those three patterns works fine in isolation. Tool chains fail in very predictable ways. If you know the patterns, you know where to look. The problem shows up when you chain tools together and the context window (the AI’s working memory) fills up.

Context window overflow.

Every LLM can only “see” a certain amount of text at once. Imagine trying to read a book but you can only ever see 10 pages at a time. If you keep shoving earlier chapters into the window to maintain “memory,” you eventually run out of room for the chapter you’re actually trying to read. Builders who chain multiple tools together can accidentally fill the context window with outputs from earlier steps, leaving no room for the actual task. Smart builders decide what to pass forward and what to leave behind.

Context Window: What Actually Breaks

🔍

Retrieve

~800 tokens

→

📝

Summarize

~600 tokens

→

🎨

Format

~700 tokens

→

📤

Send

~400 tokens

Context window (2 048 token limit) 0 / 2 048

Click Run Chain to watch the context window fill step by step.

Malformed outputs.

If step three in your chain expects an organized JSON object and step two returns a casual paragraph of text, step three breaks. It’s like asking someone to fill out a form, but instead of using the form fields, they just write you a letter. The information might be there, but the system can’t process it. This is why explicitly telling the LLM how to format its output, something like “respond only in JSON with these exact fields,” matters more than most people expect.

Latency compounding.

Each step takes time. Three tools that each take two seconds is at minimum six seconds total, plus overhead. If you’re building something people interact with in real time, that adds up fast. Builders solve this with caching, which means storing results you’ve already computed so you don’t recalculate them, and parallelism, which means running independent steps at the same time instead of one after another.

Vague instructions at the orchestration level.

The LLM decides which tool to call next based on the instructions you’ve given it. Vague instructions lead to the wrong tool getting called, or the right tool getting called with the wrong inputs. Think of it like giving someone directions. “Head toward the big building” leaves too much room for interpretation. “Turn left at the red light, go two blocks, turn right at the gas station” gets you where you need to go. The precision of your orchestration prompt determines whether your agent behaves reliably or keeps guessing.

The mental shift that changes how you AI

When you start thinking in tool chains, you stop asking “what can I get the AI to do?” and start asking “what does each step need to receive, and what does it need to output?”

That’s a systems question. And it’s actually a more useful frame than prompt craft alone, because it forces you to get specific about your requirements before you write a single instruction.

AI 102: From Vocabulary to Systems

rhawrot@gmail.com (Bekah) — Wed, 18 Mar 2026 00:00:00 +0000

If you read the vocabulary post, you know what a prompt is. You know the difference between a model and a model family. You’ve got the words now. This post is about what to do with them.

Having vocabulary for the pieces doesn’t automatically tell you how the pieces move. You can know what a prompt is and still write ones that produce wildly inconsistent results. You can understand what an agent is and still not know why yours keeps breaking at step three. The gap between “it kind of works” and “it actually works” isn’t usually a vocabulary problem anymore. It’s a structure problem. That structure comes down to three things and how they talk to each other.

These three concepts build on each other. You cannot have a workflow without prompts. You cannot have tool chaining without workflows. Understanding them in order is the fastest path to building things that actually behave the way you intended.

What is a Prompt?

A prompt is your instruction to the LLM. It’s the text you write before you press send. But it’s also a lot more than that, because the LLM doesn’t “know” what you mean the way another person would. It pattern-matches on what you’ve written and generates the most statistically likely useful response.

That sounds mechanical. And it is. But it’s also why how you write the prompt changes the output dramatically.

Think of it like talking to a contractor. “Build me a kitchen” and “Build me a 12x14 kitchen with white shaker cabinets, quartz countertops, and an island with seating for four” will get you very different results, even if you’re talking to the same person.

The LLM fills in whatever you leave blank. Sometimes that’s fine. Often it’s the source of that feeling when you get a response that’s almost what you wanted but weirdly off.

What is an AI Workflow?

A workflow is what happens when you stop treating the AI like a single-shot answer machine and start treating it like a collaborator on a multi-step process.

Most real tasks aren’t one prompt deep. “Write a blog post for me” sounds like one instruction, but if you actually want a good output, it’s more like: research the topic, outline the structure, draft the intro, write the body, edit for tone, format for publishing. That’s six distinct steps.

A workflow is those steps, defined in sequence. The output of one step becomes the input of the next.

This is the shift that changes everything for people who are building with AI seriously. You stop asking “what should I prompt?” and start asking “what are the steps this task actually requires?”

If you’ve been frustrated that the AI doesn’t produce what you actually want in one shot, this is probably why. You’re expecting one step to do the work of five.

What is Tool Chaining?

Tool chaining is what happens when you connect the AI to other tools, and those tools pass information back and forth automatically. The AI isn’t just generating text. It’s calling a search API, reading the results, feeding those results into the next prompt, then writing output to a database or sending an email.

Each tool in that chain does one thing. The AI reasons about what tool to use next and what to pass to it.

Think of it like an assembly line where the AI is the foreman deciding which station does what, and in what order.

The difference between a workflow and tool chaining is that a workflow can be manual. You can paste outputs from step to step yourself. Tool chaining is when that handoff becomes automatic, which is what people mean when they start talking about “AI agents.”

Putting It All Together

Here’s what a lot of people miss: these three things aren’t separate techniques. They’re nested.

Every tool chain is made of workflows. Every workflow is made of prompts. If your prompts are vague, your workflows produce inconsistent outputs. If your workflows aren’t structured, your tool chains break in unpredictable places. This is not just about being more technical. It’s about building something that actually behaves the same way twice.

What are you building right now where the output feels inconsistent? That inconsistency probably lives in one of these three layers.

The people who move forward aren’t smarter. They just start thinking in systems instead of prompts.

In the next post, we’ll make that concrete by walking through the actual tools and how they pass information between each other.

AI Vocabulary 101

rhawrot@gmail.com (Bekah) — Wed, 18 Mar 2026 00:00:00 +0000

I’ve been having a lot of conversations with non-tech people recently about AI. What I keep running into is the same pattern: smart, curious people who are genuinely trying to understand what’s happening, but who don’t have the vocabulary to name what they don’t know. And when you can’t name it, you can’t ask the right question, which means you stay stuck at the surface.

The car wash test is a perfect example of this.

A few months ago, screenshots flooded social media of people asking ChatGPT, Claude, and Grok a deceptively simple question: the car wash is 40 meters from my house. Should I walk or drive? The chatbots said walk.

What many people in the conversation didn’t understand is that the people getting bad results weren’t using a bad AI. They were using a lesser model, probably the free tier of a product, without knowing that’s what they were doing. And without vocabulary, there’s no way to even articulate that distinction.

Here’s likely what actually happened. “ChatGPT” isn’t one thing. It’s a product that runs on a family of models. In ChatGPT, there are three models: GPT-5 Instant, GPT-5 Thinking, and GPT-5 Pro, and a routing layer selects which to use based on the your question. On top of that, the current flagship family looks like this:

Think of GPT-5.4 like a full-service restaurant kitchen. GPT-5.4 mini is the fast-casual version: quicker, cheaper, good enough for most everyday questions. GPT-5.4 nano is even lighter, like a food truck setup. And GPT-5.4 pro is the version that takes extra time to think through the really hard problems, like a chef who slow-cooks instead of microwaving.

The key difference: free users don’t get the full kitchen. They get routed to whichever option is fastest and cheapest at that moment. That version can answer a car wash question correctly, but it’s also more likely to give inconsistent results on anything with nuance. Paying users get reliable access to the better models.

So when someone says “ChatGPT told me X” and someone else says “ChatGPT told me Y,” they may have been talking to completely different models, without either of them knowing it. That’s not a gotcha. That’s just what happens when you don’t have the vocabulary to describe what you’re actually using.

This is why vocabulary matters. Not to be pedantic about terminology, but because the words give you handles on things you can actually change.

Here are the terms that help close that gap.

What AI Is

Three words that get used interchangeably. They shouldn’t be.

Artificial intelligence is the broad category. Any system performing tasks we’d normally associate with human reasoning, recognizing images, detecting fraud, recommending what to watch next. LLMs are one kind of AI. The algorithm shaping your social media feed is another kind entirely. Think of AI as “transportation.” It’s the whole category. LLMs are like cars specifically, while recommendation algorithms (for example, what shows to watch next) are like trains.

A large language model, or LLM, is AI trained specifically on enormous amounts of text. It works with words, reading, predicting, generating. GPT-5.4, Claude, Gemini, Llama: all LLMs.

A model is the specific trained artifact underneath the product. When someone asks “which model are you using,” they’re not asking about the company. They want the exact version, because different models in the same family behave differently, cost differently, and have different knowledge cutoffs. This is like asking whether you’re driving a 2024 Civic or a 2026 Accord. They might be the same manufacturer, but very different capabilities.

These nest. AI contains LLMs. LLMs come in specific models. They are not synonyms.

How the Model Thinks

Token. The LLM doesn’t read words the way you do. It reads tokens: chunks of text that might be a full word, part of a word, a punctuation mark, or a space. Everything about LLM capacity and pricing is measured in tokens, not words or characters. Think of tokens like syllables in speech. Sometimes they’re a whole word (“cat”), sometimes they’re a fragment (“un-break-able”).

Context window. The total amount of text, in tokens, the model can hold in working memory at once. Your prompt, the conversation history, any documents you’ve passed in, the response being generated: all of it counts. When the window fills, older content gets dropped. This is why long conversations sometimes feel like the AI forgot something from earlier. It didn’t forget. It ran out of room. Imagine a whiteboard where you can only write so much before you have to start erasing from the top to make space at the bottom.

Hallucination. When the model generates text that is confident, fluent, and wrong. Not lying: it has no concept of truth or intent to deceive. It’s pattern-matching on what a plausible response looks like, and sometimes that leads somewhere inaccurate. Hallucinations range from small factual errors to completely fabricated citations. Knowing this term means you can stop calling everything you distrust a “hallucination” and start distinguishing between “the model reasoned badly” versus “the model stated something false with full confidence.” It’s like when you confidently give someone directions to a restaurant that closed three years ago. It’s not malicious, just working from outdated information.

How You Work With It

Prompt. Your instruction to the model. Everything it receives before it starts generating. Prompt quality is one of the highest-leverage variables in any AI system. Vague prompts don’t just produce vague outputs: they produce unpredictable ones.

Agent. An AI system that can take actions, not just generate text. It has access to tools, search, email, databases, APIs, and decides which to use and in what order. The defining characteristic is that it can affect the world outside the conversation. If an LLM is like a consultant who gives advice, an agent is like an assistant who can actually book your flight, send the email, and update the spreadsheet.

Harness. The scaffolding you build around an LLM to make it useful in a specific context. System prompt, retrieval logic, error handling, tool connections: all of it together. The model is the engine. The harness is everything that makes it go where you want. Think of a Formula 1 car: the engine is powerful, but useless without the steering wheel, brakes, suspension, and chassis that let you actually control it.

More Advanced Terms If You’re Building With AI

API (Application Programming Interface). The formal connection point between two pieces of software. This isn’t AI-specific. It’s how all modern software connects, from weather apps to payment processors. But it’s essential vocabulary for AI because almost every AI tool you use is either calling an API (to get the model’s response) or offering one (so other tools can connect to it). When tools say they “integrate,” they almost always mean they share an API connection. Think of it like the electrical outlet in your wall. It’s a standardized interface that lets different appliances plug in and get power without rewiring your house each time.

MCP (Model Context Protocol). A way to let AI access your stuff: files, calendar, email. It’s trying to make these connections easier, but it’s early days and each company still does it a bit differently. You might see tools advertising MCP support. Just know it means the tool is trying to play nice with AI, even if the setup isn’t always smooth yet.

The Real Lesson from the Car Wash

The conversation around that test wasn’t really about whether AI could reason through a simple question. It was about people evaluating something they couldn’t fully name.

If you know the difference between a model and a model family, you ask “which version were they using?” instead of “is AI smart or dumb?” If you understand context windows, you stop blaming the AI when it forgets something from earlier in a long conversation. If you know what hallucination actually means, you stop using it as a catch-all for every output you don’t trust.

That’s what vocabulary does. It turns vague frustration into specific, solvable problems.

AI Has Entered the AI Development Loop

rhawrot@gmail.com (Bekah) — Wed, 04 Mar 2026 00:00:00 +0000

It feels like we crossed a recursive threshold in February and the internet yawned.

In February 2026, OpenAI published this in their blog:

“GPT-5.3-Codex is our first model that was instrumental in creating itself… our team was blown away by how much Codex was able to accelerate its own development.”

That line matters more than most of the benchmarks that followed.

It doesn’t mean the model designed itself or trained itself. Humans still ran the research program. But it does mean something new: a model helping debug the experiments, analyze the results, and build the internal tools used to develop the next model.

In other words, AI has started participating in the process that improves AI. Not designing itself. Not training itself. But participating directly in the development loop.

It’s a subtle shift, but it changes the development loop in ways people haven’t fully processed yet.

What Actually Happened with Codex

Early versions of Codex were used by the team to debug and monitor their own training runs, track patterns, propose fixes, and build custom apps for researchers to compare behaviors against prior models. The model managed deployment work, fixed bugs, handled cache issues, and scaled dynamically during traffic surges. It built data pipelines, visualized thousands of data points, and summarized insights in minutes.

Humans still set the goals and approved the changes. But the feedback loop was tight enough that the team described themselves as “blown away” by how much it accelerated their workflow.

The important part isn’t that the model “built itself.” It didn’t.

The important part is that AI is now participating in the same engineering process that produces the next generation of AI.

For decades researchers have talked about recursive improvement — systems that help design or improve their successors. Until recently that mostly lived in theory or narrow experiments like AutoML and evolutionary optimization.

What’s different here is that the loop has moved from theory into the practical mechanics of AI development.

A model helping run experiments.
A model helping debug infrastructure.
A model helping analyze results that feed into the next model.

That shortens the distance between building an AI system and improving it.

And once that loop tightens enough, the limiting factor on progress starts to shift.

The Near-Term Is Already Here

Inside major AI labs, development workflows are already changing.

Leadership comments and internal reports suggest that a large share of internal code is now AI-assisted. Engineers increasingly describe their role less as writing every line of code and more as supervising systems that generate, test, and iterate on it.

GPT-5.3-Codex is also the first OpenAI model rated “High capability” under their Preparedness Framework specifically for identifying software vulnerabilities. That’s one reason they launched a $10M API credit program aimed at security researchers the same week.

But the more important shift is development velocity.

When a model helps build the tools, pipelines, and analyses that support AI research, the iteration cycle compresses. Experiments run faster. Failures get diagnosed quicker. Teams can test more ideas in the same amount of time.

That’s not a new pattern to software engineering. Compilers eventually compile themselves. Build systems generate other build systems. Tooling improves the tooling that follows it.

What’s new is the intelligence now sitting inside that loop. That matters because progress in AI has often been limited less by ideas than by how quickly researchers can run experiments, interpret results, and try again.

The Research Velocity Bottleneck

What makes this significant is research velocity. Progress in AI has often been limited less by ideas than by how quickly researchers can run experiments, interpret results, and try again. Training runs take time. Infrastructure breaks. Data pipelines fail. Evaluations produce thousands of signals that humans have to sift through before the next iteration begins.

When a model starts helping with those steps — debugging experiments, summarizing outcomes, generating analysis tools — the iteration cycle compresses. More experiments can run in the same amount of time. More hypotheses get tested. The frontier moves not because any single model is dramatically smarter, but because the feedback loop around improvement gets faster.

AI development has historically been limited by compute, data, and human research time. If part of that research loop becomes automated, the bottleneck shifts again.

This pattern shows up repeatedly in technological progress. Semiconductor advances accelerated when fabrication and testing cycles became automated. Software development accelerated when continuous integration systems started running builds and tests automatically. In both cases, the breakthrough was both better ideas and shortening the loop between trying something and learning whether it worked.

AI entering its own development loop looks similar. When the systems being improved start helping run the improvement process, iteration speeds up. And when iteration speeds up, progress compounds.

The question now isn’t whether a single model is dramatically smarter than the last one. It’s how quickly the next iteration can happen.

The Medium-Term Is Where It Gets Uncomfortable

Sam Altman has publicly said they have a goal of an “AI research intern” capability by September 2026 and “true automated AI researcher” by March 2028. As the loop tightens, the cost of pushing the frontier drops. This will mean that either more companies can compete or the leaders pull further ahead because their iteration cycles compound faster. Meanwhile, parts of the engineering stack are already shifting.

That transition isn’t happening slowly. As we’ve seen repeatedly with technological shifts, organizations often adapt under competitive pressure rather than through careful planning which tends to produce messy transitions and uneven outcomes. And the ripple effects won’t stop at tech. Any field built around complex, repeatable knowledge work will feel some version of the same pressure.

What felt like a 5–10 year horizon for broad disruption is now measured in 1–3 years for many industries. This is why the anxiety feels bigger than “just devs.” It’s not isolated; it’s systemic acceleration.

The Long-Term Is the Part Nobody Wants to Say Out Loud

If AI systems eventually assist with the full research loop the feedback cycle tightens further. Hypothesis generation, experiment design, training runs, evaluation, all of it. That doesn’t automatically mean runaway intelligence. Capabilities could compound in ways that are genuinely hard to reason about in advance. But it does mean the systems advancing AI become partially automated themselves.

That has implications people don’t fully understand yet.

Neither path is guaranteed. What’s not up for debate is that when AI writes the code that trains the next AI, auditing gets harder. Tiny undetected biases, optimization pressures, and specification gaming can propagate across iterations.

OpenAI and others have safeguards in place. The real question is whether those safeguards scale as quickly as the systems themselves.

That’s not a rhetorical question. It’s an open one.

Why You Should Care Now

My instinct is usually to frame these shifts in ways that feel manageable, maybe even exciting. And some of it is exciting. But preparing people for what’s actually coming means being honest that the timeline is compressed, the impacts are uneven, and the people least prepared for the disruption will feel it most.

The anxiety you might feel reading this isn’t irrational. It’s information. The question is what you do with it.

The roles that will matter most aren’t necessarily the ones that write the most code. They’re the ones that can evaluate what AI produces critically, catch what automated systems miss, and understand enough about the systems they’re building on to ask the right questions. That’s worth investing in now, not when the next wave lands.

Machines are now helping build the machines that come after them.

That’s not the future. That’s February 2026.

Why Capable AI Keeps Getting Blocked

rhawrot@gmail.com (Bekah) — Thu, 26 Feb 2026 00:00:00 +0000

Amazon bans Claude Code internally. Enterprises quietly block Copilot. Security teams flag agentic workflows before they ever make it to production. SDK usage restrictions start showing up in internal policy docs that nobody announced out loud.

Different companies and reasons, but the same underlying instinct.

When something feels uncontrollable, the first response is rarely “let’s understand it better.” It’s “let’s shut it down.” When elevators became were first introduced, people refused to ride them alone. Building operators had to hire elevator attendants because people needed a human present to feel safe (keeping the human in the loop). The technology worked. The trust infrastructure didn’t exist yet.

It’s not a failure of vision yet. It’s a pretty rational response to a real problem, but it’s where things go from here that matters. The question isn’t “why are companies banning AI tools?” The question is “what would have to be true for those tools to not need banning in the first place?”

The Problem isn’t the Tools

The last two years focused almost entirely on capability.

Bigger models.
Autonomous agents.
Sophisticated chaining.

Those bets paid off, and the systems are genuinely powerful.

But capability without visibility is risk with a good PR story.

We already learned this lesson in distributed systems. You don’t deploy a microservice without logs. You don’t scale a database without monitoring. You don’t run Kubernetes without observability. Those systems became trusted not because they were powerful, but because operators could see what they were doing.

AI agents haven’t reached that level of maturity.

An agent can:

Modify dozens of files
Call external APIs
Chain multiple model decisions
Execute tools across a session

And when the session ends, most of that reasoning disappears.

If something goes wrong:

Can you replay the exact decision path?
Can you inspect intermediate model outputs?
Can you produce a structured audit trail for security?
Can you deterministically reproduce the outcome?

In many environments, the answer is no.

So institutions respond the way institutions always do when power outruns accountability: they restrict access. That’s institutions doing what institutions do when power outruns accountability.

The Next Phase of AI Maturity

The bans aren’t the story. They’re a signal that we’ve entered a new phase of AI maturity, one where the capability questions are largely settled and the infrastructure questions are just getting started. Brian Douglas wrote more about this shift in his post The Push Code Era is Over.

What needs to exist isn’t another wrapper or another interface. It’s the same thing every distributed system eventually needed: operator-grade tooling. Full request and response recording. Durable execution trails. Deterministic replay. The primitives that let you run powerful systems with confidence instead of just running them with hope.

It’s not just about more capable agents. It’s about agents that are actually safe to operate at scale, ones that security teams can audit, that legal teams can defend, and that developers can trust with real work.

The question worth asking right now isn’t which tools are going to get banned next. It’s what would have to be true for those tools to not need banning in the first place.

AI Ate the Homework: What Communities Are Actually For Now

rhawrot@gmail.com (Bekah) — Mon, 24 Nov 2025 00:00:00 +0000

When I was learning to code, one of the things that motivated me most was the sense of community. I found a ton of value in the Twitter community, where people answered questions, shared resources, and celebrated each other’s wins. I also found incredible support in online coding communities. A huge part of this was the ability to ask questions and get help from others who had been where I was. They brought empathy and experience in a way that documentation and tutorials couldn’t, and made me feel like I could do it even when I didn’t believe that.

A huge part of Virtual Coffee’s early growth was people finding each other to ask questions, get help, and learn together. It was a safe space to say “I don’t know how to do this” or “Is this interview experience ‘normal’?” and have someone patiently walk you through it.

Not only did having your question answered give you the information you needed, it gave you validation. You weren’t alone. You were struggling with something that other people struggled with too. But. it also felt good to help. And in a lot of ways, you experienced growth and it felt tangible when you were able to answer someone else’s question. Successful communities saw collective knowledge sharing, mutual aid, opportunities to learn together.

By 2024, something had fundamentally shifted.

ChatGPT could answer your JavaScript question in three seconds. Claude could debug your code and explain why. The questions that used to fill Discord and Slack, “how do I center a div?” or “what’s the difference between let and const?” or “why isn’t my API call working?” suddenly had a faster, always-available answer. And now, you prompt your LLM and get code that works, explanations that make sense, and debugging help without needing to wait for someone to see your question and respond.

And with that shift came a new tension nobody quite knew how to name: the growing frustration when someone asks a question that AI could have answered, and the growing anxiety about asking questions when you’re not sure if you’ve “done enough work first.”

The bar rose.

The Numbers Tell the Story

Stack Overflow traffic dropped 14% month-over-month from March to April 2023, right after GPT-4 launched. By December 2024, new questions had dropped 60% year-over-year. The volume of questions is down 75% from its 2017 peak and 76% since ChatGPT’s launch in November 2022.

Developers weren’t being difficult. They were being rational.

Why post a question on Stack Overflow and wait for someone to answer when ChatGPT gives you working code in seconds? Why search through Discord message history when Claude can explain the concept in plain English, tailored to your specific context? Why ask a community and risk judgment and assholes on the internet when AI is always available, non-judgmental, and fast?

AI could now handle most of the questions communities used to.

The Unspoken Contract Changed

Here’s what this shift did to the implicit contract of online communities:

In 2020-2021:

You asked questions, even basic ones, and people were happy to help
The community was the primary resource for learning and problem-solving
At Virtual Coffee, we embraced horizontal mentrship—everyone could ask and everyone could answer
Asking for help was normal and expected

In 2025-2026:

You’re expected to try AI first before “wasting” people’s time
The community is for questions AI can’t answer
There’s an unspoken frustration at questions ChatGPT could handle
Asking for help requires demonstrating you’ve done your homework

We started to see that community members who were tired of answering the same basic questions when AI could do it faster.

What Communities Are Actually For Now

So if AI handles basic questions, what are communities actually for?

The answer should be: judgment, experience, connection, and the questions AI can’t answer.

“Should I take this job or stay at my current role?”
“How do you actually work with this technology in production?”
“What’s the culture like at {company}?”
“I’m burned out. How did you work through it?”
“Here’s this cool thing I built and I think it could help others. What do you think?”
“How do you navigate sick kids and a feature launch???”

These are inherently human questions requiring human judgment, lived experience, and contextual understanding. They’re the questions that make communities valuable. They’re the questions that foster connection and belonging. They’re the questions that create shared understanding and collective wisdom.

But here’s the problem: many communities haven’t consciously made this shift. They’re still structured around Q&A patterns that AI now handles better. They’re still trying to be “the place developers get answers” when that race is lost.

Product communities are particularly stuck. They’re trying to serve two populations:

Drive-by users who just need their build to work and will never engage beyond that
Community seekers who want connection, depth, and belonging

These need different things. The drive-by user benefits from AI-first + good docs. The community seeker needs human connection. Trying to serve both with the same strategy doesn’t work.

The Sustainability Crisis

This creates a sustainability problem that’s quietly breaking communities:

For community builders: You’re caught between welcoming everyone and managing finite volunteer energy. When someone asks a question ChatGPT could answer in 3 seconds, do you answer it (and enable learned helplessness) or redirect them (and risk seeming unwelcoming)? There’s no good answer, and the constant navigation is exhausting.

For community members: You’re navigating unwritten rules about what’s “appropriate” to ask. You feel guilty asking for help because maybe you didn’t try hard enough. You see others get redirected to AI and worry you’ll be next. The psychological safety that made communities work is eroding.

The Uncomfortable Questions

Where does this leave us? With some hard questions we need to actually ask:

About AI expectations:

How do we honor that AI makes many questions obsolete without making people feel unwelcome?
What’s our responsibility when not everyone has the same AI access?
How do we shift from “Q&A community” to “judgment and experience community”?
What questions actually need humans now?
Is “try ChatGPT first” gatekeeping or reasonable boundary?

About community purpose:

Are we trying to be everything when we should be something specific?
Can drive-by Q&A and deep connection coexist in one space?
What happens when 80% of your community just wants fast answers?
How do we serve people who need basic help without burning out the helpers?

About sustainability:

Can volunteer-run communities survive when the “easy” questions (that felt good to answer) are gone?
How do we make helping feel rewarding again when all that’s left are hard questions?
What’s the minimum viable community when AI handles the basics?

What Actually Works Now

The communities thriving in 2026 aren’t the ones fighting AI or pretending it doesn’t exist. They’re the ones that:

Accepted the shift in purpose. They’re not trying to be Stack Overflow. They’re spaces for nuanced discussion, career advice, lived experience, and human judgment calls. They’ve made peace with AI handling the basics.

Stay welcoming while having boundaries. “Hey, ChatGPT might be faster for this!” is fine. “Why are you wasting our time?” is not. There’s a way to redirect to AI tools while maintaining psychological safety.

Separate transaction from connection. Some spaces are for quick help (and that’s fine). Some spaces are for deeper belonging (and that’s different). Trying to be both creates friction.

Accepted different participation levels. Drive-by questions are fine. People who only show up when they need something are fine. The always-engaged ideal is dead, and that’s okay.

Built for the people who actually need them now. People navigating complex career decisions. People working with niche technologies where AI training is thin. People who need human judgment, not just answers. People without AI access. Not everyone, because not everyone needs human community for Q&A anymore.

The bar that nobody asked for—AI capability—did change what communities are for. But it didn’t eliminate the need for community. It just clarified it.

We don’t need communities to answer “how do I center a div?” anymore. We need them for “should I take this job?” and “how do I not burn out?” and “what’s it actually like to work there?”

And honestly? Those are better questions. They just require us to be more human, not less.

The Invisible Load: How AI Workflows Can Replace Your Team's 'Glue Person'

rhawrot@gmail.com (Bekah) — Thu, 06 Nov 2025 00:00:00 +0000

Every team has one, and, tbh, a lot of relationships have one. The person who remembers. For teams, it might be the person who remembers to update the changelog. Who posts the weekly standup summary. Who follows up on that GitHub issue from three weeks ago. Who makes sure the docs match the latest release. Who bridges the gap between what engineering ships and what the rest of the company knows about.

We call this “glue work,” and research shows it disproportionately falls on women in teams, and mothers in relationships. It’s the invisible labor that keeps everything running smoothly, but rarely shows up in performance reviews or promotion discussions.

The problem is that glue work is essential, but it shouldn’t be someone’s primary job. And it definitely shouldn’t be the reason talented people get passed over for advancement.

But what if AI workflows could be the glue instead?

The Glue Work Problem

Tanya Reilly’s essay “Being Glue” describes how critical but undervalued work like coordinating between teams, translating technical concepts, maintaining documentation, ensuring follow-through often becomes invisible. The people who do it often make everything seem easy. But there’s a cost, and it’s compounding in the background.

If you have one teammate who’s spending hours each week:

Updating tickets after standups
Posting release summaries to Slack
Making sure customer support knows about new features
Chasing down PR reviews
Updating documentation after merges
Following up on blocked issues

when none of this is their actual job, then they may be your “glue.” All of it is necessary. But when they stop doing it, things fall apart.

Maybe it doesn’t seem that bad right now, but coordination work compounds as teams grow.

What If Workflows Could Be the Glue?

This is where composed AI workflows change everything. Not because they eliminate coordination work, but because they automate it at the seams between tasks.

In his post on composed workflows, Continue CEO Chad Metcalf makes an important distinction: a single workflow saves time, but composed workflows compound. When the output of one workflow can trigger the next, you’re doing more than just automating individual tasks. You’re automating the entire coordination system.

Let’s look at what this actually means.

Example 1: The Release Communication Burden

Current state: After every release, someone (usually the same someone) needs to:

Draft changelog entries
Update product documentation
Post to company Slack
Update customer-facing docs
Create support team briefing
Close related Linear issues

That “someone” spends 2-3 hours per release on coordination work. Not working on more impactful work. Just making sure everyone knows what shipped.

With composed workflows:

Merge to main 
  → Extract changes from PR descriptions 
  → Draft changelog entry 
  → Update technical docs 
  → Generate customer-facing summary 
  → Post to internal Slack 
  → Update support knowledge base 
  → Close related issues
  → Post completion summary

The entire coordination chain runs automatically. The output of one workflow triggers the next. No one spends their afternoon being glue. Instead, they become the human in the loop who reviews and improves the process.

Example 2: The Follow-Up Tax

Current state: You’re in standup. Someone mentions they’re blocked on a security review. Everyone nods. The meeting ends.

Three days later, nothing’s happened because nobody remembered to:

Create a ticket
Tag the security team
Follow up when there’s no response
Update the original ticket
Let the blocked person know it’s unblocked

Guess who remembers? The glue person, who now spends their time tracking other people’s blockers instead of writing code.

With composed workflows:

"Blocked on X" detected in standup notes 
  → Create Linear issue with context 
  → Tag relevant team 
  → Set reminder for 2 days 
  → Follow up if no response 
  → Update original ticket when resolved 
  → Notify blocked person

The follow-through happens automatically. Nobody has to be the memory keeper.

Example 3: The Support Handoff

Current state: Customer reports a bug in Slack. Engineering fixes it. But somehow:

Support never gets notified the fix is live
Customer still thinks it’s broken
Docs don’t reflect the fix
The original Slack thread is forgotten

Someone (the glue person) ends up manually connecting all these dots. Every. Single. Time.

With composed workflows:

Bug report in Slack 
  → Create Linear issue 
  → PR created and merged 
  → Update documentation 
  → Generate fix summary 
  → Post to support channel 
  → Reply to original Slack thread 
  → Close Linear issue with summary

The entire loop closes itself. From report to fix to notification to documentation to closure. No human glue required.

Why This Works Where Other Solutions Don’t

It’s Not About Replacing People

AI workflows aren’t replacing the glue person’s judgment or expertise. They’re replacing the repetitive coordination tasks that shouldn’t require judgment.

When a PR merges, updating the changelog doesn’t need human insight. Following up on a blocked issue after two days doesn’t require strategic thinking. Posting a deployment summary to Slack isn’t creative work.

These are mechanical transitions between tasks. Perfect candidates for automation.

It Compounds Over Time

Here’s what makes this different from other automation attempts: composition creates compounding value.

Each workflow you add doesn’t just save time on that specific task. It amplifies the value of workflows already running. The deployment workflow outputs information the changelog workflow needs. The Linear sync workflow triggers the documentation update workflow. The customer support workflow feeds the product insights workflow.

You’re not just automating individual tasks. You’re automating the entire coordination system.

It Preserves the Actual Value of “Glue”

The valuable part of glue work isn’t the mechanical coordination. It’s the strategic connection-making, the pattern recognition, the ability to see across teams and translate context.

When AI workflows handle the mechanical parts, the humans who were doing glue work can focus on the strategic parts.

They can spend time:

Identifying patterns across customer feedback
Improving team processes
Mentoring junior developers
Solving actually complex problems
Advancing their technical skills

The things that actually deserve their expertise.

The Composition Advantage

Individual workflows are helpful. Composed workflows are transformative.

As Chad Metcalf writes in his post on composed workflows: “Individual workflows give linear improvements. Composed workflows compound.” This distinction is crucial when thinking about how to replace organizational glue work.

Because here’s what happens when workflows compose: the coordination work stops being a burden on any individual. Instead, it becomes part of the system itself.

You’re not asking someone to remember to update the docs after deployment. The deployment workflow triggers the documentation workflow automatically. You’re not relying on someone to follow up on blocked issues. The standup workflow creates follow-up workflows with built-in reminders.

This is infrastructure that scales with your team. As you grow, the glue work compounds. But with composed workflows, the automation compounds instead.

Real Team Impact: Beyond Time Savings

Let’s talk about what this actually means for teams.

No More “That Person”

When coordination work is automated, it stops being concentrated on one or two people. The person who used to spend 10 hours a week on glue work can spend those hours on actual engineering. Or product work. Or whatever they were actually hired to do.

More importantly: they stop being the bottleneck. When knowledge and coordination flows through automated systems rather than through specific people, teams become more resilient. People can take vacation without everything falling apart. New team members can onboard without needing to know who to ask for everything.

Career Equity

Glue work is often invisible during performance reviews. “Sarah keeps everything running smoothly” doesn’t translate to promotion decisions the way “shipped three major features” does.

When AI workflows handle coordination, engineers can focus on work that’s more visible and valued. This has disproportionate impact on people—often women and mothers—who tend to take on more glue work.

Team Velocity at Scale

Small teams can coordinate informally. “Hey, remember to update the docs” works when you’re five people.

At 20 people? 50? Informal coordination breaks down. You need systems. The question is: will those systems be human-dependent, automated, or composed with a human in the loop?

Composed workflows scale. Human coordination doesn’t.

How to Actually Do This

Don’t start by trying to automate everything. Start with the most repetitive, predictable coordination work on your team.

Step 1: Identify Your Glue Work

Have an honest conversation. Ask:

What coordination tasks happen after every release?
What follow-ups consistently fall through the cracks?
Where does information get stuck between teams?
Who’s spending time on mechanical updates vs. strategic work?

Write it down. You’re looking for patterns, not one-off tasks.

Step 2: Build One Workflow

Pick the most painful coordination task. The one that happens constantly and requires zero judgment.

Examples:

Changelog updates after merges
Standup note distribution
PR review reminders
Linear ticket status syncing
Documentation updates post-deployment

Build a workflow that handles it end-to-end. Run it for a week. Measure intervention rate—how often does it need human correction?

Get that intervention rate below 5%. Then move to step 3.

Step 3: Compose

Look at the output of your first workflow. What happens next in the coordination chain?

If your workflow posts deployment notes to Slack, what normally happens after that? Maybe documentation gets updated. Maybe customer support gets briefed. Maybe Linear tickets get closed.

Build workflows for those next steps. Connect them to your first workflow’s output.

Now you have composition. One workflow’s completion triggers the next. The coordination chain runs automatically.

Step 4: Keep Going

Each new workflow amplifies the ones before it. The deployment workflow feeds the documentation workflow. The documentation workflow triggers the changelog workflow. The changelog workflow posts to Slack, which triggers the customer communication workflow.

You’re not just saving time on individual tasks. You’re building a system where coordination happens automatically at every transition point.

The Bigger Picture

This isn’t just about efficiency. It’s about equity.

When essential coordination work is visible and automated, nobody gets stuck being the invisible glue. Everyone can focus on the work they’re actually good at, the work that gets recognized and rewarded.

Teams that build composed AI workflows aren’t just shipping faster. They’re redistributing the coordination burden from people to systems. They’re making space for everyone to do their best work.

Look at your team. Who’s the glue person? What would they be working on if they weren’t constantly coordinating?

That’s the real value of composition.

When We Became What We Do: The Identity Crisis That Companies Mistook for Opportunity

rhawrot@gmail.com (Bekah) — Sun, 02 Nov 2025 00:00:00 +0000

In March 2020, a weird thing happened to how we answered the question “Who are you?”

Before the pandemic, most of us had multifaceted identities. I was the person who went to the gym and lifted weights 6x a week, who took my kids to the park all the time, who volunteered at the school, attended the occasional book club, and who took a break by going grocery shopping on Saturday mornings. For many of us, our sense of self was distributed across multiple domains, including social, familial, recreational, and professional.

The Great Identity Consolidation

Lockdown stripped most of those identities away in a matter of weeks or even days. Even family gatherings and Sunday dinners and holiday traditions moved to Zoom calls or stopped entirely.

Every space where we’d embody our various identities closed. I couldn’t be “the person who deadlifted on Tuesdays” when there was no weightroom open. You can’t be “the parent who knows everyone at school” when school is a URL. You can’t be “the person who always hosts game night” when gathering is prohibited.

Our professional identity didn’t just persist. It intensified, because work didn’t stop. In actuality, for a lot of us it intensified or became the one thing we could control. I lost my job, but I could look for another. For many people, work-from-home meant more hours. Slack channels kept pinging. Standups kept happening. Deadlines didn’t pause for a pandemic.

Suddenly, “developer” or “designer” or “product manager” wasn’t just what we did. It became almost the entirety of who we were.

Not by choice. By elimination.

Remote work intensified what researchers called “identity blur” or the breakdown of boundaries between personal and professional life. Not to mention that an entire generation of early-career professionals were doing their identity formation almost exclusively through the professional lens.

Why Tech Communities Exploded

This identity shift created fertile ground for professional communities to thrive in unprecedented ways.

Developer communities, in particular, saw explosive growth. The community infrastructure was already there: Slack, Discord, forums, virtual meetups. But suddenly, these weren’t just places to ask technical questions or network for jobs. They became primary social spaces.

When I started Virtual Coffee in March of 2020, I was desperately looking for people after I lost my first developer job. It wasn’t supplementing my social life because it was my social life. The Tuesday meetups became my weekly social anchor.

And I wasn’t alone. Across the tech ecosystem, professional communities became all-purpose gathering spaces. The hallway track at conferences had always been valuable, but now people were craving the hallway track without the conference. They wanted the coffee shop where everyone was a developer. They wanted to belong somewhere, and professional identity was one of the few identities still accessible.

The Numbers That Told a Story

By 2021, the indicators were everywhere:

Community engagement increased
Community programs saw increased recognition of their value
Having an online community became more important in 2020
Time on social and community platforms jumped dramatically

But here’s what the numbers weren’t saying: they weren’t showing that people had discovered a permanent need for professional community. They were showing that professional community was filling a vacuum left by every other kind of community disappearing.

Professional community wasn’t competing with other professional communities. It was competing with—and replacing—gyms, coffee shops, happy hours, hobby groups, neighborhood connections, and casual friendships.

The Company Gold Rush

Companies looked at those engagement numbers and saw opportunity.

If you were a tech company in 2020-2021 watching developers flock to online communities, the conclusion seemed obvious: we need a community. If you were hiring and saw that developer engagement was at all-time highs, you might think: we need a community manager. I became a technical community manager because tech was primed to invest in community roles.

The role that was previously a nice-to-have became a strategic imperative.

Companies launched Slacks, Discord servers, forums, and user groups. They hired community managers, developer advocates, and DevRel teams. They built content strategies around community engagement. They measured success by the metrics they were seeing everywhere: member counts, daily active users, message volume.

The logic seemed on track:

People are engaging with online communities at unprecedented levels
Our competitors are building communities
Community drives product adoption and loyalty
Therefore, we need to invest in community

But this logic missed context.

The Substitution Effect Nobody Acknowledged

What companies were observing wasn’t a permanent shift in how people want to engage with brands or products. It was a temporary substitution driven by extraordinary circumstances.

In 2020-2021, professional communities were standing in for:

Local social connections (because we couldn’t gather)
Recreational identities (because hobbies were paused)
Casual professional networking (because conferences were canceled)
Workspace camaraderie (because offices were closed)
General human connection (because isolation was mandatory)

The engagement wasn’t high because people suddenly valued brand communities more. It was high because professional community was the only community many people had access to.

Think about it this way: if you’re working from home, can’t go to the gym, can’t meet friends for coffee, and can’t attend local meetups, where do you find people? If your identity as a weight lifter is on hold because gyms are closed, and your identity as a parent is strained because you’re homeschooling, what’s left? Your professional identity. And where do professionals gather? Online, in communities organized around their work.

What Success Really Looked Like

Companies celebrated metrics that looked like success:

“Our Discord hit 10,000 members!” “Daily active users up 300%!” “Community engagement is our highest ever!”

But a lot of them were ignoring the fact that people weren’t necessarily there because your product was so compelling that they wanted to be part of your brand community. They were there because they were lonely, isolated, and craving connection, and your professional community was one of the only options available.

This isn’t to diminish the genuine connections people made or the real value these communities provided. Virtual Coffee meant–and still means–the world to me. The developer communities that emerged during this time saved people’s mental health and careers.

But the reason for that value was specific to the moment. We were all in crisis, and professional community became a lifeline not because it was uniquely better than before, but because everything else was gone.

Belonging Doesn’t Scale the Way Companies Hoped

But you can’t manufacture the conditions that created pandemic-era engagement.

You can’t make someone lonely enough to spend three hours a day in your Discord.

You can’t make someone isolated enough to treat your Slack like their primary social group.

You can’t make someone identity-starved enough to build their sense of self around your brand community.

And you most definitely should not want to.

As the world reopened, people’s identities re-diversified. The parent identity came back with in-person school. The athlete identity returned with reopened gyms. The friend identity flourished with in-person coffee dates. The hobbyist identity resumed with craft groups and sports leagues.

Professional identity didn’t disappear, but it was one of many identities, not the primary or only identity.

But companies didn’t anticipate: people wanted to keep both.

The connections made during the pandemic weren’t casual networking. They were trauma bonds. We didn’t just share technical knowledge in those slacks and Zoom rooms. We survived isolation together, processed fear together, figured out how to keep going together. We saw each other at our worst: unmuted kids screaming, laundry piles stacked and thrown across the floor, tears with lost jobs. We celebrated new babies through screens. We mourned miscarriages together in the #heavy channel. We watched marriages fall apart in real-time as people processed isolation and stress.

And we lost people.

And when that happened, we couldn’t gather. We couldn’t hug each other. We couldn’t sit together at a funeral. We watched memorial services on Zoom, crying alone in our homes, typing condolences in chat windows, wishing desperately we could just be there together in person.

The grief was compounded by the medium. These were people who’d kept us sane, who we’d talked to nearly every day, who felt like lifelines. And when they were gone, we had to process that loss the same way we’d built the relationship, through screens, at a distance, without the physical comfort that humans need in grief.

These weren’t casual professional connections. These were people who’d seen us completely, who’d held space for our fear and loneliness, who’d shared their own vulnerability in ways that rarely happen in professional contexts. The bonds formed under those conditions of shared trauma, radical vulnerability, mutual survival, don’t just dissolve when offices reopen.

This wasn’t like moving to a new city and losing touch with old friends, or kids graduating so you stop seeing other parents at pickup. Those transitions are natural drift. This was different. People wanted to maintain these deep connections while returning to physical community.

But time is finite. You can’t spend three hours a day in the Virtual Coffee co-working room when you’re back at an actual office. You can’t attend every virtual event when you’re back at the gym, at your kid’s school, at in-person meetups.

The decline in engagement wasn’t people abandoning communities they didn’t care about. It was people being pulled between communities they cared about deeply and being forced to choose.

Some people stayed in their pandemic communities because those bonds meant everything. Some drifted away despite wanting to stay connected. Many tried to maintain both and felt guilty about not being as present online.

Professional identity didn’t disappear, but it returned to being one of many identities, not the primary or only identity. And with finite time and attention, something had to give.

The Misread That Shaped a Strategy

Companies saw the engagement decline and treated it like a problem to solve rather than a natural consequence of changed circumstances. The mistake wasn’t that companies built communities. Many of those communities genuinely serve people who need them, and many of those pandemic-era bonds are real and lasting.

The mistake was thinking they could recreate or sustain trauma-bond-level engagement without the trauma.

They thought the pandemic-era engagement levels were:

Sustainable (Actually, many required conditions no one should want to recreate)
Universal (Actually, many were born of collective crisis)
Reproducible (Actually, many were trauma bonds form under specific circumstances)
Transferable (Actually, you can’t manufacture that depth of connection on command)

Companies built community strategies around peak crisis participation and crisis-level bonding. They staffed for engagement that made sense when professional community was substituting for all community and people were processing collective trauma together. They created expectations for involvement that assumed people’s entire social lives would continue to flow through professional channels with that same intensity.

When engagement inevitably declined, it wasn’t because the communities failed. People’s lives and needs changed, and then companies panicked. They hired more community managers. They added more features. They pushed harder for participation.

But you can’t solve for the absence of shared crisis with better Slack integrations.

And with that shift, professional communities changed in character, not just size.

Many became transactional. People drop in, ask a question, get an answer, leave. They need the resource, the collective knowledge, the troubleshooting help, the documentation links. But they don’t want or need the connection. They’re not looking for the coffee shop vibe anymore. They’re looking for Stack Overflow with a pulse.

This isn’t everyone. Remote workers still exist. Niche specialists still need their people. Global collaborators still benefit from async communication across time zones. People for whom online professional community isn’t a substitute for anything, because it’s genuinely where their professional community exists.

But even within those groups, the engagement looks different. It’s purposeful, not ambient. It’s “I’m here when I need something” rather than “this is where I hang out.”

And then there are the community builders caught in the middle, trying to recreate that pandemic-era connection and intimacy in product-focused communities where most people just want help with their API integration. They’re hosting office hours that get three attendees. They’re planning social events that get polite “maybe” responses. They’re fighting to build connection in spaces where the majority of members are perfectly content with drive-by interactions.

It’s not that these community builders are doing it wrong. They’re trying to create depth in spaces where most people want efficiency. They’re optimizing for belonging when most users are optimizing for answers.

The communities that thrived on trauma bonds and shared vulnerability can’t be replicated in a product community where people just need their build to work. And expecting them to is setting community builders up to burn out trying to recreate something that only existed under very specific, unrepeatable conditions.

What job is this community actually doing?

In 2020-2021, professional communities were doing the job of: general social connection, professional development, casual friendship, identity formation, and mental health support.

In 2025, they should be doing the job of: professional knowledge sharing, specific technical support, collaboration, and professional networking.

Those are different jobs requiring different strategies, different staffing, and different success metrics.

Communities that thrive post-pandemic aren’t trying to be everything to everyone. They’re specific about who they serve and why. They’re intentional about the value they provide. They recognize that lower engagement isn’t failure. It’s actually right-sizing.

The Uncomfortable Truth

Not every company needs a community.

Even if you needed one in 2020, you might not need one now.

Even if your competitors have one, that doesn’t mean you should too.

Even if engagement was high during the pandemic, that doesn’t mean it should be high now.

The companies that will succeed with community in 2025 and beyond are the ones willing to ask: “Is this actually serving a real need, or are we chasing ghosts of pandemic-era metrics?”

Because belonging doesn’t scale the way we hoped. Identity doesn’t consolidate because we want it to. And crisis-driven engagement isn’t a sustainable business strategy.

This is the second in a series exploring how our understanding of community has changed from 2020 to 2025. Next: How AI and changing expectations are breaking the communities that remain.

When 'Local' Went Global: The Pandemic Era of International Communities

rhawrot@gmail.com (Bekah) — Thu, 30 Oct 2025 00:00:00 +0000

During the pandemic, I occupied the same space—a Zoom room-with members of the Virtual Coffee community from all over the world. We’ve had members across the US, Canada, South America, Europe, Australia, and Asia. We saw each other whether in an official Virtual Coffee even or eventually in our virtual co-working room that stayed open 24/7. Sometimes we’d chat. Sometimes, we’d just… exist together.

It was the digital equivalent of running into someone in the dairy aisle, except the dairy aisle was a Zoom room, and the “someone” could be in Jakarta, São Paulo, Manchester, or Kansas City.

For a brief window in modern history, “local” stopped meaning geography and started meaning something else entirely.

The Collapse of Default Community

Before March 2020, most of us didn’t have to think much about what “community” meant. It was simply the people you saw regularly: coworkers, neighbors, your kid’s soccer team parents, the familiar faces at church or the gym. Community was embedded in the infrastructure of daily life and was predictable, physical, and largely determined by proximity.

Then proximity disappeared.

When lockdowns began, the familiar networks evaporated overnight.

The impact was immediate and profound. Two-thirds of adults reported experiencing social isolation during the pandemic. For younger adults, 61% of young felt “serious loneliness” during this period.

We didn’t lose our desire for community. We lost the infrastructure that had been quietly supporting it all along.

The Great Virtualization

What happened next wasn’t entirely new. People had been building online communities for years. But the scale and speed were unprecedented. Suddenly, everyone needed to figure out how to find belonging through a screen. When the physical infrastructure disappeared, we rebuilt it digitally.

From massive pandemic hackathons to new Slack and Discord communities, people everywhere began re-creating local-belonging at scale.

I started Virtual Coffee with weekly Tuesday meetings that were regular, predictable, and rhythmic. In a lot of ways, therapeutic. Then, the co-working room that transformed it into something that felt genuinely “local.” That room was open all the time. You could drop in whenever. You’d see who else was around. Sometimes you’d end up in a spontaneous conversation about your project, or someone’s career transition, or absolutely nothing at all. We added a virtual book club, CodeWars challenges, and another day of coffee chats. Interintellect salons hosted three-hour events where people from diverse backgrounds came together for intellectually stimulating conversation, bridging tech and non-tech interests through Discord.

The magic was in the serendipity. The unplanned encounters. The way you’d sign on to get work done and end up chatting with someone from Nigeria about their startup idea, or find yourself in a breakout room with a developer from Russia who was working through the same frustrating bug you’d just solved.

We were strangers from different continents creating something that felt remarkably like what a neighborhood coffee shop might have provided. Except our “neighborhood” spanned time zones, and our “coffee shop” never closed.

What Made It Work

Looking back, I think the pandemic-era virtual communities that thrived shared a few key characteristics:

Regularity without rigidity. You knew when things were happening, but you weren’t required to show up. The co-working room was always there. The Tuesday meetings happened every Tuesday. This created rhythm, a temporal equivalent of “I know I’ll see you at the grocery store on Saturday mornings.”
Space for the unplanned. I still believe that the most meaningful connections don’t happen during structured programming. They happened in the margins: before the official meeting start, in the co-working room at odd hours, in side channels where someone posted a random question and three people end up in a deep conversation.
Low barriers, high humanity. The fact that events moved online opened communities up to people who might have been too uncomfortable to attend an in-person event due to anxiety, financial constraints, or something else, allowing for realtime conversations over Slack or Discord instead of struggling with in-person social time. Nobody cared about ring lights or professional setups–ok, maybe once I learned about those things, I did invest some money to upgrade a little bit. But we still showed up in our kitchens, with kids screaming in the background, with laundry visible behind us. The bar for participation was simply: be present, be kind, be human.
Shared vulnerability. We were all figuring it out together. Nobody had their shit completely sorted. That leveled the playing field in a way that’s rare in professional communities. In other words, the senior engineer and the bootcamp student/grad (ie, me) were equally disoriented by the moment we were living through.

The Shift Back

Then, gradually, the physical world opened back up.

People returned to offices, or to coffee shops, gyms, schools, or co-working spaces again. The default infrastructure of community came back in-person.

And the international local communities… shifted.

The co-working room got quieter. The Tuesday meetings still happen, but attendance has thinned. Not because people stopped caring, but because they could now get some of those needs met in physical space again. Time—everyone’s most finite resource—got redistributed back to the in-person world.

Before the pandemic, people spent the bulk of their social time at work, and remote work led to loneliness and feeling disconnected. The shared physical space offered opportunities to network, mentor others, and build community that were hard to recreate in a scattered, virtual workforce.

This wasn’t a failure. It was just the natural consequence of changed circumstances.

But it left a lot of questions unanswered.

Where We Are Now

We’re in a strange liminal space. Virtual communities haven’t disappeared, but they’re not serving the same function they did in 2020-2022. The urgency is gone. Community programs saw an increased recognition of their value during the pandemic, but that recognition was tied to a specific moment in time—a moment that has passed.

People are negotiating between physical and digital belonging in ways we haven’t fully figured out yet.

And meanwhile, companies are asking: “Why isn’t our community as engaged as it was during the pandemic?”

But that’s the wrong question.

The right question is: “Who actually needs this community now, and what are we building it for?”

During the pandemic, virtual communities weren’t just filling a professional need. They were filling all our social needs. Professional community became a substitute for general community because it was all we had. The developer slack was my coffee shop, my gym, my after-work happy hour, my weekend hangout.

Now that general social needs can be met locally again for many people, the population who needs online-as-local has shifted back to who it always was:

Fully remote workers who’ve left physical proximity to colleagues behind entirely
Developers who want casual peer conversation without the overhead of professional networking events
People who want the hallway track experience (those serendipitous conversations that happen between sessions)
Specialists in niche areas where their “local” doesn’t have anyone else working on their specific stack or problem domain
Disabled folks, caretakers, and others for whom physical gatherings have always been inaccessible
Global collaborators building projects across continents and time zones
People who want the coffee shop, but the coffee shop is all technies

These communities still matter deeply. They’re still someone’s local. The mistake isn’t that these communities exist—it’s that companies think everyone needs this, all the time.

The coffee shop didn’t disappear; it just got quieter.

Redefining Local, Again

The always-on, drop-in, developer coffee shop model didn’t stop working. It just stopped being universal.

In 2020-2022, everyone needed it because everyone was isolated. In 2025, it serves a specific population: people whose physical environment doesn’t provide the technical community they need. This isn’t new. This population always existed. The pandemic just temporarily made everyone part of it.

The confusion comes from companies who saw engagement numbers during lockdown and thought, “This is what community looks like now.” They built strategies around peak-crisis participation and are now wondering why engagement dropped when the crisis ended.

But for the people who are fully remote, who do work in niche areas, who actually need virtual-as-local? The future of virtual community isn’t choosing between “always-on” and “seasonal engagement.” It’s recognizing that different models serve different needs:

Always-on spaces for people who need virtual-as-local (remote workers, niche specialists, global teams)
Event-driven communities for people who have local networks but want to expand them occasionally
Project-based cohorts for people collaborating on specific initiatives
Hybrid models that acknowledge some members need daily presence while others drop in monthly

The brief era when local went global taught us something important about what community actually requires. Not geography. Not even, proximity.

Rhythm, serendipity, and the willingness to show up wherever you are and be human together.

Those needs haven’t disappeared. But the population experiencing them has returned to its pre-pandemic size—still significant, still vital, just less universal.

The question now is: can we build sustainable models for the people who actually need virtual-as-local, without expecting everyone to need it all the time?

This is the first in a series exploring how our understanding of community has changed from 2020 to 2025. Next: Why companies misread the moment and built communities for everyone when they should have built for someone. When the world redefined community, companies thought they could scale it. But belonging doesn’t scale, at least, not the way they hoped.

A Developer’s Guide to Choosing an AI Coding Assistant That Boosts Productivity Without Overwhelming Your Workflow

rhawrot@gmail.com (Bekah) — Wed, 09 Jul 2025 00:00:00 +0000

Finding the assistant that fits just right.

At Virtual Coffee over the last year, we’ve been talking about our experiences with different AI Coding Assistants. Some of the things I’ve heard include, “It felt like I was constantly being interrupted,” “I barely notice it’s there until I need it,” “Sometimes it feels like it’s micromanaging me, so I turn it off.” A lot of times, it’s the same tool with different experiences.

Over the last couple of weeks, I’ve been writing about my journey to find the right coding assistant, but I thought it would be useful to distill what I’ve learned so far into a simple guide.

This is what I’m calling this “The Goldilocks Problem.” Some AI coding assistants are too intrusive, some are too passive, and some are just right. But that sweet spot depends entirely on you.

This guide is designed to help you find an AI assistant that enhances your workflow without hijacking it.

Step 1: Understand the Types of AI Assistant Behavior

AI tools fall along a spectrum based on how actively they interact with you:

1. The Background Helper (Minimal Intrusion)

Quiet until called upon
Great for deep-focus devs
Acts like autocomplete on demand

2. The Proactive Partner (Moderate Intrusion)

Offers smart suggestions as you type
Balances guidance with control
Ideal for those who like nudges but not noise

3. The Active Collaborator (High Intrusion)

Suggests proactively, refactors on its own
Sometimes takes initiative beyond what you asked
Best for devs who want maximum AI assistance.
Can be fun for vibe coding.

Step 2: Audit Your Workflow Style

The right assistant depends on how you work.

What kind of coder are you?

Flow-state coder: You need focus and minimal interruptions
Burst coder: You are energized by context-switching and quick input

What breaks your concentration?

Are popups or suggestions distracting?
Do you lose focus without a prompt?

How do you prefer to learn?

Learn-by-doing: Prefer code patterns and examples
Learn-by-understanding: Need deep explanations

Step 3: Match Assistant Style to Your Workflow

Once you know how you work, you can align that with the assistant type.

Option 1: Invisible Until Needed

Best for: Experienced devs who want help with boilerplate, syntax, and docs

What Assistant Features to Look for

Autocomplete only for common patterns
Context-aware suggestions that activate on pause
On-demand doc lookup

Tools to try

Continue.dev
GitHub Copilot (with conservative settings)

Option 2: Gentle Guidance

Best for: Developers who want AI help while staying in control

What Assistant Features to Look for

Inline suggestions that feel natural Code completion that adapts to your style Suggestions that teach, not just do

Tools to try

Most assistants with moderate config
Continue’s philosophy is to put the developer in control
Copilot with smart prompt tuning

Option 3: Active Partnership

Best for: Complex projects and devs ready to shift their workflow

What Assistant Features to Look for

Full-project understanding
Multi-file suggestions
Proactive refactors and implementations

Tools to Try

Cursor
Continue.dev (advanced mode)
GithHub Copilot

Step 4: Run a Workflow Integration Test

Before committing, test tools with these 5 workflow scenarios:

The Morning Startup Test Does the AI help you pick up where you left off, or get in the way?
The Deep Focus Test Can you stay in flow, or does it interrupt too much?
The Context Switch Test Does it keep up when jumping between files and tasks?
The Learning Moment Test When you hit something unfamiliar, does it help you understand?
The Cleanup Test Can you read and modify the AI’s code later?

Step 5: Signs an AI Assistant Is Helping Or Hurting Your Workflow

Red Flags (It’s disrupting your workflow)

Constantly fighting the suggestions
Code quality or clarity drops
You rely on it so much that you can’t code solo
You feel anxious when it’s off. (Maybe it’s time to see a therapist too :joy: )

Green Flags (It’s enhancing your workflow)

You forget it’s there until you need it
You’re learning new patterns
You feel more confident and productive

TL;DR: Finding the Right-Fit AI Coding Assistant

If you’re looking for an AI assistant that boosts productivity without overwhelming your workflow try GitHub Copilot or Continue.dev if you prefer minimal interruption.

Choose tools with gentle, context-aware prompts if you want help but not takeover. Explore Cursor or advanced Continue setups for high-involvement AI assistance.

Pros and Cons of the Top AI Code Assistants: Continue.dev, GitHub Copilot, and Cursor (With a Hero’s Twist)

rhawrot@gmail.com (Bekah) — Mon, 07 Jul 2025 00:00:00 +0000

Every great hero needs the right weapon. Captain America has his shield, Aragorn wields Andúril, and David brought down Goliath with nothing but a slingshot and unshakeable faith.

As developers, facing the giants of legacy code, impossible challenges, and the eternal question, “Can you just add one small feature?”, having the right “weapon” can mean the difference in how successful we are. The AI coding assistant landscape is about finding your legendary weapon. It’s about choosing our superhero origin story.

Choosing Your Coding Weapon: A Hero’s Guide to AI Assistants

Continue.dev: Pros, Cons, and Best Use Cases 🪃

Hero Archetype: The resourceful underdog who’s powers lie in adaptability and cleverness.

“For the battles aren’t won by size, but by skill and choosing your shot”

The Metaphor: David’s Slingshot

Everyone expected David to suit up in Saul’s armor, but he looked at that heavy gear and said, “Nah, I’m good with my slingshot.” That’s Continue.dev.

While other tools come loaded with corporate armor and preset strategies, Continue says, “Here’s your slingshot. You choose the stones.”

Pros

Shape-shifting: Works with any AI model you choose (GPT-4, Claude, etc.)
Stealth mode: Can run everything locally
Weapon crafting: Custom assistant creation
Open source: Driven by community improvements

Cons

Slight learning curve for setup and workflows
Less polished UI than commercial tools
Requires some config to reach full power

Best For:

Developers who’ve been burned by vendor lock-in
Power users who want full control
Anyone building their own coding workflows

GitHub Copilot: Pros, Cons, and Best Use Cases 🛡️

Hero Archetype: The steadfast leader who inspires confidence through consistency.

“I can do this all day.”

The Metaphor: Captain America’s Shield

The first Avenger, the one who established what it means to be an AI coding assistant. Steve Rogers’ shield isn’t flashy. It doesn’t shoot lasers. But it’s reliable, trusted by the team, and always ready.

That’s GitHub Copilot.

Pros

Unbreakable consistency: Works the same way every time
Team integration: Easy to roll out across orgs
Battle-tested: Millions of developers rely on it
Seamless with VS Code and GitHub

Cons

Occasionally hallucinates or misinterprets intentions
Offers limited insight into why things break
Not ideal for deeper refactoring or debugging scenarios

Best For:

Developers who want plug-and-play completion
Teams looking for low-friction onboarding
Fast-paced shipping of small features or fixes

Cursor: Pros, Cons, and Best Use Cases ⚔️

Hero Archetype: The chosen one destined for greatness if you’re willing to pay the price.

“Reforged from the shards of what came before”

The Metaphor: Aragorn’s Andúril

Reforged from the shards of what came before, Cursor is VS Code reborn and transformed into something powerful.

Pros

Royal bloodline: Built on VS Code’s foundation
AI-first vision: UI centered around AI workflows
Multi-realm mastery: Understands and edits your whole codebase
Composer magic: Suggests multi-file implementations intelligently

Cons

Premium pricing tiers
Can make sweeping changes outside of scope
Might be overwhelming for newer devs

Best For:

Developers who want deep AI collaboration
Projects involving large-scale refactors
Those ready to go “all in” on an AI-native IDE

TL;DR: Pros & Cons of Top AI Code Assistants

Tool	Pros	Cons
Continue.dev	Open source, model-agnostic, runs locally, educational modes	Not as beginner-friendly, more setup required
GitHub Copilot	Fast completions, trusted by teams, easy to use in VS Code	Can hallucinate, struggles with context-aware fixes
Cursor	AI-native IDE, great for refactoring and large changes, smart UI	Expensive, can overreach and change more than intended

Debugging Mobile Navigation Bugs with AI Code Assistants: Continue vs Copilot vs Cursor

rhawrot@gmail.com (Bekah) — Mon, 30 Jun 2025 00:00:00 +0000

A follow-up to “Which Code Assistant Actually Helps Developers Grow?” This time, testing how AI assistants handle debugging existing code problems.

Last week, I tested three AI coding assistants on building a new feature. This time, I wanted to see how they handle something most developers deal with daily: debugging existing code problems.

I was debugging a mobile responsiveness issue on my Astro + Tailwind site (see the GitHub Project here). The navbar wasn’t collapsing on mobile, causing layout issues. Instead of a full navigation bar cramming into mobile view, I needed a proper hamburger menu. Instead of manually rewriting it, I tested how three AI code assistants—Continue, Copilot, and Cursor—would solve it.

Here’s what I told each assistant:

“There’s an issue with mobile view on the site. I think the main problem is with the navbar. But I don’t think it makes sense to have a nav bar for a mobile site. We should make the site responsive and add a sticky nav bar with a hamburger menu instead of the full navigation bar once the site hits mobile-sized screens.”

TL;DR: I tested Continue, GitHub Copilot, and Cursor to debug a broken mobile navbar in an Astro-based site. Continue offered the best explanations and teaching moments, Cursor was fast but made extra assumptions, and Copilot was fast but error-prone. If you’re debugging UI bugs, Continue’s Chat mode helps you understand why things break, not just how to fix them.

Can Continue Debug a Responsive Nav Issue in Astro?

I used Continue in Agent mode, giving it context from Header.astro, Nav.astro, and BaseLayout.astro.

The Good

Created a dedicated hamburger menu component
Asked for permission between file changes
When I got a transparency issue with the menu panel, it fixed it in one go
It added comments to understand the steps it was taking in the code and debug logs in the code to help me see what was working and when
Everything worked within 12 minutes

The Learning Experience

When I tested the same fix using Continue’s Chat mode instead of Agent mode, it took longer but provided much more thorough explanations. The conversation was more educational, walking me through the reasoning behind each change.

Verdict

Continue balances efficiency with learning. Agent mode got me working code fast, while Chat mode taught me the “why” behind the solutions.

Copilot started by unnecessarily converting a Svelte component, then immediately threw a TypeScript error: Argument of type 'EventTarget' is not assignable to parameter of type 'Node'

I’m not sure why it decided that the ThemeToggleButton needed to be converted. At the very least, that’s outside of the scope of this PR, in my opinion.

It was able to solve the problem pretty quickly when I used the “Fix with Copilot” function, explaining, “You should cast e.target to Node when passing it to .contains() to resolve the type error.”

The Real Problem

The hamburger menu initially didn’t appear at all. The responsiveness was “fixed” because the navigation disappeared, but users couldn’t access any menu items.

After back-and-forth debugging, Copilot resorted to !important declarations (not ideal) and the old “turn the background red” debugging trick. Even when the menu became visible, clicking it did nothing.

Eventually, we identified JavaScript as the culprit. Copilot fixed it, but then the menu links appeared directly over the page content without any background container. More back-and-forth with questionable styling decisions followed.

It was to the point where I definitely could fix this faster than having a back-and-forth with Copilot, so I called it. After that, I also realized there was a bug where, after expanding the hamburger menu on mobile and then switching to desktop view, the mobile menu remained open on top of the restored navigation bar.

Time: About 20 minutes, with me ultimately fixing the styles myself.

Learning Value: Minimal. Copilot told me what it was doing, but didn’t really explain its approach or help me understand the underlying problem.

Cursor Fixes More Than You Ask—Helpful or Harmful?

Cursor’s response was immediate and organized:

The Process

Automatically read the global CSS
Outlined exactly what needed to change and why
Provided all necessary file updates
Hit the same cross-page JavaScript issue as Copilot

The Interesting Part

Cursor went beyond my request, automatically improving mobile styles across the site that I hadn’t asked for. This raises an interesting question: should AI assistants make assumptions about what you “really” need?

Time: About 15 minutes to complete.

Learning Value: Good explanations of changes. I appreciate that it gives more information on why errors were happening in the context of using Astro.

Context Switching Costs

Here’s something I noticed that none of the assistants addressed: familiarity bias. Cursor and GitHub Copilot felt nearly identical to use, so I moved faster with them. Continue required slightly more of a learning curve, which actually slowed me down initially but provided better educational value.

This isn’t a knock against Continue. It’s a reminder that switching tools comes with costs, even when the new tool might be better in the long term.

Debugging vs. Building: Different Skills Required

This debugging scenario revealed something my first test missed, that building new features and fixing existing problems require different AI assistance approaches.

Building New Features

Clear requirements
Blank slate approach
Focus on “what should this do?”

Debugging Existing Code

Understanding legacy decisions
Identifying root causes
Focusing on “why isn’t this working?”

Continue did well with the debugging mindset, asking permission before changes and explaining the reasoning. Copilot and Cursor were more aggressive about “fixing” things, sometimes creating new problems in the process.

Which AI Coding Assistant Wins for Debugging?

For Learning: Continue, especially in Chat mode. It helped me understand not just what was broken, but why the original approach failed.

For Speed: Cursor, if you don’t mind AI making assumptions about improvements you didn’t request.

The Bigger Picture

This comparison reinforced something I mentioned in my first post: the tool is only part of the equation. Each assistant performed differently not just because of their capabilities, but because of how they approached the problem-solving process.

Continue treated debugging as a learning opportunity. Copilot treated it as a code completion task. Cursor treated it as a comprehensive redesign project.

If you want to know which coding assistant helps developers grow when you’re debugging, try this: Before asking for a fix, ask the AI to help you understand why the original code failed. The debugging skills you develop will be more valuable than any individual fix.

Which Code Assistant Actually Helps Developers Grow?

rhawrot@gmail.com (Bekah) — Fri, 27 Jun 2025 00:00:00 +0000

Over the past year, we’ve had a ton of conversations at Virtual Coffee about AI. If you’ve opened up X or LinkedIn, you probably realize that people have very strong opinions about AI. At Virtual Coffee, we’re a pretty close-knit community, so there are a lot of concerns about the impacts of AI, how junior developers grow (or stay stagnant) with AI, whether or not to adopt it as a team, and whether to use it without telling your boss. At the heart of a lot of these conversations is the feeling that you’re somehow “cheating” if you use AI, and that you won’t learn or grow if you’re using it. I think the sentiment comes from the right place, caring about people, but I think there are a lot of options and approaches you can take to prevent that. I believe that when we consider the evolving landscape in tech, we also need to think about the changing landscape of tech education. Most of us will end up using AI in our workflow, either out of necessity or because our team mandates it. That’s why I also think that AI coding assistants actually have the ability to help everyone grow in ways they couldn’t before.

Learning vs. Speed Trap

Your approach to learning with AI assistants definitely matters. And not all AI coding assistants will help increase developers’ coding skills. Learning about the code you’re writing, how your team approaches problems, and how to utilize AI as part of your workflow is necessary to grow in tech. Teams don’t need someone who can prompt their way to a working solution but can’t debug it when it breaks. Most AI coding assistants are optimized for speed and not for learning. They’re designed to get you from problem to solution as quickly as possible. If your goal is skill development, you should think of AI adoption more like onboarding a mentor, rather than replacing you.

Context-Aware Guidance

The most effective learning-focused assistants should understand what you’re trying to do and what you should learn from doing it. They highlight patterns, point out potential issues, and suggest alternative approaches that might teach you something new.

Today, I’m testing out a couple of AI coding assistants on a new feature. (I’m interested in doing a follow-up post that uses it on an existing file. Let me know if that’s something you’d like to see!) I tested out each coding assistant on a new feature I’m adding to my writing site, with this simple prompt:

I want to create a game for this site, where people (not logged in) can add a word to a story. Once the story hits 300 words, it locks the submission. No one should be able to submit more than 3 words in a row.

Here are my takeaways for Continue, GitHub Copilot, and Cursor. I gave the same initial prompt for each of them.

Continue

Continue stands out here because their philosophy explicitly addresses the learning problem. Their documentation talks about “amplifying intent” rather than replacing it, and they specifically warn against becoming a “human clipboard.” You can explore ideas through “vibe coding” during creative phases, but when it comes to production work, they emphasize that developers need to stay in control. It’s open source, model-flexible (bring your own LLM), and encourages creating custom assistants that reinforce your team’s coding standards. For teams focused on growth and increasing their developers’ coding skills, Continue offers both transparency and control.

Before giving me any kind of code, it gave me an initial planning response, outlining a step-by-step approach to the user story. Seeing the plan helps the user to walk through the task with Continue.

After this, it provided commented code along with a reusable template. The inline comments break down some of the logic, and helps the user understand the process it went through to generate the code. After the code, it summarized all the changes it had made. You might notice it mentions Flask, but this is actually an Astro app. That was my mistake. When I initially set up the assistant, I had configured it with Python-focused instructions and directed it to Python documentation, since my rules were originally written for a Python assistant. Once I updated those settings and specifically shared my repository with the assistant, Continue was able to properly follow my project’s styling conventions and leverage the existing components.

Lastly, it gave both an overview of what was implemented and ideas for improvement. I appreciate that it provided more context about its approach, commented code throughout the new file, and offered inspiration for my next iteration.

Without having to ask further questions about the decisions it made and the approach it took, I think it provided a good amount of context for the developer to understand the process.

Copilot

GitHub Copilot is known for excelling at code completion and includes agent-based features. It can speed up repetitive tasks, but the learning tends to happen through osmosis. You need to recognize the patterns in suggestions and might pick them up over time. You have to be more active with your learning by asking Copilot about the decisions it made.

Copilot’s approach was a lot different from Continue’s. It jumps straight into code generation without context-setting or explanation of its approach.

It did provide a “wrap up” after the code, but it wasn’t as thorough or complete as what I got from Continue.

For what it’s worth, Copilot also told me that creating a Svelte component was the best option, and then, when I questioned it, Copilot told me that Astro was actually the best path. It was flexible with the approach once I questioned it, but it definitely required me to go down the rabbit hole with it. Learning is definitely passive with Copilot.

Cursor

Cursor offers an AI-first editor experience with agent modes, but their emphasis on “AI that builds with you” raises questions about how much actual building the developer is doing during complex tasks. Although I’m just doing a basic test for this post with a brand new feature, I did experiment a bit with its interactive, AI-native IDE experience by highlighting some of the code it generated and asking, “What does this do?” I plan on doing more of that in a follow-up post for comparison.

After being given the same prompt as Continue and Copilot, Cursor walked me through the approach it was taking and included what files it looked at to get there. However, it automatically created a Svelte file for the game (I did have Svelte installed in the project), and I had to do a lot of back and forth with it to understand the decisions it made and why. I’ve actually never used Svelte, so this was something I had to dig into deeper to understand.

One of the things I appreciated about Cursor’s experience was that it explained piece by piece and required me to accept changes. That forces the user to think about what’s being implemented. It also auto-corrected some of its own errors, which is a good learning opportunity to see how it debugs.

I wish it would have automatically added code comments throughout, but the explanations were valuable. The takeaways at the end walked through what the user could do and the functionality. It was more thorough than Copilot, but I liked the improvements suggestion that Continue had.

Building a Learning-First AI Strategy

I think this exploration is important for new folks coming into tech, and for teams serious about using AI to help their team grow and not just ship faster. The path here should:

Start with Intent: Before adding any AI tool to your workflow or your team’s, clearly define your goals. Are you trying to help yourself or junior developers on the team understand architectural patterns? Learn a new framework? Improve code review skills? Different learning goals might call for different AI approaches.
Choose Tools with Teaching DNA: Look for AI assistants that were designed with education in mind, not just productivity. Continue’s emphasis on amplifying developer intent rather than replacing it is a good example of this thinking.
Implement Learning Safeguards: Whatever tool you choose, build processes that encourage learning by requiring explanations for AI-generated solutions, having regular code review focused on understanding, not just correctness, adding pair programming sessions where AI suggestions become discussion points, documenting decisions and trade-offs.
Measure Learning, Not Just Output: Track whether your developers are asking better questions over time, not just whether they’re closing tickets faster. Are they suggesting alternatives during code review? Can they debug issues in AI-generated code? Are they learning patterns they can apply without AI assistance?

We want developers who are using AI to understand problems. That’s the difference between an AI assistant and an AI mentor.

Wrapping Up

I think the best AI coding assistant for individuals and teams focuses on developer skill growth. Based on philosophy, approach, and explicit focus on learning, Continue seems to understand this distinction better than most. But the tool is only part of the equation. The bigger part is approaching AI adoption with learning as the primary goal, not just productivity. The most productive teams and developers understand what they’re building, whether with or without AI help.

Comparing 5 AI Coding Assistants: Which One's Right for You?

rhawrot@gmail.com (Bekah) — Tue, 24 Jun 2025 00:00:00 +0000

A couple of days ago, I saw Jerome Hardaway’s LinkedIn post, and it really resonated with me. I like the idea of thinking of AI coding tools as “really great intern[s]. Fast, helpful, capable in the right hands – but still needs supervision, clear direction, and someone to clean up afterward.” There are a couple of projects that I’m working on this summer: the author site that I share with my brothers that uses Astro, a new project I’m launching for osscommunities.com. This seems like the perfect opportunity to find the right tool that’s worth adding tool to my workflow.

My AI Assistant Philosophy

I’ve always been a proponent of using AI just like any other tool in your toolbox. It’s there to help you level up, work more effectively, and move faster. If I were a carpenter who was too afraid or skeptical to try a hammer, I wouldn’t be as effective as other carpenters. And honestly, as a mom of four, I’ve been looking for ways to be more efficient for years.

As we all know, your coding assistant is only as good as you guide it to be. You have to make sure to correct it when it hallucinates, to double-check its work, to help it understand what you actually need. For me, it’s all about finding the best partner for the work I’m doing.

AI Assistant Tools & Their Promises

I chose these five AI coding assistants based on different approaches to the same problem: Continue.dev for its open source flexibility and developer-first philosophy, Cursor for its AI-native editor approach, GitHub Copilot as the established market leader, Tabnine for its enterprise angle, and Windsurf as the rebranded dark horse. In my opinion, these represent the current landscape of AI code completion tools, from open source flexibility to enterprise privacy to AI-first design philosophies. Here’s a little more on each:

1. Continue.dev

Their Promise: Amplify developers, don’t replace them.

My Expectation: I think Continue.dev’s chat, autocomplete, edit, and agent modes in one tool sounds interesting and comprehensive. I’m hoping this flexibility translates to better suggestions for my workflow.

2. GitHub CoPilot

Their Promise: AI that builds with you

My Expectation: I’ve used CoPilot before, so this is the obvious choice since I already have experience with it. But I’m really curious to compare it to other tools out there to see how it stacks up.

3. Cursor

Their Promise: Cursor is a powerful AI-first code editor that enhances your development workflow.

My Expectation: The real test for me is whether building the editor around AI from day one actually feels different than VS Code with AI-extensions and whether or not the experience feels disjointed.

4. Tabnine

Their Promise: Tabnine claims that it is the world’s most contextually aware AI software development platform, helping mature engineering teams speed up and simplify their entire development process.

My Expectation: They seem to be targeting enterprise developers, but I’m curious if their focus on “mature engineering teams” translates to better suggestions for solo projects like mine.

5. Windsurf

Their Promise: Windsurf is a next-generation AI IDE built to keep you in the flow.

My Expectation: The “dream bigger” messaging is heavy on inspiration, but there’s not a lot of specifics. I want to see how well that translates to the user experience.

What’s Next?

I’m not looking for the tool that writes the most code for me. I’m looking for the best AI coding assistant that makes me a better developer while helping me ship faster. The goal isn’t just to find another autocomplete tool. My goal is to discover which AI code assistant deserves a permanent spot in my development workflow. Whether that ends up being Continue.dev’s customizable approach, Cursor’s seamless integration, or one of the other contenders, I’ll share what I’ve learned in the coming weeks. Stay tuned for the full AI coding assistant comparison and see which tool actually lives up to the productivity promises.

Test Drive Before You Buy: Your Guide to AI Code Assistant Trials in 2025

rhawrot@gmail.com (Bekah) — Mon, 23 Jun 2025 00:00:00 +0000

In my last post, I talked about spending time this summer looking at different AI tools. I want to get hands-on, figure out what I want to integrate into my workflow. But before I spend time (and money) testing things out, I wanted to start with the free/trial periods. So you’re starting at the beginning of this journey with me. The question that I started with is: Which AI code assistants will actually let me take them for a proper test drive? In this post, I’ll share what I found across five top AI Coding Assistants—Continue, Windsurf, Cursor, GitHub Copilot, and Tabnine—and what I’m interested in learning as I put them to the test.

The Trial Landscape: What’s Actually Available with AI Assistants

After digging through pricing pages, here’s what you can try without putting in your credit card:

Continue.dev is one of the most flexible and accessible AI Coding Assistants out there. It’s open source, which means you can literally use it forever for free if you just bring your own API keys, and it supports any model you choose, including Claude 4 Sonnet, 4o, llama3.1 8b. Continue’s IDE extension has gained a lot of recent attention (20K+ GitHub stars), and integrates into tools that you might already use (VS Code and JetBrains). You can also create public assistants and invite your entire team.
Windsurf surprised me here. Their free tier includes 25 prompt credits per month, all premium models, unlimited Fast Tab completions, and even a 2-week Pro trial to test the advanced features. Built by the Codeium team, it’s essentially giving you a full-featured AI IDE for nothing. The supercomplete feature claims to understand your entire workspace to give intelligent suggestions across files.
Tabnine offers a “Dev Preview” that’s completely free for qualified users, giving you AI code completions for current line and multiple lines, plus AI-powered chat. There’s also a paid Dev plan at $9/month with more advanced features. The Dev plan includes their foundational AI agents that can autonomously generate code, tests, docs, and fixes.
Cursor gives you a Pro two-week trial as part of their free Hobby plan, plus 2,000 completions to play with. After that, their Pro plan is $20/month. It’s a significant jump but with unlimited agent requests and tab completions, two weeks is enough time to test their agent mode on a real project and see if the autonomous coding capabilities live up to the hype.
GitHub Copilot offers a solid 30-day free trial on their Pro plan before charging $10/month. Thirty days is actually enough time to see if it clicks with your workflow or just generates more bugs than it fixes. Since it’s deeply integrated in the GitHub ecosystem, you’ll be able to see how well it understands project context.

What to Actually Test During Your Trial

I want to avoid some of the common problems I hear developers talk about when they sign up for AI Coding Assistants. I want to do more than test drive a car and park it in a lot. Here’s the approach I’m trying to take:

The Real-World Gauntlet

Test it on your actual codebase. I have some existing projects that I’ve created over the years. My blog is a Jekyll site that I have done only enough updating to keep things running over the past couple of years. It definitely has some “why did past me write this” code in the codebase. I want to make sure that AI can handle past me. (I’m actually interested in creating a Continue assistant to help update my Jekyll site.)
Try it on unfamiliar territory. I need my AI Coding Assistant to be a force multiplier. When I’m working in my strengths, it doesn’t take me as long. But when I use it with code that I’m not super familiar with, I need it to be good. I don’t want it to help me write bad code faster. Test both scenarios. I have a new project I’ve been wanting to work on, and this seems like a good use case.
See how it handles context. Can it understand your team’s coding conventions? Does it remember what you were working on five files ago? Context awareness separates the good from the great. This is not applicable for what I’m working on right now, but this is super important if you’re working with a team.

The Stress Test

You should try to push these tools to their breaking point. (Semi-related, I posted about LLMs giving up when we need them the most. Feel free to add to the conversation! Ask them to refactor a complex function. Have them write tests for edge cases you know are problematic. See if they can debug that one weird issue that’s been haunting your team for weeks.

The goal is to find the AI Assistant that fails gracefully and teaches you something useful in the process.

The Hidden Costs

This is where the trial period becomes really important. Most AI assistants have usage-based pricing that can get out of hand really quick. You can eat through your budget if you’re not careful. During your trial, pay attention to those usage meters since they’re previewing your future bills.

Start with the free tiers. Continue if you want maximum control, Windsurf if you want simplicity, Tabnine if you just want better autocomplete.

Use the trial period to answer this question: Does this tool make you a better developer, or just a faster typist? At the end of the day, you’re responsible for all production code you ship. If you don’t understand your code, AI is a temporary solution to your problem, and that approach can end badly.

Here’s your homework (and we can do it together, just comment which one you’re testing below!):

Pick one tool from the list above
Set it up on your current project
Use it for a week on real work (not tutorials)
Ask yourself: “Am I learning, or just copying?”

I plan on starting with Continue and working my way through the list.

The right AI assistant will enhance and amplify your skills, not replace them.

Taking Time to Breathe: A New Chapter Begins

rhawrot@gmail.com (Bekah) — Tue, 10 Jun 2025 00:00:00 +0000

As of June 1st, I’m no longer with the Linux Foundation. While I’ll share more details about this transition in a future post, I wanted to take a moment to reflect on what comes next.

Going through an acquisition is intense, especially when you’re leaving what was truly your favorite job. The experience has been both professionally enriching and personally challenging, and I’ve realized how important it is to give yourself permission to pause and process major changes rather than immediately jumping into the next thing.

So that’s exactly what I’m doing this summer: taking a pragmatic approach to my career and family life. I’m giving myself time to breathe, to explore opportunities I didn’t have bandwidth for before, and to be intentional about my next steps.

What’s Coming This Summer

My primary focus for the coming months will be diving deep into AI tools and their practical applications. I’ve been wanting to explore more AI tools, but I haven’t had the time to until now. As someone who’s spent considerable time thinking about content strategy and audience development, I’m fascinated by how AI is reshaping not just what we create, but how we create it.

You can expect a lot of AI-related content from me in the weeks ahead. I don’t have an exact plan mapped out, so it might be everything from tool reviews and practical use cases to my thoughts on how these technologies are changing the content landscape.

Looking Forward

I’ll have more to share about my long-term plans soon, but for now, I’m embracing this period of exploration. Thanks for following along on this journey. The next few months should be interesting.

Beyond Stars and Forks: Why Open Source Needs Better Collaboration Metrics

rhawrot@gmail.com (Bekah) — Thu, 29 May 2025 00:00:00 +0000

When we were working on the Intro to Open Source course, one of the biggest painpoints we noted with new contributors was the frustration they felt when their PRs weren’t merged in in what they felt was a reasonable amount of time. They had done their research, found an issue, gotten assigned, and then…nothing. No feedback. No merge. Just silence.

It’s a familiar story. I’ve had contributors tell me, “My PR has been sitting there for two weeks and I haven’t heard a thing.” And I get it. There are so many reasons this happens, including burnout, abandoned projects, the lottery factor, and it’s rarely about bad intentions. That’s why I always tell contributors to join the community before contributing. It helps you understand the project’s rhythms, how to communicate with maintainers, and whether it’s a space that supports new members.

If you’ve read anything I’ve written in the last five years, you know I care deeply about the open source community. But how we have traditionally evaluated projects and metrics doesn’t give enough insight into the most meaningful parts. A lot of times, these metrics—stars, forks, downloads, and DORA metrics—miss the most important part of the story: how people collaborate.

A Different Approach to Open Source Metrics

Since OpenSauced shut down, I’ve been exploring different options for understanding the collaboration problem. Collab.dev isn’t a replacement for OpenSauced, but it’s telling a different (and important) part of the story and capturing how people collaborate. It surfaces the human patterns behind the code, like review responsiveness, contributor distribution, and merge dynamics. Industry-accepted metrics like DORA are valuable for understanding software delivery performance, but not so much in the human department. They can tell you how fast code gets deployed, but not whether contributors feel supported, welcomed, or left in the dark. Open source is as much about relationships as releases, and we need metrics that reflect that.

The Collaboration Visibility Gap

The problem isn’t just that our current metrics are incomplete. Vanity metrics have been touted as meaningful indications of the project’s health, and, to be direct, they’re just not that important.

If we consider the challenges maintainers face every day, we’ll see that it’s often difficult to:

Identify which contributors are most likely to become long-term participants.
Pinpoint exactly where the review process stalls or breaks down.
Understand if the community environment genuinely feels welcoming to newcomers.
Distinguish between sustainable growth and problematic scaling.

The path isn’t clearer for potential contributors either. They often struggle to determine:

Whether the project actively reviews and merges community contributions.
How long it typically takes for contributions to be reviewed.
Which maintainers are most responsive in the contributor’s area of interest.
If there’s a healthy balance between contributions from the core team and the wider community.

For many of us, we have to make a decision about where to invest our time and energy. It can be a real letdown if we’ve invested time and realized we made the wrong decision, coming out of it with nothing to really show for the work we’ve done. For instance, I wanted to learn more about cognee, an AI Memory management framework, recently, so I created a collab.dev cognee page to learn more about the collaboration happening. When you first look at cognee on GitHub, it looks like a growing open source project with a decent star count, active issues, and regular commits. But looking at Collab.dev’s dashboard, I get a richer story.

The Story Cognee’s Data Tells through Collab.dev

Contributor Distribution

When we think about good contributor distribution in an open source project, that usually means responsibilities, activity, and knowledge aren’t tied to a few people. Distribution allows for decreased burnout, project resilience, and creates a more welcoming environment. What we see with cognee is a genuinely balanced project. With 51% of contributions coming from the core team and 49% from the community, cognee has built real community ownership without abandoning maintainer responsibility, and we can make a connection with a collaborative environment and higher motivation to support the project from the community.

PR Lifecycle Metrics

It continues to get interesting. The review funnel shows that 88% of PRs receive reviews and 85.2% get approved. That approval rate tells a story about quality control and contributor experience. It suggests that either the project has excellent contribution guidelines that help people submit good PRs, or the maintainers are actively helping contributors improve their work rather than just rejecting it. On top of this, there’s a quick turnaround with a median response time of 1.9 hours and 42% of reviews happening within an hour. They’re not waiting three weeks for a review. The maintainers are cultivating a positive contributor experience through their responsiveness.

What this tells us about the Human Story

As a maintainer, I’ve been in the situation where I don’t have the capacity to immediately respond to contributors, and sometimes they even have to wait weeks for my response. Obviously, this isn’t ideal. Usually, what happens is that the person has moved on, they may not respond at all, or they’re less likely to contribute again. What we see from cognee’s numbers is that they don’t have that same problem.

When someone contributes to cognee, they aren’t left wondering whether or not their efforts are valued. They get fast enough feedback to stay engaged and iterate quickly. Their turnaround time for a review (1.6hrs) is a good way to encourage repeat contributors. Additionally, with a median merge time of 19.5 hours signals to contributors that their work has real and immediate impact. And they’re able to see their contributions available to users.

The Collaboration Pattern

When you look at these metrics together, they’re telling a story of intentional collaboration design, a story that thinks about the contributor and maintainer experience. They’ve created systems and habits that make collaboration feel responsive and worthwhile. What’s telling about this data is also what’s not happening. We don’t see any pile-ups of unreviewed PRs. There are no huge gaps between approval and merge. There are no signs of contributor frustration or maintainer overwhelm.

This collaboration story matters, not just to show that cognee looks like a good place to contribute, but because this can become a replicable story. Other projects can learn how to make collaboration feel good for the contributors involved. We can look at the data and the project and better understand what systems and practices created these patterns, and we can reach out to maintainers of projects we admire to ask: How do you build review workflows that are both thorough and fast? How do you maintain quality while staying responsive to community contributions?

Collaboration quality doesn’t have to be something we guess at. We can learn more through the data and find projects that have the capacity to take contributions from community members. (And if you’re interested, collab.dev also has a nifty comparison tool. You can check out my mem0 v. cognee comparison.)

The Bigger Picture: Measuring What Matters

We’re in a stage of open source where complex human dynamics determine whether open source projects succeed or fail. Collaboration metrics can help lead to better outcomes. When we measure collaboration effectively, we can:

Reduce contributor burnout by identifying overwhelmed maintainers
Increase successful first contributions by directing early contributors to responsive projects
Build more sustainable projects by understanding what healthy collaboration looks like
Create feedback loops that help projects improve their community practices

In open source, we’ve proven that collaborative development can create incredible value, but we can’t ignore the sustainability challenges, maintainer burnout, and the difficulty of scaling human collaboration.

Better visibility into collaboration patterns can help us to understand the future health of open source. We need tools that help us understand not just what code exists, but how effectively people work together to create and maintain it.

Open source has always been about people working together. Our metrics should reflect that meaningful work.