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

71–80 of 410 posts

Re: A staff engineer's journey with Claude Code

#71

Post by awesome_dude »

LtWorf wrote: post #61
awesome_dude wrote: post #42

Earlier quoted context omitted.

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,…

You've got to check the assembly, not the binary, for optimisations…

Yeah - or I could just not care unless I have to (which, in the last 20 plus years, has been... let me think... oh, right... never)

Re: A staff engineer's journey with Claude Code

#72

Post by into_ruin »

jedberg wrote: post #65

I'd like to share my journey with Claude (not code). I fed Claude a copy of everything I've ever written on Hacker News. Then I asked it to generate an essay that sounds like me. Out of five paragraphs I had to change one sentence. Everything else sounded exactly as I would have written it. It was scary good.

I'm doing a project in a codebase I'm not familiar with in a language I don't really know, and Claude Code has been amazing at _explaining_ thing to me. "Who calls this function," "how is this generated," etc. etc.

I'm not comfortable using it to generate code for this project, but I can absolutely see using it to generate code for a project I'm familiar with in a language I know well.

Re: A staff engineer's journey with Claude Code

#74

Post by BoiledCabbage »

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 what's so funny about this. In some alternative universe I hope that LLMs never get any better. Because they force so much of good things.

They are the single closest thing we've ever had to objective evaluation on if an engineering practice is better or worse. Simply because just about every single engineering practice that I see that makes coding agents work well also makes humans work well.

And so many of these circular debates and other best practices (TDD, static typing, keeping todo lists, working in smaller pieces, testing independently before testing together, clearly defined codebase practices, ...) have all been settled in my mind.

The most controversial take, and the one I dislike but may reluctantly have to agree with is "Is it better for a business to use a popular language less suited for the task than a less popular language more suited for it." While obviously it's a sliding scale, coding agents clearly weight in on one side of this debate... as little as I like seeing it.

Re: A staff engineer's journey with Claude Code

#75

Post by bcrosby95 »

jprokay13 wrote: post #68
lucasyvas wrote: post #55

Earlier quoted context omitted.

I reached this conclusion pretty quickly. With all the hand holding I can write it faster - and it’s not bragging, almost anyone experienced here could do the same. Writing the code is the fast and easy part once you know what you want to do. I use AI as a rubber duck to shorten that cycle, then write it myself.

I am coming back to this. I’ve been using Claude pretty hard at work and for personal projects, but the longer I do it, the more disappointed I become with the quality of output for anything bigger than a script. I do love planning things out and clarifying my thoughts. It’s a turbocharged rubber duck - but it’s not a great engineer

My thoughts on scripts are: the output is pretty bad too, but it doesn't matter as much in a script, because its just a short script, and all that really matters is that it kinda works.

Re: A staff engineer's journey with Claude Code

#76

Post by adastra22 »

LtWorf wrote: post #58
CuriouslyC wrote: post #30

Earlier quoted context omitted.

Why bother handing stuff to a junior when an agent will do it faster while asking fewer questions, and even if the first draft code isn't amazing, you can just quality gate with an LLM reviewer that has been instructed to be brutal and do a manual pass when the code gets by the LLM reviewer.

Because juniors learn while LLMs don't and you must explain the same thing over and over forever.

If you are explaining things more than once, you are doing it wrong. Which is not on you as the tools currently suck big time. But it is quite possible to have LLM agents “learn” by intelligently matching context (including historical lessons learned) to conversation.

Re: A staff engineer's journey with Claude Code

#77

Post by jaggederest »

rco8786 wrote: post #54
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 feel like I do all of this stuff and still end up with unusable code in most cases, and the cases where I don't I still usually have to hand massage it into something usable. Sometimes it gets it right and it's really cool when it does, but anecdotally for me it doesn't seem to be making me any more efficient.

The key is prompting. Prompt to within an inch of your life. Treat prompts as source code - edit them in files, use @ notation to bring them into the console. Use Claude to generate its own prompts - https://github.com/wshobson/commands/ and https://github.com/wshobson/agents/ are very handy, they include a prompt-engineer persona.

I'm at the point now where I have to yell at the AI once in a while, but I touch essentially zero code manually, and it's acceptable quality. Once I stopped and tried to fully refactor a commit that CC had created, but I was only able to make marginal improvements in return for an enormous time commitment. If I had spent that time improving my prompts and running refactoring/cleanup passes in CC, I suspect I would have come out ahead. So I'm deliberately trying not to do that.

I expect at some point on a Friday (last Friday was close) I will get frustrated and go build things manually. But for now it's a cognitive and effort reduction for similar quality. It helps to use the most standard libraries and languages possible, and great tests are a must.

Edit: Also, use the "thinking" commands. think / think hard / think harder / ultrathink are your best friend when attempting complicated changes (of course, if you're attempting complicated changes, don't.)

Re: A staff engineer's journey with Claude Code

#78

Post by nicoburns »

kyleee wrote: post #56
dontlaugh wrote: post #51

Earlier quoted context omitted.

At that point, why not just write the code yourself?

Partly it seems to be less taxing for the human delivering the same amount of work. I find I can chat with Claude, etc and work more. Which is a double edged sword obviously when it comes to work/life balance etc. But also I am less mentally exhausted from day job and able to enjoy programming and side projects again.

I guess each to their own? I can easily end up coding for 16 hours straight (having a great time) if I'm not careful. I can't imagine I'd have as much patience with an AI.

Re: A staff engineer's journey with Claude Code

#79

Post by everforward »

AnotherGoodName wrote: post #49
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 nee…

I don't know what Intellij's AI integration is like, but my brief Claude Code experience is that it really chews through tokens. I think it's a combination of putting a lot of background info into the context, along with a lot of "planning" sort of queries that are fairly invisible to the end user but help with building that background for the ultimate query.

Aider felt similar when I tried it in architect mode; my prompt would be very short and then I'd chew through thousands of tokens while it planned and thought and found relevant code snippets and etc.

Re: A staff engineer's journey with Claude Code

#80

Post by ethanwillis »

meerab wrote: post #62

I have barely written any code since my switch to Claude Code! It's the best thing since sliced bread! Here's what works for me: - Detailed claude.md containing overall information about the project. - Anytime Claude chooses a different route that's not my preferred route - ask my preference to be saved in global memory. - Detailed planning documentation for each feature - Describe high-level functionality. - As I de…

Personally, I give Claude a fully specified program as my prompt so that it gives me back a working program 100% of the time.

Really simple workflow!

Post reply on HN