DEV Community: BekahHW

How AI Tools talk to Each Other

BekahHW — Tue, 31 Mar 2026 15:58:07 +0000

For a more interactive version of this post, visit https://bekahhw.com/how-ai-tools-communicate

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.

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

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.

Streaming

Instead of waiting for the full response, the output arrives piece by piece. This is why ChatGPT seems to type its answer in real time rather than making you wait for the whole thing to appear at once. It's useful when you're generating long content or building something that needs to feel responsive.

Events

Instead of asking and waiting, a tool watches for something to happen and then reacts. A new email arrives. A file is uploaded. A timer fires. The agent picks it up and acts without anyone pressing a button. This is how you build things that run in the background autonomously.

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.

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 Vocab 102

BekahHW — Tue, 24 Mar 2026 17:41:45 +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 Vocab 101

BekahHW — Thu, 19 Mar 2026 22:25:31 +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

BekahHW — Wed, 04 Mar 2026 19:12:10 +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.

AI Ate the Homework: What Communities Are Actually For Now

BekahHW — Fri, 27 Feb 2026 22:05:16 +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.

Why Capable AI Keeps Getting Blocked

BekahHW — 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.

When Cloud Agents Are the Right Tool (And When They Aren’t)

BekahHW — Fri, 30 Jan 2026 16:25:26 +0000

In a recent episode of Training Data, Making the Case for the Terminal as AI’s Workbench, one of the key takeaways highlights the impact of cloud agents on the software industry.

That framing matters, because it marks a shift many teams are already feeling but haven’t named yet. Increasingly, useful AI work happens after a deploy, when an alert fires, when a dependency update lands, or when a backlog quietly grows.

This work doesn’t belong to a single developer session — it belongs to the system. And once AI work moves into the background like this, a new problem appears:

How do you run, observe, control, and trust AI that’s operating continuously?

That’s the real job of cloud agents, and it’s also where teams tend to misuse them.

They promise automation, scale, and relief from the endless stream of alerts, security issues, and operational cleanup work that shows up after code ships. But like most powerful tools, they’re easy to misuse — and when that happens, teams either over-automate or swear them off entirely.

The problem isn’t cloud agents themselves. It’s knowing when they’re actually the right tool. This post is a practical guide for software teams deciding where cloud agents help, where they don’t, and how to start without creating new risks.

First: What We Mean by “Cloud Agents”

A cloud agent is:

an AI-driven process that runs on remote infrastructure,
can be triggered by tasks, schedules, or external events,
uses reasoning over changing inputs to produce reviewable outcomes across shared engineering systems.

Unlike local or IDE-based agents, cloud agents can operate continuously and reactively, even long after a PR has merged. They're most useful for repetitive work that isn’t tied to a single coding session and affects a team. (You can learn more about them in our [Cloud Agent Taxonomy](https://docs.continue.dev/guides/cloud-agents/cloud-agents-taxonomy or watch our What is a Cloud Agent? video.

When Cloud Agents Are the Right Tool

Cloud agents are most effective when work meets three conditions:

It keeps coming back
It follows known rules
It already has human review built in Here are the clearest signs you should be using one: oai_citation:6‡Continue Blog

Check out our When to Use Cloud Agents Guide for a checklist to help you decide if it's the right fit for your team.

1. The Same Problem Keeps Reappearing

If you’ve fixed the same issue more than once, it’s no longer a bug — it’s a pattern.

Examples:

The same class of Sentry errors showing up every week
Repeated dependency or vulnerability fixes
CI failures caused by known, predictable issues
Analytics anomalies that require the same investigation steps

Cloud agents are good for work that keeps coming back. They help resolve the issues that are backlogged on your to-do list but still need to be done.

Cloud Agents can end the repetition. Often, if there's an external trigger (Snyk alert, GitHub PR, etc.), there's a good indication a cloud agent can support or handle the work.

2. The Work Is Reviewable

A good rule of thumb:

If you’d be comfortable reviewing this work in a PR, a cloud agent can probably help.

Cloud agents work best when:

outputs are diffs, comments, or structured changes
a human can review the result before it ships
the blast radius is clearly scoped

Examples:

Documentation: "Update the README based on PR changes"
Migration: "Generate TypeScript interfaces for any new API schemas"
Triage: "Label new issues based on their content"
Security fixes: "Fix new issues with known remediation paths"

Review is the safety rail. Without it, automation becomes risk.

3. The Work Doesn’t Require Product Judgment

Cloud agents are not product managers.

They fit well for:

applying known rules
following established patterns
enforcing consistency

They’re a poor fit for:

deciding what features to build
interpreting ambiguous user intent
making trade-offs that require deep business context

If the question is “What should we do?” → a human should answer it.

If the question is “Can we apply a known fix again?” → a cloud agent likely can.

4. The Cost of Delay Is Higher Than the Cost of Review

Some work is painful not because it’s hard, but because it lingers. Security backlogs, error queues, and operational debt tend to grow quietly. Cloud agents help when:

delays increase risk
issues pile up faster than teams can address them
the work isn’t urgent enough to block feature development, but still matters

In these cases, cloud agents act as a pressure release valve, not a replacement for engineering judgment.

When Cloud Agents Are Not the Right Tool

Just as important: knowing when not to use them.

1. One-Off, Exploratory Work

If a task is:

brand new
poorly understood
unlikely to repeat

…then automation is premature.

Cloud agents add value when they can amortize effort over time. For truly one-off investigations or experiments, a local or interactive workflow is usually better.

2. Highly Coupled, High-Blast-Radius Changes

Cloud agents should not be the first line of defense for:

major architectural changes
cross-cutting refactors
anything where small mistakes have large consequences

These changes need deep human context, deliberate sequencing, and explicit ownership first. Automation can follow later after the pattern is proven.

3. Work Without Clear Ownership or Review

If no one is responsible for reviewing outcomes, cloud agents will create friction over time.

Before introducing automation, a team should ask:

Who reviews this?
Where does the output live?
What happens if it goes wrong?

Cloud agents work best where ownership and visibility are explicit.

A Safer Way to Start

Most teams succeed with cloud agents by following a progression:

Start with one narrow problem: A single error class. One security rule. One repetitive task.
Run the agent manually at first: Observe outputs. Tune prompts. Build trust.
Require review for every run: Treat outputs like any other code change.
Automate only after repetition is proven: Automation is a milestone, not a default.

Why Teams Centralize Cloud Agents

As usage grows, teams discover cloud agents need:

visibility
history
coordination
a shared place to review outcomes

Without a central hub, agents become hard to track, tough to trust, and easy to forget about.

This is why managing cloud agents through a shared control layer where runs, reviews, schedules, and adjustments live together can help teams create a more effective cloud agent experience.

Cloud Agent "Sweet Spot": Deterministic & Event-Driven

Use cloud agents when work repeats, is reviewable, and benefits from consistency. Avoid them when judgment, novelty, or high-risk changes are involved. If you get that boundary right, cloud agents stop feeling risky and start feeling like they're alleviating pressure on your team.

Cloud agents in Continue live in Mission Control. They are designed for automated execution without human interaction while still keeping a human in the loop. Now you can monitor and manage cloud agent activity so your team can ship as fast as they can code.

5 Security Chores You Should Offload to Cloud Agents (Before They Burn You Out)

BekahHW — Thu, 15 Jan 2026 21:31:59 +0000

Let's talk about the "Security Sandwich."

On one side, you have excellent detection tools like Snyk and PostHog telling you exactly what’s wrong. On the other side, you have... you. You manually reading a JSON payload, finding the file, checking if the patch breaks the build, and writing a PR description.

The bottleneck isn't finding vulnerabilities anymore; it’s the sheer manual labor of fixing them.

This is where Cloud Agents come in. Unlike a simple script or a CI job (see the Cloud Agents Comparison Matrix to learn more), Cloud Agents can adapt their behavior based on code context, make judgment calls, and explain their decisions in human-reviewable outputs. It can read your code, understand your rules, and make decisions.

💡Definition: Cloud Agents
Cloud Agents are AI-driven processes that run on remote infrastructure. They are triggered by tasks, schedules, or external events, and use reasoning over changing inputs to produce reviewable outcomes (such as pull requests, reports, or summaries) across shared engineering systems.
Here are five security chores you can stop doing yourself today.

1. The "Smart" Vulnerability Patch

Standard auto-fixers are often too aggressive. They bump a version in package.json and walk away, leaving you to deal with the breaking changes.

A Cloud Agent approaches a vulnerability like a senior engineer would. When we use the Snyk Integration Agent, we don't just tell it to "fix it." We give it a strict 3-step protocol:

Investigate: Understand the CVE and the consequences.
Implement: Fix the immediate issue without "over-cleaning" or making breaking changes.
Report: Open a PR with a structured summary.
The Result: instead of a generic "Bump v1.2 to v1.3" message, you get a PR that looks like this:

PR Title: [Snyk] Fix prototype pollution in minimist

Issue Type: Security Vulnerability

Priority: High

Summary: Updated minimist to v1.2.6 to resolve CVE-2021-44906. Verified that no breaking changes were introduced to command-line argument parsing logic.

Snyk Issue Details: (Hidden in collapsible toggle)
The agent does the grunt work of formatting and context-gathering, so you just have to review the logic. This isn’t just automation. It’s contextual remediation

💡 Learn More: When to Use Cloud Agents | Automated Security Remediation with Snyk

2. Dependency Hygiene (The "Quiet" Update)

Waiting for a critical alert to update dependencies is like waiting for your car to break down before changing the oil.

You can schedule a Cloud Agent to run weekly on a "Cron" trigger. Its job?

Scan for deprecated (but not yet vulnerable) packages.
Read the changelogs.
Attempt the upgrade in a PR.
Crucial Step: the agent investigates the dependency, what it's being used for, what other packages will be impacted, and advises on the best path forward with context.

The agent does the work to avoid breaking changes with dependency updates.

3. UI Hardening (The “Forgotten Input” Sweep)

Cross-Site Scripting (XSS) isn’t usually caused by one big mistake. It’s caused by small inconsistencies over time. Reviewing every form field by hand in a mature codebase is the definition of a chore. Instead of manual spot-checks, you can deploy a Cloud Agent to enforce secure UI patterns automatically by:

Scanning src/components for all and elements
Verifying they use your sanctioned wrapper component (for example, )
Refactoring any raw HTML inputs to the safe version
Opening a reviewable PR with a full diff and summary

This doesn’t eliminate XSS by itself. It enforces consistency so unsafe UI patterns don’t quietly re-enter the codebase over time. This kind of sweep is especially valuable in legacy codebases, where the real risk is drift. This goes beyond automation with contextual remediation.

4. The "Monday Morning" Triage

If you come back from the weekend to 50 new alerts, you usually just skim them. That’s dangerous.

Instead of drowning in notifications, use an agent to summarize and group them. You can prompt an agent to:

Pull all open Snyk issues.
Group them by "affected service" or "vulnerability type" (e.g., XSS, SQLi).
Generate a summary for review.

You start your week reading a one-page executive summary, not 50 raw logs.

5. Audit & Compliance Prep

"Audit" is a scary word because it usually implies a frantic scramble to document who accessed what and when.

Because Cloud Agents run on infrastructure you control and log every step they take, they generate their own audit trail. You can create a specialized "Audit Agent" that:

Checks if all recent PRs have a linked issue.
Verifies that all new API endpoints include proper error handling and input validation.
Generates a markdown report of your current security posture.

How to Start

You don't need to build these from scratch. Here are some ways you can get started:

Connect the Snyk Integration in Continue Mission Control to immediately remediate high and critical issues.
Create a Custom Agent: Create a prompt that tells the agent what to do, set your trigger and repository, and create guardrails with rules (Check out the Snyk MCP, Snyk Secure at Inception Rules if you're using Snyk)

Stop being the bottleneck. Let the agent handle the chores so you can handle the architecture. Cloud Agents aren’t ideal for simple, deterministic checks. Those still belong in CI or linters, which you can read more about here.

The Platform Gap: How to Scale Your Engineering Without Scaling Headcount (Yet)

BekahHW — Tue, 23 Dec 2025 20:49:27 +0000

In 2006, Amazon CTO Werner Vogels gave an interview that would define a generation of engineering culture. He famously said, "You build it, you run it."

It became the rallying cry for the DevOps movement, promising to tear down the wall between developers and operations. And for a long time, we accepted it as gospel.

But as Humanitec points out in their excellent analysis, "You build it, you run it" comes with a warning label. When Vogels said that, Amazon was a fraction of its current size. There were no microservices. The cloud was in its infancy. The cognitive load required to "run it" was manageable.

Fast forward to today. "Running it" now means managing Kubernetes manifests, IAM roles, security compliance, database migrations, and observability pipelines.

If you are a full-stack team without a dedicated Platform Engineering group, you aren't just "running it"—you are drowning in it. You are living in the Platform Gap.

This is the awkward growth phase where you have real infrastructure headaches but not enough budget to hire the team to solve them. You build the features, but you also fight the fires. You are the architect and the janitor.

At Continue, we believe Mission Control is the answer to this gap. It helps small teams survive the maintenance tax by automating the "run" so they can focus on the "build."

1. Automate Triage Until You Can Hire (Sentry + GitHub)

The Reality: You don't have an SRE on-call rotation yet.
The Gap: When production breaks, your lead developer stops coding to fix it.

The Bridge:
Connect Sentry to Mission Control to handle the "noise" of production. Instead of alerting a human for every issue, you create a "First Responder" Agent.

Trigger: A new exception in Sentry.
Action: The agent analyzes the stack trace and the codebase.
Result: It opens a PR with a proposed fix and links it to the issue.

This doesn't replace deep architectural debugging. It just clears the low-hanging fruit so your team isn't dying a death by a thousand cuts.

2. Automate Compliance Without the Bottleneck (Snyk + GitHub)

The Reality: You don't have a DevSecOps lead.
The Gap: Security patches pile up because nobody has time to prioritize dependency upgrades.

The Bridge:
Use the Snyk integration to automate your security baseline.

Trigger: Snyk detects a vulnerability in an npm package.
Action: A "Security Agent" runs the upgrade and verifies the build.
Result: A PR appears with the fix and context.

This ensures you don't get blocked by security audits when you are trying to close a partnership or raise your next round. It keeps you compliant while you focus on growth.

3. Maintain Data Hygiene Automatically (Supabase & PostHog)

The Reality: You don't have a Data Engineer.
The Gap: Analytics tracking breaks, and RLS policies get outdated, creating tech debt that hurts later.

The Bridge:
Use Mission Control Workflows to keep your house clean automatically.

Supabase: An agent periodically audits your Row Level Security (RLS) to ensure new tables aren't left exposed.
PostHog: An agent watches user sessions for friction points and logs tickets for the frontend team.

Conclusion: Making "You Build It" Possible Again

Werner Vogels wasn't wrong, but he was speaking to a different world. In 2025, "You build it, you run it" is only sustainable if you have a platform that handles the heavy lifting.

For enterprise giants, that platform is a team of 50 engineers building internal developer portals.
For the lean full-stack team, that platform is Mission Control.

By using Agents to standardize workflows and automate maintenance, you bridge the Platform Gap. You get the autonomy Vogels promised without the burnout he didn't foresee.

Bridge the gap.
Connect your tools in Mission Control and start automating your maintenance tax today.

Bug Reports Should Fix Themselves: Dogfooding Our Slack Cloud Agent with GitHub and Linear

BekahHW — Tue, 16 Dec 2025 16:42:47 +0000

It's a painful experience when you’re in the zone, and a notification pops up in Slack that you need to fix. Continue's cloud agents turn Slack conversations into GitHub pull requests.

By connecting Slack and GitHub via Continue's Mission Control Integrations, developers can fix bugs, address security issues, and ship changes without leaving the tools where they already work.

Maybe it’s a bug report, a 404 on a new page, or a logic error in an endpoint. Sure, it’s important, but it’s an interruption. Usually, the workflow looks like this:

Read the Slack message
Sigh
Open Jira or Linear and create a ticket
Open your IDE, stash your current work, and check out a new branch
Reproduce the bug
Fix it
Push a commit, open a PR, and switch context back

That “quick fix” just cost you 45 minutes of flow state.
At Continue, we are building a world where your tools talk to Continue, and Continue takes action. We believe that if you can describe the fix in Slack, you shouldn't have to leave Slack to implement it.

Here is how we use our own Slack integration to turn bug reports into Pull Requests without leaving the conversation.

The "Drive-By" Fix: Turning Slack Bug Reports into Pull Requests

Sometimes, the fix is obvious, but the friction to implement it is high. The same Slack agent that opens Pull Requests can also create and update Linear issues, assign owners, change states, and link work across systems.

Recently, our team noticed a bug where the inbox list view was loading as empty because it defaulted to the wrong tab. I posted a screen recording of the issue.

Nate knew exactly what the problem was. In a traditional workflow, Nate would have to stop what he was doing to go fix a default state in InboxPageClient.tsx.

Instead, the conversation went like this:

Continue:

Looked at the selected repo: continuedev/remote-config-server
Action: Created ticket CON-5031.
Action: Changed default preset from "review" to "all".
Result: GitHub PR created.

Nate didn't open his IDE. He didn't stash his changes. He delegated the implementation to the cloud agent and moved on. Minutes later, the fix was deployed.

Slack as a Control Plane for Linear

The same Slack agent that creates Pull Requests can also work directly with Linear. In one Slack message, I asked Continue to update a Linear issue assigned to me, change the status, and leave a comment. I didn’t open Linear, search for the issue, or change context.

Behind the scenes, the Slack agent executed the request.

What the Slack agent did via the Linear MCP:

Identified the correct Linear issue based on name and assignment
Updated the issue status to In Progress
Added a structured comment with actionable next steps
Linked related internal tickets for traceability

This is a simple example, but it’s foundational. You can update status, assign owners, changing priority, link issues, directly from Slack. Slack becomes the interface. Linear becomes programmable. The agent handles the glue. If you want to take it a step further, you can call @Continue in the Linear issue and ask it to draft a PR as well.

From context switching to flow state. Continue turns Slack conversations into actions across your tools, so bug reports don’t pull you out of the zone.

Handling Logic & Security Flaws with Cloud Agents

It’s easy to assume AI agents are only good for simple one-liners. But we use them for architectural fixes, too.
Dallin, another engineer on the team, spotted a flaw in how we were handling permissions on an edit agent endpoint. The endpoint was checking the currently selected organization on the client side, rather than verifying the user's rights to the specific agent file on the backend.

This is a nuance that requires understanding the codebase. Dallin tagged @Continue with the context:

"The edit agent file trpc endpoint has a flaw. It checks the currently selected org and sends that, it should just check if user has rights to edit that agent file on the backend..."

The agent didn't just hallucinate a patch. If we look at the Mission Control view for this session, we can see what the cloud agent did:

Search: It searched for editAgentFile and updateAgentFile to locate the relevant router.
Read: It read src/trpc/routers/agent/agentRouter.ts to understand the current implementation.
Analyze: It found the updateVisibility mutation and saw it was accepting orgOwnerId as an input parameter (the security flaw).
Fix: It removed the parameter from the mutation and verified that packageProcedure was already handling the authorization correctly.
Clean up: It even updated the NewAgentFileForm on the frontend to stop passing the now-removed parameter.

The agent removed the insecurity, cleaned up the TypeScript errors caused by the change, and opened a PR. Dallin reviewed the code, gave it a thumbs up, and the security hole was patched.

Why this Matters for Developer Workflow and Flow State

The goal of Continuous AI isn't to replace developers; it's to replace friction.

When you connect your tools—like Slack, Linear, and GitHub—to Mission Control, you aren't just creating a chatbot. You are creating a programmable layer of automation that has context of your codebase with a cloud agent.

Thread Context: The agent reads the thread. If you discuss the bug before tagging @continue, it uses that conversation as context.
Mission Control: You can watch the agent work in real-time. If it gets stuck, you can jump in. If it succeeds, you get a PR link.
Flow State: You stay where you are productive.

We built this integration because we were tired of the "context switch tax." If you want to stop trading flow state for bug fixes, try connecting Slack to Continue today.

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

BekahHW — 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

BekahHW — 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.