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

What makes Claude Code so damn good

minusx.ai

Post reply on HN
Print view View original

171–180 of 322 posts

Re: What makes Claude Code so damn good

#171

Post by rbren »

the_mitsuhiko wrote: post #53

Unfortunately, Claude Code is not open source, but there are some tools to better figure out how it is working. If you are really interested in how it works, I strongly recommend looking at Claude Trace: https://github.com/badlogic/lemmy/tree/main/apps/claude-trac... It dumps out a JSON file as well as a very nicely formatted HTML file that shows you every single tool and all the prompts that were used for a session.

If you’re looking for an OSS alternative check out OpenHands CLI: https://github.com/All-Hands-AI/OpenHands?tab=readme-ov-file

Re: What makes Claude Code so damn good

#172

Post by esafak »

BeetleB wrote: post #119
socalgal2 wrote: post #47

Earlier quoted context omitted.

I’m trying to learn jj. Both Gemini and ChatGPT gave me incorrect instructions 4 of 5 times https://jj-vcs.github.io/jj/

That's because jj is relatively new, and constantly changing. The official tutorial is (by their own admission), out of date. People's blog posts are fairly different in what commands/usage they recommend, as well. I know it, because I recently learned jj, with a lot of struggling. If a human struggles learning it, I wouldn't expect LLMs to be much better.

That's ironic considering jj is supposed to make version control easier.

Re: What makes Claude Code so damn good

#173

Post by turnsout »

orsorna wrote: post #112
imiric wrote: post #96

Earlier quoted context omitted.

Well, don't be shy, share what CC helped you build.

[flagged]

There’s still a stigma. I think people are worried that if it gets out that their startup was built with the help of an LLM, they’ll lose customers who don’t want to pay for something “vibe coded.”

Honestly I don’t think customers care.

Re: What makes Claude Code so damn good

#174

Post by monkpit »

bilekas wrote: post #170
dgunay wrote: post #157

Earlier quoted context omitted.

Letting go of the particulars of the generated code is proving difficult for me. I hand edit most of the code my agents produce for taste even if it is correct, but I feel that in the long term that's not the optimal use of my time in agent-driven programming. Maybe the models will just get so good that they know how I would write it myself.

I would argue this approach will help you in the long term with code maintainability. Which I feel will be one of the biggest issues down the line with AI generated codebases as they get larger.

The solution is to codify these sorts of things in prompts and tool use and gateways like linters etc. you have to let go…

Re: What makes Claude Code so damn good

#175

Post by zackify »

zackify wrote: post #162
erelong wrote: post #161

> The main takeaway, again, is to keep things simple. if true this seems like a bloated approach but tbh I wouldn't claim to know totally how to use Claude like the author here... I find you can get a lot of mileage out of "regular" prompts, I'd call them? Just asking for what you need one prompt at a time? I still can't visualize how any of the complexity on top of that like discussed in the article adds anything to…

How you see and use it is the same way I do. So interested to hear other replies

Wow. Auto correct. I meant “interested”

Re: What makes Claude Code so damn good

#176

Post by mlrtime »

throwaway314155 wrote: post #129
koakuma-chan wrote: post #110

Earlier quoted context omitted.

https://github.com/dnakov/claude-code :trollface:

That's been DMCA'd since you posted it. Happen to know where I can find a fork?

Just search dnakov/claude-code mirror and there is a path to the source code, I found it in 2 minutes.

Re: What makes Claude Code so damn good

#177

Post by chazeon »

ahmedhawas123 wrote: post #104

Thanks for sharing this. At a time where this is a rush towards multi-agent systems, this is helpful to see how an LLM-first organization is going after it. Lots of the design aspects here are things I experiment with day to day so it's good to see others use it as well A few takeaways for me from this (1) Long prompts are good - and don't forget basic things like explaining in the prompt what the tool is, how to hel…

I want to note that: long prompts are good only if the model is optimized for it. I have tried to swap the underlying model for Claude Code. Most local models, even those claimed to work with long context and tool use, don't work well when instruction becomes too long. This has become an issue for tool use, where tool use works well in small ChatBot-type conversation demos, but when Claude's code-level prompt length increases, it just fails, either forgetting what tools are there, forgetting to use them, or returning in the wrong formats. Only the model by OpenAI, Google's Gemini, kind of works, but not as well as Anthropic's own models. Besides they feel much slower.

Re: What makes Claude Code so damn good

#178

Post by mlrtime »

turnsout wrote: post #173
orsorna wrote: post #112

Earlier quoted context omitted.

[flagged]

There’s still a stigma. I think people are worried that if it gets out that their startup was built with the help of an LLM, they’ll lose customers who don’t want to pay for something “vibe coded.” Honestly I don’t think customers care.

I used the analogy to how online dating started. I remember [some] people were embarrassed to say they met online so would make up a story. We're in that phase of AI development, it will pass.

Re: What makes Claude Code so damn good

#179

Post by hoyo1s »

fragmede wrote: post #160
actsasbuffoon wrote: post #156

Earlier quoted context omitted.

This mirrors a weird thought I’ve had recently. It’s not a thing I necessarily agree with, but just an idea. I hear people say things like, “AI isn’t coming for my job because LLMs suck at [language or tech stack]!” And I wonder, does that just mean that other stacks have an advantage? If a senior engineer with Claude Code can solve the problem in Python/TypeScript in significantly less time than you can solve it in…

LLMs write python and typescript well, because of all the examples in their training data. But what if we made a new programming language whos goal was to be optimal for an LLM to generate it? Would it be closer to assembly? If we project that the future is vibe coded, and we scarcely look at the outputted code, testing, instead, that the output matches the input correctly, not looking at the code, what would that la…

Strict type-checking and at least with some dependent type and inductive type

Re: What makes Claude Code so damn good

#180

Post by majormajor »

actsasbuffoon wrote: post #156
schmookeeg wrote: post #144

Earlier quoted context omitted.

Claude and some of the edgier parts of localstack are not friends either. It's pretty okay at rust which surprised me. It makes me think that the language/platform/architecture that is "most known" by LLMs will soon be the preferred -- sort of a homogenization of technologies by LLM usage. Because if you can be 10x as successfully vibey in, say, nodejs versus elixir or go -- well, why would you opt for those in a gre…

This mirrors a weird thought I’ve had recently. It’s not a thing I necessarily agree with, but just an idea. I hear people say things like, “AI isn’t coming for my job because LLMs suck at [language or tech stack]!” And I wonder, does that just mean that other stacks have an advantage? If a senior engineer with Claude Code can solve the problem in Python/TypeScript in significantly less time than you can solve it in…

All the disadvantages of those stacks still exist.

So if you need to avoid GC issues, or have robust type safety, or whatever it is, to gain an edge in a certain industry or scenario, you can't just switch to the vibe tool of choice without (best case) giving up $$$ to pay to make up for the inefficiency or (worst case) having more failures that your customers won't tolerate.

But this means the gap between the "hard" work and the "easy" work may become larger - compensation included. Probably most notably in FAANG companies where people are brought in expected to be able to do "hard" work and then frequently given relatively-easy CRUD work in low-ROI ancillary projects but with higher $$$$ than that work would give anywhere else.

And the places currently happy to hire disaffected ex-FAANG engineers who realized they were being wasted on polishing widgets may start having more hiring difficulty as the pipeline dries up. Like trying to hire for assembly or COBOL today.

Post reply on HN