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

171–180 of 410 posts

Re: A staff engineer's journey with Claude Code

#171

Post by mindwok »

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…

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.

Re: A staff engineer's journey with Claude Code

#172

Post by Jcampuzano2 »

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.

If devs salaries are so crazy its quite the opposite. NOT investing 1-1.5k/mo to improve their productivity by a measurable amount would quite literally be just plain stupid and I would question your boss ability to think critically.

Not to mention - while I know many don't like it, they may be able to achieve enough of a productivity boost to not require hiring as many of those crazy salaried devs.

Its literally a no-brainer. Thinking about it from just the individual cost factor is too simplified a view.

Re: A staff engineer's journey with Claude Code

#173

Post by jprokay13 »

utyop22 wrote: post #88
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

What you're describing is a glorified mirror. Doesn't that sound ridiculous to you?

I am still working on tweaking how I work and design with Claude to hopefully unlock a level of output that I’m happy with.

Admittedly, part of it is my own desire for code that looks a certain way, not just that which solves the problem.

Re: A staff engineer's journey with Claude Code

#174

Post by bsder »

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…

We have all these superpowered AI vibe coders, and yet open source projects still have vast backlogs of open issues.

Things that make you go "Hmmmmmm."

Re: A staff engineer's journey with Claude Code

#175

Post by biggc »

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…

Thin sounds a lot like making a change yourself.

Re: A staff engineer's journey with Claude Code

#176

Post by therein »

biggc wrote: post #175
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…

Thin sounds a lot like making a change yourself.

It appeals to some people because they'd rather manage a bot and get it to do something they told it to do rather than do it themselves.

Re: A staff engineer's journey with Claude Code

#177

Post by adastra22 »

faangguyindia wrote: post #141
adastra22 wrote: post #95

Earlier quoted context omitted.

Plan mode disabled the tools, so I don’t see how it would do that. A sandboxed devcontainer is worth setting up though. Lets me run it with —dangerously-skip-permissions

how can it plan if it does not have access to file read, search, bash tools to investigate things? If it has access to bash tools then it's going to write code, via echo or sed.

It has file read, search, but not bash AFAIK.

Re: A staff engineer's journey with Claude Code

#178

Post by enobrev »

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.

> it doesn't seem to be making me any more efficient

That's been my experience.

I've been working on a 100% vibe-coded app for a few weeks. API, React-Native frontend, marketing website, CMS, CI/CD - all of it without changing a single line of code myself. Overall, the resulting codebase has been better than I expected before I started. But I would have accomplished everything it has (except for the detailed specs, detailed commit log, and thousands of tests), in about 1/3 of the time.

Re: A staff engineer's journey with Claude Code

#179

Post by __mharrison__ »

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…

There's a LOT of bad/newbie Python code floating around. I find that if I'm specific, it does a good job. (I'm also passing in my code/notebooks as context, so one would assume that it is attempting to mirror my style.)

Re: A staff engineer's journey with Claude Code

#180

Post by adastra22 »

lkjdsklf wrote: post #140
adastra22 wrote: post #98

Earlier quoted context omitted.

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

Works for me. Not vanilla Claude code though- you need to put some work into generating slash commands and workflows that keep it on task and catch the bad stuff.

Take this for example: https://www.reddit.com/r/ClaudeAI/comments/1m7zlot/how_planm...

This trick is just the basic stuff, but it works really well. You can add on and customize from there. I have a “/task” slash command that will run a full development cycle with agents generating code, many more (12-20) agent critics analyzing the unstaged work, all orchestrated by a planning agent that breaks the complex task into small atomic steps.

The first stage of this project (generating the plan) is interactive. It can then go off and make 10kLOC code spread over a dozen commits and the quality is good enough to ship, most of the time. If it goes off the rails, keep the plan document but nuke the commits and restart. On the Claude MAX plan this costs nothing.

This is how I do all my development now. I spend my time diagnosing agent failures and fixing my workflows, not guiding the agent anymore (other than the initial plan document).

I still review every line of code before pushing changes.

Post reply on HN