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

131–140 of 410 posts

Re: A staff engineer's journey with Claude Code

#131

Post by johnfn »

bakugo wrote: post #89
ale wrote: post #45

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…

Actually providing examples of real tasks given to the AI and the subsequent results would break the illusion and give people opportunities to question the hype. Can't have that. We'll just keep getting submission after submission talking about how amazing Claude Code is with zero real world examples.

Really, zero real world examples? What about this?

https://news.ycombinator.com/item?id=44159166

Re: A staff engineer's journey with Claude Code

#132

Post by shaunxcode »

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…

I am convinced that this comment once read aloud in the cadence of Ginsberg is a work of art!

Re: A staff engineer's journey with Claude Code

#133

Post by skydhash »

mumbisChungo wrote: post #114
utyop22 wrote: post #111

Earlier quoted context omitted.

And? Go create more stuff. Come back and post here when you have built something that has commercial success. Show us all how it's done. Until then go away - more noise doesn't help.

I don't think there's anything I could tell you about the companies I've built that would dissuade you from your perspective that everyone is as intellectually lazy as your projection suggests.

Not GP, but I really want to know how your process is better than anyone else. People have produced quite good software (as in solving problems) on CPU that’s less powerful than what’s on my smart plug. And whose principles is still defining today’s world.

Re: A staff engineer's journey with Claude Code

#134

Post by block_dagger »

meerab wrote: post #119
block_dagger wrote: post #25

The author doesn't make it clear why they switched from Cursor to Claude. Curious about what they can do with Claude that can't be done with Cursor. I use both a lot and find Cursor to be superior for the very large codebases I work in.

Personal opinion: Claude code is more user friendly than cursor with its CLI like interface. The file modifications are easy to view and it automatically runs psql, cd, ls , grep command. Output of the commands is shown in more user friendly fashion. Agents and MCPs are easy to organized and used.

I feel just the opposite. I think Cursor's output is actually in the realm of "beautiful." It's well formatted and shows the user snippets of code and reasoning that helps the user learn. Claude is stuck in a terminal window, so reduced to monospaced bullet lines. Its verbose mode spits out lines of file listings and other context irrelevant to the user.

Re: A staff engineer's journey with Claude Code

#135

Post by colordrops »

drzaiusx11 wrote: post #69
colordrops wrote: post #50

Earlier quoted context omitted.

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.

Isn't what you're describing exactly what Kiro aims to solve?

Possibly, I've never heard of Kiro, will look into it.

Re: A staff engineer's journey with Claude Code

#136

Post by block_dagger »

RomanPushkin wrote: post #87
block_dagger wrote: post #25

The author doesn't make it clear why they switched from Cursor to Claude. Curious about what they can do with Claude that can't be done with Cursor. I use both a lot and find Cursor to be superior for the very large codebases I work in.

It's easy: Cursor are resellers, they optimize your token usage, so they can make a profit. Claude is the final point, and they offer tokens for the cheapest price possible.

I use Cursor in MAX mode because my employer pays for the tokens. I probably should have mentioned that in my OP. It makes a huge difference.

Re: A staff engineer's journey with Claude Code

#137

Post by colordrops »

adastra22 wrote: post #99
colordrops wrote: post #50

Earlier quoted context omitted.

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.

My set of Claude agent files have an explicit set of interface definitions. Is that what you’re talking about?

Are Claude agent files per module? If so, then I guess so.

Re: A staff engineer's journey with Claude Code

#138

Post by dingnuts »

ale wrote: post #45

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…

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

Re: A staff engineer's journey with Claude Code

#139

Post by mumbisChungo »

skydhash wrote: post #133
mumbisChungo wrote: post #114

Earlier quoted context omitted.

I don't think there's anything I could tell you about the companies I've built that would dissuade you from your perspective that everyone is as intellectually lazy as your projection suggests.

Not GP, but I really want to know how your process is better than anyone else. People have produced quite good software (as in solving problems) on CPU that’s less powerful than what’s on my smart plug. And whose principles is still defining today’s world.

I just find that I learn faster by interrogating (or being interrogated by) a lossy encyclopedia than I do by reading textbooks or stackoverflow.

I'm still the one doing the doing after the learning is complete.

Re: A staff engineer's journey with Claude Code

#140

Post by lkjdsklf »

adastra22 wrote: post #98
lkjdsklf wrote: post #37

Earlier quoted context omitted.

The problem is, by the time you’ve gone through the process of making a granular plan and all that, you’ve lost all productivity gains of using the agent. As an engineer, especially as you get more experience, you can kind of visualize the plan for a change very quickly and flesh out the next step while implementing the current step All you have really accomplished with the kind of process described is make the world…

It takes maybe 30min and then it can go off and generate code that would take literal weeks for me to write. There are still huge productivity gains being had.

That has not been my experience at all.

It takes 30-40 minutes to generate a plan and it generates code that would have taken 20-30 minutes to write.

When it’s generating “weeks” worth of code, it inevitably goes off the rails and the crap you get goes in the garbage.

This isn’t to say agents don’t have their uses, but i have not seen this specific problem actually work. They’re great for refactoring (usually) and crapping out proof of concepts and debugging specific problems. It’s also great for exploring a new code base where you have little prior knowledge.

It makes sense that it sucks at generating large amounts of code that fits cohesively into the project. The context is too small. My code base is millions of lines of code. My brain has a shitload more of that in context than any of the models. So they have to guess and check and end up incorrect and poor and i don’t. I know which abstractions exist that i can use. It doesn’t. Sometimes it guesses right. Often Times it doesn’t. And once it’s wrong, it’s fucked for the entire rest of the session so you just have to start over

Post reply on HN