Live data from Hacker News

6 weeks of Claude Code

blog.puzzmo.com

81–90 of 603 posts

Re: 6 weeks of Claude Code

#81
post #67

Earlier quoted context omitted.

Claude code is great until it isn’t. You’re going to get to a point where you need to modify something or add something… a small feature that would have been easy if you wrote everything, and now it’s impossible because the architecture is just a mishmash of vibe coded stuff you don’t understand.

The trick is to ask it to do more narrow tasks and design the structure of the code base yourself.

This. It helps to tell it to plan and to then interrogate it about that plan, change it to specification etc. Think of it as a refinement session before a pairing session. The results are considerably better if you do it this way. I've written kubernetes operators, flask applications, Kivy applications, and a transparent ssh proxy with Claude in the last two months, all outside of work.

It also helps to tell it to write tests first: I lean towards integration tests for most things but it is decent at writing good unit tests etc too. Obviously, review is paramount if TDD is going to work.

Re: 6 weeks of Claude Code

#82

I have about two weeks of using Claude Code and to be honest, as a vibe coding skeptic, I was amazed. It has a learning curve. You need to learn how to give it proper context, how to chunk up the work, etc. And you need to know how to program, obviously. Asking it to do something you don't know how to do, that's just asking for a disaster. I have more than 25 years of experience, so I'm confident with anything Claude…

Claude code is great until it isn’t. You’re going to get to a point where you need to modify something or add something… a small feature that would have been easy if you wrote everything, and now it’s impossible because the architecture is just a mishmash of vibe coded stuff you don’t understand.

Having used Claude Code extensively for the last few months, I still haven't reached this "until it isn't" point. Review the code that comes out. It goes a long way.

Re: 6 weeks of Claude Code

#83

I have about two weeks of using Claude Code and to be honest, as a vibe coding skeptic, I was amazed. It has a learning curve. You need to learn how to give it proper context, how to chunk up the work, etc. And you need to know how to program, obviously. Asking it to do something you don't know how to do, that's just asking for a disaster. I have more than 25 years of experience, so I'm confident with anything Claude…

> as a vibe coding skeptic, I was amazed. The interesting thing about all of this vibe coding skepticism, cynicism, and backlash is that many people have their expectations set extremely low. They’re convinced everything the tools produce will be junk or that the worst case examples people provide are representative of the average. Then they finally go out and use the tools and realize that they exceed their (extreme…

It doesn't help that a lot of skeptics are also dishonest. A few days ago someone here tried to claim that inserting verbose debug logging, something Claude Code would be very good at, is "actually programming" and it's important work for humans to do.

No, Claude can create logs all across my codebase with much better formatting far faster than I can, so I can focus on actual problem solving. It's frustrating, but par for the course for this forum.

Edit: Dishonest isn't correct, I should have said I just disagree with their statements. I do apologize.

Re: 6 weeks of Claude Code

#84
I've been using Claude code 12-16 hours a day since I first got it running two weeks ago. Here's the tips I've discovered:

1. Immediately change to sonnet (the cli defaults to opus for max users). I tested coding with opus extensively and it never matches the quality of sonnet.

2. Compacting often ends progress - it's difficult to get back to the same quality of code after compacting.

3. First prompt is very important and sets the vibe. If your instance of Claude seems hesitant, doubtful, sometimes even rude, it's always better to end the session and start again.

4. There are phrases that make it more effective. Try, "I'm so sorry if this is a bad suggestion, but I want to implement x and y." For whatever reason it makes Claude more eager to help.

5. Monolithic with docker orchestration: I essentially 10x'd when I started letting Claude itself manage docker containers, check their logs for errors, rm them, rebuild them, etc. Now I can get an entirely new service online in a docker container, from zero to operational, in one Claude prompt.

Re: 6 weeks of Claude Code

#85

I have about two weeks of using Claude Code and to be honest, as a vibe coding skeptic, I was amazed. It has a learning curve. You need to learn how to give it proper context, how to chunk up the work, etc. And you need to know how to program, obviously. Asking it to do something you don't know how to do, that's just asking for a disaster. I have more than 25 years of experience, so I'm confident with anything Claude…

Maybe instead try opencode or crush with Gemini/Google auth when your Claude Code hits the limit.

Re: 6 weeks of Claude Code

#86

Earlier quoted context omitted.

You're not setting good enough boundaries or reviewing what it's doing closely enough. Police it, and give it explicit instructions. Then after it's done its work prompt it with something like "You're the staff engineer or team lead on this project, and I want you to go over your own git diff like it's a contribution from a junior team member. Think critically and apply judgement based on the architecture of the proj…

Ah yes…the old “you’re holding it wrong”. The problem is these goddamn things don’t learn, so you put in the effort to police it…and you have to keep doing that until the end of time. Better off training someone off the street to be a software engineer.

Not so. Adding to context files helps enormously. Having touchstone files (ARCHITECTURE.md) you can reference helps enormously. The trick is to steer, and create the guardrails.

Honestly, it feels like DevOps had a kid with Product.

Re: 6 weeks of Claude Code

#87

Earlier quoted context omitted.

How can you end up with code you don't understand, if you review anything it writes? I wouldn't let it deviate from the architecture I want to have for the project. I had problems with junior devs in the past, too eager to change a project, and I couldn't really tell them to stop (need to work on my communication skills). No such problem with Claude Code.

So youre telling me that reading is the same as writing? In terms of the brain actually consuming and processing the info you gave it and storing it

> a mishmash of vibe coded stuff you don’t understand.

No, there is a difference between "I wrote this code" and "I understand this code". You don't need to write all the code in a project to understand it. Otherwise writing software in a team would not be a viable undertaking.

Re: 6 weeks of Claude Code

#88

I have about two weeks of using Claude Code and to be honest, as a vibe coding skeptic, I was amazed. It has a learning curve. You need to learn how to give it proper context, how to chunk up the work, etc. And you need to know how to program, obviously. Asking it to do something you don't know how to do, that's just asking for a disaster. I have more than 25 years of experience, so I'm confident with anything Claude…

Claude code is great until it isn’t. You’re going to get to a point where you need to modify something or add something… a small feature that would have been easy if you wrote everything, and now it’s impossible because the architecture is just a mishmash of vibe coded stuff you don’t understand.

The people successfully using Claude Code for big projects aren’t letting it get to the point where they don’t understand what it wrote.

The best results come from working iteratively with it. I reject about 1/3 of edits to request some changes or a change of direction.

If you just try to have it jam on code until the end result appears to work then you will be disappointed. But that’s operator error.

Re: 6 weeks of Claude Code

#89

I have been coding with claude code for about 3 weeks and I love it. I have bout 10yoe and mostly do Python ML / Data Eng. Here are a few reasons: 1. It takes away the pain of starting. I have no barrier to writing text but there is a barrier to writing the first line of code, to a large extend coming form just remembering the context, where to import what from, setting up boilerplate etc. 2. While it works I can use…

> 4. It makes it so much easier to "go the extra mile" (I don't add "TODOs" anymore in the code I just spin up a new Claude for it)

This especially. I've never worked at a place that didn't skimp on tests or tech debt due to limited resources. Now you can get a decent test suite just from saying you want it.

Will it satisfy purists? No, but lots of mid hanging fruit long left unpicked can now be automatically picked.

Re: 6 weeks of Claude Code

#90
post #29

Earlier quoted context omitted.

> 2. Start with a good spec. Spend enough time on the spec. You can get AI to write most of the spec for you, if you provide a good outline. Curious how you outline the spec, concretely. A sister markdown document? How detailed is it? etc. > 3. Make sure you have tests from the beginning. This is the most important part. Tests (along with good specs) are how an AI agent can recurse into a good solution. TDD is back.…

> Curious how you outline the spec, concretely. A sister markdown document? How detailed is it? etc. Yes. I write the outline in markdown. And then get AI to flesh it out. The I generate a project structure, with stubbed API signatures. Then I keep refining until I've achieved a good level of detail - including full API signatures and database schemas. > Ironically i've been struggling with this. For best results i'v…

I don't even write the outline myself. I tell CC to come up with a plan, and then we iterate on that together with CC and I might also give it to Gemini for review and tell CC to apply Gemini's suggestions.
Post reply on HN