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…
A staff engineer's journey with Claude Code
331–340 of 410 posts
Re: A staff engineer's journey with Claude Code
#332Does 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…
I personally have not watched much, but it sounds just like what you are looking for!
Re: A staff engineer's journey with Claude Code
#333Earlier 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…
How long would it have taken if you had written “the detailed specs, detailed commit log, and thousands of tests”?
The commits - some would be detailed, plenty would have been "typo" or "same as last commit, but works this time"
The tests - Probably would have been decent for the API, but not as thorough. Likely non-existent for the UI.
As for time - I agree with the other response - I wouldn't have taken the time.
Re: A staff engineer's journey with Claude Code
#334Earlier quoted context omitted.
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…
I'm thiiiis close to writing a Firefox extension that auto-hides any HN headline with an LLM/AI-related keyword in the title, just so I can find something interesting on here again.
Re: A staff engineer's journey with Claude Code
#335I 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…
> - The code that is written by LLMs always needs to be heavily monitored for correctness, style, and design, and then typically edited down, often to at least half its original size For this language matters a lot, if whatever you're using has robust tools for linting and style checks, it makes the LLMs job a lot easier. Give it a rule (or a forced hook) to always run tests and linters before claiming a job is done…
1) I broke the tests, guess I should delete them.
2) I broke the tests, guess the code I wrote was wrong, guess I should delete all of that code I wrote.
3) I broke the tests, guess I should keep adding more code and scaffolding. Another abstraction layer might work? What if I just add skeleton code randomly, does this add random code whack-a-mole work?
That last one can be particularly "fun" because already verbose LLM code skyrockets into baroque million line PRs when left truly unsupervised, and that PR still won't build or pass tests.
There's no true understanding by an LLM. Forcing it to lint/build can be important/useful, but still not a cure-all, and leads to such fun even more degenerate cases than hand-holding it.
Re: A staff engineer's journey with Claude Code
#336I 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…
Right! Problem, billions of dollars have been poured into this wrt to infrastructure, datacenters, compute and salaries. LLMs need to be at the level of replacing vast swathes of us to be worth it. LLMs are not going to be doing that.
This is a collosal malinvestment.
Re: A staff engineer's journey with Claude Code
#337Earlier quoted context omitted.
I'm thiiiis close to writing a Firefox extension that auto-hides any HN headline with an LLM/AI-related keyword in the title, just so I can find something interesting on here again.
You can do this with a custom filter list in Ublock Origin, no custom extension necessary.
Re: A staff engineer's journey with Claude Code
#338Earlier quoted context omitted.
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…
I'm thiiiis close to writing a Firefox extension that auto-hides any HN headline with an LLM/AI-related keyword in the title, just so I can find something interesting on here again.
Re: A staff engineer's journey with Claude Code
#339Earlier quoted context omitted.
I don't believe it's to do with the requirements. I think you'll still hit the same problems if those greenfield projects grow. It's still fundamentally about the code. I think you're missing the difference between a 10/100k+ lines of code professional software vs a quick 3k lines greenfield project. In a few thousand lines of code you can get away with a massive amount of code bloat, quick hacks and inconsistent API…
I personally find Claude Code has no real issues working and producing code in the 40k LoC Ruby on Rails repo I work in nor in the 45k LoC Elixir/Phoenix repo I work in. For the last few months I'd say 99% of all changes I do to both are purely via Claude Code, I almost never use my editor anymore at all. It's common things don't work on the first try or aren't exactly what I want but usually just giving an error to…
I haven't tried it yet, but I thought elixirs easily implementable static analysis of code could make enforcement whenever the LLM goes off rails highly useful, and an umbrella architecture would make modularity well established.
Modules could all define their own contexts via nested CLAUDE.md and subagents could be used to give it explicit implementation details.
Did you try something like that before MGriisser? (successfully or not?)
Re: A staff engineer's journey with Claude Code
#340I 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…
>- LLMs utility is high enough that it is now going to be a standard tool in the toolbox of every software engineer, but it is definitely not replacing anyone at current capability. Right! Problem, billions of dollars have been poured into this wrt to infrastructure, datacenters, compute and salaries. LLMs need to be at the level of replacing vast swathes of us to be worth it. LLMs are not going to be doing that. Thi…
Nobody knows when. But it will. TBH the biggest danger is that all the hopes and dreams aren't materialised and the appetite for high-risk investments dissipates.
We've had this period in which you can be money losing and its OK. But I believe we have passed the peak on that - and this is destined to blow up.