This is one thing I think they need to get in-line with, and rename CLAUDE.md to AGENTS.md to follow convention.

We have an AGENTS.md symlinked to CLAUDE.md, seems to work fine.

Yeah that's probably a slightly cleaner way of doing it.

You think it would be a good idea to use a symlink instead?

In my experience, neither Claude nor any other agent actually reads AGENTS.md (or CLAUDE.md or anything else) without being told to explicitly every session.

Thanks! I def don't think I would have guessed this use case when MCP first came out, but more and more it seems Claude just yearns for scripting on data rather than a bunch of "tools". My/MCPs job has become just getting it that data.

Agreed. My only MCP is a code interpreter. I also recently started experimenting with making an MCP “proxy” which acts a better harness that lets the agent call MCP from within a code interpreter [1]

But in general I still don’t really use MCP. Agents are just so good at solving problems themselves. I wish MCP would mostly focus at the auth part instead of the tool part. Getting an agent access to an API with credentials usually gives them enough power to solve problems on their own.

[1]: https://x.com/mitsuhiko/status/1984756813850374578?s=46

This is how MCP works if you use it for as essential an internal tool API gateway (stateless http) instead of a client facing service that end users are connecting directly to. It's basically just OpenAPI but slightly more tuned for LLM inference.

Yeah I'm fairy pessimistic about how much folks will read

100%. I was excited when i read that disclaimer and found myself disappointed by the limited content. That said, i did get a couple tidbits out of it.

I've found the latency of /compact makes it unusable. Perhaps this is just the result of my waiting until I have 0% context remaining.

Fun fact, a large chunk of context is reserved for compaction. When you are shown that you have "0% context remaining," it's actually like 30% remaining that's reserved for compaction.

And yet, for some reason I feel like 50% of the time, compaction fails because it runs out of context or hits (non-rate) API limits.

Definitely experience this. After losing over 2 hours fiddling between a few sessions and still having no actual control I’ve settled on a handful of python and perl/regex scripts to make sure things are following my own conventions

I have quite long CLAUDE.md file and claude code follows it almost all the time. When it was ignoring some instructions, i told it to update CLAUDE.md to make sure it does. It emphasized it with uppercase and IMPORTANT! ALWAYS DO ... and that make it work for me like 95% of the time. And I do this for multiple project with different CLAUDE.mds with similar results. I don't know why your experience differs so much.

Same experience, although I gave up already a while ago so not sure if CLAUDE.md is better followed in newer versions.

It's a known issue among us Claudemasters.

Better? Hard to say. Different? Yes. Worth evaluating? Absolutely. Using it for 30 minutes will answer your question better than any reply here. I think you'll answer your own question quickly.

I've been coding seriously for about 15 years. No single tool has changed how I code more than claude code and I'm including non-"AI" tooling/services. This sounds like I'm shilling but I am not affiliated. It's played a large part in injecting my passion back into building stuff.

Yeah I started with Cursor, went hybrid, and then in the last month or so I've totally swapped over.

Part of it is the snappy more minimal UX but also just pure efficacy seems consistently better. Claude does its best work in CC. I'm sure the same is true of Codex.

Direct use of Codex + GPT5 or Claude Code CLI gives a better result, compared to using the same models in Cursor. I've compared both. Cursor applies some of their augmentation, which reduces the output size, probably to save on tokens.

I use Claude and Codex in VS Code and they work really well.

> I select the text and Cmd-L, saying "fix this part, it's broken like this

This flow works well.

Claude is able to detect the lines of code selected in vscode anyway

Yes and you can select multiple files to give it focus. It can run anything in your PATH too. Eg it's pretty good at using `gh` and so on

They all have optional ide integration, e.g Claude knows the active vscode tab and highlighted lines.

Claude is just better at coding than cursor.

Really, the interface isn't a meaningful part of it. I also like cmd-L, but claude just does better at writing code.

...also, it's nice that Anthropic is just focusing on making cool stuff (like skills), while the folk from cursor are... I dunno. Whatever it is they're doing with cursor 2.0 :shrug:

It seems so ... LLM-based coding tools are mostly about speed and cost of development - corporate accounting metrics, but what customers care about is mostly product features (& lack of bugs).

There is no customer advantage to developing cheap and fast if the delivered product isn't well conceived from a current and future customer-needs perspective, and a quickly shipped product full of bugs isn't going to help anyone.

I think the same goes for AI in general - CEOs are salivating over adopting "AI" (which people like Altman and Amodei are telling them will be human level tomorrow, or yesterday in the case of Amodei), and using it to reduce employee head count, but the technology is nowhere near the human level needed to actually benefit customers. An "AI" (i.e. LLM) customer service agent/chatbot is just going to piss off customers.

What do you mean by "customer"? Because I'm also using these tools to understand the customer better.

I have the same instinctive response to reading AI generated stuff, but I'm coming to a more moderate position where I'm trying to judge the content on the content itself. For example, in a post like this, it doesn't bother me at all because it's still an extremely useful reference, and the author clearly read through, organized, and edited the output. This is a good example of usage of AI in my opinion.

The people who just copy paste output from ai and ship it as a blog post however, deserve significant condemnation for that.

The internet is dead. Long live the internet.

> Tired of reading posts written by AI.

Didn’t realize you were forced to read this?

> Feels disrespectful to your readers

I didn’t feel disrespected—I felt so respected I read the whole thing.

Nothing crazy about it, judging by how much CPU and memory it uses. Now, if it managed to grow features without bringing my M4 Mac with 64GB of ram to a crawl... that's be magic.

The prerequisite thought here is that you're using CC to invoke CLI tools.

So now you need to get CC to understand _how_ to do that for various tools in a way that's context efficient, because otherwise you're relying on either potentially outdated knowledge that Claude has built in (leading to errors b/c CC doesn't know about recent versions) or chucking the entirety of a man page into your default context (inefficent).

What the Skill files do is then separate the when from the how.

Consider the git cli.

The skill file has a couple of sentences on when to use the git cli and then a much longer section on how it's supposed to be used, and the "how" section isn't loaded until you actually need it.

I've got skills for stuff like invoking the native screenshot CLI tool on the Mac, for calling a custom shell script that uses the github API to download and pull in screenshots from issues (b/c the cli doesn't know how to do this), for accessing separate APIs for data, etc.

Maybe these might be handy: - https://github.com/anthropics/skills - https://www.anthropic.com/engineering/equipping-agents-for-t...

I think if it literally as a collection of .md files and scripts to help perform some set of actions. I'm excited for it not really as a "new thing" (as mentioned in the post) but as effectively an endorsement for this pattern of agent-data interaction.

apparently I missed Simon Willison's article, this at least somewhat explains them: https://simonwillison.net/2025/Oct/16/claude-skills/

So if youre building your own agent, this would be a directory of markdown documents with headers that you tell the agent to scan so that its aware of them, and then if it thinks they could be useful it can choose to read all the instructions into its context? Is it any more than that?

I guess I dont understand how this isnt just RAG with an index you make the agent aware of?

to be clear that repo is simply a thin neovim plugin for the truly excellent agent TUI opencode

I recommend using it directly instead of via the plugin

We have a linter that checks for this to help mitigate

Yeah it is a mystery to me how folks could also maintain context in more than two sessions. The code review would be brutal.

You’ll also end up dealing with merge conflicts if you haven’t carefully split the work or modularized the code.

I generally like to use it. But I one project in the org which simply can’t work because the internal built system expects a normal .git directory at the root. Means I have to rewrite some of the build code that isn’t aware of this git feature. And yes we use a library to read from git but not the git cli or a more recent compatible one that understands that the current work tree is not the main one.

Agree, depending on the repo and changes it’s hard with local dev servers. It sometimes works well if you don’t need local dockers and want to outsource git workflow to CC as well. Then it can do on that branch whatever it wants and main work is in another worktree with more steering and or docker env.

I have a bash script that creates the worktree, copies env over and changes the ports of containers and the services. I then can proxy the "real" port to any worktree, it's common I'll have 3 worktrees active to switch back and forth

I gave that a try, then I decided to use devcontainers instead, and I find that better, for the reasons you mentioned.

With all the LLM coding assistants, you have to get a feel for each model and which extension/interface you're using with them. Not only that, but it's also dependent on your project!

For example, if you're writing a command line tool in Python, it doesn't really matter what model you use since they're all really great at Python (LOL). However, if you're writing a complicated SPA that uses say, Vue 3 with Vite (and some fancy CSS framework) and Python w/FastAPI... You want the "smartest" model that knows about all these things at once (and regularly gets updated knowledge of the latest versions of things). For me, that means Claude Code.

I am cheap though and only pay Anthropic $20/month. This means I run out of Claude Credits every damned week (haha). To work around this problem, I used to use OpenAI's pay-per-use API with gpt5-mini with VS Code's Copilot extension, switching to GPT5-codex (medium) with the Codex extension for more complicated tasks.

Now that I've got more experience, I've figured out that GPT5-codex costs way too much (in API credits) for what you get in nearly all situations. Seriously: Why TF does it use that much "usage". Anyway...

I've tried them all with my very, very complicated collaborative editor (CRDTs), specifically to learn how to better use AI coding assistants. So here's what I do now:

    * Ollama cloud for gpt-oss:120b (it's so fast!)
    * Claude Code for everything else. 

With Claude Code, it's like magic: You give it a really f'ing complicated thing to troubleshoot or implement and it just goes—and keeps going until it finishes or you run out of tokens! It's a, "the future is now!" experience for sure.

With gpt-oss:120b it's more like having an actual conversation, where the only time you stop typing is when you're reviewing what it did (which you have to do for all the models... Some more than others).

FYI: The worst is Gemini 2.5. I wouldn't even bother! It's such trash, I can't even fathom how Google is trying to pass it off as anything more than a toy. When it decides to actually run (as opposed to responding with, "Failed... Try again"), it'll either hallucinate things that have absolutely nothing to do with your prompt or it'll behave like some petulant middle school kid that pretend to spend a lot of time thinking about something but ultimately does nothing at all.

I just started developing self-hosted services largely with AI.

It wasn't possible before for me to do any of this at this kind of scale. Before, getting stuck on a bug could mean hours, days, or maybe even weeks of debugging. I never made the kind of progress I wanted before.

Many of the things I want, do already exist, but are often older, not as efficient or flexible as they could be, or just plain _look_ dated.

But now I can pump out react/shadcn frontends easily, generate apis, and get going relatively quickly. It's still not pure magic. I'm still hitting issues and such, but they are not these demotivating, project-ending, roadblocks anymore.

I can now move at a speed that matches the ideas I have.

I am giving up something to achieve that, by allowing AI to take control so much, but it's a trade that seems worth it.

Often code in SaaS companies like ours is indeed how we solve customer problems. It's not so much the amount of code but the rate (code per time) we can effectively use to solve problems/build solutions. AI, when tuned correctly, lets us do this faster than ever possible before.

>> Why are you producing so much code?

This is basically a "thinking tax".

If you don't want to think and offload it to llm they burn through a lot of tokens to implement in a non-efficient way something you could often do in 10 lines if you though about it for a few minutes.

There's an Atlasian cli with Jira support https://developer.atlassian.com/cloud/acli/reference/command...

Jiratui[0] has some support for basic automation. That's probably what OP is using as it is the most poppular Jira cli tool out there.

0: https://github.com/whyisdifficult/jiratui

First search result (on Kagi): https://github.com/ankitpokhrel/jira-cli

Latest version from 2 momths ago, >4700 stars on GitHub

At some point I vibecoded myself everything into cli commands, anything that has API could be a cli command.

It seems to be relative to skill level. If you're less-experienced, you're letting these things write most if not all of your code. If you're more experienced, that's inverted (you write most of the code and let the AI safely pepper things in).

Makes sense. I work for a growth stage startup and most of these apply to our internal mono repo so hard to share specifics. We use this for both new and legacy code each with their own unique AI coding challenges.

If theres enough interest, I might replicate some examples in an open source project.

No, I think it is normal. If it were easy to gain a mental model of the code simply by reading, then debugging would be trivial. The whole point of debugging is that there are differences between your mental model of the code and what the code is actually doing, that sometimes can't be uncovered unless you step through it line by line even if you're the one who wrote it.

It is why I am a bit puzzled by the people who use an LLM to generate code in anything other than a "tightly scoped" fashion (boilerplate, throwaway code, standalone script, single file, or at the function level). I'm not sure how that makes your job later on any easier if you have even a worse mental model of the code because you didn't even write it. And debugging is almost usually more tedious than writing code, so you've traded off the fun/easy part for a more difficult one. Seems like a faustian deal.

I treat everything I find in code review as something to integrate into the prompts. Eventually, on a given project, you end up getting correct PRs without manual intervention. That's what they mean. You still have to review your code of course!

I've found planning to be key here for scaling to arbitrary complex changes.

It's much easier to review larger changes when you've aligned on a Claude generated plan up front.

Given that this space is so rapidly evolving, these kinds of posts are helpful just to make sure you aren't missing anything big. I've caught myself doing something the hard way after reading one of these. In this case, the framing is basically man pages for CLIs was a helpful description of sills that gives me some ideas about how to improve interaction with an in-house CLI my co. uses.

I wouldn't use as a guide necessarily, but I would use as a way to sync my own findings and see if I have missed something important.

I wouldn't say I follow them as guides, but I think the field is changing quickly enough that it's good, or at least interesting, to read what's working well for other people.

This one is already out of date. The bit on the top about allocating space in CLAUDE.md for each tool is largely a waste of tokens these days. Use the skills feature.

Sometimes I write with Claude in English and German mixed with really bad typos and it’s amazing how well it works.

Skills seem like the way forward, but Claude still needs to be convinced to activate the skill. If that's not happening reliably, hooks should be able to help.

A sibling comment on hooks mentions some approaches. You could also try leveraging the UserPromptSubmit hook to do some prompt analysis and force relevant skill activation.

I wonder how well a sentence or two in CLAUDE.md, saying to search the local project for examples of similar use cases or use of internal libraries, would work.

Hooks can also be useful for this. If it's using the wrong APIs then can hint on write or block on commit with some lint function that checks for this.

If you have no modifications or customization of Claude code then it comes down to a preference for proactivity (codex) or a bit more restraint.

If you are using literally any of Claude Code’s features the experience isn’t close, and regardless of model preference (Claude is my least favorite model by far) you should probably use Claude code. It’s just a much more extensible product for teams.

CC has better agent tools and is faster. The ability to switch from plan mode to execution mode and back is huge. Toggling thinking also. And of course they are innovating all of these agentic features like MCP, sub-agents, skills, etc...

Codex writes higher quality code, but is slower and less feature rich. I imagine this will change within months. The jury is still out. Exciting times!

I use both at the same time. CC seems to have better access to web and researching capabilities compared to Codex. Maybe I'm not using Codex right or missing something, but it has frequent troubles browsing internet. Also Claude Code is faster. So I use it when I know it can handle the task.

Ecosystem features and cohesion.

Both. Codex MCP within CC as a second brain. Best of both worlds.

I feel or have the fear that the world will tumble and crack under the sheer amount of code we produce and can’t be maintained because at one point no one human can understand all the stuff that was written.

At the moment though I also code on and off with an agent. I’m not ready or willing to only vibe code my projects. For one is the fact that I had tons of examples where the agent gaslighted me only to turn around at the last stage. And in some cases the code output was to result focused and didn’t think about the broader general usage. And sure that’s in part because I hold it wrong. Don’t specify 10million markdown files etc. But it’s a feedback loop system. If I don’t trust the results I don’t jump in deeper. And I feel a lot of developers have no issue with jumping ever deeper. Write MCPs now CLIs and describe projects with custom markdown files. But I think we really need both camps. Otherwise we don’t move forward.