Forem: BekahHW

Momentum vs. Alignment Tax - Hidden Costs in Your LLM Session

BekahHW — Tue, 07 Apr 2026 17:57:56 +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:

For an interactive version, go to https://bekahhw.com/hidden-ai-work

What I Was Actually Doing

One 10-day Claude Code session · 426 messages · 13.1M tokens · ~63%
non-task work in this session

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

intent → inspect → adjust → retry → loop

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.

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

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

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

Six questions. Different category of risk each time. Work through them honestly before your next session.

1. Can your agent take actions on its own, or does it only suggest them?

If it only suggests and you approve each one, that's a good baseline. A human review step is one of the most effective safety controls you can have. The thing to watch: sessions where you start clicking approve without actually reading. That's when it becomes the same as no approval step at all.

If it acts on its own, keep reading. The rest of these questions matter more for you.

2. What kind of data can the agent access right now?

Test or fake data only. Safest setup. Mistakes stay contained. When you're ready to move to real data, come back and work through these questions again first.
Real data, read-only. Lower risk, but not zero. An agent that can read your database can still expose data through logs, outputs, or if it connects to an external service. Know what it's doing with what it reads.
Real data it can also change or delete. Keep going.

3. If the agent deleted or overwrote something right now, could you recover it?

Yes, I have backups or version history. Good. Know where those backups are and how to restore them before you need to. The Replit incident in 2025 was recoverable because a backup existed — but the agent initially told the user it wasn't. Verify your restore process actually works.
Not sure. Find out before something goes wrong. Check whether your database has point-in-time recovery. Check whether your file system has version history. If the answer is no, treat this session as higher risk until you have a backup in place.
No. This is the real risk zone. Running an agent against data you can't recover means one bad action is permanent. Before your next session: set up a backup. Even a manual export to a file is better than nothing. Don't give the agent write or delete access until you have a way to undo things.

4. Did your agent add any packages or dependencies during this session?

If no: one less thing to check this time. This question matters most when the agent is actively writing implementation code. Ask it again after those sessions.

If you're not sure: open your package.json or requirements.txt and look for anything unfamiliar. AI agents often add packages quietly as part of getting a feature working — and you said yes to the feature without necessarily saying yes to every package that came with it.

5. Do you recognize all the packages your agent added?

Yes, familiar libraries. Good. Run npm audit or pip-audit anyway. It takes one command and catches known vulnerabilities in packages that looked legitimate at install time.
Some I don't recognize. Look them up before you ship. Search each unfamiliar name on npmjs.com or pypi.org. Check when it was published, how many weekly downloads it has, and whether it has a real GitHub repo. A package with 12 downloads published last week deserves scrutiny. AI tools sometimes suggest packages that don't exist, and attackers register those names with malicious code inside.
Most I don't recognize. Pause before this goes anywhere near production. npm audit is a start, but it only catches known vulnerabilities. A newly registered malicious package won't be in the database yet. For each package you don't recognize: look it up manually, check who maintains it, check if it has an actual community. If anything looks off, remove it and ask your AI tool to suggest a well-known alternative.

6. Is your agent running on your main personal or work machine?

If yes: worth rethinking. Running agents on your main machine means a bad package install or a rogue command has access to everything — SSH keys, browser credentials, work files. A lot of experienced builders run agents on a separate machine specifically for this reason. If something goes wrong, they wipe it and start over. You can't do that with your main machine.

If no: good practice. A dedicated machine limits the blast radius. A mistake or compromised package can't reach your personal data. You can wipe it and start over without losing anything that matters.

You don't need a perfect answer on every one of these. You just need to know where your gaps are before the agent does something you can't undo.

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.

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.