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

A staff engineer's journey with Claude Code

sanity.io

Post reply on HN
Print view View original

41–50 of 410 posts

Re: A staff engineer's journey with Claude Code

#41

Post by yodsanklai »

MangoCoffee wrote: post #26
swframe2 wrote: post #3

Preventing garbage just requires that you take into account the cognitive limits of the agent. For example ... 1) Don't ask for large / complex change. Ask for a plan but ask it to implement the plan in small steps and ask the model to test each step before starting the next. 2) For really complex steps, ask the model to write code to visualize the problem and solution. 3) If the model fails on a given step, ask it t…

I've been vibe coding a couple of personal projects. I've found that test-driven development fits very well with vibe coding, and it's just as you said break up the problem into small, testable chunks, get the AI to write unit tests first, and then implement the actual code

Actually, all good engineering principles which reduce cognitive load for humans work for AI as well.

Re: A staff engineer's journey with Claude Code

#42

Post by awesome_dude »

groby_b wrote: post #27
awesome_dude wrote: post #19

Earlier quoted context omitted.

But I still find myself needing (strongly) to let Claude know when it's made a breakthrough that would have been hard work on my own.

Curious: Do you also laud your compiler for particularly good optimizations?

There's a couple of things there

1. I don't see the output of the compiler, as in, all I get is an executable blob. It could be inspected, but I don't think that I ever have in my 20+ year career. Maybe I lie and I've rocked up with a Hex editor once or twice, out of pure curiousity, but I've never got past looking for strings that I recognise.

2. When I use Claude, I am using it to do things that I can do, by hand, myself. I am reviewing the code as I go along, and I know what I want it to do because it's what I would be writing myself if I didn't have Claude (or Gemini for that matter).

So, no, I have never congratulated the compiler (or interpreter, linker, assembler, or even the CPU).

Finally, I view the AI as a pairing partner, sometimes it's better than me, sometimes it's not, and I have to be "in the game" in order to make sure I don't end up with a vibe coded mess.

edit: This is from yesterday (Claude had just fixed a bug for me - all I did was paste the block of code that the bug was in, and say "x behaviour but getting y behaviour instead)

perfect, thanks

Edit You're welcome! That was a tricky bug - using rowCount instead of colCount in the index calculation is the kind of subtle error that can be really hard to spot. It's especially sneaky because row 0 worked correctly by accident, making it seem like the logic was mostly right. Glad we got it sorted out! Your Gaps redeal should now work properly with all the 2s (and other correctly placed cards) staying in their proper positions across all rows.

Re: A staff engineer's journey with Claude Code

#43

Post by nostrademons »

jason_zig wrote: post #4
swframe2 wrote: post #3

Preventing garbage just requires that you take into account the cognitive limits of the agent. For example ... 1) Don't ask for large / complex change. Ask for a plan but ask it to implement the plan in small steps and ask the model to test each step before starting the next. 2) For really complex steps, ask the model to write code to visualize the problem and solution. 3) If the model fails on a given step, ask it t…

I've seen people post this same advice and I agree with you that it works but you would think they would absorb this common strategy and integrate it as part of the underlying product at this point...

A lot of it is integrated into the product at this point. If you have a particularly tricky bug, you can just tell Claude "I have this bug. I expected output 'foo' and got output 'bar'. What went wrong?" It will inspect the code and sometimes suggest a fix. If you run it and it still doesn't work, you can say "Nope, still not working", and Claude will add debug output to the whole program, tell you to run it again, and paste the debug output back into the console. Then it will use your example to write tests, and run against them.

Re: A staff engineer's journey with Claude Code

#44

Post by abraxas »

lordnacho wrote: post #23

I'm using Claude all the time now. It works, and I'm amazed it worked so easily for me. Here's what it looks like: 1) Summarize what I think my project currently does 2) Summarize what I think it should do 3) Give a couple of hints about how to do it 4) Watch it iterate a write-compile-test loop until it thinks it's ready I haven't added any files or instructions anywhere, I just do that loop above. I know of people…

I tried to follow the same pattern on a backend project written in Python/FastAPI and this has been mostly a heartache. It gets kind of close but then it seems to periodically go off the rails, lose its mind and write utter shit. Like braindead code that has no chance of working.

I don't know if this is a question of the language or what but I just have no good luck with its consistency. And I did invest time into defining various CLAUDE.md files. To no avail.

Re: A staff engineer's journey with Claude Code

#45

Post by ale »

It’s about time these types of articles actually include the types of tasks being “orchestrated” (as the author writes) that aren’t just plain refactoring chores or React boilerplate. Sanity has quite a backlog of long-requested features and the message here is that these agents are supposedly parallelizing a lot of the work. What kind of staff engineer has “80% of their code” written by a “junior developer who doesn't learn“?

Re: A staff engineer's journey with Claude Code

#46

Post by lordnacho »

abraxas wrote: post #44
lordnacho wrote: post #23

I'm using Claude all the time now. It works, and I'm amazed it worked so easily for me. Here's what it looks like: 1) Summarize what I think my project currently does 2) Summarize what I think it should do 3) Give a couple of hints about how to do it 4) Watch it iterate a write-compile-test loop until it thinks it's ready I haven't added any files or instructions anywhere, I just do that loop above. I know of people…

I tried to follow the same pattern on a backend project written in Python/FastAPI and this has been mostly a heartache. It gets kind of close but then it seems to periodically go off the rails, lose its mind and write utter shit. Like braindead code that has no chance of working. I don't know if this is a question of the language or what but I just have no good luck with its consistency. And I did invest time into de…

Has this got anything to do with using a stronger typed language? I've heard that reported, not sure whether it's true since my python scripts tend to be short.

Does it end in a forever loop for you? I used to have this problem with other models.

Re: A staff engineer's journey with Claude Code

#47

Post by dakiol »

Yoric wrote: post #36
dakiol wrote: post #34

To all the engineers using claude code: how do you submit your (well, claude’s) to review? Say, you have a big feature/epic to implement. Typically (pre-ai) times you would split it in chunks and submit each chunk as PR to be reviewed. You don’t want to submit dozens of file changes because nobody would review it. Now with llms, one can easily explain the whole feature to the machine and they would output the whole c…

I regularly write big MRs, then cut them into 5+ (sometimes 10+) smaller MRs. What does Claude Code change here?

The split seems artificial now. Before, an average engineer would produce code sequentially, chunk after chunk. Each chunk submitted only after the previous one was reviewed and approved. Today, one could submit the whole thing for review. Also, if machines can write it, why not let machines review it too? Seems weird not to do so.

Re: A staff engineer's journey with Claude Code

#48

Post by hex4def6 »

nostrademons wrote: post #39
swframe2 wrote: post #3

Preventing garbage just requires that you take into account the cognitive limits of the agent. For example ... 1) Don't ask for large / complex change. Ask for a plan but ask it to implement the plan in small steps and ask the model to test each step before starting the next. 2) For really complex steps, ask the model to write code to visualize the problem and solution. 3) If the model fails on a given step, ask it t…

I've found that an effective tactic for larger, more complex tasks is to tell it "Don't write any code now. I'm going to describe each of the steps of the problem in more detail. The rough outline is going to be 1) Read this input 2) Generate these candidates 3) apply heuristics to score candidates 4) prioritize and rank candidates 5) come up with this data structure reflecting the output 6) write the output back to…

FYI: You can force "Plan mode" by pressing shift-tab. That will prevent it from eagerly implementing stuff.

Re: A staff engineer's journey with Claude Code

#49

Post by AnotherGoodName »

albingroen wrote: post #32

So we’re supposed to start paying $1k-$1,5k on top of already crazy salaries just to maybe get a productivity boost on trivial to semi trivial issues? I know my boss would not be keen on that at least.

I can't use $20 of credit (gpt-5 thinking via intellij's pro AI subscription) a month right now with plenty of usage so I'm surprised at the $1k figure. Is Claude that much more expensive? (a quick Google suggests yes actually).

Having said the above some level of AI spending is the new reality. Your workplace pays for internet right? Probably a really expensive fast corporate grade connection? Well they now also need to pay for an AI subscription. That's just the current reality.

Re: A staff engineer's journey with Claude Code

#50

Post by colordrops »

yodsanklai wrote: post #41
MangoCoffee wrote: post #26

Earlier quoted context omitted.

I've been vibe coding a couple of personal projects. I've found that test-driven development fits very well with vibe coding, and it's just as you said break up the problem into small, testable chunks, get the AI to write unit tests first, and then implement the actual code

Actually, all good engineering principles which reduce cognitive load for humans work for AI as well.

This is the big secret. Keep code modular, small, single purpose, encapsulated, and it works great with vibe coding. I want to write a protocol/meta language similar to the markdown docs that Claude et al create that is per module, and defines behavior, so you actually program and compose modules with well defined interfaces in natural language. I'm surprised someone hasn't done it already.
Post reply on HN