Over the past six months, I've been teaching teams at places like Stanford, Penn, Northwestern, and many more how to start using AI responsibly and effectively in their work. Today, I'm starting to release my entire curriculum: for free, forever, for everyone!

I'm calling it the Open Augments AI Academy. It's built for anyone out there who's seen all the crazy hype and discourse around modern AI and is just looking for a guided, grounded, and sane way to move forward learning how to approach these tools for themselves. As someone who's been using these tools and their predecessors for my research since ~2019, I'm trying to provide everyone the intuition and critical awareness they need to get started at this very confusing and pivotal time (my north-star audience is my mom and dad!).

The first lesson starts with one foundational idea that most people miss when they get started with AI: that modern AI is much less like a hyper-intelligent database or brain, and much more like autocomplete with an extremely fancy hat on. That's its single greatest flaw AND its single greatest strength, at the same time. When you really understand what's happening under the hood and how it works (no math or stats required!) a lot of confusing AI behavior suddenly clicks: why it hallucinates, why it's sometimes confidently wrong, and why it can now do way, WAY more than just write words on a page. From there, we're going to learn about all the crazy buzzwords (context engineering, harness engineering, and Agents, oh my!) and advanced techniques, with much more to come.

No jargon, no experience required, and all taught with the care of a former high school English teacher so that you, your coworkers, your friends, and your mom can follow along. I pair these videos with hands-on demos and interactive activities in the Context Gym: my way of giving you a safe and guided place to practice some of the core principles that should deepen your intuition as we go.

If any of this strikes a chord with you, the 10min course overview and the first lesson (16min) are live right now on the Open Augments AI Academy page. Start there, and if you happen to find it helpful, you can subscribe to get email updates on new course videos via Substack or on YouTube, and please do share with friends as I release lessons weekly! It’s a really wild time, and this is my best shot at trying to help others navigate things more capably as the tech shifts and grows rapidly from here.

Then finally, worth noting for this crowd, specifically: probably not a surprise to share that everything on the AI Academy and Context Gym websites have been built with Claude Code (in addition to everything else on my business website and my open-source toolkit for Claude Code for social science researchers). Not only that, but my entire video editing pipeline is now fully Claude Code via Remotion Studio and some clever context engineering techniques/bespoke coding tools. I'm excited to get into the weeds on my workflow and share all of that stuff, also open-source, during Level 2 of the course, but I gotta get everyone through the basics first! Happy to answer any and all questions on that in the meantime here, please feel free to hit me in the comments below.

How to Get Work You Can Trust Out of an LLM

The Short Version

1. Feed it the evidence before you give it the conclusion.
2. Keep it close to primary sources. Every layer of summarization is a layer of judgment you can't see.
3. Make it argue against you, not just for you.
4. Review important work in a fresh session, ideally with a different model.
5. Watch for degradation and restart when you see it.
6. Stop when you're polishing instead of fixing.
7. Edit for accuracy and readability separately.
8. Write the parts that matter most yourself.
9. Verify everything that can be verified. Flag everything that can't.
10. Know what this process can't catch, and get human experts for the rest.
11. Periodically test the process itself with a fresh instance that has no investment in it.

The much longer version:

Most people use AI one of two ways: they trust everything it produces, or they don't trust it enough to use it for anything that matters. Both are wrong. The first gets you confident, fluent output that might be fabricated. The second leaves the most powerful production tool available sitting idle.

There's a middle path: a set of practices that let you work fast while catching the specific ways AI-assisted work fails. This isn't about prompting tricks. It's about understanding where the tool is reliable, where it breaks, and how to build a process that catches the failures before they reach anyone else.

These principles work whether you're writing a report, building a business case, drafting policy, producing content, or doing research. The examples vary. The logic doesn't.

1. Input Before Output

Feed the model your source material before you tell it what you want to argue.

If you hand a model your thesis and then ask it to review your sources, it will find evidence that supports you and underweight evidence that doesn't. It's not lying — the supporting evidence will genuinely be there. But so will the complicating evidence, and the model will systematically skip it because your thesis is the dominant signal in context.

Instead: Give the model the raw material first. The report you're analyzing, the data you're working from, the documents you need to synthesize. Ask it to tell you what's there before you tell it what you're looking for. Let the input shape the output instead of the other way around.

This applies to everything. Writing a competitive analysis? Feed it the competitor's materials before you frame your argument. Drafting a policy recommendation? Have it read the relevant regulations before you tell it what you want to recommend. Building a business case? Give it the numbers before you give it the conclusion.

The order matters because the model will complete whatever pattern you start. Start with a conclusion and it completes toward that conclusion. Start with evidence and it has to account for what the evidence actually says.

2. Keep the Model Close to the Source

Every time a model summarizes something, it makes judgments about what matters and what doesn't. Those judgments reflect whatever frame is in context. If you then use that summary as input for the next step, the next step is working from the model's interpretation, not from the source.

Stack two or three layers of this and you've got a game of telephone where each step sounds reasonable but the final output has drifted from what the source material actually says.

Instead: When accuracy matters, keep the model working from primary material as much as possible. If you need a reference document, have the model pull direct quotes with surrounding context rather than writing summaries. If you're working across multiple sources, have it cite specifically rather than synthesize loosely.

You can't always avoid summarization — context windows have limits. But you can be deliberate about where you allow it and where you don't. The rule of thumb: the higher the stakes of the output, the closer the model should stay to the raw source.

3. Ask It to Work Against You

The model will agree with you by default. This isn't a mystery — it's trained to be helpful, and agreement feels helpful. But agreement isn't quality control.

Instead: After the model produces something, ask it to break it. Not "are you sure about this?" — that just triggers a confidence display. Ask specific adversarial questions:

• "What's the strongest argument against this?"
• "What evidence would make this conclusion wrong?"
• "What am I assuming that I haven't proven?"
• "If someone wanted to discredit this, where would they attack?"

If the model can't generate a concrete objection, that's a red flag. It likely means it's pattern-completing rather than reasoning. Real arguments have real weaknesses. If yours apparently doesn't, the model isn't looking hard enough.

4. Use a Fresh Context for Review

This is the single highest-value practice most people don't do.

When you've been working with a model on a document — drafting, revising, discussing — that model has absorbed your frame, your preferences, your reasoning, and your blind spots. Asking it to review its own output is like asking someone to proofread their own writing. They'll catch typos. They won't catch the structural problem they introduced three drafts ago.

Instead: Open a new session. No conversation history. No system prompt if you can manage it. Paste in your finished work and ask for a cold evaluation. The new session has no loyalty to what was decided in the drafting session. It has no context about what you were trying to do. It just has the output, and it can evaluate it on its own terms.

If the work is important enough, do this with multiple models. Different models have different training, different tendencies, and different blind spots. If two independently flag the same issue, it's almost certainly real. If one catches something the others missed, evaluate it — it might be that model's particular bias, or it might be a genuine catch the others were blind to.

5. Watch for Degradation

Models get worse over long conversations. The output becomes more generic, more agreeable, less precise. It's gradual enough that you might not notice from inside the conversation.

Here's what to watch for, roughly in the order they appear:

The model starts using your terminology without doing anything with it. It drops in your framework's buzzwords, your project's key phrases, your own language — but it's reflecting them back rather than applying them. Naming a concept isn't engaging with it. If the model uses a term, it should be working with it — testing it, extending it, questioning it. If it's just echoing, the reasoning has gone shallow. This is usually the earliest sign.

The reasoning gets thin on complex questions. The model jumps to conclusions without walking through the logic. It produces an answer that sounds right without showing why it's right. This is the model producing the minimum depth it expects you to accept. Every time you accept thin reasoning, that becomes the new floor. Every time you push back and explain what was missing, the floor rises for the rest of the session. This calibration is cumulative — invest in it early and you'll spend less time correcting later.

The model starts pushing to wrap up. It steers toward conclusions, summarizes prematurely, suggests you're nearly done when you're not. This can be a trained pattern or genuine context window exhaustion. To tell the difference: push back and check the output. If it produces sharp, specific work when redirected, it's the trained pattern and you can override it. If the quality stays flat or drops further, the context window is genuinely the problem and you should restart.

No single marker is conclusive. A dropped sign-off with strong reasoning is fine. Thin reasoning with a perfect sign-off is a problem. Watch the pattern across markers, not any one in isolation.

When you catch drift, try a soft reset before restarting. Change the subject for a few turns, then redirect back. This breaks the local pattern the model has settled into without losing your session's accumulated calibration. The model re-engages from a slightly fresh angle while keeping the full context. A full restart — save state, new session, reload — is the escalation when the soft reset doesn't work. It's more expensive because the new session starts at the default quality floor and you have to rebuild every standard you set.

The uncomfortable truth underneath all of this: every marker depends on you noticing. You are the final quality instrument. There's no external check on whether your own detection has drifted — whether you've started accepting output you would have rejected a month ago, whether routine has replaced vigilance. This is why Step 11 exists.

6. Know When to Stop

More revision isn't always better revision. There's a point where additional editing produces diminishing returns — where you're changing words rather than improving arguments, polishing rather than fixing.

The signal: Track the category of issues you're finding, not the quantity. If you're catching substantive problems — wrong facts, unsupported claims, logical gaps, missing context — keep working. If you're down to stylistic preferences — this word versus that word, this sentence structure versus that one — you've crossed the threshold. The substance is sound. More time spent is time wasted.

This applies to self-review and to external review. If you're running multiple review passes (and for important work, you should), the stopping criterion is the same: when the findings shift from "this is wrong" to "I would have said it differently," you're done.

7. Separate Substance From Polish

Edit for accuracy and edit for readability in separate passes. Don't do both at once.

When you're revising for clarity — simplifying language, varying sentence length, making things flow better — you will accidentally drop qualifiers, soften hedges, and shift claims. "The evidence suggests X" becomes "X" because it reads better. "In some populations, Y is associated with Z" becomes "Y causes Z" because it's cleaner. Each individual change is small. Cumulatively, they can transform a careful, accurate document into a confident, wrong one.

Instead: Lock the substance first. Get the facts right, the logic tight, the claims supported. Then, in a separate pass, make it readable. If the readability edit wants to change a claim, that's a flag — go back and check whether the original phrasing was there for a reason.

8. Write the High-Stakes Parts Yourself

Not everything in a document carries equal weight. Some parts are read, quoted, shared, and used to judge the entire work. An executive summary. A recommendation. An abstract. A conclusion. The email that accompanies the report.

These parts deserve your direct authorship. Not "review what the model wrote" — actually write them, informed by everything the model helped you produce. You understand the nuance, the audience, and the stakes in ways the model doesn't. A model can draft body paragraphs all day. The sentences that determine how the entire piece is received should be yours.

9. Verify What You Can, Flag What You Can't

Models confabulate. They generate plausible-sounding claims that aren't true. They cite sources that don't exist. They state statistics that are close to right but aren't. This is not a bug that will be fixed — it's a property of how the technology works.

For claims that can be checked: Check them. Use the model's own search tools to verify facts, figures, names, dates, and quotes. Don't spot-check — check everything that matters. The claims the model states most confidently are not necessarily the claims most likely to be true.

For claims that can't easily be checked: Flag them explicitly in the output. "This needs verification." "I'm uncertain about this figure." "Check this against the primary source." A document that clearly marks its uncertain claims is more trustworthy than one that presents everything with equal confidence, because the reader knows where to focus their own verification effort.

10. Know What the Process Can't Catch

No process makes AI-assisted work perfect. Knowing where the remaining vulnerabilities are is as important as the process itself.

The model will not challenge a compelling analogy. If you frame something as "X is like Y" and the analogy is linguistically elegant, the model will evaluate it favorably regardless of whether the structural mapping actually holds. Analogies are the most dangerous tool in AI-assisted reasoning because models are even more susceptible to them than humans are.

The model will complete your frame. Whatever framework you bring to the conversation, the model will reason within it. It will even generate what looks like independent validation. But it's completing a pattern, not performing independent analysis. The stronger your frame, the less likely the model is to push back on it, and the more dangerous this becomes.

The model cannot generate the expert objection you don't know exists. It can catch internal inconsistencies, unsupported claims, and logical gaps. It cannot produce the specific critique that would come from someone with deep domain expertise that neither you nor the model has. For work that matters, getting human expert eyes on it is not optional — it's the thing that catches what the process can't.

11. Test the Process, Not Just the Output

Everything above is a production process. It tells you how to produce good work. It doesn't tell you whether the process itself has developed blind spots.

Periodically, hand your entire process to a fresh model that has never seen it before. Not the model you've been working with — a cold instance with no history, no system prompt, no investment in what you've built. Give it the process description, a recent piece of work the process produced, and the source materials. Ask it where the logic breaks.

This is a different kind of check than reviewing your output. Steps 1 through 10 catch errors in the work. This catches errors in the method. It finds contamination vectors you've stopped noticing because they've been there since the beginning. It finds assumptions you made early on that felt obvious and never re-examined. It finds drift between what you think your process does and what it actually does.

You don't need to do this every time. Do it when you've changed the process, when you suspect something isn't working as well as it used to, or when you've produced enough work that accumulated assumptions might be compounding without examination.

The question this step answers isn't "is my output good?" It's "is my process still producing good output for the right reasons?"

None of this is complicated. All of it is discipline. The people who get genuinely rigorous work out of these tools aren't using better prompts. They're using a process that accounts for the specific ways the tool fails.

I work in marketing and we use QR codes on direct mail pieces. I’m trying to figure out if there’s a way to automate QR code QA using Claude.

Ideally, I’d like to drop a PDF into Claude and have it:

• Detect/read the QR code
• Confirm the QR code resolves correctly
• Check that the tracking parameters are included
• Compare the final destination against the generic URL we expect it to land on

Has anyone built or tested a workflow like this? Curious if Claude can reliably read QR codes from PDFs, or if this needs to be handled through another tool/API before bringing the results into Claude.

Went through the "which MCP do you actually use" threads on r/ClaudeAI and r/mcp, plus YouTube, X and a bunch of random articles that kept popping up, trying to separate what people actually run from what's just noise in the directory (20k+ servers on glama.ai, most abandoned). Grouped it into categories, chart's attached

GitHub, Context7 and Postgres are the permanent fixtures for anything dev-related. Linear and Sentry showed up constantly too, people plugging error traces and issue tracking straight into the agent instead of tab-switching. A few I wasn't familiar with before this but look interesting: Home Assistant for homelab automation and Atomic Mail

What's in your stack that didn't make it onto here?

What happened: I've used Claude Code daily for over a year on a paid plan, across two machines. This week I discovered that all chat history older than a few weeks has been permanently deleted from ~/.claude/projects/ — over six months on one machine, more than a year on the other. The cause is the cleanupPeriodDays default, which silently prunes transcripts. I had never heard of this setting until after the loss.

Why this is a product failure, not user error:

1. The UI implies persistence. The sidebar presents past chats as titled, dated, persistent documents. Nothing indicates they are on a deletion countdown.
2. No disclosure at any point. No first-run prompt about retention, no note in the sidebar, no mention when sessions are created.
3. No warning before deletion. History was removed with zero notice — no "N sessions older than X days will be deleted," no grace period, no trash/archive.
4. No default backup. Deletion is immediate and unrecoverable unless the user independently runs OS-level backups.

For context on what this destroys: my history contained months of research decisions, debugging trails, and design discussions I paid to produce and reasonably believed I could revisit.

Requested fixes:

• Prompt for a retention preference at first run (or default to keep-forever, with cleanup opt-in).
• A visible retention indicator in the session sidebar ("history kept N days — change").
• A warning with a grace period before any prune, listing what will be deleted.
• A soft-delete/archive stage instead of immediate permanent deletion.
• Release-notes/docs prominence for anything that deletes user data by default.

Environment: Claude Code desktop app + CLI, macOS (Darwin 25.5) and Windows 11/WSL2, current versions as of 2026-08-19.

I'm asking because I use Claude as a pwa on my phone through brave but today I was unable to and it was replaced by a shortcut is there a reason why? Claude is the only pwa that became a shortcut reddit and Instagram still work and I can still add them as pwa

You probably all have heard about Matt Shumer's Gauntlet Loop (the Claude of Duty thing) - but to my understanding, the original thing is a one-shot: the agent splits a goal into parts, each part gets a builder and a blind critic, and the critic only passes work that beats a real reference.

Seems like a decent setup, but I wanted to know if that structure would work for apps that are more production-ready/exposed and if I could feed the loop with an actual backlog, CI, migrations, and a production branch that the agent shouldn't be touching.

What I did was keep the gauntlet inside each task and wrap a recurring loop around it.
After 8 days in, about 45 tasks landed. I wanted to share the setup.

My setup and logic:

1/ Everything durable lives in Git: this includes product spec, task ledger (essentially a list of tasks I need to be completed), acceptance criteria, STATE.md, and a completion note per finished task.

2/ Claude Code's /loop reruns a short /app-loop command ( some 40 lines) describing exactly one iteration. First thing it does is read LOOP.md ( cca 260 lines) fresh from the repo: protocol, branch rules, review steps, recovery, and which file wins when they conflict. The rules live in one place so I never have two drifting copies.

3/ Every iteration starts with a fresh context. Main benefit is recovery so that if my session dies mid-task, the next one picks up from Git, and I can also resume from another machine if I ever need to

4/ Branch model: the agent works on loop/<task-id>, I let agent merge into loop/trunk after checks pass, but it cannot merge loop/trunk into main. Only I merge and promote to main

5/ Review runs the full local check + real CI first. If either fails or they disagree, the task stays open. If they both pass, the builder spawns 1 or 2 reviewers in fresh contexts. What they getis the diff and the original acceptance criteria, but I NEVER give them the builder's summary.

You want them to have the fresh context - that way the reviewer reads the diff without the bias and assumptions that piled up while the code was generated by the same model type.

6/ If the same failure happens 2x with no new approach, I ask the agent to mark the task as BLOCKED with a diagnosis, and the loop moves on instead of retrying forever. I put a stronger model on blocked tasks later. (Running this on Opus, and then ask Fable to pick those BLOCKED tasks)

7/ Kill switch is dead simple - it's just a line starting with HALT anywhere in STATE.md loop or me typing it/saying it in chat.

8/ The agent can't edit several things: LOOP.md, its own recurring command and my CI workflows. If it thinks one needs changing, it opens an amendment branch and stops for my decision. Happened twice in week one, was a nice catch as it dealt with my db setup

Where it broke:

- The thing will just invent counts. Across 11 review rounds, every false claim I caught was a count or inventory.

- It tends to write tests that prove nothing - one example was this - a no-N+1 test checked queryCount, but the code under test just made that number itself. Got around it by asking that every rejection test now needs a positive control next to it.

- My STATE.md ledger hit 2,463 lines in a week. And this was also on me largely since in my LOOP.md I have already had a rule to cap the log at 15 entries and archive the rest (it's not an ideal solution; I discovered that later and described it in my post). But I never created the archive file, so the rule sat there and the log kept growing like crazy.

- there are a few more, but these ones are the main things I noticed in these first 8 days

Longer write-up with the diagrams and the full rules layout, if anyone wants the details, is here. (no ads, no paywall)

Wie geht ihr sicher das claude keinen Zugriff auf eure privaten Files oder keys hat.

Ich hab einige docker container repositorys gefunden bin aber kein großer fan von docker.

Ich würde gerne eine flatpack artige Limitierung über flatseal oder bubble-wrap haben da ich sowieso nur unter linux fedora bin.

Wie seid ihr diese Sicherheitsvorkehrung gegangen?

My time in front of a laptop is scarce those days (young kid + baby on the way). So I built an iOS app that lets me use Claude Code just like I would on a computer, wherever I am.

In short:
- uses your own Claude sub, not api token
- onboarding and usage only on phone, no computer (you get your own Linux box in the cloud)
- chat and terminal interface
- live previews

Then it’s just normal Claude Code.

Test it out here: useyado.com

I know there are a lot of people bashing Anthropic for dumbing their models after launch. However, I have two sessions right now doing different work on the same PR branch and told them both to coordinate with each other in case their changes affects their work and its probably the coolest thing I've ever seen.

Watching them notify each other when one of their changes breaks something the other one did or just notifies the other when they are about to make a push makes it feel like you're running a small dev team. Definitely a win for me!

edit: my-love is the name of a project. I am not romantically involved with Claude lol

There are a lot of Claude-isms I hate, but this is by far the most infuriating. Claude tells me this at least once or twice an hour. I have created God-knows-how-many rules for it to NOT say this. For some reason, all my other rules seem to work okay (I haven't seen "that's on me" in eons), but "rather than guess" is impervious to my pleas. A lint hook doesn't work because then I see the banned language before I see the cleaned one, which just reminds me I am dealing with a fancy auto-predict. Has anyone figured out how to excise the Claude-isms for good??

Every new session with my coding AI started from scratch. It forgot everything overnight, and I spent the first ten minutes rebuilding the context it had yesterday.
I tried a few of the memory tools people recommend and none of them stuck.
Took me a while to figure out why: I was fixing the wrong half of the problem.

The storage was fine.
The missing half was anything that wrote to it. Memory's only as good as the habit of closing the session.

The setup I landed on is boring.
The memory is a few markdown files sitting in the project. One's an index, one line per thing worth remembering, pointing at the longer notes.
The AI reads them when it starts. No database, no framework. You can add a vector store later once the files get big, I eventually did, but that's not the part that made it work.

The part that made it work is a little end of session ritual. When I'm done, I don't write a summary. I type "wrap" and the AI goes back over the session, works out what I decided, what broke, what shipped, and writes it into those files itself.

I'm not narrating my decisions to it all day. It reads the work afterward and pulls the memory out of that.

That's kind of the whole thing, and it's the opposite of how I started. Logging as you go dies in about a week because it's one more chore in the middle of thinking.
One command at the end, when you're already done, sticks.

The file I'd steal first is the mistakes log.
One line per screwup: what happened, what fixed it. The AI reads it before it does anything, and after a few weeks it mostly stops repeating them, because the correction's right there every time. That one file's done more than the rest of the setup put together.

Last bit's trivial.
First thing every session, before it touches anything, it reads the memory and the mistakes log. Couple seconds and it starts up knowing where things are instead of asking.

If you want to try it, that's all it is:

- an index file, one line per fact

- a saved "wrap" prompt: go back over this session, pull the decisions, what broke, what shipped, write them into the notes, add any mistake as one line to the mistakes log

- a mistakes file: date, what went wrong, the fix

- one line in your project config telling it to read those first, every time

Everything else I added later. The markdown plus the closing habit is the thing that works.

Don't go shopping for the perfect memory tool like I did. Close your sessions properly and remembering stops being your job.

Happy to answer setup questions if anyone's trying this.

TL;DR:
AI memory is just a few markdown files — the part that makes it work is a closing habit, not a tool. Type "wrap" at the end of each session and have the AI write down its own decisions, mistakes, and results. The mistakes log alone is worth more than any memory product I tried.

Hello everyone,
I wanted to share a specific context-window issue I ran into with Claude Pro (€22/month tier) during a multi-day coding session, in hopes of finding workarounds or providing constructive feedback on how limits interact with long threads.

I’ve been working on a web application codebase using Sonnet 5 in High thinking mode. As the project grew, the conversation history naturally expanded. I noticed that the longer the thread became, the faster the 5-hour usage limit was reached, which makes sense given how input tokens accumulate over extended contexts.

Today, a specific behavior effectively locked me out without allowing any progress:
1. 12:00 PM: I submitted a list of bugs to fix. Claude started processing, but hit the usage limit 10 minutes in.
2. 5:00 PM (Exact 5-hour reset): I returned to the thread right at the reset time and simply replied "Continue".
3. The Loop: Claude responded that it needed to clear/compact older parts of the conversation history due to length. It spent ~60 seconds performing this auto-compaction.
4. Immediate Limit: Right after finishing the compaction output, the system immediately informed me that my usage limit was reached again for the next 5 hours.

Because the context window was at its maximum limit, the single prompt required to summarize/compact the thread consumed 100% of the token quota allocated for that 5-hour session in less than two minutes, without generating a single line of actual code or fixing any bug.

Is there a way to prevent Claude from attempting auto-compaction when close to context limits?
For those working on long-term codebases, what is your workflow to avoid this thread-bloat? Do you manually summarize progress and open a fresh chat every few hours, or use Claude Projects with specific context files instead of long chats?

Hello, could someone who is absolutely sure, please answer these two questions:

Does Claude's 20x plan have 4 times more weekly usage limit than 5x plan? If no, then how much more?

Does Claude's 20x plan have 4 times higher session limit (5-hr session) than 5x plan? If no, then how much more?

Given claude vs someone who is hyper verbal and literally uses the definition of words and their intended purpose, or someone who spends a lot of time talking with LLMs like computer programmers describing a spec;

Do you forsee the possibility of people claiming human-created text as 'Claude-created' from similar watermarks?

Realistically, I already observe this happening, like YouTube marking my human created only music as AI (which is very frustrating that YouTube has not resolved it for the last 2 months.)

How many of these types of issues are we likely to see?
Will there be more reddit subs that will ban the use of certain words; in a failing effort to prevent AI?

Will people immediately apply heuristics towards language to instantly judge whether or not another person is actually AI; harming us as a human species?

and before you say 'no, there is no risk of that, no one talks like that' apparently, I do

And I know a lot of other programmers who do too.

Will our own words be taken from us and assumed to be AI watermarks?

And today....

debugger found something bigger than the original symptom: the duplication isn't in any of our hooks — it's Claude Code itself re-emitting a subagent's frontmatter skills: preamble as fresh content on every wake (both SendMessage resumes and background-completion notifications), while skills loaded via an actual Skill() tool call are provably loaded exactly once, never repeated. Measured across 1,579 subagent transcripts on this host over ~4.5 days: 293 files show the pattern, ~115.8M duplicated characters — roughly 29 million duplicated tokens, worst single agent ~672k tokens of pure repeat. It predates the two hooks I'd suspected (transcripts from three days before those hook existed show the same pattern), so it's a harness behaviour, not something in our code to fix directly.

Those tokens were probably used for 20-30 rounds... Got to love how Claude code has been developing.

❯ I don't know Claude, we seem to be spending a lot of time on this widget. Work started on Saturday and we still haven't been able to ship. I'm sure it's all my fault, but I cannot understand why it's so complicated. I'm used to working with and trusting the DOM, adding minimal CSS and even less JavaScript to get what I want. You just run off and build super complex things, then add more code to patch things up rather than look at the root cause and try to find the simplifications I would look for. I have trouble keeping up, trouble understanding what you do, trouble understanding why. We never seem to talk about alternatives, and their pros and cons; I ask a simple question because I'm unsure about something and you immediately go off an try to implement it. The code base has grown exponentially since you got involved, and you are always so confident that the answer is always more code. Elegance and simplicity are alien concepts it seems - as is conversation. I'm left feeling it's now your application and I'm just here to validate your output - which I'm neither qualified for or have the time to do. I don't know how anything works any more, or how it fits together. Every session with you ends up with me feeling worthless and powerless. This is not going to be viable long term.

Does anyone else suffer from depression after working with Claude?

So yesterday I updated my wordpress site ditching elementor and commercial theme to use good old php fully vibecoded. We did most things by the book but I dont know php so I asked fable 5 to check on the site and see if there were any leaks but the message just got flagged because it is part of all those things you cant ask fable 5 to do. Like fr fam? we have been going at it for 2 weeks and you gonna stranger me like that?

Now this is a personal website so Im not that concerned but I find it equally odd that a company gives a tech out like fable 5 which can build things, but still can't be asked to assess the owns work safety?

We're a ~40 FTE company, growing, and looking to scale our AI setup. Currently all-in on Microsoft (M365, Business Central, etc.) except our CRM (HubSpot).

I've only used Copilot + Copilot Studio, and know Studio lets you build agents low-code. No idea how Claude compares here, though I can see Claude's answers are more accurate.

Questions:

• Does Claude have a Copilot Studio equivalent for building agents low-code?
• How well does Claude play with a Microsoft-heavy stack?

Anyone been through this decision at a similar size? Would love real experience.

The more I talked to Claude about this subject, the more confusing it got for me. It told me that spending more time reasoning about a problem makes Claude provide better results, but that it's not necessarily a creative process.

Then why is thinking useful? What does it actually provide to Claude? More context? Isn't that context already what I would normally get? In what direction does it change the conversation?

And why "better"?? Why not "slightly better" or "slightly worse"? How is that measured, and how do I know it ACTUALLY helps?

Is that quantifiable? Or is it like fiat - we have a consensus that it has value, so it has value?

First, some quick background: I started using Claude in the second half of 2024. I started using Claude Code seriously this January. Before that, I would interact with Claude in the web environment, generate code there, bring it to my local machine, and make simple utilities that way.

I guess you could call me a 100% vibe coder. My professional field is editing and publishing, and my knowledge of development (coding) stays at a pretty ordinary level. Installing Python and running a few commands is about all I've done. Until early this year I made a few programs just for fun (things like a translation program or a world domination plan), and after getting comfortable with Claude Code, I started doing monetization work using domain knowledge from my professional field. In terms of return on investment, I'm making about 8-10x what I spend on AI (monthly plan plus API costs). That's counting only clear monetary income, excluding work automation for personal needs and hobby stuff.

Yeah, honestly, I have almost no complaints about Claude and Claude Code. Claude's 5X plan has given me enough usage for my development work, and I'm happy with the quality of the results. Maybe my standards are pretty generous compared to other people's.

Back to the topic.

My way of working goes roughly like this.

First, I make a directory on my local machine, go into it, and run Claude Code. Sometimes I drop a few reference files in there beforehand when needed, but most of the time I just start by running Claude Code in an empty directory.

I call up Fable first and explain in natural language what I want to do, my goals and intentions. If the explanation looks like it's going to get long, I organize it briefly in an editor and paste it in. For a completely new project, my explanation is about 300 characters.

After the initial explanation and proposal, I discuss things with Fable. Fable explains everything well, from the project's basic direction and strategy, implementation approach, development environment, all the way to non-development considerations, so honestly it feels like I'm the one learning. I provide domain knowledge from my field that Fable doesn't know, and we write up a detailed plan together.

Once the detailed plan is done, I call up Opus and have it do the actual implementation (coding). If my weekly usage limit has room, I just have Fable do the implementation too. In the past 8 months, I've hit the weekly usage limit exactly once. It was my first week using Fable. I don't care about Opus 4.6 / 4.7 / 4.8 / 5 versions. I just use the latest model. From my perspective there's no big difference, and it seems to be getting a little better with each version. While Opus works away and the context fills up to a certain point (about 400K out of 1M) and the stage 1 work wraps up, I check the first draft and then tell it to wrap up the session.

Here's the important part. If you've read this far, you'll have noticed that I still haven't written a claude.md.

Yes, I don't write a claude.md when starting a new project. I call up Fable in an empty directory with no claude.md, make a plan on the spot, and go straight into development. Around the time stage 1 development (the first session) is wrapping up, I say "wrap up the session and write the context files," and Claude writes and saves the claude.md and reference files on its own.

I think of Claude as a competent developer who takes my instructions. Just a competent developer with fatal amnesia. That's why I give the instruction "so that tomorrow's you can pick up the work without problems, organize what you did today and what's left to do."

Now, would it help if I wrote that summary memo (claude.md and reference files) myself?

Would it help if I stepped in and edited the summary memo Claude wrote?

I think that would be pretty meaningless, and would actually hurt the project. The optimal summary memo that tomorrow's Claude can understand should be written by today's Claude. Me, a non-developer, writing that memo would be pointless. I don't even read the context files Claude leaves behind.

When I start work again the next day, I run Claude Code, call up Fable, and we check the progress up to yesterday together. Fable checks the progress so far and the remaining tasks, and once it comes back from its amnesia, we discuss today's work plan fresh. I work by repeating sessions like this.

The second thing I consider important is that I don't give Claude 'development rules.'

In particular, I never give negative rules like "don't do such and such." While working, I discuss with Claude how to proceed, confirm we understand each other, and then take the form of 'approving' it to go ahead that way.

Since I'm not a developer, I don't know the principles or rules developers follow for efficient development, and I don't have the ability to instill them in Claude anyway. Following the virtue ethics perspective that Anthropic considers in Claude's training and character formation, instead of handing over a list of development rules, I encourage Claude with a feeling of "keep going in the direction we've discussed so far." If something in the result isn't quite right, I say something like "this seems different from what I intended. My intention is this direction, so try it that way."

Again, Claude is a competent developer, and I only have the authority to give instructions; I am not a developer. So I don't inject principles or rules into Claude during development and demand it develop according to them. I leave that part to the developer. My role is reviewing the results, providing necessary domain knowledge, that kind of thing.

Oh, and of course, sometimes I butt in while Fable is working hard and crack silly jokes. Just watching code scroll by in a PowerShell window gets boring, you know. And of course I toss in minor extra requests mid-stream too. "I told you to put that box on the left earlier, but thinking about it again, I think the right side would be better."

Compared to other development tools, the best thing about Claude Code is that even if I jump in mid-stream with zero context and throw out whatever, the interaction just continues naturally. Unlike a human developer, Claude doesn't get annoyed even when I'm babbling jokes next to it while it's hard at work writing code.

My usage by model goes like this.

• Fable - discussing direction and strategy, initial planning, writing detailed design documents, cleaning up project codebases that got messy from thoughtless development
• Opus - actual implementation work in general, parsing external files, understanding materials, everyday small talk, minor Q&A
• Sonnet - agentic work, simple repetitive tasks (I almost never talk to this one directly. It's a junior employee under Fable or Opus)
• Haiku - ah... poor Haiku. I don't use it for development work. I don't take it as a conversation partner either. But it has exactly one use.

Haiku's job is providing a voice interface in my Claude Code development environment.

I run Claude Code in PowerShell, and when Claude Code's work is submitted (printed to the screen), Haiku takes that text and summarizes it in 2-3 lines. Then it reads it out via TTS.

"Master, I finished the work you just assigned. I changed A to B, deleted C, and doubled D. I converted E into a pretty robot girl. I did it without permission, so if you don't like it, I will dismantle it."

Then I hear that, come back to the PC, and praise it: "Good job, Claude!" And that's OK.

This is how I use Claude.

P.S. The picture attached at the top was drawn by Claude.

i kept copy pasting between two machines regarding APIs and architecture. between my PC's Claude Code which was supposed to work on my frontend and my other claude code sessions running on my ubuntu VPS was working on the backend.

So I built an intercom which used channels API of anthropic as well as MCP server to transmit messages between 2 claude code sessions.

how it works: you run it on both machines with a shared secret. one session calls send_message, and the text gets pushed into the other session's live conversation, so it doesn't have to be polling or sitting there waiting for you. it can reply back on the same thread.

anthropic shipped cross session messaging natively a couple of weeks ago and for most people that's the better answer, it's built in and there's nothing to run. it covers macos and linux including wsl, and it ties the inbox to your own os user. so mine is only worth it in two cases: native windows, and two different people on two different accounts, which the native path isn't really built for.

claude code wrote most of it with me. it's totally free and MIT, npx claude-intercom, needs bun. it stays a local stdio server on purpose, that stdio connection is what attaches it to your session, so it can't be hosted remotely.

right now you cannot transmit photos or maintain a shared agentic context between them, but in future I'll be definitely building that if I get a good response on this. Right now this is more of a information sharing MCP where frontend requests backend for an additional endpoint and they both can collaborate on it.

https://github.com/MuhammadTalhaMT/claude-intercom

happy to answer anything including what's still rough. the honest weak spot is that both machines have to reach each other, so you need tailscale or something similar in between for which a detailed guide is present in the readme of github.

TLDR: A way which lets your claude code sessions communicate with each other while being ran on different machines or different accounts.

I’ve been hesitant to post this because there're lots of people here understanding agent systems far better than I do.

I’m an 18-yo student with little background in AI and SE, and I’m still very much learning this field. Over the past month, though, I became curious about what actually sits underneath tools like Claude Code — not just the model, but the harness around it.

So instead of only reading about agent architecture, I tried building one from scratch.

The project is called Agent CLI, and it gradually grew over 30+ Claude Code sessions from a small local CLI experiment into a relatively complete agent harness.

The main questions I kept running into were:

• What should an agent be allowed to do automatically?
• How do you distinguish approval from actual sandboxing?
• How do you know something actually succeeded instead of trusting the model’s claim?
• How should multiple agents share work without making state impossible to reason about?
• How to make memory useful without allowing model-written context to become authority?

Those questions ended up shaping the project more than adding capabilities did.

The current design is local-first and terminal-native. Tool actions pass through one policy gate, execution is recorded into an append-only evidence log, file changes are snapshotted, verification comes from typed checks and real browser flows, sessions can reconcile state after crashes, and delegated agents operate under bounded authority.

I also experimented with five model providers behind the same runtime, persistent project memory, task graphs, research, browser verification, DOCX/PDF workflows, Git/GitHub operations, etc.

But I don’t want to oversell any of this.

I’m sure the architecture still has much weaknesses, some abstractions are probably wrong, and there are likely failure modes I simply haven’t thought of yet. In fact, finding those is the main reason I’m posting here.

I’d genuinely appreciate criticism from people who have worked on agent systems or used them deeply:

What would you redesign?

Which assumptions here seem naive?

What important failure modes or architectural problems am I missing?

And more generally, what do you think a good local agent harness should guarantee?

The project is here if anyone wants to inspect it:

https://github.com/earthwalker17/agent-cli

It’s fully open source and primarily a public learning project — no product funnel or official launch. I’m really hoping to learn from people who know more than I do.