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

291–300 of 410 posts

Re: A staff engineer's journey with Claude Code

#291

Post by MontyCarloHall »

spicyusername wrote: post #290

I guess we're just going to be in the age of this conversation topic until everyone gets tired of talking about it. Every one of these discussions boils down to the following: - LLMs are not good at writing code on their own unless it's extremely simple or boilerplate - LLMs can be good at helping you debug existing code - LLMs can be good at brainstorming solutions to new problems - The code that is written by LLMs…

It's almost as if you could recapitulate each of these discussions using an LLM!

Re: A staff engineer's journey with Claude Code

#292

Post by bootsmann »

searene wrote: post #191
jprokay13 wrote: post #68

Earlier quoted context omitted.

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

Me too. I’ve been playing with various coding agents such as Cursor, Claude Code, and GitHub Copilot for some time, and I would say that their most useful feature is educating me. For example, they can teach me a library I haven’t used before, or help me debug a production issue. Then I would choose to write the code by myself after I’ve figured everything out with their help. Writing code by myself is definitely fas…

> For example, they can teach me a library I haven’t used before.

How do you verify it is teaching you the correct thing if you don't have any baseline to compare it to?

Re: A staff engineer's journey with Claude Code

#293

Post by dotancohen »

mattmanser wrote: post #275
dotancohen wrote: post #246

Earlier quoted context omitted.

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.

No, I really am talking about how the database is organised. Tables representing objects, normalisation, etc. Whether or not it is accessed through the application with an ORM.

Re: A staff engineer's journey with Claude Code

#294

Post by rafaelmn »

spicyusername wrote: post #290

I guess we're just going to be in the age of this conversation topic until everyone gets tired of talking about it. Every one of these discussions boils down to the following: - LLMs are not good at writing code on their own unless it's extremely simple or boilerplate - LLMs can be good at helping you debug existing code - LLMs can be good at brainstorming solutions to new problems - The code that is written by LLMs…

> but this was true when they wrote their own code with stack overflow.

Searching for solutions and integrating examples found requires effort that develops into a skill. You would rarely get solutions that would just fit into the codebase from SO. If I give a task to you and you produce a correct solution on the initial review I now know I can trust you to deal with this kind of problem in the future. Especially after a few reviews.

If you just vibed through the problem the LLM might have given you the correct solution - but there is no guarantee that it will do it again in the future. Just because you spent less effort on search/official docs/integration into the codebase you learned less about everything surrounding it.

So using LLMs as a junior you are just breaking my trust, and we both know you are not a competent reviewer of LLM code - why am I even dealing with you when I'll get LLM outputs faster myself ? This was my experience so far.

Re: A staff engineer's journey with Claude Code

#295

Post by dawnerd »

spicyusername wrote: post #290

I guess we're just going to be in the age of this conversation topic until everyone gets tired of talking about it. Every one of these discussions boils down to the following: - LLMs are not good at writing code on their own unless it's extremely simple or boilerplate - LLMs can be good at helping you debug existing code - LLMs can be good at brainstorming solutions to new problems - The code that is written by LLMs…

On your last point I’ve found it about a wash in terms of time savings for me. For boiler plate / throw away code it’s decent enough - especially if I don’t care about code quality and only want a result.

It’s wasted so much time trying to make it write actual production quality code. The consistency and over-verbose nature kill it for me.

Re: A staff engineer's journey with Claude Code

#296

Post by Difwif »

Aeolun wrote: post #265
coffeeri wrote: post #238

Earlier quoted context omitted.

This video [0] is relevant, though it actually supports your point - it shows Claude Code struggling with non-trivial tasks and needing significant hand-holding. I suspect videos meeting your criteria are rare because most AI coding demos either cherry-pick simple problems or skip the messy reality of maintaining real codebases. [0] https://www.youtube.com/watch?v=EL7Au1tzNxE

> I suspect videos meeting your criteria are rare because most AI coding demos either cherry-pick simple problems or skip the messy reality of maintaining real codebases. Or we’re just having too much fun making stuff to make videos to convince people that are never going to be convinced.

I took a quick informal poll of my coworkers and the majority of us have found workflows where CC is producing 70-99% of the code on average in PRs. We're getting more done faster. Most of these people tend to be anywhere from 5-12 yrs professional experience. There are some concerns that maybe more bugs are slipping through (but also there's more code being produced).

We agree most problems stem from: 1. Getting lazy and auto-accepting edits. Always review changes and make sure you understand everything. 2. Clearly written specification documents before starting complex work items 3. Breaking down tasks into a managable chunk of scope 4. Clean digestible code architecture. If it's hard for a human to understand (e.g: poor separation of concerns) it will be hard for the LLM too.

But yeah I would never waste my time making that video. Having too much fun turning ideas into products to care about proving a point.

Re: A staff engineer's journey with Claude Code

#297

Post by xenobeb »

thayne wrote: post #161
jaggederest wrote: post #77

Earlier quoted context omitted.

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.

I am certain it has much to do with being in the training data or not.

I have loved GPT5 but the other day I was trying to implement a rather novel idea that would be a rather small function and GPT5 goes from a genius to an idiot.

I think HN has devolved into random conversations based on a random % of problems being in the training data or not. People really are having such different experiences with the models based on the novelty of the problems that are being solved.

At this point it is getting boring to read.

Re: A staff engineer's journey with Claude Code

#299

Post by chamomeal »

spicyusername wrote: post #290

I guess we're just going to be in the age of this conversation topic until everyone gets tired of talking about it. Every one of these discussions boils down to the following: - LLMs are not good at writing code on their own unless it's extremely simple or boilerplate - LLMs can be good at helping you debug existing code - LLMs can be good at brainstorming solutions to new problems - The code that is written by LLMs…

Yeah every time I see one of these articles posted on HN I know I'll see a bunch of comments like "well here's how I use claude code: I keep it on a tight leash and have short feedback loops, so that I'm still the driver, and have markdown files that explain the style I'm going for...". Which is fine lol but I'm tired of seeing the exact same conversations.

It's exhausting to hear about AI all the time but it's fun to watch history happen. In a decade we'll look back at all these convos and remember how wild of a time it was to be a programmer.

Re: A staff engineer's journey with Claude Code

#300

Post by chamomeal »

jbs789 wrote: post #286

I often find that Claude introduces a level of complexity that is not necessary in my cases. I suspect this is a function of the training data (large repos or novel solutions). That said, I do sometimes find inspiration for new techniques in its answers. I just haven't heard others express the same over-engineering problem and wonder if this is a general observation or only shows up b/c my requests are quite simple.…

Seems like LLMs really suffer from the "eh I'll just write it myself" mindset. Yesterday on a react app using react-query (library to manage caching and re-fetching of data) claude code wanted to update the cache manually, instead of just using a bit of state that was already in scope in the exact same component!

For me, stuff like that is the same weird uncanny valley that you used to see in AI text, and see now in AI video. It just does such inhuman things. A senior developer would NEVER think to manually mutate the cache, because it's such desperate hack. A junior dev wouldn't even realize it's an option.

Post reply on HN