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

401–410 of 410 posts

Re: A staff engineer's journey with Claude Code

#401

Post by imron »

vincent_builds wrote: post #325
nikcub wrote: post #91

> budget for $1000-1500/month for a senior engineer going all-in on AI development. Is this another case of someone using API keys and not knowing about the claude MAX plans? It's $100 or $200 a month, if you're not pure yolo brute-force vibe coding $100 plan works. https://www.anthropic.com/max

Author here, quick clarification on pricing: the $1000-1500/month is for Teams/Enterprise with higher rate limits, not the consumer MAX plans. Consumer MAX ($200/month) works for lighter usage but hits limits quickly with parallel agents and large codebases. For context: that's 1-2% of a senior engineer's fully loaded cost. The ROI is clear if it delivers even 10% productivity gain (we're seeing 2-3x on specific task…

> The ROI is clear if it delivers even 10% productivity gain

What if what feels like a productivity gain is actually a productivity loss?

https://mikelovesrobots.substack.com/p/wheres-the-shovelware...

(see link in the article to a study showing developers thought AI gave them a 20% gain in productivity, but measuring this showed they instead had a 20% loss)

Re: A staff engineer's journey with Claude Code

#402

Post by ochronus »

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…

Just found the video you're looking for! https://www.youtube.com/watch?v=JeNS1ZNHQs8

Re: A staff engineer's journey with Claude Code

#403

Post by rafaelmn »

theshrike79 wrote: post #390
OvbiousError wrote: post #355

Earlier quoted context omitted.

> 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. So much this. I see a 1000 lines super complicated PR that was whipped up in less than a day and I know they didn't read all of it, let alone understand.

This is exactly what code reviews are for, doing reviews with juniors is always time-consuming

Yes but your supposed to reap the benefit of learning from that junior. If there is no progress and no trust in ability acquired they are just a burden.

Re: A staff engineer's journey with Claude Code

#404

Post by samurai_sword »

godelski wrote: post #375
rafaelmn wrote: post #294

Earlier quoted context omitted.

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

> you learned less about everything surrounding it. I think one of the big acceleration points in my skills as a developer was when I moved from searching SO and other similar sources to reading the docs and reading the code. At first, this was much slower. I was usually looking for a more specific thing and didn't usually need the surrounding context. But then as I continued, that surrounding context became importan…

You are absolutely right. I work as Robotics Engineer at autonomous company. I use cursor and currently using gpt-5-high for coding. When I started out coding for my project 3 years ago there was no AI coding. I had to learn how to code by reading lots of docs and reading lots & lots of code(nav2 stack). This gave me the sense of how code is architected, why it is the way it is, etc. I also try to not blindly follow any code I see but every single piece of code I critically ask lots of questions(this made me crazy, good kind). This helped me to learn extremely fast. So the point is "everyone must know when their brain is being used and when not. If your brain is not being used at anytime of a project then you are probably out of loop".

The thing about AI is when it started out(coding models) they were kinda bad. But I feel any tool that provides value to time or effort is a useful tool. I use AI now mostly to add some methods, ask questions about the code base and brainstorm ideas against that code base. There are levels on how you use this tool(AI).

1. Complete trust(if its easy task and you can verify quickly). 2. medium trust( you ask questions back to AI to critically understand why it did what it did). 3. zero trust.(this is very important for learning fast, not coding. You need to stress AI to give me lots of information, right or wrong, cross-check it manually and soak it in your brain carefully. Here you will know whether that AI is good or bad.)

Conclusion: We are human beings. Any tool must be used with caution, especially AI that is capable of playing tricks with your precious brain. Build razor sharp instincts and trust them ONLY.

Re: A staff engineer's journey with Claude Code

#405

Post by rhubarbtree »

theshrike79 wrote: post #396
rhubarbtree wrote: post #370

Earlier quoted context omitted.

That’s unusual though? I think programming languages, idioms, features - for example - are adopted by consensus, not by every programmer starting out from scratch and evaluating each one.

So if the "consensus" adopts ... Erlang, you will just start using it? And because this "consensus" adopted it, you know what it's good for and what kind of problems its good at solving and whether it's a good option for what you specifically are doing? Using LLMs is a skill that's (currently) a bit hard to teach, it's a ball of math and vectors that doesn't work in a deterministic way. Some magic words in the prompt…

> So if the "consensus" adopts ... Erlang, you will just start using it?

If everyone’s using it I will certainly learn it, yes.

Re: A staff engineer's journey with Claude Code

#406

Post by enobrev »

theshrike79 wrote: post #397
enobrev wrote: post #178

Earlier quoted context omitted.

> 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, d…

I'm not calling bullshit here, but something smells. If you really can write a full-ass system like that faster than an LLM, you're either REALLY fucking good at what you do (and an amazing typer), or you're holding the LLM wrong as they say.

I'm ok on speed. Not 10x or anything, but I've been writing full-stack web apps and websites from scratch for a quarter century.

The issue is getting the LLM to write _reasonably decent_ code without having to read every line and make sure it's not doing anything insane. I've tried a few different methods of prompting, but setting up a claude sub-agent that's doing TDD very explicitly and ensuring that all tests pass after every iteration has been most effective.

My first attempt was so fast, it was mind-bending. I had a "working" App and API running in about a day and a half. And then when I tried to adjust features, it would start changing things all over the place, LOTS of tests were failing, and after a couple prompts, I got to a point where the app was terribly broken. I spent about a day trying to prompt my way out of a seemingly infinite hole. I did a more thorough code review and it was a disaster: Random code styles, tons of half-written and abandoned code, tests that did nothing, //TODOs everywhere, and so, so many tweaks for backwards compatibility - which I did NOT need for a greenfield project

At that point I scrapped the project and adjusted my approach. I broke down the PRD into more thorough documentation for reference. I streamlined the CLAUDE.md files. I compiled a standard method of planning / documenting work to be done. I created sub-agents for planning and implementation. I set up the primary implementation sub-agents to split up the spec into bite-sized portions of work ("30-45 minute tasks").

Now I'm at the opposite side of the spectrum - implementation is dog slow, but I rarely have to read what was actually written. I still review the code at large after the primary tasks are finished (comparing the feature branch against main in my IDE), but for the most part I've been able to ignore the output and rely on my manual app tests and then occasionally switch models (or LLMs) and prompt for a thorough code-review.

Re: A staff engineer's journey with Claude Code

#407

Post by jf22 »

ruszki wrote: post #351
jf22 wrote: post #322

Earlier quoted context omitted.

Yeah but you get the two days of hacking in 15 minutes. And I highly doubt you spend months, as in 5+ weeks at the least making it production ready. What even is "production readiness?" 100% fully unit tested and ready for planetary hyper scale or something? 95% of the human generated software I work on is awful but somehow makes people money.

First of all, you can rarely write down in English, what you want in 15 minutes… It’s even common to have longer specification, than its implementation. Just look at tests. Especially, if you want to do something which was never done before, the disparity can be staggering. Claude Code for example is also not that quick at all. It produces some code quickly, but even scaffolding three hello world level example projec…

I'm not sure if you're using these tools if you think a weekend hackathon project can't be done in 15 minutes.

Re: A staff engineer's journey with Claude Code

#408

Post by maigret »

block_dagger wrote: post #136
RomanPushkin wrote: post #87

Earlier quoted context omitted.

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.

Can you elaborate on “huge”?

Re: A staff engineer's journey with Claude Code

#409

Post by oblio »

stitched2gethr wrote: post #307
MontyCarloHall wrote: post #280

Earlier quoted context omitted.

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.

This contains some specific data with pretty graphs: https://youtu.be/tbDDYKRFjhk?t=623 But if you do professional development and use something like Claude Code (the current standard, IMO) you'll quickly get a handle on what it's good at and what it isn't. I think it took me about 3-4 weeks of working with it at an overall 0x gain to realize what it's going to help me with and what it will make take longer.

Thank you for sharing the video, it's great! Puts into words a lot of things I was thinking.

Re: A staff engineer's journey with Claude Code

#410

Post by ruszki »

jf22 wrote: post #407
ruszki wrote: post #351

Earlier quoted context omitted.

First of all, you can rarely write down in English, what you want in 15 minutes… It’s even common to have longer specification, than its implementation. Just look at tests. Especially, if you want to do something which was never done before, the disparity can be staggering. Claude Code for example is also not that quick at all. It produces some code quickly, but even scaffolding three hello world level example projec…

I'm not sure if you're using these tools if you think a weekend hackathon project can't be done in 15 minutes.

There are billions of other possible reasons, like our coding skills can be different, your hackathon experience can be completely different than mine, our care of quality can be different, even during hackathons, our coding speed can be different, etc.
Post reply on HN