kaydub
Our claude bills are rivaling our datadog bills and might get to the size of our AWS bills. It's pretty crazy.
I hate when people put things in quotes as if they're quoting something but it's not even a quote of anything.
Maybe go read the user policy instead of the headlines and the snippets. If your attention span can't manage that, get off the computer a little bit.
If I have a business and I raise $10M at a $100M valuation for 10% of the company, the people giving me the money really value the business at $90M, their addition of the $10M into the business brings the valuation to $100M.
It's not always exactly like that, 1 for 1, but that's the gist. Without the capital, the business is not worth as much as the valuation at the time of the raise.
You know it's possible to READ too, right? I don't have to write the code or documentation... not that writing documentation means anything.
I have hundreds of repos at my job, some are in the 10s of thousands of lines of code, many are in the hundreds of thousands, and we still have a couple monoliths in the millions of lines of code range.
Personal projects completely built with the LLM range in the 10s to 100s of thousands of lines.
It's sustainable. LLMs have no problem working on all these projects and working on them across repos.
But I don't know what "vibe coding actual large projects blind" is supposed to mean.
I don't miss sshing into servers or using puppet, ansible, salt, chef.
I run a bunch of cheap (free?) custom apps for myself in the "serverless" or "cloud native" stuff in AWS. Everything else is on my NAS running on my home network (I see people mentioning qbittorrent, jellyfin, etc).
I stopped using cheap vps providers probably a decade ago, not a huge difference between a $5/mo cheap vps to a basic ec2 instance in pricing. And there were always issues with the cheap vps. Not to mention how easy it is to backup mediawiki + mysql in AWS vs having to spin up ANOTHER vps. Maybe there are cheap vps providers that offer object storage now, but I never bothered looking.
You're really going to use papers from 2023 and 2024? It's 2026. The models are better these days... a lot better. Like come on man "The best-performing model, Claude 2" You're going to base your assessment on THAT?
Dude, maybe it's YOU guys working on small codebases that are worrying about "knowing the codebase" or maybe you guys just work on shit code, I don't know. This industry isn't new, there are known patterns and the models know them. It's really not hard to navigate a new codebase if you know what you're doing or if you know the framework or patterns of the language/platform. If you think you know your whole codebase though, I'd argue that it's YOU working on a small or simple app.
I'm not even understanding your line of questioning here. I don't know the codebase because I had an LLM write it and I didn't write documentation? You think writing documentation means you know the codebase? You think having your goals in writing is any different than putting it in the prompt?
Prove it.
Somewhat related, I DID test some of this stuff today. Plain claude, telling it to use gitlab mcp to review our codebase vs a big claude skill (for mr reviews) with a lot of details encoded in the plugin, kinda like these overly verbose and other llm generated document rube goldberg machine.
Plain claude with a simple paragraph prompt + gitlab mcp outperformed the skill by quite a bit. Less false positives, one finding the skill didn't find, ran in 4min for less than $1 vs 45min and $20 for the skill (which is basically overly verbose documentation packaged up)
The llms don't need your prose or your documentation, they can figure things out more efficiently without it.
> Are you writing any of the code? Writing the tests? If not, then there isn’t any proof that you actually know the code base unless you have documentation
The code is the documentation. You can read the code. This makes zero sense.
Your two statements are contradictory here. Docs should be good enough so the llm doesn't need to read the codebase, but it should just summarize everything? You can't have both.
I even stated in my OG post that I still keep a claude/agents.md, they're just VERY SMALL. I'm railing against the decision docs, the explosion of markdown files, and the extremely verbose code comments. All the LLM generated docs are causing friction more than anything, the llms are just good enough to work through it.
You absolutely need some documentation. Like I originally said, I still do keep a claude/agents.md too, they're just stripped down A LOT.
Human maintained knowledge base and documentation is good. Not even 100% human maintained, just make sure human eyes are reading it before you commit it! And if it's said in code it doesn't need to also be said in the docs, that's how they get stale and you get drift. This is causing LLMs problems.
The docs you don't need are big decision docs that keep getting appended to, multiple long lived markdown files, and verbose comments (I literally saw multiple MRs today with more lines of comments than lines of code, as bad as one file that had a single line changed but then 5 paragraphs of mostly unrelated details, overly specific details, and just plain claude slop). This stuff isn't helping.
And the one issue I'm mainly conflating this with are all the skills/plugins/etc that people are making thinking it's making their claude better. Like the super-powers repo that's been floating around for months, that thing is trash, you don't need it. Maybe you did before (I still don't really think so) but you especially don't need it now.
One guy is talking about running tests and parsing json with claude... but why would you even do that? Just make deterministic tools and then you run those for your testing.
Again, something else I'm seeing, someone wedging claude into ci/cd and then having claude use skills that run linters and trivy. Why is that not just in ci/CD???
The proliferation of prose is maddening
* vanilla claude with our MCPs + a decent prompt (like a paragraph tops) * an agent that was previously made, much more concise skills * the mr tool this IC created
The MR tool didn't even catch some of the stuff in our domain that the others caught and it took 45minutes, cost $20 vs 4mins for vanilla (<$1) and 7mins for the agent ($3ish)
And yeah, code-reviews are supposed to be by humans, but we have a ton of reviews come in where there's a ton of low hanging fruit. This tool is meant to be a gate between getting an actual human code review and some of the slop coming in these days.
I'll go through a bunch more MR reviews, see how things go. But I've gotta start figuring out how to test the documentation, decision docs, and other plugins/skills.
People take things a little too literally and absolute on the internet. I'm more posting like this as a push back from the absolutely insane amount of documentation, plugins/skills, decision docs, and other bs I'm seeing in my professional life and being shared online.
I even said in my original comment in here that I still do have AGENTS/CLAUDE.md files. I've just trimmed them.
There's documentation where I work. I'd say I even made up about 5-10% of the documentation on our knowledge base (pre-llm). But now our knowledge base is mostly useless because every eng/dev is creating so much fucking documentation. A lot of it trash LLM generated.
I've already DONE the large docs, the decision docs, the skills/plugins. I'm ripping those out now because I can see that they're garbage and they add little to zero value.
And I don't get where you think I'm telling everyone I don't have proof that I understand what my AI built. Doesn't even make sense. Because I don't have it generate tons of prose that's going to get stale? I'm okay not generating low value garbage and patting myself on the back for it.
I've got one example that's at the top of my mind driving me crazy right now.
We have to move some git repos. It requires making sure there are no secrets in git history or committed, in a lot of cases we're just archiving, creating new repos, copying the code over. We just have to mostly mirror the config of the prior repo. There are probably about 100 repos that we need to move. I farmed this out to 3 of my ICs, a Sr and 2 jr/mid level guys. I thought one of them would figure out a way to mass move them and worst case they just move them real quick... shouldn't be too hard.
Well my Sr has spent the past 6-8 weeks building claude skills/plugins to move the repos. Every week he finds an edge case or the tool doesn't do something perfect, so every sprint he has "fixes" for it.
So far he's moved 5 repos. The jr/mid level guys, one has moved 30 the other has moved 10. I grabbed one of these tasks, threw claude at it (again, no tools or any bullshit), gave it a quick prompt, knocked out one of these in 20 minutes (while multi-tasking).
This same IC has built an MR review tool. It takes 20-60 minutes to run and costs $20-$50+ each run. Wants to put it into our CI/CD so that it runs on MRs. If you include all the pipelines that would run because of a dev updating a branch in an MR we're talking hundreds to thousands of pipelines a day.
I thought this dev was token maxing or just trying to look busy and I've had to sit down and talk to him, pull him aside for quick 1 on 1s, and to be honest, I don't get the feeling that he knows what he's doing is a gigantic waste of time. The LLMs are sycophants that glaze you. You think everything coming out of it is GREAT work because it tells you that. And I think this is happening across all layers of every org out there in various degrees.
The condescending attitude isn't a great look, especially when you're making up strawmen arguments.
But due to how LLMs work I just don't think it's possible. We still need deterministic software imo.
I'm seeing ENORMOUS decision files and when I read them a lot of the decisions are self-evident. Or the decisions flip flop but the old decisions remain in the file, which fucks up context. It's often better to completely remove a reference to X rather than leave it and have an amendment later that says "don't do X". Because X is in context, now the LLM is more likely to stumble into doing X.
So many people producing documents, comments, prose and it's just unnecessary. The LLMs don't do well keeping it up to date too. It's the snake eating its tail.
I don't really care how claude parses json. I'd say you're just wasting your time caring about that detail. I definitely wouldn't put that kind of useless info into my claude.md/agents.md.
If I DID care, yeah, I think it makes more sense to just correct the action. I'm not parsing json in every session so why would I want it in context for every session AND every sub-agent's session?
I like how so many of you get offended or go on the attack acting like I'm vibe coding some small apps. I'm working at a small/medium enterprise business with about 1B in ARR. We have 100s of repos, a couple of which are our original monolithic products. There's no issue working on any of these apps. The models have no problem using gitlab mcp to get pertinent information when they need it.
You aren't putting into 500 tokens what takes 5k tokens to discover. I've found that when I had these larger markdown files with all the details the models STILL went to the code to review. Then the markdown files get stale in spots, NO MATTER WHAT. Not only stale, but if you're having agents maintain these files they WILL hallucinate or input superfluous or unnecessary info. Now that I have short markdown files (or none in some instances) the agent just looks at the code and it's pretty simple to figure out.
And yes, I think most of the skills are a waste of time. You're just creating more shit to maintain. The most usable and reusable skills end up being short and concise, to where you could just type them into the prompt in any number of ways adhoc... effectively making the skill mostly worthless. The big skills end up being too much and less effective ime. And it can be difficult to rely on agents to invoke skills or the right skills.
If my skills need maintenance and hand holding, what am I really gaining?
Like you said, an inline comment probably makes more sense. Sure, maybe it misses it, then you can just tell it. Better than putting such granular details in a CLAUDE/AGENTS.md and better than having disparate markdown files or decisions documents that get unwieldy.
I've just been trimming down to the recommended < 100 lines and I keep only super high level info in there and allow the agents to figure things out by reading the code.
I wouldn't use a blog post from Nov 2025 be my guiding light.
Anthropic over the past few months have said they've cut their system prompts 80%. These are current best practices. The models are good enough and can figure things out on their own BETTER than you can present the info in markdown files and "decision" documents.
I'm seeing decision files that are so big the LLM can't fit it all in context on some projects. Then the LLM makes decisions that revert previous ones and later sessions don't pick that up so it sticks to the original decision. Now in some sessions, every so often I have to remind the LLM, "no, we changed that later, we do it this way now"
And I'm seeing our knowledge base grow to a completely useless giant mess of stale, outdated, duplicated, or superfluous info. LLMs often pull unrelated info or confuse similar but different things or get old documentation for something that's been updated to new documentation in a different part of the knowledge base. And these are LLMs generating the docs. And we have LLMs and agents reconciling. But it doesn't seem to always get everything.
For code comments, it's terrible because the comments are starting to get larger than the code. A large chunk of the comment can be discerned from the code itself. Then the comment has details on why that maybe don't quite make much sense. It's like the LLMs start using words in a specific context that doesn't really apply to the word in normal spoken english. Then it will also often include a specific JIRA ticket id, you check the JIRA ticket, you see that yeah, the code was changed because of that JIRA ticket, but it's not really related to the ticket itself, it was just a blocker. But now the comment forever links it to THAT ticket (And then now sometimes the LLM pulls in that ticket with the atlassian mcp).
Locally? Our devs can do whatever they want. For anything I'm working on, for local deployments and testing, I generally build it out so it's set in Makefile/Taskfile. If you're running your determinstic tests locally it should really just be a single command that bootstraps everything and runs the tests, or updates a certain part of your app and runs the tests. The LLM shouldn't need credentials in that instance.
Regardless I'm deploying a local stack of some sort all the credentials and everything are probably stored locally or in an env var where the llm will have access. So if I was having the LLM drive a browser during active development, it can look at the files.
Sure, I guess we could put in the top level markdown more details about this... but why? It takes little time or context for it to figure it out. We have shit change so frequently that it's just something else we have to maintain.