Live data from Hacker News

A staff engineer's journey with Claude Code

sanity.io

181–190 of 410 posts

Re: A staff engineer's journey with Claude Code

#181
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…

that sounds like just coding it yourself with extra steps

Re: A staff engineer's journey with Claude Code

#182

Earlier quoted context omitted.

I've been vibe coding a couple of personal projects. I've found that test-driven development fits very well with vibe coding, and it's just as you said break up the problem into small, testable chunks, get the AI to write unit tests first, and then implement the actual code

Works great until it’s stuck and it starts just refactoring the tests to say true == true and calling it a day. I want the inverse of black box testing, like the inside of the box has the model in it with the code and it’s not allowed to reach outside the box and change the grades. Then I can just do the Ralph Wiggum as a software engineer loop to get over the reward hacking tendencies

Don't let it touch the test file then? I usually give context to the LLM about what it's allowed to touch. I don't do big sweeping changes though. Don't trust LLM for that. For small, focused changes its great

Re: A staff engineer's journey with Claude Code

#183

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.

I can't use $20 of credit (gpt-5 thinking via intellij's pro AI subscription) a month right now with plenty of usage so I'm surprised at the $1k figure. Is Claude that much more expensive? (a quick Google suggests yes actually). Having said the above some level of AI spending is the new reality. Your workplace pays for internet right? Probably a really expensive fast corporate grade connection? Well they now also nee…

Anthropic and OpenAI both have a high SSO/enterprise tier tax.

Re: A staff engineer's journey with Claude Code

#184
post #47
post #36

Earlier quoted context omitted.

I regularly write big MRs, then cut them into 5+ (sometimes 10+) smaller MRs. What does Claude Code change here?

The split seems artificial now. Before, an average engineer would produce code sequentially, chunk after chunk. Each chunk submitted only after the previous one was reviewed and approved. Today, one could submit the whole thing for review. Also, if machines can write it, why not let machines review it too? Seems weird not to do so.

Will the LLM take responsibility for the bugs and bad code introduced by the review? If it does and I'm free, then go for it.

Re: A staff engineer's journey with Claude Code

#185
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…

Seems like this logic could all be represented in Claude.md and some agents. Has anyone done this? I’d love to just import that into my project because I’m using some of these tactics but it’s fairly manual and tedious.

Re: A staff engineer's journey with Claude Code

#186

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.

What's weird for me is that most frameworks and tools usually include generators for boilerplate code anyway so not sure why wasting tokens/money on that is valuable.

Re: A staff engineer's journey with Claude Code

#187
I don’t understand the use of MCP described in the post.

Claude code can access pretty much all those third party services in the shell, using curl or gh and so on. And in at least one case using MCP can cause trouble: the linear MCP server truncates long issues, in my experience, whereas curling the API does not.

What am I missing?

Re: A staff engineer's journey with Claude Code

#188
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.

> 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.

Re: A staff engineer's journey with Claude Code

#189

Earlier quoted context omitted.

Actually, all good engineering principles which reduce cognitive load for humans work for AI as well.

This is what's so funny about this. In some alternative universe I hope that LLMs never get any better. Because they force so much of good things. They are the single closest thing we've ever had to objective evaluation on if an engineering practice is better or worse. Simply because just about every single engineering practice that I see that makes coding agents work well also makes humans work well. And so many of…

Well put, I like this perspective.

Re: A staff engineer's journey with Claude Code

#190

Earlier quoted context omitted.

This is what's so funny about this. In some alternative universe I hope that LLMs never get any better. Because they force so much of good things. They are the single closest thing we've ever had to objective evaluation on if an engineering practice is better or worse. Simply because just about every single engineering practice that I see that makes coding agents work well also makes humans work well. And so many of…

While a lot of these ideas are touted as "good for the org," in the case of LLMs, it's more like guard rails against something that can't reason things out. That doesn't mean that the practices are bad, but I would much prefer that these LLMs (or some better mechanism) everyone is being pushed to use could actual reason, remember, and improve, so that this sort of guarding wouldn't be a requirement for correct code.

The things GP listed are fundamentally good practices. If LLMs get so good they don't need even these guardrails, ok great but that is a long way off, and until then I am really happy if the outcome of AI assisted coding is that we humans get better at using these ideas for ourselves.
Post reply on HN