A staff engineer's journey with Claude Code • Hacker News Board

Re: A staff engineer's journey with Claude Code

#161

Post by thayne » Wed, Sep 03, 2025, 2:27 AM UTC

jaggederest wrote: post #77

rco8786 wrote: post #54

Earlier quoted context omitted.

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

This works fairly well for well defined, repetitive tasks. But at least for me, if you have to put that much effort into the prompt, it is likely easier just to write the code myself.

Re: A staff engineer's journey with Claude Code

#162

Post by 2muchcoffeeman » Wed, Sep 03, 2025, 2:27 AM UTC

skydhash wrote: post #118

2muchcoffeeman wrote: post #63

Earlier quoted context omitted.

I’ve been trapped in a hole of “can I get the agent to do this?” And the change would have taken me 1/10th the time. Choosing the battles to pick is part of the skill at the moment. I use AI for a lot of boiler plate, tedious tasks I can’t quite do a vim recording for, small targeted scripts.

How many of these boilerplate do you actually have to do? Any script or complicated command that I had to write was worthy to be recorded in some bash alias or preserved somewhere. But they mostly live in my bash history or right next to the project. The boilerplate argument is becoming quite old.

I’m doing a lot of upgrades to neglected projects at the moment and I often need to do the same config over and over to multiple projects. I guess I could write a script, or get AI to write a script, but there’s no standard between projects. So I need the same thing over and over but from slightly different starting points.

I think you need to imagine all the things you could be doing with LLMs.

For me the biggest thing is so many tedious things are now unlocked. Refactors that are just slightly beyond the IDE, checking your config (the number of typos it’s picked up that could take me hours because eyes can be stupid), data processing that’s similar to what you have done before but different enough to be annoying.

Re: A staff engineer's journey with Claude Code

#163

Post by pseudosavant » Wed, Sep 03, 2025, 2:35 AM UTC

This has been my experience too. I’m just not quite as far along as the author.

Detachment from the code has been excellent for me. Just started a v2 rewrite of something I’d never had done in the past. Mostly because it would have taken me too much time to try it out if I wrote it all by hand.

Re: A staff engineer's journey with Claude Code

#164

Post by shortstuffsushi » Wed, Sep 03, 2025, 2:40 AM UTC

BoiledCabbage wrote: post #74

yodsanklai wrote: post #41

Earlier quoted context omitted.

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…

While a lot of these ideas are touted as "good for the org," in the case of LLMs, it's more like guard rails against something that can't reason things out. That doesn't mean that the practices are bad, but I would much prefer that these LLMs (or some better mechanism) everyone is being pushed to use could actual reason, remember, and improve, so that this sort of guarding wouldn't be a requirement for correct code.

Re: A staff engineer's journey with Claude Code

#165

Post by rcfox » Wed, Sep 03, 2025, 2:49 AM UTC

cjonas wrote: post #151

Once thing I've noticed is the difference in code quality by language. I'm constantly disappointed by the output of python code. I have to correct it to follow even the most basic software development principles (DRY, etc). Typescript on the other hand, seems to do much better on first pass. Still not always beautiful code, but much more application ready. My hypothesis is that this is due to the billions LOC of Jupy…

With Typescript, I find it pretty eager to just try `(foo as any).bar` when it gets the initial typing wrong. It also likes to redefine types in every file they're used instead of importing.

It will fix those if you catch them, but I haven't been able to figure out a prompt that prevents this in the first place.

Re: A staff engineer's journey with Claude Code

#166

Post by Zee2 » Wed, Sep 03, 2025, 2:54 AM UTC

ethanwillis wrote: post #80

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!

Ah, I’ve tried that one, but I must be doing something wrong. I give it a fully specified working program, and often times it gives me back one that only works 50% of the time!

Re: A staff engineer's journey with Claude Code

#167

Post by harrall » Wed, Sep 03, 2025, 2:57 AM UTC

dontlaugh wrote: post #51

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…

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

I don’t do much of the deep prompting stuff but I find AI can write some code faster than I can and accurately most of the time. You just need to learn what those things are.

But I can’t tell you any useful tips or tricks to be honest. It’s like trying to teach a new driver the intuition of knowing when to brake or go when a traffic light turns yellow. There’s like nothing you can really say that will be that helpful.

Re: A staff engineer's journey with Claude Code

#168

Post by keeda » Wed, Sep 03, 2025, 3:02 AM UTC

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.

Reid Hoffman, LinkedIn co-founder, has gone whole hog on that idea and has a literal AI clone of himself, trained on all his writings, videos and audio interviews -- complete with AI-generated deep-fake visuals and cloned voice:

https://www.linkedin.com/posts/reidhoffman_can-talking-with-...

I've watched a handful of videos with this "digital twin", and I don't know how much post-processing has gone into them, but it is scary accurate. And this was a year+ ago.

Re: A staff engineer's journey with Claude Code

#169

Post by Mars008 » Wed, Sep 03, 2025, 3:06 AM UTC

plaguuuuuu wrote: post #112

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 using a few LLMs/agents for a while and I still struggle with getting useful output from it. In order for it not to do useless stuff I need to expend more energy on prompting than writing stuff myself. I find myself getting paranoid about minutia in the prompt, turns of phrase, unintended associations in case it gives shit-tier code because my prompt looked too much like something off experts-exchange or wh…

> What I really want is something like a front-end framework but for LLM prompting

It's not simple to even imagine ideal solution. The more you think about it the more complicated your solution becomes. Simple solution will be restricted to your use cases. Generic is either visual or a programming language. I's like to have visual constructor, graph of actions, but it's complicated. The language is more powerful.

Re: A staff engineer's journey with Claude Code

#170

Post by Jcampuzano2 » Wed, Sep 03, 2025, 3:08 AM UTC

saulpw wrote: post #156

15155 wrote: post #125

Earlier quoted context omitted.

Hardware companies routinely license individual EDA tool seats that cost more than numerous developer salaries - $1k/year is nothing if it improves productivity by any measurable amount.

The OP was saying it's $1k/mo. That's a 5-10% raise, which is a bit more than nothing.

There are many companies that regularly spend much more than that on other software related licenses that devs need to do their job productively.

If the average US salaried developer is 10-15% more productive for just 1k more a month it is literally a no-brainer for companies to invest in that.

Of course on the other side of the coin there are many companies that are very stingy with paying for literally anything for their employees that could measurably improve productivity, and hamper their ability to be productive by intentionally paying for cheap shitty tools. They will just lose out.