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

221–230 of 322 posts

Re: What makes Claude Code so damn good

#221

Post by jonasft »

techwiz137 wrote: post #218
brokegrammer wrote: post #213

Earlier quoted context omitted.

I've used Claude Code, Cursor, and Copilot is Vscode and I don't "know" that Claude Code is better apart from the fact that it runs in the terminal, which makes it a little faster but less ergonomic than tools running inside the editor. All of the context tricks can be done with Copilot instructions as well, so I simply can't see how Claude Code is superior.

For code generation, nothing so far beats Opus. More likely than not it generated working code and fixed bugs that Gemini 2.5 pro couldn't solve or even Gemini Code Assist. Gemini Code Assist is better than 2.5 pro, but has way more limits per prompt and often truncates output.

Let’s say that is correct, you can still just use Opus in Cursor or whatever.

Re: What makes Claude Code so damn good

#222

Post by jaggederest »

bilekas wrote: post #193
monkpit wrote: post #174

Earlier quoted context omitted.

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

What do you mean "you have to let go". I use some ai tools and sometimes they're fine, but I won't in my lifetime anyway hand over everything to an AI, not out of some fear or anything, but even purely as a hobby. I like creating things from scratch, I like working out problems, why would I need to let that go?

Well, the point is, if it's not a hobby, you have to encode your preferences in lint and formatters, rather than holding onto manually messing with the output.

It's really freeing to say "Well, if the linter and the formatter don't catch it, it doesn't matter". I always update lint settings (writing new rules if needed) based on nit PR feedback, so the codebase becomes easier to review over time.

It's the same principle as any other kind of development - let the machine do what the machine does well.

Re: What makes Claude Code so damn good

#223

Post by rendx »

techwiz137 wrote: post #218
brokegrammer wrote: post #213

Earlier quoted context omitted.

I've used Claude Code, Cursor, and Copilot is Vscode and I don't "know" that Claude Code is better apart from the fact that it runs in the terminal, which makes it a little faster but less ergonomic than tools running inside the editor. All of the context tricks can be done with Copilot instructions as well, so I simply can't see how Claude Code is superior.

For code generation, nothing so far beats Opus. More likely than not it generated working code and fixed bugs that Gemini 2.5 pro couldn't solve or even Gemini Code Assist. Gemini Code Assist is better than 2.5 pro, but has way more limits per prompt and often truncates output.

The article is not comparing models, but how the models are used by tools, in this case Claude Code. It's not merely a thin wrapper around an API.

Re: What makes Claude Code so damn good

#224

Post by airtonix »

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…

[dead]

Re: What makes Claude Code so damn good

#225

Post by arcanemachiner »

itbeho wrote: post #192
mike1o1 wrote: post #189

Earlier quoted context omitted.

If you haven’t yet, you should try out usage_rules mix package. I mostly use Ash, which has great support for usage rules and it’s a night and day difference in effectiveness. Tidewave is also really nice as an MCP as it lets the agent query hexdocs or your schema directly. https://hexdocs.pm/usage_rules/readme.html

Thank you! I'll definitely check that out.

Also check out the AGENTS.MD file that's been added to Phoenix 1.8.

Make sure you read it first though... I believe it expected Req to be present as a dependency when generating code that makes HTTP requests.

Re: What makes Claude Code so damn good

#227

Post by jaggederest »

davepeck wrote: post #200
1zael wrote: post #82

I've literally built the entire MVP of my startup on Claude Code and now have paying customers. I've got an existential worry that I'm going to have a SEV incident that will trigger a house of falling cards, but until then I'm constantly leveraging Claude for fixing security vulnerabilities, implementing test-driven-development, and planning out the software architecture in accordance with my long-term product roadma…

> I've literally built the entire MVP of my startup on Claude Code and now have paying customers. Would you mind linking to your startup? I’m genuinely curious to see it. (I won’t reply back with opinions about it. I just want to know what people are actually building with these tools!)

My github has examples of work I've done recently that are open source.

I'm deliberately trying not to do too much manual coding right now so I can figure out these (infuriating/wonderful) tools.

Re: What makes Claude Code so damn good

#228

Post by jaggederest »

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

Earlier quoted context omitted.

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

[flagged]

I generally work as openly as possible on github, and I am deliberately avoiding manual coding for a while to try to learn these (infuriating/wonderful) tools more thoroughly.

Unfortunately I can't always share all of my work, but everything on github after perhaps 2025-06-01 is as vibe-coded as I can get it to be. (I manually review commits before they're pushed, and PRs once in a complete state, but I always feed those reviews back into the tooling, not fix them manually, unless I get completely fed up.)

Re: What makes Claude Code so damn good

#229

Post by brabel »

samuelstros wrote: post #146
nuwandavek wrote: post #138

Earlier quoted context omitted.

(author of the blogpost here) Yeah, you can extract a LOT of performance from the basics and don't have to do any complicated setup for ~99% of use cases. Keep the loop simple, have clear tools (it is ok if tools overlap in function). Clarity and simplicity >>> everything else.

does a framework like vercel's ai sdk help, or is handling the loop + tool calling so straightforward that a framework is overcomplicating things? for context, i want to build a claude code like agent in a WYSIWYG markdown app. that's how i stumbled on your blog post :)

Check the OpenAI REST API reference. Most engines implement that and you can see how tool calls work. It’s just a matter of understanding the responses they give you, how to put them in the messages history and how to invoke a tool when the LLM asks for it.

Re: What makes Claude Code so damn good

#230

Post by brabel »

djmips wrote: post #10
ezfe wrote: post #7

Earlier quoted context omitted.

Gemini frequently didn't write code for me for no explicable reason, and just talked about a hypothetical solution. Seems like a tooling issue though.

Sounds almost human!

LLMs are built on human content and they do behave similarly to humans sometimes, including both the good and the bad.
Post reply on HN