Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Claude Code works in large codebases

claude.com

Post reply on HN
Print view View original

141–150 of 191 posts

Re: How Claude Code works in large codebases

#141

Post by vntok »

wg0 wrote: post #140
JohnMakin wrote: post #138

Earlier quoted context omitted.

The article listed explains how to avoid this. If you naively turn it loose on a big code base, yes, you’ll burn a lot of tokens while it tries to find stuff.

If I set a regular expression as watcher on a filesytem to notify me if any file changes and I write that in go and assuming regular expression isn't buggy nor its implementation - and then I write rules in a file (as regex) then there's snowball in hell of a chance that it would misnotify or miscategorize anything. Are LLMs that super reliable in their output already with all the guardrails around? Don't think so. H…

> Are LLMs that super reliable in their output already with all the guardrails around?

Well, what is your definition of "super reliable in the output", and is it a quantifiable/measurable target or just a feeling?

Is it "more than humans", "more than senior developers", "almost perfect", "perfect"?

> It might behave differently than specified and a human is required to validate every output carefully or else.

Sure, just like meatbag developers. All the security flaws AI finds today were introduced years/decades ago by humans and haven't been found (that we know) by humans in ages.

Re: How Claude Code works in large codebases

#142

Post by zihotki »

I wonder if Anthropic tested their claims on a pro, 5x, 20x subscriptions. When you have infinite amount of free tokens it sure makes sense, you just throw tokens at the problem. But not in a limited usage scenarios it doesn't fly far..

Re: How Claude Code works in large codebases

#143

Post by zihotki »

mewpmewp2 wrote: post #85
suzzer99 wrote: post #63

Earlier quoted context omitted.

Yeah I'm working on one of those now that a 3rd-party vendor cranked out for us. I spent all day ripping out an endpoint that did 98% of what another endpoint did and should never have existed. I also ripped out 80 lines of code that looked like this: const sqlStatement = (!params.mostRecentOnly) ? {giant SQL statement} : {identical giant SQL statement + 'LIMIT 1' at the end} AI never met a problem that can't be solv…

That is a skill issue though. I have rules for my agents to write compositional, reusable, modular, small files and to avoid any sort of boilerplate etc. Being config driven, single source of truth, having other agents review that rules are followed, etc. Any API or UI or any sort of entry points very light, just proxying to the modular logic basically, so this logic could be reused by any entrypoint easily. UI compo…

How do you make it so that the model doesn't forget to follow those rules and skills? How do you make it actually understand the architecture and constraints? You can't, current models don't work that way to make it happen.

Re: How Claude Code works in large codebases

#144

Post by wg0 »

vntok wrote: post #141
wg0 wrote: post #140

Earlier quoted context omitted.

If I set a regular expression as watcher on a filesytem to notify me if any file changes and I write that in go and assuming regular expression isn't buggy nor its implementation - and then I write rules in a file (as regex) then there's snowball in hell of a chance that it would misnotify or miscategorize anything. Are LLMs that super reliable in their output already with all the guardrails around? Don't think so. H…

> Are LLMs that super reliable in their output already with all the guardrails around? Well, what is your definition of "super reliable in the output", and is it a quantifiable/measurable target or just a feeling? Is it "more than humans", "more than senior developers", "almost perfect", "perfect"? > It might behave differently than specified and a human is required to validate every output carefully or else. Sure, j…

It is quantifiable thing not a feeling.

Between ten thousand runs of:

``` const int MAX_COUNT = 10000;

printf("I'll count up to %d", MAX_COUNT); for(int i=1; And of the following prompt:

``` You'll count to 10,000. At the start say "I'll count up to 10,000" and then for each number say "I'm now counting " and do not say anything else. Do not miss numbers in between. ```

Which one is going to produce 100% correct results out of a 10,000 run of each?

Now don't give me "these are different tools". We all know. I'm talking about reliability and predictability.

Re: How Claude Code works in large codebases

#145

Post by bluGill »

sumitkumar wrote: post #71
marhee wrote: post #39

Earlier quoted context omitted.

The answer is in the introduction: > Claude Code is running in production across multi-million-line monorepos, decades-old legacy systems, distributed architectures spanning dozens of repositories (…) So it is optimized for the general case, using robust tooling that works everywhere, especially when large & messy. That being said, your remark is right and for well organised smaller repo’s there’s better tooing it ca…

But the general use case is not the most efficient for a greenfield to-be fully managed by an agentic system code-base. It is built to be good around the scaffold(programming like humans) and not the actual problem space. Anthropic's target should be a codebase designed for agentic comprehension from the first commit. Here the codebase adapts to the agent. You can enforce conventions, structured metadata, semantic in…

The large majority of coding is maintenance work, not greenfield development. Even if you are doing greenfield development, it won't be long before it is maintenance.

Re: How Claude Code works in large codebases

#147

Post by tommy29tmar »

belZaah wrote: post #2

How very interesting. In an industry, where things shift around in months if not weeks, there’s been not only enough time for clear patterns to emerge but also these patterns have proven successful on large codebases. What’s the success criteria? Didn’t delete production database? Team velocity has increased? Codebase TTL has increased? Operations guys are happier?

[flagged]

Re: How Claude Code works in large codebases

#148

Post by cpursley »

digitaltrees wrote: post #34
giancarlostoro wrote: post #3

Earlier quoted context omitted.

> Didn’t delete production database? I still say if this happens to you with AI tooling, that's both a failure on you and your org for giving a developer prod credentials that could nuke production resources. I don't think I've worked in a place that gave me this level of blind access.

Dude, AI has been shown to execute queries on coworkers env files, extract master keys, decrypt variables and push to production.

Why are important push secrets in a dev env config? Btw humans devs make this same mistake all the time.

Re: How Claude Code works in large codebases

#149

Post by eithed »

I ask Claude to fix given test:

- runs the test what is failing | grep "x|failing" | tail 10

- runs the test again to get the why it's failing message | tail 10

- runs the test again because tail 10 cut off the message

every time. What developers do things like this?!

I have a skill for it to not do that = save output for whatever test you run into file, read from file using whatever commands you want. Ignores the skill.

Same for debugging - something is failing. Instead of debugging given issue to see why it's failing, looking at the results it will look at the code trying to deduce why it's failing. First trace it finds that looks suspicious? "THAT'S IT, I FOUND IT. But let me reconsider." and after 15m it produces summary that is wrong. Put a debug point, look at it, then make your decisions. You have a skill to use for debugging that is phrased to do exactly that! No. I've never seen a human do things like this either.

It's maddening. It's as if, puts on tinfoil hat, it's designed to waste your tokens, while eventually accomplishing its task.

Re: How Claude Code works in large codebases

#150

Post by DanielHB »

JohnMakin wrote: post #138
wg0 wrote: post #136

> How claud code works in large codebases? Simple - It even eats up to 35% five hour usage limit in first prompt even on small projects and then there's 5 minutes time out for you to respond quickly or caches would go bust and you'll pay another 12% to 15% on the next prompt.

The article listed explains how to avoid this. If you naively turn it loose on a big code base, yes, you’ll burn a lot of tokens while it tries to find stuff.

This is such a shame, finding where stuff is in a large codebase is my number 1 use for LLM. I hate it that it relies on grep so much, I can do grep better and faster myself.
Post reply on HN