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

271–280 of 410 posts

Re: A staff engineer's journey with Claude Code

#271

Post by sdeframond »

rhubarbtree wrote: post #212

Does anyone have a link to a video that uses Claude Code to produce clean robust code that solves a non trivial problem (ie not tic tac toe or a landing page) more quickly than a human programmer can write? I don’t want a “demo”, I want a livestream from an independent programmer unaffiliated with any AI company and thus not incentivised to hype. I want the code to have subsequently been deployed in production and de…

Does any experienced dev have experience outsourcing to another dev that produces clean robust code that solves a non trivial problem (ie not tic tac toe or a landing page) more quickly than she would by herself?

I think not.

The reason is about missing context. Such non-trivial problems have a lot of specific unwritten context. It takes a lot of effort to share that context. Often more than doing anything one self.

Re: A staff engineer's journey with Claude Code

#272

Post by ryukoposting »

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.

Parent comment isn't joking. Good simulators for RF stuff can be well over $5k per month.

Re: A staff engineer's journey with Claude Code

#273

Post by apercu »

sirpalee wrote: post #251
rhubarbtree wrote: post #212

Does anyone have a link to a video that uses Claude Code to produce clean robust code that solves a non trivial problem (ie not tic tac toe or a landing page) more quickly than a human programmer can write? I don’t want a “demo”, I want a livestream from an independent programmer unaffiliated with any AI company and thus not incentivised to hype. I want the code to have subsequently been deployed in production and de…

I had success with it on a large, established project when using it for refactoring, moving around functions, implementing simple things and writing documentation. It failed when implementing complex new features and horribly went off the rails when trying to debug issues. Almost all its recommendations were wrong, and it kept trying to change things that certainly weren't the problem.

This matches my experience as well. One unexpected benefit is that I learned a couple pieces of hardware inside and out because LLMs make so many mistakes. If I wouldn’t have used an LLM I wouldn’t have gone down all these rabbit holes based on incorrect info - I would have just read the docs and solved my use case but missed out on deeper understanding.

Just reinforces my biases that LLMs are currently garbage for anything new and complicated. But they are a great interactive note taker and brainstorming tool.

Re: A staff engineer's journey with Claude Code

#274

Post by ryukoposting »

f311a wrote: post #82
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…

What you’re working on? In my industry it fails half of the time and comes up with absolute nonsense. The data just don’t exist for our problems, it can only work when you guide it and ask for a few functions at max.

This sounds like my experiences with it. I'm writing embedded firmware in C and Rust. I'd describe further, but Claude seems incompetent at all aspects of this space.

Re: A staff engineer's journey with Claude Code

#275

Post by mattmanser »

dotancohen wrote: post #246
all2 wrote: post #188

Earlier quoted context omitted.

> The code itself is basically disposable. I'm finding this is the case for my work as well. The spec is the secret sauce, the code (and its many drafts) are disposable. Eventually I land on something serviceable, but until I do, I will easily drop a draft and start on a new one with a spec that is a little more refined.

I just like to add that the database design is the real secret sauce, important even more than external APIs in my opinion.

Well, not DB design really, you can achieve the same thing by defining your POCOs well. I switched entirely to code-first design years ago. If you haven't worked with a good ORM, you're really missing out, though I admit there was quite a bit of friction at first.

Re: A staff engineer's journey with Claude Code

#276

Post by apercu »

sunnyam wrote: post #254
boesboes wrote: post #237

Earlier quoted context omitted.

I've been using it to do all my work for the last month or two and have decided it's not worth it. I haven't made any recordings or anything, so this is purely my subjective experience: it's ok at greenfield stuff with some hand-holding to do things properly all the time. It knows the framework well, but won't try to use it correctly and go off on weird detours to 'debug' things that fail because of it. But on a bigg…

I have the same opinion, but my worry with this attitude is that it's going to hold me back in the long run. A common thread in articles about developers using AI is that they're not impressed at first but then write more precise instructions and provide context in a more intuitive manner for the AI to read and that's the point at which they start to see results. Would these principles not apply to regular developers…

I think of current state LLMs as precocious but green assistants that are sometimes useful but often screw up. It requires a significant amount of hand holding, still usually a net positive in my workflow but only (arbitrarily) a modest productivity bump (e.g. 10-15%). I feel like if I can get better at reigning in LLMs I can improve this productivity enhancement a bit more, but the idea that we can wholesale replace technical people is not realistic yet.

If I were a non-tech, non-specialist and/or had no business skills/experience and my job was mostly office admin I would be retraining however, because those jobs may be over except as vanity positions.

Re: A staff engineer's journey with Claude Code

#277

Post by skydhash »

juped wrote: post #198
dingnuts wrote: post #138

Earlier quoted context omitted.

the kind of engineer who has been Salesified to the point that they write such drivel as "these learnings" instead of "lessons" in an article that allegedly has a technical audience. it's funny because as I have gotten better as a dev I've gone backwards through his progression. when I was less experienced I relied on Google; now, just read the docs

Yeah, the trusty manual becomes #1 at around the same time as one starts actually engineering. You've entered the target audience!

These days, I often just go straight to the source (when available) to clear some confusion about the library/software behavior. It can be a quite nice 10 mn break.

Re: A staff engineer's journey with Claude Code

#278

Post by bjornsing »

all2 wrote: post #188
mindwok wrote: post #171

Earlier quoted context omitted.

IMO “junior developer who doesn't learn“ is not quite right. Claude is more like an senior, highly academic engineer who has read all the literature but hasn't ever written any code. Amazing encyclopaedic knowledge, zero taste. I've been building commercial codebases with Claude for the last few months and almost all of my input is on taste and what defines success. The code itself is basically disposable.

> The code itself is basically disposable. I'm finding this is the case for my work as well. The spec is the secret sauce, the code (and its many drafts) are disposable. Eventually I land on something serviceable, but until I do, I will easily drop a draft and start on a new one with a spec that is a little more refined.

So how do you best store and iterate on the spec? One way I guess would be to work on a branch an modify Claude.md to reflect what the branch is for. Is that a good approach? Are there others?

Re: A staff engineer's journey with Claude Code

#279

Post by skydhash »

globular-toast wrote: post #214
jpollock wrote: post #120

Avoiding the boilerplate is part of the job as a software developer. Abstracting the boilerplate is how you make things easier for future you. Giving it to an AI to generate just makes the boilerplate more of a problem when there's a change that needs to be made to _all_ the instances of it. Even worse if the boilerplate isn't consistent between copies in the codebase.

Yeah. I'm increasingly starting to think this LLM stuff is simply the first time many programmers have been able to not write boilerplate. They didn't learn to build abstractions so essentially live on whatever platform someone else has built for them. AI is simply that new platform. I'm lazy af. I have not been manually typing up boilerplate for the past 15 years. I use computers to do repetitive tasks. LLMs are goo…

The one thing I’m always suspicious about is the actual mastery (programming language and computer usage) involved. You never see anyon describe the context of what they’ve been doing pre-llm.

Re: A staff engineer's journey with Claude Code

#280

Post by MontyCarloHall »

rhubarbtree wrote: post #212

Does anyone have a link to a video that uses Claude Code to produce clean robust code that solves a non trivial problem (ie not tic tac toe or a landing page) more quickly than a human programmer can write? I don’t want a “demo”, I want a livestream from an independent programmer unaffiliated with any AI company and thus not incentivised to hype. I want the code to have subsequently been deployed in production and de…

Forget a livestream, I want to hear from maintainers of complex, actively developed, and widely used open-source projects (e.g. ffmpeg, curl, openssh, sqlite). Highly capable coding LLMs have been out for long enough that if they do indeed have meaningful impact on writing non-trivial, non-greenfield/boilerplate code, it ought to be clearly apparent in an uptick of positive contributions to projects like these.
Post reply on HN