DEV Community: BekahHW

Using the right AI should be the easy part

BekahHW — Fri, 09 Oct 2026 14:27:00 +0000

Picture an office building with no front desk. Everyone who works there has their own key to every door. Visitors walk in off the street and find a room. Contractors let themselves in at night. Nobody knows who is in the building, which rooms are busy, or what any of it costs until the utility bill arrives.

That's most companies' AI setup right now. Every tool that talks to a model has its own key and its own route out the door. Harness asked 700 engineering leaders about it this year. Most companies know they need to do something about AI spend, but they don't have the visibility to make educated decisions.

The fix is a front desk. In AI infrastructure it's called an AI gateway: one door every request goes through on the way to a model. Everyone still gets to their meeting. Someone just wrote down who came in, where they went, and when they left.

The desk is step one. Two more layers make it smarter, and each one is built on the one below it. Start with the simplest version of the question: what does a front desk know by the end of its first week that nobody in your building can tell you right now?

An AI gateway gives you one place to make decisions

Without a gateway, every AI tool talks directly to a model provider. Right now, every tool is like its own island. It has its own provider connection, spend, rules, decisions about what model to use. A gateway gives you a place to control all of that.

Every AI request passes through the same point (the gateway), so you can see which tools and teams are making requests, track spending, apply policies across teams, and decide where each request should go.

Think of it like this: all your AI tools → one control point → the right model.

That gives you one place every request passes through. Now you can see which tools and teams are making requests, track what they're spending, apply the same policies across all of them, and decide where each request should go. The tools don't change. The base URL does.

An AI gateway directs where the request should go. Maybe that's OpenAI. Maybe it's Anthropic. Maybe one provider is unavailable this afternoon and you need another. The gateway makes that call once, for everyone, instead of every tool carrying its own version of the logic.

Your teams don’t all need the same model, provider, budget, or policy. A gateway lets you make those decisions once instead of asking every engineer, team member, and tool to make them independently. The goal is to take that mental load away from the people doing the work.

Policies might look like this:

Product gets a fast, capable default model.
Platform is allowed to use the strongest models for harder infrastructure work.
Support gets a cheaper model for high-volume summarization.
A sensitive workload can be restricted to a particular provider.
Everyone can have different budgets, rate limits, or fallback behavior.

The person setting up the gateway defines the guardrails once. After that, they mostly disappear. An engineer opens their agent and gets to work. They don’t have to remember which model they’re supposed to use, which provider is approved, or whether a particular task is worth the more expensive option. The system already knows the rules. The right way becomes the easy way.

An AI gateway can route based on who is asking. A semantic gateway can route based on what they’re asking it to do.

A semantic gateway asks what the request needs

A semantic gateway looks at the request itself and asks: "what kind of work is this?"

A simple question goes to a smaller, cheaper model. A hard coding problem goes to a stronger one. The person using the agent doesn't have to stop and choose.

That matters more than it sounds, because today the choosing falls on the person using the AI tool. The problem isn’t necessarily that one person uses up the team’s AI budget (though it certainly can be). But if every engineer is being asked to spend their own allowance wisely that means deciding, task by task, which model is worth the cost.Developers have been posting about exactly this since the weekly caps arrived.

Cutting model spend is the smaller win. The bigger one is that you can give your best engineers the most capable models when that capability actually makes their work better, without paying that price for every request the company makes. Using the cheapest model everywhere should never be the goal. Using the right amount of intelligence for each piece of work is.

"The employee makes fewer decisions. The organization makes better decisions."

That’s a much better system than asking every engineer to make that calculation themselves.
A semantic router can recognize that a task looks simple or complex. It can choose a model based on that classification. What it can’t know from the request alone is whether the cheaper model struggled, whether the stronger model was overkill, or whether the engineer had to step in and fix the result.

Choosing the right model is only half the problem. You also need to know whether it was the right choice.

The bigger opportunity is an intelligence platform you own

What happens when a system can learn from the work your team is already doing? Every agent session contains evidence: what someone tried, what worked, what failed, what they corrected, which model handled it, which tools were called, and what finally got the job done.

The record matters after the request is over. Most of a gateway's value is synchronous: what should happen to this request, right now? There's an asynchronous value too: what can we learn from everything that happened this month? Once the desk is keeping the record, the traces, the sessions, the corrections people typed, the skills that got written, the evaluations, and the dreams and inceptions an agent runs on its own history stop being separate features. They become one loop: the next decision uses what happened last time. Continue, retry, hand the work to another agent, or stop and ask a person before spending another $16 on a fix that already failed once.

A reflection identifies what mattered in one session. A dream looks across those reflections for patterns: a failure your team keeps hitting, an approach that consistently works, work that doesn't actually need your strongest model. An inception takes one of those lessons and tests it against the original work to see whether applying it actually changes the outcome.

In other words, the goal isn't to have an AI system invent advice about how your team should work. It's to learn from what your team has already proven. And then you can start thinking about where that knowledge belongs. Maybe a repeated workflow becomes a skill. Maybe a pattern about successful work becomes context an agent can retrieve. Maybe evidence that a smaller model performs just as well changes a routing rule. Maybe a known failure causes an agent to try a different approach, or stops it before it burns another $16 doing the same thing again.

We aren't at a point where all of that happens automatically, and I don't think it should happen without evidence. But the pieces start to connect. First, remove friction by putting policy and routing behind the scenes. Then you learn from the work. Then you use what you've learned to remove the next bit of friction.

Where to start if your AI requests still skip the front desk

The first layer is one base-URL change. Three moves, in order:

01. Put the front desk in. Even with one provider. Our gateway docs cover the setup, and the maturity model shows what each level buys. The bill-by-team answer arrives the first month.
02. Keep the full session record. A request log tells you what was sent. The record of what came back, and what the person said next, is what the third layer runs on.
03. Read a week of follow-ups. If more than one in six is someone saying "still failing," you have the same gap we do, and now you have the number to show whoever owns the budget.

The goal isn’t cheaper AI. It’s spending intelligence where it matters.

Skills vs. fine-tuning (or, why my kids are terrible at putting away laundry)

BekahHW — Wed, 07 Oct 2026 00:00:00 +0000

With four kids, laundry is one of those things that is never really done. There is always a basket somewhere, clean clothes waiting to be folded, dirty clothes that made it near the dirty clothes basket. And it wouldn’t be a week in our house without a random single sock in the middle of the floor.

When I tell one of my kids, “Put away your laundry,” I know what I mean. However, that does not mean they know what I mean.

Apparently, my 12 year old interprets “put away your laundry” as:

Pick up the entire pile of clothes.
Open one drawer.
Shove everything into it.
Close drawer as much as physically possible.
Done.

Technically, the laundry is no longer in the basket so he completed the assignment. This is also a pretty good way to think about working with AI agents. “Put away your laundry” feels like a perfectly reasonable instruction.

The problem is that there are a lot of things I’ve left unsaid. Shirts go in this drawer. Pants go in that one. Socks need to be matched. Things should probably be folded. If something is dirty, don’t put it back with the clean clothes. If the drawer won’t close, the solution is not to push harder.

I know all of those things because I have a mental model of what “put away your laundry” looks like. My kid has a different mental model. The same thing happens when we give an agent an instruction like:

Update the docs.
Open a PR.
Review this code.

There might be fifteen decisions hiding inside that sentence. And sometimes the agent makes exactly the decisions we wanted. Othertimes, it dumps all of the laundry into one drawer.

What does a skill do?

I could solve the laundry problem by giving my kid much clearer instructions:

First, separate the clothes by type.
Fold the shirts.
Put shirts in the top drawer.
Put pants in the second drawer.
Match the socks.
If you don’t know where something goes, ask.

Now “put away your laundry” has a process attached to it. More importantly, it’s a process we can use again tomorrow. That’s how I think about skills.

A skill is a repeatable set of instructions for doing a particular kind of work.

Instead of hoping the agent understands everything implied by “open a PR,” we can tell it what our team actually means when we say that.

Run the tests.
Check the diff.
Use this format for the description.
Link the issue.
Don’t include generated files.
Ask before changing the API.

Now we’ve taken knowledge that used to live in someone’s head and turned it into instructions the agent can follow. And the next time we ask it to do the same kind of work, we don’t have to explain the whole thing again.

What’s the difference between a skill and fine-tuning?

This is the part that really matters when you’re a parent. No one wants to give their kids a twelve-step laundry checklist for the rest of their lives.

Eventually, I want them to look at a pile of clothes and just know what to do. That takes doing laundry over and over. It takes realizing that shirts fit better in the drawer when they’re folded and putting socks in the wrong place and having to find them later and me saying, “No, you cannot put wet towels in there.”

Eventually, the behavior starts to become the default. That’s closer to fine-tuning.

A skill tells the model what to do for this kind of task.Fine-tuning changes the model’s tendency to behave a certain way in the first place.

If I have a very specific process for opening PRs at my company, that probably belongs in a skill, but maybe I notice something broader across hundreds of agent sessions. The agent tends to guess instead of asking when information is missing. It keeps retrying the same failed approach, changes more code than necessary, starts implementing before it understands the problem.

Those are patterns of behavior. And if I have enough examples of the behavior I want instead, fine-tuning gives me a way to teach the model that pattern. Fine-tuning isn’t explaining something once. This is the part I think is easy to miss.

My kids don’t become good at looking for lost things because I tell them once, “Look everywhere before you ask me.” They learn by losing a water bottle, then a shoe, then homework, then the charger they were definitely holding five minutes ago.

Over time, they start to recognize the pattern:

Before asking Mom, actually look.

Models work similarly. If I want a model to learn a behavior that transfers into new situations, I need examples across different situations.

If every example I give it is about laundry, I might get something that is extremely good at laundry. What I actually want it to learn is the larger pattern underneath those examples:

Look carefully before escalating.
Try a different approach when the first one fails.
Ask when important information is missing.
Prefer the smallest reasonable change.

That’s why the data matters and individual examples are useful. The pattern across the examples is what we’re really trying to teach. But it can also be tricky not to teach the wrong lesson

There’s another parenting problem here. Let’s say I’m extremely committed to teaching my kids not to ask me where things are.

“Look everywhere before you ask me.”

So they learn the lesson very, very well. Now one of them spends forty-five minutes searching for a permission slip because asking me would mean admitting they hadn’t looked hard enough. That’s not really the behavior I wanted either. I want persistence, but I accidentally taught reluctance to ask for help.

Fine-tuning can work the same way.You’re not just teaching individual answers. You’re shifting tendencies. Push too hard toward caution and the model might stop taking reasonable action. Push too hard toward autonomy and it might stop asking when it should. Teach it to avoid one failure mode and you can accidentally create another.

So the goal isn’t just collecting examples of things the agent did wrong. It’s figuring out what behavior you actually want instead. Skills are great when we know the process and can write it down. Prompts are great when we need to give the model instructions right now and we’ll probably never need to repeat them again.

Fine-tuning is interesting when we keep seeing the same behavioral pattern across different kinds of work and we want the better behavior to become the default. Sometimes the answer is a better checklist. Sometimes it’s a better instruction. And sometimes you realize you’ve explained how to put away the laundry fifty times and maybe it’s time for the lesson to stick.

You’re allowed to complain. Then you have to move.

BekahHW — Fri, 07 Aug 2026 00:00:00 +0000

Complaining has a place in life and in community. We don’t want to fall into the trap of performing our best selves all the time. We want to be able to say, “This is hard,” and have someone hear us.

People complain when something has hurt, disappointed, exhausted, or made them feel powerless. The complaint is usually pointing at something real.

A job search is a good example. You can do everything you were told to do. You can tailor your resume for every job, apply to 10+ jobs a day, customize your cover letters, send thank you messages, ask for feedback, show up to events, and even sound confident when nothing could be further from the truth.

And then silence. It’s the kind of silence that wears a person down.

And if you don’t have an outlet for that complaint, the silence can start to be consuming until it feels soul crushing. I’ve been there. There is value in being heard and validated.

So no, I don’t think the answer is to tell people to stop complaining. That usually makes people feel more alone, and loneliness is already part of the problem.

But I do think we have to be honest about the line between being witnessed and staying stuck.

Complaining can build connection, and that’s why it works

Over the past handful of years, I’ve found it really useful to understand why patterns in behavior happen, like dive into the Huberman version of what’s going on. There is a reason complaining feels useful.

When someone says, “This is awful,” and another person says, “Yes, it really is,” the first person feels less alone. The frustration has somewhere to go. The emotion gets named out loud instead of sitting unspoken in the body.

That part matters.

Researchers who study rumination have found that repeatedly talking through problems can be associated with stronger friendships, but it can also be associated with more anxiety and depressive symptoms.

That tracks. The same conversation can make you feel known and keep you anchored to the same wound. That’s the part we need to watch.

The goal of community cannot ever be to make discouragement more comfortable forever. A good community gives you room to tell the truth, then helps you find the next truthful step.

Stuckness can become a brain pattern

I’m not a neuroscientist, but I am someone who cares about what happens to people when disappointment turns into identity.

The neuroscience is useful because it gives us a more compassionate way to understand stuckness.

Learned helplessness research has changed over time. The older framing was that people or animals “learned” nothing they did mattered. More recent neuroscience complicates that. Maier and Seligman argue that passivity after uncontrollable stress may be closer to a default response, and that what has to be learned is control. That learning involves prefrontal systems detecting agency and helping regulate stress responses.

If someone has tried over and over and still hasn’t gotten traction, their brain may start protecting them from the cost of trying again. It may become easier to complain than to risk one more failed attempt.

That doesn’t make the person lazy. It also doesn’t mean the person is finished. The work is to rebuild evidence of control in small enough pieces that the brain can tolerate trying again.

The job search breaks momentum before it breaks effort

The job search is awful right now. And I’m so sorry to see so many people struggle through it. I hear stories over and over and over that validate that effort and outcome are painfully disconnected.

You can send twenty applications and hear nothing, have a great conversation and still get passed over, improve your portfolio and have no idea whether anyone noticed, and be qualified and still lose to someone with a referral, a better market fit, or better timing.

That makes the job search a perfect place for helplessness to grow. The person may still be trying, but the trying stops feeling connected to anything. Then the complaint becomes the only part of the process that gives immediate relief.

The application gives silence. The complaint gives validation.

It’s natural for the brain to reach for the thing that gives something back, but validation isn’t the same as momentum. If all you have is validation, you might feel understood while your actual situation remains unchanged.

The first move is to separate the feeling from the conclusion

When someone says, “I’m never going to find a job,” I don’t think the best response is, “That’s not true.”

It might be true that they are exhausted. It might be true that they feel rejected. It might be true that the market is brutal. It might be true that their current strategy is not working. It might be true that they need help.

The sentence “I’m never going to find a job” is doing too much work.

So we need to encourage starting by separating the feeling from the conclusion.

I know this is hard, but it is possible to name the feeling without letting it define the outcome.

“I feel embarrassed that I’m still looking.”

“I feel angry that I keep doing the work and getting no response.”

“I feel scared that nothing I try is changing the outcome.”

Those are cleaner sentences, and I’m sure they’re painful, but they are workable. Because once the real feeling is named, the next question changes.

You’re no longer asking, “What is wrong with me?”

You can ask, “What part of this process needs a different input?”

That question isn’t small. It’s the first step toward agency.

A complaint needs a conversion point

I don’t think we should ban complaining from communities. That would make people less honest, but I do think every healthy community needs a conversion point.

A conversion point is the moment the conversation moves from pain to agency. It can be gentle:

“You’re right. That sounds exhausting. Do you want help thinking through the next step?”

“I get why you’re frustrated. Let’s look at what happened in the last five applications.”

When I lost a job early in my tech career, a friend said to me, “Ok, so self-evaluation time. What’s next? What can you do differently?” That was a really hard question to hear at the time, but it immediately changed my perspective and let me move to the next thing.

Small actions teach control again

When someone is discouraged, big advice can make things worse.

Build a new portfolio.
Rebrand yourself.
Apply to fifty jobs.
Network every day.
Learn a new framework.
Start posting consistently.

Maybe some of that is useful later. But for a person who is already overwhelmed, it can sound like one more way to fail. So sometimes we ahve to start smaller.

Implementation intention research gives us a practical structure for this. People are more likely to follow through when they make a specific plan for when, where, and how they will act. The common format is: if this happens, then I will do that.

If I get a rejection, then I will wait ten minutes before deciding what it means about me.

If it is Monday at 9 AM, then I will send one message to someone in my network.

If I catch myself doom-scrolling job posts, then I will save one role and write down the actual requirements.

If I feel too embarrassed to ask for help, then I will send the shortest honest message I can.

It can be easier if you start with one small action. That’s how you start giving your brain different evidence.

Track the actions that still count

When someone is discouraged, it can feel like nothing they do matters. That is a lie. The work still counts, even if the market doesn’t respond.

Job-search research has linked job-search self-efficacy, motivation, and persistence with the search process and employment outcomes. That doesn’t mean every person can effort their way through a broken market. It means people need ways to keep acting when the market gives them very little feedback.

A tracker can be a witness to remind you that you are still participating in your own life.

Behavioral activation gives momentum a shape

There is another useful idea here: behavioral activation. Behavioral activation is used in mental health treatment, especially for depression. The basic idea is that action can help interrupt avoidance and low mood by reconnecting people with meaningful or rewarding activities.

That’s a reminder that waiting to feel motivated can keep you waiting for a very long time.

Sometimes the sequence has to be:

Move first. Feel later.

Send the message before you feel brave. Open the document before you feel clear. Take the walk before you feel hopeful. Ask for help before you feel deserving of it.

The feeling may not change immediately. Do it anyway.

Not because your feelings are fake. Because your feelings are real, and they do not get to be the only force driving the day.

Your public posture becomes part of the job search

If you are looking for work, people look at how you show up online. That doesn’t mean you need to become fake. It doesn’t mean every post needs to be polished into corporate language. It doesn’t mean you should hide the fact that the job search is hard.

But your public presence is part of the signal. If every visible post is bitterness, blame, despair, or contempt, people notice.

We all agree that the market is hard. We understand why you are tired. Most of us want better systems for hiring, training, and entry-level work. But you don’t want people reading your posts wondering what it would feel like to work with you.

That’s the hard part.

A hiring manager is trying to answer more than one question. Can this person do the work? Can this person recover from frustration? Can this person take feedback? Can this person stay steady when the answer is unclear? Can this person be honest without making everyone else carry the full weight of their discouragement?

Those questions may feel unfair when you are already exhausted. They are still being asked, so tell the truth purposefully:

“This job search has been brutal, and I’m discouraged” is honest.

“This has been a hard week, so I’m tightening my resume and asking two people for feedback” is honest with movement attached.

“I got rejected again, and I’m taking the weekend to reset before I send the next batch” is honest with a recovery plan.

That’s different from posting the same helpless complaint every day with no visible attempt to change the input.

One makes people want to help, and the other makes people step back.

Resilience has to become visible

I don’t want communities where people are afraid to admit they are struggling. I want communities where people can tell the truth and still be invited back into agency.

But at some point, adults have to get back up.

That sentence has an edge to it, but it’s because I think it needs one.

Because there is a kind of support that accidentally trains fragility. Validating feelings is important, but not when it prevents forward motion and treats it like an unwanted demand. That’s not care. Care tells the truth and stays in the room.

The truth is that rejection hurts. The truth is that the market can be brutal.The truth is that some people have more access, more money, more connections, and more margin. The truth is that discouragement can change your brain and your body. The truth is that you may need help. The truth is that your resume and skills might need work. Your communication might need to be clearer. Your portfolio might need to be more visible. Your network might need to be bigger. Your timing might need to be better.

And the truth is that you still have to move.

It doesn’t all have to be dramatic. We can start one rep at a time. Read your resume, send a follow-up message, ask questions, track the things you do, practice your answers, take a walk outside, plan things that feel manageable, but above all, don’t stay stuck.

If you’ve been complaining about the same problem for more than three conversations, stop and write down what action came after each one.

If the answer is “nothing,” there’s your data. It’s not a moral failing. It’s not to shame yourself. It’s to identify a pattern that can be changed.

A complaint can tell you where something hurts. It can show you what feels unfair, what feels blocked, what feels too heavy to carry alone. But the complaint cannot become the whole practice.

You still have to train. You still have to build evidence that you can act when the outcome is uncertain.You still have to become the kind of person who can take a hard week, tell the truth about it, and make the next right move anyway.

Start small if you need to.

But start.

Ownership, Not Origin

BekahHW — Mon, 06 Jul 2026 13:00:00 +0000

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

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

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

Judge writing by ownership, not origin.

What ownership means

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

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

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

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

The verification objection

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

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

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

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

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

What honest transparency looks like

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

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

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

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

Writing in the age of good tools

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

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

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

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

Is it yours?

If it is, hit publish.

The Wrong Problem

BekahHW — Mon, 06 Jul 2026 12:00:00 +0000

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

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

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

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

What actually harms readers

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

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

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

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

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

The fear response

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

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

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

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

The problem we’re not allowed to name

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

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

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

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

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

The Stigma Machine

BekahHW — Mon, 06 Jul 2026 11:00:00 +0000

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

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

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

What the badge actually says

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

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

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

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

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

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

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

The accusation engine

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

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

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

The best case for the other side

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

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

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

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

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

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

What stigma costs us

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

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

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

The Disclosure Double Standard

BekahHW — Mon, 06 Jul 2026 10:00:00 +0000

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

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

The rule we never had

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

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

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

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

The label that can’t label

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

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

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

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

We’ve been here before

Every writing tool arrives to the same funeral music.

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

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

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

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

Which is exactly what a disclosure checkbox cannot capture.

What the double standard reveals

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

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

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

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

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

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

Why We Write

BekahHW — Mon, 06 Jul 2026 00:00:00 +0000

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

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

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

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

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

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

Why do we write at all?

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

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

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

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

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

The rule that fails its own test

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

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

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

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

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

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

The test we should be using

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

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

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

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

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

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

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

AI Companies Know Your Data Is Valuable. Why Doesn't Your Team?

BekahHW — Wed, 01 Jul 2026 06:02:00 +0000

The most valuable thing your team produces with AI isn't the code that shipped. It's the path the agent took to write it — the prompts that worked, the retries that didn't, the architecture decision someone made out loud before they touched the keyboard. That path is not exhaust. It is prior experience. Frontier labs have spent the last year paying a billion dollars a year to prove the point. Most engineering teams are deleting that path every time the terminal closes.

The vendor wants your session for training. The engineer means to save it for next time. The team needs to save it to learn from each other.

The labs already named what the path is worth

OpenAI COO Brad Lightcap put a number on the static-text era: if you combined all the proprietary text from major publishers and added it to GPT-4's training mix, "it would boost the data volume by less than 0.1%." Buying corpora is effectively over. What labs are paying for now is what Foundation Capital calls agency — "interactive reinforcement-learning environments with sequential action traces, not static input-output pairs." That's a long phrase for a simple idea.

The path through a problem is the asset.

Recent research is starting to point in the same direction. The systems that improve agent performance aren't just keeping better prompts around. They are preserving prior runs — source changes, execution traces, prompts, tool calls, scores, failures, and state — so future agents can search across what happened before instead of starting from a blank context window. The lesson isn't “stuff more into the prompt.” It's: make prior experience durable enough to query.

Mercor, the marketplace that sells those traces to OpenAI, Anthropic, and six of the Magnificent Seven, crossed $1B in annualized revenue in June at a $10B valuation. The product is a session record — the full trajectory of a senior engineer and an AI agent working through a hard problem together. Surge AI, its closest competitor, named the thing right on the box: "thousands of hours of expert reasoning, pre-built and ready to use today, spanning RL environments, coding, and the core capabilities every model needs."

And the model vendors are productizing it themselves. Anthropic and OpenAI are reportedly building services that store "the entire conversation record of the code-writing process, or trajectory," so users can later look up the intent behind why code was written a certain way. GitHub flipped Copilot Free, Pro, and Pro+ to collect interaction data by default in April — "inputs, outputs, code snippets, and associated context" — used to train models unless you opt out.

The labs already named the thing. They called it trajectory. They're paying for it, building products around it, and harvesting it from the tools your team uses every day.

Meanwhile, in your terminal

Your team's sessions already contain the trajectory. Every prompt, every tool call, every retry, every fix. The same artifact Mercor sells at $200 an hour is sitting in your engineers' shells today, and the moment they close the terminal, it's gone.

Capture changes what that artifact can do. A captured session record is searchable. It's replayable. It can be compared against the next run. It can show which prompt sent the agent down a dead end, which tool call recovered the task, and which context actually mattered. It turns yesterday’s one-off debugging session into tomorrow’s starting point. It's something the next engineer can pull up when they hit the same Kafka config error your senior engineer solved at 11pm last Tuesday instead of opening a fresh prompt and walking through the dead ends one more time.

Without capture, the whole industry is admitting that the workflow trace is too fragile to lean on. Anthropic itself published a postmortem in May about a bug that quietly wiped session context every turn for nearly four weeks before anyone caught it. The vendor that builds the tool admits intra-session memory is fragile.

O'Reilly Radar put the daily texture bluntly: "Your AI partner — who just spent 20 minutes understanding your codebase — forgets everything and starts suggesting the same wrong approaches you already rejected."

Mark Dominus wrote in March about how he now asks Claude to write a structured summary at the end of every project and commits it to the repo manually, because if he doesn't scrape it out himself, the workflow knowledge is gone. He noted, with appropriate dryness, that developers will document for Claude what they won't document for each other.

JetBrains researchers reported in April on telemetry from roughly 800 developers: context-switching trended steadily upward in the AI-assisted workflow, and 74% of those developers didn't notice the increase. AI doesn't uniformly reduce developer effort, the team argued. It redistributes it into more fragmented, reactive work that doesn't show up on anyone's calendar.

If you and the engineer next to you have each solved the same flaky-test config error more than once, you don't have a model problem. You have a missing archive.

This isn't a memory problem. It's a capture problem.

Memory is what the agent can still see. Capture is what the team can still use. I'm not running data licensing strategy at a frontier lab. But the shape of it is clear enough from the outside. Vendor, engineer, team — none of those three groups has agreed on where the session lives, what format it's in, or who owns it.

So most of the time, nobody saves anything. The session ends. The terminal closes. The next person on the team starts from zero.

What capture as a primitive looks like

Distributed systems solved a version of this in the 1980s. Every production database writes a write-ahead log. Every message queue checkpoints offsets. Every event-sourced system can replay its history from an append-only record. The assumption is that the running process will fail, and the next one needs to know what the last one did.

Agent workflows ignore those lessons. The model talks to the provider. The provider responds. The session closes. An hour of design work, dozens of tool calls, three debugging loops, and one extremely specific lesson about how a flaky integration test recovers — all of it evaporates when the user moves on.

Capture, as a primitive, is the thing that stops the evaporation. An append-only record of the work: every prompt, every response, every tool call, every retry, every fork in reasoning. Owned by the team, not the vendor. Queryable later, by humans and agents. An archive, not a scrollback buffer.

That’s the bet Paper Compute is making. Agent sessions are not disposable chat logs. They are the operational record of AI-assisted work. Capture them, and your team can inspect, compare, search, and eventually reuse what your best engineers and agents have already figured out.

The asset isn't the code the agent produced. The asset is the path the agent took.

Start treating the session like it's worth something

Capture your sessions. Tell the people you work with that what they figured out last Tuesday is worth saving — because Mercor is renting senior engineers at $200 an hour to record exactly that, and your team is doing it for free.

The labs already agree on what your team's work is worth. Now your team has to start treating it like infrastructure.

Prompt Caching Is Subsidizing Bad AI Architecture

BekahHW — Mon, 29 Jun 2026 18:01:47 +0000

Brian's recent post, the true cost of Claude Code, looked at the subsidy under modern AI coding tools. I wanted to see what the subsidy was actually paying for inside my own workflows, so I pulled nineteen days of Claude Code session data from my paper CLI session data: 3,697 messages across two projects and three models (Opus, Sonnet, and Haiku). Because every request was captured at the HTTP boundary, I had the model used, the token counts, the cache reads and writes, and the way each message connected to the ones before it. That's more than a bill or a single transcript can show.

Prompt caching saved 82% of my input cost. The savings are real, but they also make a particular kind of architectural waste cheap enough to ignore: prompts that grow without limit, context blocks attached to the wrong tasks, sub-agents that rewrite their parent's cache prefix. Caching subsidizes that architecture by burying it inside an aggregate number that looks healthy. The only way to see what is being subsidized is to look at the workflow underneath: which prompts stayed stable, which kept mutating, where parents forked into children, and whether the reused context actually contributed to useful work.

Prompt caching is just the observable surface of a deeper system: AI workflows behave as stateful, branching systems, and current telemetry only sees them as isolated calls.

AI workflows have outgrown traditional telemetry

A few years ago, "an AI call" was a single request. One prompt in, one response out. Logs, traces, and billing dashboards were enough to reason about it.

That world is over. Modern agent workflows are different on five axes at once: they run for a long time, they keep state across turns, they branch into sub-tasks, they call other agents, and they rewrite their own prompts as they go. A single coding session can spawn sub-agents, read dozens of files, run tools, and end up with a prompt that bears little resemblance to where it started. The individual model call is the cheap, well-instrumented part. The workflow around it is what decides whether the work was efficient, durable, or wasteful. Traditional telemetry doesn't see any of it.

Request logs show one request at a time. Distributed traces show service-to-service flows, not prompt-to-prompt lineage. Billing dashboards aggregate everything into a total. None of those answer the questions that matter once a workflow is the unit of analysis:

Which prompts stay stable across a session, and which keep mutating?
When a parent agent spawns a sub-agent, does the child inherit the parent's prompt prefix or build its own?
Where does context branch, and where does it merge?
Which sessions paid to create cache that never paid back?
How is a workflow's prompt shape drifting week over week?

These questions need different primitives: prompt lineage, context inheritance, cache topology, prompt mutation, sub-agent divergence, and session structure tracked over time.

Economic vs. architectural efficiency

Cheap reuse is not the same as good architecture.

Economic efficiency asks if we reuse tokens cheaply. Architectural efficiency asks if this context should have been reused at all. Those are different questions, and prompt caching only answers the first.

A workflow can be economically efficient and architecturally wasteful. It can also be architecturally clean and economically expensive when the work itself doesn't repeat much. Confusing the two has concrete operational costs:

Runaway context growth. Prompts pick up rules and notes faster than anyone removes them.
Hidden cost amplification. Wasteful workflows look cheap while caching is generous and turn expensive the moment the discount weakens.
Prompt entropy. Sub-agents and projects drift apart slowly, and cache reuse degrades with them.
Degraded cache reuse. A high aggregate hit rate can hide sessions that keep rewriting their own prefix.
Hard to debug. When two sessions act differently, there is no way to compare what changed in the prompts that drove them.
Hard to compare architectures. No way to ask whether one team's agent design reuses context better than another's.

None of those show up on a bill. They show up in the topology of sessions captured over time.

What the data showed

Across nineteen days, my Claude Code usage hit 102.6 million input tokens with a 93.0% cache hit rate: 95.5M cache reads priced at 10% of base input, 5.0M cache writes priced at 125% of base input, and 2.1M fresh tokens at full price. Here and throughout, "cache hit rate" means the share of input tokens served as cache reads, computed across the whole nineteen-day window. That works out to about 17.9M base-equivalent tokens against a nominal 102.6M, an 82% savings on input.

In dollars, actual input cost was $232 against a no-cache equivalent of $1,321, a saving of $1,089. The no-cache equivalent would have been about 6.6x my $200/month Claude Code Max plan price, so the cache subsidy and the plan subsidy compound on top of each other.

Model	Actual cost	No-cache cost	Saved
Opus 4.6	$220	$1,274	$1,053 (82.7%)
Sonnet 4.6	$8	$41	$33 (80.9%)
Haiku 4.5	$4	$6	$3 (42.3%)

Dollars rounded to the nearest whole. Percentages computed on the unrounded underlying values, so a few rows may not visibly cross-foot.

The bill tells me what I spent, but it can't tell me which sessions, which models, or which prompt shapes were responsible for the ratio, or whether any of that work was reusable in the first place. The next-most-aggregated number is the cache hit rate. It tells you how much input was reused. It can't tell you whether the reused context deserved to be there.

A 95% cache hit rate can mean you built a stable workflow. It can also mean you built a very efficient junk drawer.

When I broke the hit rate apart by model and the workload-shape, I learned a lot.

Model	Messages	Input tokens	Cache hit rate	Fresh tokens
Opus 4.6	767	82.7M	95.6%	0.1M
Sonnet 4.6	136	13.3M	94.4%	0.0M
Haiku 4.5	478	6.6M	58.6%	2.1M

Haiku ran 353 separate root sessions to handle 478 messages, roughly one session per message. Virtually all the fresh tokens in the dataset (2.1M of 2.2M across all three models) came from Haiku, which was my one-shot model: title generation, quick classifications, duplicate checks, small judgment calls. Each request had its own shape and rarely a long shared prefix to reuse. Opus and Sonnet, by contrast, ran inside long, stable sessions where the prefix was set once and reused constantly. A 95.6% hit rate on Opus is the prompt cache doing exactly what it's supposed to do on workhorse workloads.

A healthy AI workflow doesn't have one universal cache hit rate. It has different cache shapes for different kinds of work, and a single scalar smashes those distinctions together.

If your cheap one-shot model has the same cache profile as your expensive long-context model, one of them is probably lying about its job.

Even the per-model breakdown is still one number per row. Two sessions can post the same hit rate while behaving completely differently inside. That difference is the cache topology: the actual sequence of writes, reads, branches, mutations, and merges across a session. It is the shape the aggregates flatten, and it has to be captured directly.

The clearest example from my own data of the stable workhorse row was an Opus session from April 29: 728 messages, 42.9M total input tokens, 42.2M of them cache reads. The session opened with a 31k-token context write, then every subsequent call read that prefix back and added incrementally. You can see it in the prompt sizes stepping up: 31k, 32k, 39k, 43k, 44k, 46k, 47k, 51k, 54k. Writes appeared when new context was added. Reads dominated everywhere else. That's a topology, not a number.

Four patterns the topology surfaces

Once you can see sessions as shapes, four architectural patterns become legible.

Prompt Accretion: system prompts that only grow

The first pattern is the prompt that grows by accretion and never gets pruned. A system prompt starts at 800 tokens. Someone adds a rule, then a tool description, then a security note, then an edge case nobody remembers the reason for. Eventually every call carries thousands of tokens of instructions and no one knows which parts still matter.

The April 29 session is a quiet example. 255 separate cache-write events across 728 messages, roughly one write every three turns, sitting inside a session that still posted a 55x read-to-write ratio overall. The aggregate ratio says the workflow is healthy. The write distribution says the prompt kept mutating throughout. Economic efficiency and architectural drift can live in the same session.

Universal context blocks: the same bundle attached to the wrong jobs

The second pattern is a reusable context block attached too broadly. One large "standard" prompt bundle ends up on coding tasks, title generation, classification, one-line edits, and small judgment calls.

For long coding work, that context may earn its keep. For a tiny utility task, it doesn't. The right question is whether this task should have received that context at all, not whether the cache is reusing it.

Sub-agent divergence: child agents that fragment the cache prefix

The third pattern is the parent-child loop that changes its prompt shape as it delegates. From the outside the workflow looks like one task. At the cache layer it is several separate prompt families. The parent writes and reads one prefix. Each sub-agent writes its own. The session still has reuse, but the lineage is fragmented.

This pattern only shows up if the captured data keeps the parent-child structure. paper records a parent_hash on every node, which let me read my 3,697 messages as a tree: 408 conversation roots, 3,289 child messages branching off them, with the deepest single thread running 495 messages deep. Without that tree, every message looks like an isolated cache event and parent-child divergence is invisible.

Context dumps: large cache writes with little reuse

The fourth pattern is the short session that pays the 125% cache-write premium and gets little reuse back. Open the tool, dump a pile of context into one turn, do one thing, close the laptop.

The heaviest example from my own data was an Opus session from April 21: 14 messages, 87k tokens written to cache, 156k tokens read back, a 1.8x read-to-write ratio. The April 29 session sat at 55x for comparison. A session that reads back barely twice what it wrote is paying premium prices for almost no compounding benefit. It is a workflow choice with a cost that is small in isolation and large in aggregate when a team makes a habit of it.

What this means in practice

The four patterns aren't just diagnoses. Each one points at a concrete change.

If you find prompts that grow by accretion, prune them. Pull up the longest system prompts in your captured sessions and walk through them rule by rule. Anything nobody can defend should come out. The first request still pays the cache-write premium each time you change the prompt, so a smaller stable prefix is cheaper to maintain and easier to reason about.

If you find universal context blocks, separate work by shape. A tiny utility task should not inherit a coding agent's full preamble. The framing should be "what is the minimum context this call needs to succeed," not "what is the largest context the cache can absorb."

If you find sub-agent divergence, normalize the prompt across the loop. Pick one stable prefix the parent and its children all share, then append the differences as a smaller tail. The cache stays usable across the tree, and the parent doesn't have to rebuild context every time a child returns.

If you find context dumps, ask whether the work is really one-shot. A dump for one quick task is fine. A dump pattern repeating across a team is a workflow design choice, and the work can usually be reshaped into a session that pays the cache-write premium once instead of every time.

The bigger question is the same in all four cases: is this pattern one you chose, or one you ended up with? Telemetry doesn't decide that for you. It puts the question in front of you instead of letting the bill answer it for you.

What it takes to see this in your own workflows

None of the four patterns above are visible at the request level, the trace level, or the bill level. They live at the session-and-topology level, which means surfacing them needs a different kind of telemetry than logging, tracing, or cost accounting. Four primitives matter:

HTTP-boundary capture. Every model call recorded in one consistent shape, regardless of which tool made it. When you switch from Claude Code to the next tool, the data layer stays the same.
Queryable session structure. A week of sessions you can sort by cache writes, group by model, or compare by prompt shape. "Show me the five heaviest cache-write sessions this week" should be a query, not an afternoon of reading transcripts.
Lineage preservation. Every node knowing its parent. This is what makes sub-agent divergence visible, and what lets you trace one fan-out back to the call that started it.
Topology-aware analysis. A session treated as a sequence of write and read events with shape, not a single hit-rate scalar. This is what produces the figure above.

Without these primitives, the patterns above stay invisible no matter how detailed the logs look. If you want to look at your own workflows the way I looked at mine, that is the data shape you need.

The time to inspect the shape is when the bill still looks fine

AI workflows are becoming systems. Architectures optimized around today's cache subsidy may not survive tomorrow's pricing, scale, or model changes. The expensive patterns feel like non-issues when they're cheap. They become issues the moment the subsidy weakens, the model mix shifts, or the agent count grows.

The bill tells you what you spent. The transcript tells you what happened once. The topology tells you what shape your AI is settling into, and whether that shape will hold.

The time to inspect the shape is when the bill still looks fine → Get started with the paper CLI.

Virtual Coffee Needs Your Help

BekahHW — Thu, 11 Jun 2026 15:36:08 +0000

Virtual Coffee has always been a free, volunteer-led developer community supporting the tech community since 2020.

We host small-group coffees, challenges, learning opportunities, and community spaces where folks can ask questions, find encouragement, share job leads, get support, and build relationships with other people in tech.

For many members, Virtual Coffee has been more than another Slack group or online event. It has been a place to feel less alone while learning, job searching, changing careers, growing as a developer, or navigating the tech industry.

And we want to always keep it free.

That matters to us because our members are in many different seasons of life, employment, financial security, energy, and capacity. We never want cost to be the reason someone cannot participate.

Right now, though, Virtual Coffee is struggling to cover the basic costs that keep the community available.

Over time, sponsorships and individual contributions have declined. We have reached out to people and companies, covered costs ourselves when needed, and worked to reduce expenses by lowering tool costs, reviewing what we can remove or replace, and building more of our own infrastructure.

We are close to covering the basics, but not quite there.

We are also being realistic about capacity. Virtual Coffee is volunteer-led, and we are very aware of volunteer burnout. We are not promising a big relaunch, a burst of extra programming, or a sudden expansion. Our immediate goal is simpler: stabilize the basics so Virtual Coffee has room to thoughtfully plan for a sustainable future.

If you believe free, welcoming developer communities matter, we would be grateful for your support.

You can help by sponsoring Virtual Coffee through GitHub Sponsors. Even a small monthly contribution helps. One-time contributions help too.

You can also help by sharing our GitHub Sponsors page with someone at your company who supports developer communities, open source, learning, DevRel, or community programs.

And if you are looking for a developer community where you can show up, ask questions, learn with others, and be known as a whole person, we would love to welcome you.

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.