BekahHW

Ownership, Not Origin

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

A Treatise on Writing in the AI Age, Part 5

Let me go back to where this started. A moderator on Dev.to flagged my post and told me to disclose AI-generated work. Four essays later, I can finally say precisely what was wrong with that moment.

It wasn’t that they were rude. They weren’t. It wasn’t even that they were mistaken about my process, though they were. It’s that they were asking a question with no useful answer. “Did AI touch this text” tells you nothing about whether the text deserves your trust. The moderator was auditing my tools when the only thing worth auditing was my thinking.

So here is the standard I’m arguing for, as plainly as I can put it.

Judge writing by ownership, not origin.

What ownership means

Ownership isn’t a feeling. It’s a set of claims a writer makes by publishing, and it’s checkable.

When I put my name on a piece, I’m claiming the ideas are mine or credited to whoever they came from. I’m claiming I verified what I stated as fact. I’m claiming I can defend every argument in it, extend it, answer the hard comment underneath it. I’m claiming that anything presented as my experience actually happened to me. And I’m accepting that if any of that turns out false, the failure is mine. No tool absorbs the blame.

Notice what’s absent from that list. Nothing about which hands or machines shaped the sentences. A ghostwritten memoir can pass this test. A fully hand-typed post full of unverified claims fails it. The test tracks what readers actually care about, which is whether a mind stands behind the words.

Notice also what’s demanding about it. Ownership is a higher bar than origin, not a lower one. Typing every word yourself is easy to satisfy and proves nothing. Being able to defend every word is hard, and it’s exactly what AI-era writing threatens when it goes wrong. The writer who pastes a generated draft they barely read fails the ownership test spectacularly. I’m not offering AI users an escape hatch. I’m offering everyone a stricter standard aimed at the right target.

The verification objection

Now the strongest objection, the one I promised myself I’d answer honestly. A skeptic says: this is lovely, but readers can’t verify ownership any more than moderators can verify AI use. You’ve traded one unenforceable standard for another.

Here’s my answer. Ownership was never verified by inspection. It’s verified by accountability over time, and we already know how that works because it’s how writing trust has always worked.

You trust a writer because they respond substantively when challenged in the comments. Because their body of work holds together, one piece building on another. Because when they got something wrong last year, they said so and corrected it. Because their claims, when you happened to check one, checked out. Because the community around them has watched them think in public for years.

None of that requires process forensics. All of it is visible. A writer faking ownership can survive one post, maybe several. They cannot survive sustained engagement, because you can’t defend thinking you didn’t do. The comment section finds you out. The follow-up question finds you out.

Enforcement follows the same logic. Platforms can’t police process, and shouldn’t try. They can absolutely police the checkable claims. Plagiarism is detectable in the artifact. Fabricated facts are checkable. A writer who can’t engage with substantive challenges to their own post is telling you something. Those levers exist today. They’re just not being pulled, because badge-printing is easier.

What honest transparency looks like

Am I against all disclosure, then? No, and this distinction matters.

I share my process frequently in conversations and writing, and I plan to keep doing it. I talk about how I use AI to stress-test arguments, where it saved me hours, where it produced garbage, and I threw the garbage out. That kind of transparency teaches. It helps others develop the judgment that the stigma machine is currently preventing anyone from developing.

But there’s a world of difference between transparency I offer and a confession I’m compelled to make. Offered, it’s craft talk between writers, the same as explaining my outlining habit or my editing passes. Compelled, under stigma, it’s a mark. Same information, opposite meaning. The mandate poisons the very openness it claims to want, because nothing kills honest process-sharing faster than making it an admission of guilt.

If platforms want a disclosure culture, the path isn’t a checkbox. It’s destigmatization. Make process talk normal and interesting rather than incriminating, and writers will tell you more than any policy could extract.

Writing in the age of good tools

I’ve been teaching people to write, in one form or another, for most of my adult life. College classrooms, developer communities, my own kids at the kitchen table. And here’s what I believe after all of it. Writing was never sacred because of the typing. It was sacred because a person committed their mind to the page and signed their name to the result.

That commitment is still available to every one of us. No tool grants it and no tool revokes it.

So publish the post. Use the tools that make your thinking sharper and refuse the uses that replace your thinking. Verify what you claim. Credit who you learned from. Stand in the comments and defend what you wrote. Own it, all of it, and let the origin police tire themselves out.

And if you’ve been sitting on a draft because you used AI somewhere in the process and the badge scared you off, I’ll leave you with the only disclosure question that ever mattered.

Is it yours?

If it is, hit publish.

The Wrong Problem

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

A Treatise on Writing in the AI Age, Part 4

This story won’t resonate with everyone, but I’ve heard it enough to know that it’s uncomfortably common. You’ve published something you worked hard on. It could be a blog post, a twitter thread, a video, a course, some sort of content that you’ve put time and attention into. Then weeks or even days or hours later, you find your idea living in someone else’s post. I’m not talking about having the same idea as someone else. I’m talking about someone ripping your ideas, presenting them as their own, and taking credit for them. There’s no citation, link, or acknowledgment that you even exist.

On many platforms, there’s a strong stance against plagiarism, including removal of the post, suspensions, and bans. Let’s look closely at what makes that a good policy. It targets the harm itself. It’s checkable in the artifact. And it never asks what tool was involved. Steal by hand or steal by model, the violation is identical, because the reader’s injury is identical.

Now hold the AI disclosure mandate next to it. No harm requirement. Nothing checkable in the artifact, which is why enforcement runs on appearance. And the tool isn’t incidental to the rule. The tool is the rule. The same platform wrote both policies, and only one of them protects anyone.

That asymmetry is the tell. Platforms have decided that a machine touching your own ideas is a policing priority, while a human taking someone else’s ideas is a shrug. Whatever problem they think they’re solving, it isn’t reader betrayal, because this is what betrayal actually looks like.

What actually harms readers

Set aside tools entirely and ask what makes writing bad for the person reading it.

Ideas presented as original when they were lifted from someone uncredited, claims stated confidently that nobody verified, content written to game an algorithm rather than to say anything. Padding, filler, the eight-hundred-word wind-up before the answer. Recycled conventional wisdom wearing a bold headline.

Every one of those predates AI. Every one of them is thriving right now, by human and machine hands alike. And every one of them is measurable in the artifact itself, no process forensics required. You don’t need to know what tool produced an unverified claim to know it’s unverified.

Protecting readers from those harms would mean citation norms with teeth. Plagiarism response that actually responds. Quality signals that reward substance. And I want to be fair here, because that’s brutally hard work. Slow, expensive, full of judgment calls, and most platform teams are small, stretched thin, and staring down a content flood they didn’t create. I have real sympathy for anyone holding that backlog.

A disclosure checkbox is none of those things. It ships in a sprint.

The fear response

I don’t think platform teams are cynical. I think they’re afraid, and I understand why. AI dropped the cost of producing plausible text to nearly zero, and every open publishing platform is staring at a real flood of low-effort content. Something had to be done.

But look at what “something” became. The flood is a quality problem. Low-effort content was always the enemy, and AI just made it cheaper to produce. The honest response is to get better at detecting low effort. That’s hard. So instead, platforms reached for a proxy. AI produces the slop, therefore mark the AI.

The proxy fails in both directions. It misses the humans who were producing slop by hand all along and will keep producing it, badge-free. And it catches the writers using AI carefully in service of real thinking, who are producing exactly the substance the platform claims to want.

We’ve seen this pattern before, and not just in writing. When a real problem is hard to measure, institutions measure something adjacent and easy, then defend the metric instead of the mission. Every developer who’s been judged on lines of code knows how this story goes. The metric becomes the target, the target gets gamed, and the original problem sits there untouched.

The problem we’re not allowed to name

There’s one more layer, and it’s the uncomfortable one.

Some of the resistance to AI-assisted writing isn’t about readers at all. It’s about writers, and about identity. If writing well took years to learn, and a tool now closes part of that gap for others, the instinct to defend the moat is human and understandable. We’ve never accepted “it threatens my position” as an argument in open source, in education, in any community worth belonging to. Gatekeeping dressed as quality control is still gatekeeping. The developers who sneered at Stack Overflow users, the photographers who sneered at digital, the writers who sneered at bloggers. History doesn’t remember the moat-defenders kindly, and it definitely doesn’t remember them as right.

The question was never how to keep writing hard. It was how to keep writing honest. Those are different projects, and the disclosure mandate serves the first while claiming the second.

So if tool-marking is the wrong standard, what’s the right one? What would a norm look like that catches the plagiarist and the fabricator, protects the newcomer and the craftsperson, and doesn’t care which keyboard the sentences came through?

That’s the last essay, and it’s the one this whole series has been walking toward.

The Stigma Machine

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

A Treatise on Writing in the AI Age, Part 3

Let’s do a small experiment. Imagine two identical blog posts. They have the same ideas, structure, sentences. Everything is the same except example one has a small grey badge that says, “AI-assisted” and the other example doesn’t.

Which one do you read more generously? Which author do you assume worked harder? If you shared one with your team, which would it be?

If you hesitate, you understand why “it’s just a label” is a fiction. A label is never just a label when it arrives carrying a verdict.

What the badge actually says

In theory, an AI disclosure badge is neutral metadata, like a timestamp or a word count. But in practice as things stand in 2026, it reads as a confession. It says this writer took a shortcut. It says “be skeptical of this one.” It says the person behind these words is a little less of a writer than the ones without the badge, and depending on who’s reading, maybe a little less honest too.

You don’t have to take my word for the verdict part, because sometimes the platform says it out loud. On Dev.to, the disclosure tag for AI-assisted articles is #ABotWroteThis. Assisted, not just generated. For reference, when I put my post into ZeroGPT, it’s identified as human-written except 6.2%.

Develop the ideas yourself, verify every claim, edit for hours, and if a model helped anywhere in your process, the prescribed label on your work reads a bot wrote this. That’s not metadata. That’s a verdict with a hashtag. And if you decline to apply it, the guidelines note that moderators can attach it to your post for you. The platform reserves the right to put words on your work that you believe are false.

That’s not what disclosure advocates intend. Intent doesn’t matter here. Stigma lives in reception, not intention, and right now the reception is unambiguous. Writers know it, which is why disclosure feels less like transparency and more like being asked to pin a note to your own work saying “discount this.”

So the mandate creates an impossible choice for exactly the writers doing things right. Disclose honestly and watch readers disengage before evaluating a single idea. Or stay silent and risk being flagged, accused, and moderated.

The one on my post spelled it out. Comply, or admins may lower your post’s score so fewer people see it, or unpublish it altogether. The badge suppresses your work socially. Refusing it suppresses your work algorithmically. There’s no door out of that room.

The careless never face this choice. They just don’t disclose. Stigma-backed mandates punish honesty and reward shamelessness. That’s not a side effect. That’s the predictable mechanics of the design.

The accusation engine

And the enforcement side is worse, because AI use isn’t visible. A moderator cannot see your process. They can’t see the weeks of thinking, the validated research, the edit passes. All they can inspect is the artifact, so enforcement inevitably becomes inference. Does this prose feel generated?

Think about what that selects for. Clean structure, polished transitions, consistent tone, error-free grammar. The signals moderators and detection tools treat as machine-like are the same signals writers spend years learning to produce. We’ve built a system where craft itself is evidence against you.

I felt this personally when my own post got flagged. But the people I worry about aren’t established writers with communities who’ll vouch for them. It’s the newer writers. The developer publishing their third post, still unsure they belong, told by a moderator that their work doesn’t look like their own. Some of them will add the badge to avoid trouble. Some will stop publishing. I’ve spent years telling those exact people to hit publish. This system tells them something different.

The best case for the other side

Now the part where I argue against myself, because this series doesn’t deserve to survive if it can’t.

The strongest argument for disclosure isn’t about quality. It’s about trust. Readers form relationships with writers. When you read someone’s personal essay about burnout, part of what moves you is the belief that a human lived it and a human shaped it. If you later learned a machine wrote it, you’d feel betrayed, and that feeling would be legitimate. Deception through implied authorship is real, and “caveat lector” is a cold answer to it.

I think that argument is right. I want to be honest about that.

Where it goes wrong is the leap from “deception is bad” to “tool disclosure prevents it.” The betrayal in that scenario isn’t the tool. It’s the false implicit claim. A writer who presents machine-generated experiences as lived ones is lying about something specific, the same way a writer who fabricates a story by hand is lying. We already have a name for that, and it isn’t “AI use.” Meanwhile the writer who used AI to sharpen an essay about their own real burnout hasn’t deceived anyone about anything a reader actually cares about.

The mandate can’t tell those two writers apart. The badge marks both, deters the honest one, and does nothing to the liar, who was already comfortable lying.

The truth is, trust between writers and readers is worth protecting. That’s exactly why we can’t outsource it to a checkbox that measures the wrong thing.

What stigma costs us

Here’s what keeps me up about this. AI, used well, can make writing better. It can push you to consider the counterargument you were avoiding. It can surface the source you’d never have found. It can free the hours you were spending on mechanical polish and give them back to thinking. Used badly, it produces exactly the formulaic sludge everyone fears. The difference is entirely in the writer.

Stigma erases that difference. It teaches a generation of writers that the tool is shameful rather than teaching them what shameful use of the tool looks like. We’re not developing judgment. We’re developing secrecy.

And while all this energy pours into marking who touched which tool, the problems that actually betray readers go unpoliced. That’s the next essay. Because the most damning thing about the stigma machine isn’t what it does. It’s what it lets platforms avoid doing.

The Disclosure Double Standard

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

A Treatise on Writing in the AI Age, Part 2

For most people, writing a blog post isn’t solitary work. It’s start with talking to your friend over coffee and the question they ask that changes your perspective and leads you to reframe the whole thing. Then there’s the spellchecker and grammarly that give you one-click fixes and improve your voice. If you’re lucky enough, you have an editor or a teammate or colleague willing to read it over and give you feedback that leads to your third or fourth or fifth revision. And none of them appears in your byline. You’ve never been asked to disclose a single one.

But now that AI has entered the arena, you’re expected to wear a badge.

The rule we never had

Ghostwriting is the clearest tell. For a century, public figures have published books they didn’t write. Not books they wrote with help. Books where someone else produced every sentence, and the named author’s contribution was a series of interviews and a final approval. The industry is respectable, professionalized, and almost entirely undisclosed. Readers buy the memoir, connect with the story, and nobody calls it fraud.

Let’s be clear about what that means. Our writing culture has already decided that full delegation of the actual writing is acceptable, as long as the ideas and the accountability belong to the named author.

So the standard was never “you must write every word yourself.” It couldn’t have been. Editors restructure. Translators rewrite entirely. Co-authors merge beyond untangling. Writing has always been more collaborative than the solitary-genius myth admits, and readers have always been fine with it.

The disclosure mandate invents a purity standard that never existed, then applies it to exactly one tool.

The label that can’t label

Even if we granted that AI is different in kind, the mandate would still fail on its own terms, because “AI-assisted” doesn’t describe anything.

Consider what fits under that one flag. Fixing typos. Brainstorming titles. Summarizing a paper you then read yourself. Arguing with a chatbot to stress-test your thesis. Generating an outline. Generating a draft you rewrite completely. Generating a draft you don’t.

Those are wildly different acts with wildly different implications for the reader. Some of them involve less delegation than hiring an editor. One of them is closer to ghostwriting. A single checkbox flattens all of it into one undifferentiated confession.

A label that carries no information isn’t disclosure. It’s ritual.

We’ve been here before

Every writing tool arrives to the same funeral music.

Photography was going to kill painting, and for decades photographers fought to be considered artists at all, because the machine did the work. Word processors were going to ruin prose, because revision would become too easy and writers would stop thinking before typing. Calculators were going to destroy mathematical minds. Spellcheck was going to breed illiterates.

Each time, the panic confused the tool with the thinking. Each time, we eventually figured out that the craft didn’t live in the mechanical layer. Painting survived because painting was never just image production. Writing survived the word processor because writing was never just typing.

I don’t say this to wave away every concern about AI. I recognize that AI can hollow out writing in a way spellcheck can’t, if you let it do your thinking instead of your typing. That distinction matters enormously. It’s the difference between a tool and a replacement.

But notice what that distinction is. It’s not about which tool touched the text. It’s about who did the thinking.

Which is exactly what a disclosure checkbox cannot capture.

What the double standard reveals

Why does one tool get a mandate when a century of ghostwriting got a shrug?

Because the mandate was never derived from a principle. If platforms had started from “readers deserve to know how work gets made,” they’d have built process transparency for everything, and the absurdity would have been obvious immediately. Imagine the disclosure form: Did you discuss ideas with your spouse? Did you read the competitor’s post first? Did an editor rewrite the conclusion?

Nobody wants that, because readers never needed it. What readers needed was a writer who stood behind the work.

There’s even a version of this buried in my own story, and nobody flagged it. I found it myself, reading the guidelines the moderation comment linked. My post went out under my personal account and talked about how one of the features we just launched helps to fill a gap teams face when it comes to writing skills. As far as I understand, that’s allowed on the platform. Company blogs share product content there every day. But the AI guidelines add a special rule. AI-assisted articles shouldn’t promote any business, program, or course, including your own. Trace the logic. A human-drafted post can discuss the product it’s about. The identical post with AI anywhere in the process cannot. Same words, same reader, different rules, and the only variable is the tool. That’s not reader protection. That’s a purity test.

The AI mandate exists because AI is new and frightening, and new fears demand visible responses. It’s not a standard. It’s a nervous gesture wearing a standard’s clothes.

What if we asked the question the mandate skips? Not “did a machine touch this text” but “did a mind own it.” That question has an answer worth knowing. The next essay is about what happens when we settle for the wrong question instead, because the cost isn’t hypothetical. It has a name, and the name is stigma.

Why We Write

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

A Treatise on Writing in the AI Age, Part 1

Last week, one of my blog posts was flagged on Dev.to.

I want to be clear that this series is not specifically about that event or the people involved. It’s a broader exploration of using AI during the writing process and rules around labeling any AI-assisted writing. This just happens to be a relevant example. Everyone was doing their job exactly the way the policy asked. That’s the point. A system can be staffed entirely by decent people and still be built wrong.

Did I use AI in the process? Sure, I have been almost since ChatGPT came out. It’s been my brainstorm partner, my editor, my devil’s advocate, research assistant, and more. But what’s remained the same in all of my work is that the ideas were mine, they’re driven by my own experiences, and the desire to share and teach others. I validated every piece of research myself, edited draft after draft, and shaped the whole thing into something I was proud to publish. Hours went into it. This wasn’t a drive-by prompt-and-paste. That’s not my M.O.

The irony still gets me. The post argued that reconstructing work from memory is lossy and that what you think happened is missing exactly what matters. That evidence beats confident guessing. None of the work I did is visible to the moderator. They had a feeling about my prose or it was flagged by some tool and a policy that told them to act on it.

I’ve spent the last 7 years helping developers find their people and their voice online. I’ve told hundreds of new writers that their perspective matters, that they should hit publish, that the community will meet them with generosity. So when a community I’ve championed looked at my work and saw a suspect instead of a writer, I didn’t just feel annoyed. I felt something closer to grief.

But this isn’t a post about my hurt feelings. It’s a post about a question we’ve stopped asking, and before moving into tech, I taught for years in my College English 101 classes.

Why do we write at all?

If we strip writing down to first principles, it does three things.

We write to communicate. To take something that lives in your mind and make it live in another.

We write to connect. Every blog post is a hand extended to a stranger. Someone reads your story when they’re going through the same thing and feels less alone.

And we write to think. Writing isn’t the transcript of thought. It’s the act of it. Anyone who has started an essay believing one thing and finished it believing another knows this.

Those are the ends writing serves. Which means they’re also the standard every writing rule should be judged against. Does this norm help ideas move between minds? Does it help people find each other? Does it deepen thinking?

The rule that fails its own test

A disclosure mandate doesn’t help communication. The label “AI-assisted” tells a reader almost nothing because it collapses an entire spectrum of uses into a single flag. Spellcheck, brainstorming, research support, and full generation all wear the same badge. A label that can’t distinguish between them isn’t information.

It doesn’t help connection either. Right now that label carries a stigma. It marks a writer as lesser, maybe even dishonest, before a single idea gets evaluated. Readers are trained to disengage the moment they see it. That’s not transparency building trust.

That’s a scarlet letter dressed up as a courtesy.

And it certainly doesn’t deepen thinking, because the platforms enforcing it have never asked about any of the other hands in our work. Nobody discloses Grammarly. Nobody discloses the friend who talked through the argument with them over coffee, or the editor who restructured the whole second half. Ghostwriting, where someone else writes every word, has been a respectable industry for a century. No badge required.

So the mandate isn’t really about protecting readers. If it were, it would target the things that actually betray them. Plagiarism. Ideas lifted without citation. Confident claims nobody checked. Those problems are rampant on the same platforms, and they go largely unpoliced while moderators guess at which sentences feel too polished.

This is a fear response, not a principle. AI made platforms afraid, and afraid institutions reach for visible rules over meaningful ones. A disclosure badge lets a platform look responsible without doing the harder work of caring about quality.

The test we should be using

You might argue that readers deserve to know how the sausage gets made. You’re not entirely wrong. Readers do deserve honesty. But honesty about what?

Not a tool inventory. Readers have never had one and never needed one. What readers deserve is a writer who stands behind the work. Who did the thinking. Who checked the claims. Who can defend every idea on the page because the ideas are actually theirs, regardless of which tools helped shape the sentences.

That post the moderator flagged? I own every word of it. I can defend every claim in it. That’s what my hours bought, and no label can add to it or take it away.

The test isn’t about origin. It’s about ownership.

That’s the claim this series exists to defend. In the essays ahead, I’ll dig into the double standard we’ve built around writing tools, the stigma machine that disclosure mandates power, the real quality problems platforms keep ignoring, and what a standard built on ownership would actually look like.

For now, I’ll leave you with the questions I keep returning to. When you read something that moves you, what were you actually trusting? The process, or the person? And if a rule can’t tell the difference between a writer who did the work and one who didn’t, what exactly is it protecting?

I don’t think we’ve answered that yet. I think it’s time we did.

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.

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.