Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

6 weeks of Claude Code

blog.puzzmo.com

Post reply on HN
Print view View original

271–280 of 603 posts

Re: 6 weeks of Claude Code

#271

Post by jarboot »

michaelcampbell wrote: post #36
Fraterkes wrote: post #5

Irrespective of how good Claude code actually is (I haven’t used it, but I think this article makes a really cogent case), here’s something that bothers me: I’m very junior, I have a big slow ugly codebase of gdscript (basically python) that I’m going to convert to C# to both clean it up and speed it up. This is for a personal project, I haven’t written a ton of C# or done this amount of refactoring before, so this c…

I'm on the tail end of my 35+ year developer career, but one thing I always do with any LLM stuff is this: I'll ask it to solve something generally I know I COULD solve, I just don't feel like it. Example: Yesterday I was working with an Open API 3.0 schema. I know I could "fix" the schema to conform to a sample input, I just didn't feel like it because it's dull, I've done it before, and I'd learn nothing. So I aske…

I'm looking forward to the day that LLMs automatically put knowledge like this into Anki or something like it.

Re: 6 weeks of Claude Code

#272

Post by nojito »

GiorgioG wrote: post #249
zmj wrote: post #197

Earlier quoted context omitted.

Your claude.md (or equivalent) is the best way to teach them. At the end of any non-trivial coding session, I'll ask for it to propose edits/additions to that file based on both the functional changes and the process we followed to get there.

How do I distill 30 years of experience/knowledge into a Claude.md file? People learn, LLMs don't - end of story.

The same way you program...

Break apart your knowledge into relevant chunks for Claude so that you can only have what's useful in its context window.

Re: 6 weeks of Claude Code

#274

Post by joks »

deadbabe wrote: post #227

For me, the most compelling use of LLMs is to one shot scripts, small functions, unit tests, etc. I don’t understand how people have the patience to do an entire application just vibe coding the whole time. As the article suggests, it doesn’t even save that much time. If it can’t be done in one shot with simple context I don’t want it.

I did a company hackathon recently where we were encouraged to explore vibe coding more and this was essentially my take-away too. It's kinda perfect for a hackathon but it was insanely mind-numbing to relegate the problem solving and mental model-building to the LLM and sit there writing prompts all day. If that has to become my career, I genuinely might have to change career paths, but it doesn't seem like that's likely -- using it as a tool to help here and there and sometimes provide suggestions definitely feels like way to actually use it to get better results.

Re: 6 weeks of Claude Code

#275

Post by joks »

epolanski wrote: post #190

At this point I am 99% convinced that AI coding skeptics are nothing short of Luddites. They would be like "but a robot will never ever clean a house as well as I would", well, no shit, but they can still do the overwhelming majority of the work very well (or at least as good as you instruct them to) and leave you with details and orchestration.

If you get as much enjoyment out of problem-solving and programming as you do doing household chores, I'm not sure why you went into this career. I agree that the folks who are 100% anti-using-it-ever are overreacting, but IME replacing the overwhelming majority of the work with vibe-coding is both mind-numbing from a developer perspective and doesn't actually get you better results (or faster results, unless you're basically cowboy coding with no regard for thoroughly ensuring correctness)

Re: 6 weeks of Claude Code

#276

Post by zmmmmm »

I'm most interested in how well these tools can tackle complex legacy systems.

We have tonnes of code that's been built over a decade with all kinds of idioms and stylistic conventions that are enforced primarily through manual review. This relates in part to working in a regulated environment where we know certain types of things need radical transparency and auditability, so writing code the "normal" way a developer would is problematic.

So I am curious how well it can see the existing code style and then implicitly emulate that? My current testing of other tools seems to suggest they don't handle it very well; typically I am getting code that looks very foreign to the existing code. It exhibits the true "regression to the mean" spirit of LLMs where it's providing me with "how would the average competent engineer write this", which is not at all how we need the code written.

Currently, this is the main barrier to us using these tools in our codebase.

Re: 6 weeks of Claude Code

#277

Post by ryankrage77 »

hollowturtle wrote: post #154

> Painting by hand just doesn’t have the same appeal anymore when a single concept can just appear and you shape it into the thing you want with your code review and editing skills. In the meanwhile one the most anticipated game in the industry, a second chapter of an already acclaimed product, has its art totally hand painted

I think it's two schools of thought, end product vs process. It seems a lot of people who like AI only care about getting the end product, and don't care how it was made. On the other hand, some people are invested in how something is made, and see the process of creation and refinement as a part of the end product itself.

Re: 6 weeks of Claude Code

#278

Post by 0x696C6961 »

Rapzid wrote: post #264
giancarlostoro wrote: post #169

Earlier quoted context omitted.

If you are a Senior Developer, who is comfortable giving a Junior tips, and then guiding them to fixing them (or just stepping in for a brief moment and writing where they missed something) this is for you. I'm hearing from Senior devs all over thought, that Junior developers are just garbage at it. They product slow, insecure, or just outright awful code with it, and then they PR the code they don't even understand.…

Yeah I noticed the issue with more Junior developers right away. Some developers, Junior or not, have yet to be exposed to environments where their PRs are put under HEAVY scrutiny. They are used to loosey-goosey and unfortunately they are not prepared to put LLM changes under the level of scrutiny they require. The worst is getting, even smallish, PRs with a bunch of changes that look extraneous or otherwise off. Af…

Our offshore devs keep doing this and it drives me nuts. No answers to my question, completely different code gets pushed.

Re: 6 weeks of Claude Code

#279

Post by zmmmmm »

phito wrote: post #185
justlikereddit wrote: post #128

Earlier quoted context omitted.

I've been exploring vibe coding lately and by far the biggest benefit is the lack of mental strain. You don't have to try to remember your code as a conceptual whole, what your technical implementation of the next hour of code was going to be like at the same time as a stubborn bug is taunting you. You just ask Mr smartybots and it deliver anything between proofreading and documentation and whatnot, with some minor f…

It's alright until you have a bug the LLM can't solve, then you have to go in the code yourself and you realize what a mess it has made.

Perhaps you set a very high quality bar, but I don't see the LLMs creating messy code. If anything, they are far more diligent in structuring it well and making it logically sequenced and clear than I would be. For example, very often I name a variable slightly incorrectly at the start and realise it should be just slightly different at the end and only occasionally do I bother to go rename it everywhere. Even with automated refactoring tools to do it, it's just more work than I have time for. I might just add a comment above it somewhere explaining the meaning is slightly different to how it is named. This sort of thing x 100 though.

Re: 6 weeks of Claude Code

#280

Post by SatvikBeri »

zmmmmm wrote: post #276

I'm most interested in how well these tools can tackle complex legacy systems. We have tonnes of code that's been built over a decade with all kinds of idioms and stylistic conventions that are enforced primarily through manual review. This relates in part to working in a regulated environment where we know certain types of things need radical transparency and auditability, so writing code the "normal" way a develope…

I've had a lot of luck with Claude on my 8 year old, multi-language codebase. But I do have to babysit it and provide a lot of context.

I created some tutorial files which contain ways to do a lot of standard things. Turns out humans found these useful too. With the examples, I've found Opus generally does a good job following existing idioms, while Sonnet struggles.

Post reply on HN