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

391–400 of 410 posts

Re: A staff engineer's journey with Claude Code

#391

Post by theshrike79 »

chamomeal wrote: post #299
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 t…

It's fun to see Vibe Coders discover the basics of project management in real time without ever reading a book :)

That's what programming with LLMs is, it's just project management: You split the tasks into manageable chunks (ones that can be completed in a single context window), you need to have good onboarding documentation (CLAUDE.md or the equivalent) and good easy to access documentation (docs/ with markdown files).

Exactly what you use to manage a team of actual human programmers.

Re: A staff engineer's journey with Claude Code

#392

Post by theshrike79 »

tempoponet wrote: post #320
theshrike79 wrote: post #317

Earlier quoted context omitted.

> Based on my set up as of today, I’d imagine by sometime next year that will be normal and then the conversation will be very different; mostly around cost control. I wouldn’t be surprised if there is a break out popular agent control flow language by next year as well. Currently it's just VC funded. The $20 packages they're selling are in no way cost-effective (for them). That's why I'm driving all available models…

Once local models are good enough there will be a $20 cloud provider that can give you more context, parameters, and t/s than you could dream of at home. This is true today with services like groq.

Anthropic used to have unlimited subscriptions, then people started running angents 24/7.

Now they have 5 hour buckets of limited use.

Groq most likely stays afloat because they're a bit player - and propped by VC money.

With a local system I can run it at full blast all the time, nobody can suddenly make it stupid by reallocating resources to training their new model, nobody can censor it or do stealth updates that make it perform worse.

Re: A staff engineer's journey with Claude Code

#393

Post by theshrike79 »

komali2 wrote: post #262
thecupisblue wrote: post #252

Earlier quoted context omitted.

Great video! Even more, shows a few things - how good it is with such a niche language but also exposes some direct flaws. First off, Rust represents quite a small part of the training dataset (last I checked it was under 1% of code dataset) in most public sets, so it's got waaay less training then other languages like TS or Java. You added 2 solid features, backed with tests and documentation and nice commit message…

> #1: Add a subagent for git that knows your style, so you don't poison direct claude context and spend less tokens/time fighting it. I've not heard of this for, what does this mean practically? Some kind of invocation in claude? Opening another claude window?

Agents are basically separate "threads" with their own context window.

So the main claude can tell the test-runner agent "Run tests using `task test` and return the results"

Then the test-runner agent runs the tests, "wasters" its context by reading 500 lines of test results, sees that it's ok. Returns "tests ok" to the main context.

This way the main context is spared from the useless chatter and can go on for longer.

Re: A staff engineer's journey with Claude Code

#394

Post by theshrike79 »

Difwif wrote: post #296
Aeolun wrote: post #265

Earlier quoted context omitted.

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

2, 3, 4 are all what human coders need to be efficient too :)

I'm kinda hoping that this LLM craze will force people to be better at it. Have documentation up to date and easily accessible is good for everyone.

Like we're (over here) better at marking lines in the road, because the EU mandated lane keeping assist needs the road markings to be there or it won't work.

Re: A staff engineer's journey with Claude Code

#395

Post by theshrike79 »

ku1ik wrote: post #288
simonw wrote: post #261

Earlier quoted context omitted.

Armin Ronacher (long-time Python and Rust open source community figure, creator of Flask and Jinja among others) has several YouTube videos that partially fit the bill. https://www.youtube.com/watch?v=sQYXZCUvpIc and https://www.youtube.com/watch?v=Y4_YYrIKLac and https://www.youtube.com/watch?v=tg61cevJthc

I watched one of those videos and it was very underwhelming, imho not really selling Claude Code to anyone who isn’t convinced.

What was your expectation?

For me LLM coding is 90% going from "hey this kind of tool would be cool" to a workable MVC in an evening.

The 10% is me using it at work to debug issues or create boilerplate crap.

Re: A staff engineer's journey with Claude Code

#396

Post by theshrike79 »

rhubarbtree wrote: post #370
dewey wrote: post #232

Earlier quoted context omitted.

One of these things where you just have to put in the work yourself for a while and see how it works for your workflow and project.

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 will try to make it do something, but not always.

You really need to use one, preferably a few different ones, and get a feel for how they operate. Like driving a car. You can watch 420 hours of videos of people driving cars, but you really need to sit in one to get comfortable doing it.

Re: A staff engineer's journey with Claude Code

#397

Post by theshrike79 »

enobrev wrote: post #178
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.

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

Re: A staff engineer's journey with Claude Code

#398

Post by theshrike79 »

masto wrote: post #281
thayne wrote: post #161

Earlier quoted context omitted.

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.

Sometimes I spend half an hour writing a prompt and realize that I’ve basically rubber-ducked the problem to the point where I know exactly what I want, so I just write the code myself. I have been doing my best to give these tools a fair shake, because I want to have an informed opinion (and certainly some fear of being left behind). I find that their utility in a given area is inversely proportional to my skill lev…

I've had the Corporate Approved CoPilot + Sonnet 4 write a full working React page for me based on a screenshot of a Figma model. (Not even through an MCP)

It even discovered that we have some internal components and used them for it.

Got me from 0-MVP in less then an hour. Would've easily taken me a full day

Re: A staff engineer's journey with Claude Code

#399

Post by theshrike79 »

adastra22 wrote: post #95
jaggederest wrote: post #70

Earlier quoted context omitted.

> That will prevent it from eagerly implementing stuff. In theory. In practice, it's not a very secure sandbox and Claude will happily go around updating files if you insist / the prompt is bad / it goes off on a tangent. I really should just set up a completely sandboxed VM for it so that I don't care if it goes rm-rf happy.

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

I've had it do it in plan mode.

Nothing dangerous, but the limits are more like suggestions, as the Pirate code says.

Re: A staff engineer's journey with Claude Code

#400

Post by theshrike79 »

com2kid wrote: post #159
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…

> 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. I asked Claude Code to read a variable from a .env file. It proceeded to write a .env parser from scratch. I then asked it to just use Node's built in .env file parsing.... This was the 2nd time in the same session that it wrote a .env file parser from…

It doesn't say no.

For me it built a full-ass YAML parser when it couldn't use Viper to parse the configuration correctly :)

It was a fully vibe-coded project (I like playing stupid and seeing what the LLM does), but it got caught when the config got a bit more complex and its shitty regex-yaml-parser didn't work anymore. :)

Post reply on HN