How Anthropic teams use Claude Code • Hacker News Board

Re: How Anthropic teams use Claude Code

#181

Post by kevinventullo » Fri, Jul 25, 2025, 4:04 PM UTC

benreesman wrote: post #57

minimaxir wrote: post #7

A repeated trend is that Claude Code only gets 70-80% of the way, which is fine and something I wish was emphasized more by people pushing agents. This bullet point is funny: > Treat it like a slot machine > Save your state before letting Claude work, let it run for 30 minutes, then either accept the result or start fresh rather than trying to wrestle with corrections. Starting over often has a higher success rate th…

The slot machine thing has a pretty compelling corollary: crank the formal systems rigor up as high as you can. Vibe coding in Python is seductive but ultimately you end up in a bad place with a big bill to show for it. Vibe coding in Haskell is a "how much money am I willing to pour in per unit clean, correct, maintainable code" exercise. With GHC cranked up to `-Wall -Werror` and some nasty property tests? Watching…

Interesting, I wonder if there is a way to quantify the value of this technique. Like give Claude the same task in Haskell vs. Python and see which one converges correctly first.

Re: How Anthropic teams use Claude Code

#182

Post by forgotmypw17 » Fri, Jul 25, 2025, 4:05 PM UTC

Nimitz14 wrote: post #176

forgotmypw17 wrote: post #138

I’ve implemented and maintained an entire web app with CC, and also used many other tools (and took classes and taught workshops on using AI coding tools). The most effective way I’ve found to use CC so far is this workflow: Have a detailed and also compressed spec in an md file. It can be called anything, because you’re going to reference it explicitly in every prompt. (CC usually forgets about CLAUDE.md ime) Start…

We're all gonna be PMs.

That’s basically what it amounts to, being a PM to a team of extremely cracked and also highly distractable coders.

Re: How Anthropic teams use Claude Code

#183

Post by forgotmypw17 » Fri, Jul 25, 2025, 4:09 PM UTC

stillsut wrote: post #166

forgotmypw17 wrote: post #138

I’ve implemented and maintained an entire web app with CC, and also used many other tools (and took classes and taught workshops on using AI coding tools). The most effective way I’ve found to use CC so far is this workflow: Have a detailed and also compressed spec in an md file. It can be called anything, because you’re going to reference it explicitly in every prompt. (CC usually forgets about CLAUDE.md ime) Start…

Great advice, matches up to my experience. Personally I go a little cheaper and dirtier on the first prompt, then revise as needed. By the way what classes / workshops did you teach? I've written a little about some my findings and workflow in detail here: https://github.com/sutt/agro/blob/master/docs/case-studies/a...

Thank you for sharing. I taught some workshops on AI-assisted development using Cursor a Windsurf for MIT students (we built an application and wrote a book) and TAed another similar for-credit course. I’ve also been teaching high schoolers how to code, and we use ChatGPT to help us understand and solve leetcode problems by breaking them down into smaller exercises. There’s also now a Harvard CS course on developing with GenAI which I followed along with. The field is exploding.

Re: How Anthropic teams use Claude Code

#184

Post by forgotmypw17 » Fri, Jul 25, 2025, 4:11 PM UTC

AstroBen wrote: post #177

forgotmypw17 wrote: post #138

I’ve implemented and maintained an entire web app with CC, and also used many other tools (and took classes and taught workshops on using AI coding tools). The most effective way I’ve found to use CC so far is this workflow: Have a detailed and also compressed spec in an md file. It can be called anything, because you’re going to reference it explicitly in every prompt. (CC usually forgets about CLAUDE.md ime) Start…

Is working this way actually faster, or any improvement than just writing the code yourself?

Much, much faster, and I’d say the code is more formal, and I’ve never had such a complete test suite.

The downside is I don’t have as much of a grasp on what’s actually happening in my project, while with hand-written projects I’d know every detail.

Re: How Anthropic teams use Claude Code

#185

Post by foob » Fri, Jul 25, 2025, 4:12 PM UTC

mfrye0 wrote: post #62

My optimization hack is that I'm using speech recognition now with Claude Code. I can just talk to it like a person and explain the full context / history of things. Way faster than typing it all out.

I've been pretty happy with the python package hns for this [1]. You can run it from the terminal with uvx hns and it will listen until you press enter and then copy the transcription to the clipboard. It's a simple tool that does one thing well and integrates smoothly with a CLI-based workflow.

[1] - https://github.com/primaprashant/hns

Re: How Anthropic teams use Claude Code

#186

Post by Eggpants » Fri, Jul 25, 2025, 4:21 PM UTC

DANmode wrote: post #99

godelski wrote: post #76

Earlier quoted context omitted.

Unironically this can actually be a good idea. Instead of "rerunning," run in parallel. Then pick the best solution. Pros: - Saved Time! - Scalable! - Big Bill? Cons: - Big Bill - AI written code

Have you seen human-written code?

I hate to break it to you, but humans wrote the original code that was stolen and used for the training set.

Re: How Anthropic teams use Claude Code

#187

Post by mvieira38 » Fri, Jul 25, 2025, 4:21 PM UTC

I'm surprised they let it generate the tests. Aren't the tests precisely what you want to have fine control over, moreso than the code itself? Letting it write them itself feels like yielding control over what is considered "correct" code

Re: How Anthropic teams use Claude Code

#188

Post by AstroBen » Fri, Jul 25, 2025, 4:33 PM UTC

forgotmypw17 wrote: post #184

AstroBen wrote: post #177

Earlier quoted context omitted.

Is working this way actually faster, or any improvement than just writing the code yourself?

Much, much faster, and I’d say the code is more formal, and I’ve never had such a complete test suite. The downside is I don’t have as much of a grasp on what’s actually happening in my project, while with hand-written projects I’d know every detail.

How do you know the test suite is comprehensive if you don't have a grasp on what's happening?

Not a gotcha I'm just extremely skeptical that AI is at a point to have the level of responsibility you're describing and have it turn into good code long term

Re: How Anthropic teams use Claude Code

#189

Post by mvieira38 » Fri, Jul 25, 2025, 4:35 PM UTC

fragmede wrote: post #100

throwawayoldie wrote: post #47

Earlier quoted context omitted.

Because at some point, Anthropic needs to stop hemorrhaging money and actually make some.

Uber, founded in 2009 was finally profitable in 2023. That's a bit longer than 6 months.

Different situation. Uber's entire strategy was to "disrupt" the transportation industry by undercutting everyone, with the promise that eventually adoption (and monetization via data, advertising, etc.) would be large enough for fees not to rise so much as to push consumers and drivers into the established taxi industry. Anthropic, on the other hand, is a competitor brand in a brand-new industry, one with heavy reliance on capex and exploding employee salaries, for that matter.

Re: How Anthropic teams use Claude Code

#190

Post by lossolo » Fri, Jul 25, 2025, 4:43 PM UTC

yodsanklai wrote: post #175

LeafItAlone wrote: post #153

Earlier quoted context omitted.

>You can't just run several tasks in parallel hoping for one of them to complete. Not only can you, some providers recommend it and their tools provide it, like ChatGPT Codex (the web tool). Can’t find where I read it but I’m pretty sure Anthropic devs said early on that they kick off the same prompt to Claude Code in multiple simultaneous runs. Personally, I’ve had decent success from this way of working.

Ok, maybe it helps somewhat. My experience is that when the agent fails or produce crappy code, it's not a matter of non-deterministic output of the LLM but rather that the task is just not suitable or the system prompt didn't provide enough information.

Not always, sometimes just a different internal "seed" can create a different working solution.