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

Field Notes from Shipping Real Code with Claude

diwank.space

Post reply on HN
Print view View original

51–60 of 107 posts

Re: Field Notes from Shipping Real Code with Claude

#51

Post by mathgeek »

meeech wrote: post #28
diwank wrote: post #10

Earlier quoted context omitted.

You can: 1. Add instructions in CLAUDE.md to not touch tests. 2. Disallow the Edit tool for test directories in the project’s .claude/settings.json file

Disallow edit in test dirs is a good tip. thanks. I meant though in the wider context of the team - everyone uses it but not everyone will work the same, use the same underlying prompts as they work. So how do you ensure everyone keeps to that agreement?

> So how do you ensure everyone keeps to that agreement?

There's nothing specific to using Claude or any other automation tool here. You still use code reviews, linters, etc. to catch anything that isn't following the team norms and expectations. Either that or, as the article points out, someone will cause an incident and may be looking for a new role (or nothing bad happens and no one is the wiser).

Re: Field Notes from Shipping Real Code with Claude

#52

Post by localhost »

diwank wrote: post #5

Author here: To be honest, I know there are like a bajillion Claude code posts out there these days. But, there are a few nuggets we figured are worth sharing, like Anchor Comments [1], which have really made a difference: —— # CLAUDE.md ### Anchor comments Add specially formatted comments throughout the codebase, where appropriate, for yourself as inline knowledge that can be easily `grep`ped for. - Use `AIDEV-NOTE:…

Did you use Claude Code to write the post? I'm finding that I'm using it for 100% of my own writing because agentic editing of markdown files is so good (and miles better than what you get with claude.ai artifacts or chatgpt.com canvas). This is how you can do things like merge deep research or other files into the doc that you are writing.

Re: Field Notes from Shipping Real Code with Claude

#53

Post by diwank »

localhost wrote: post #52
diwank wrote: post #5

Author here: To be honest, I know there are like a bajillion Claude code posts out there these days. But, there are a few nuggets we figured are worth sharing, like Anchor Comments [1], which have really made a difference: —— # CLAUDE.md ### Anchor comments Add specially formatted comments throughout the codebase, where appropriate, for yourself as inline knowledge that can be easily `grep`ped for. - Use `AIDEV-NOTE:…

Did you use Claude Code to write the post? I'm finding that I'm using it for 100% of my own writing because agentic editing of markdown files is so good (and miles better than what you get with claude.ai artifacts or chatgpt.com canvas). This is how you can do things like merge deep research or other files into the doc that you are writing.

no, just used chatgpt to bootstrap the research :)

here's the original chat: https://chatgpt.com/share/6844eaae-07d0-8001-a7f7-e532d63bf8...

I also used bits from claude research but apparently if you use claude research, they don't let you create a share link -_-

Re: Field Notes from Shipping Real Code with Claude

#54

Post by diwank »

tomhow wrote: post #38
diwank wrote: post #37

Earlier quoted context omitted.

I completely understand. Just to clarify, when I said it was ~40%, I didn’t mean the content was written by Claude/ChatGPT but that I took its help in deep research and writing the first drafts. The ideas, all of the code examples, the original CLAUDE.md files, the images, citations, etc are all mine.

Ok, sure, these things are hard to quantify. The main issue is that we can't ask the community to refrain from accusing authors of publishing AI-generated content if people really are publishing content that is obviously AI-generated. What matters to us is not how much AI was used to write an article, but rather how much the audience finds that the article satisfies intellectual curiosity. If the audience can sense t…

I appreciate this :)

Re: Field Notes from Shipping Real Code with Claude

#55

Post by diwank »

dkobia wrote: post #50

Thank you for writing this. Many software developers on HN are conflicted about ceding control of software development to LLMs for many reasons including the fact that it feels unstructured and exploratory rather than rigidly planned using more formal methodologies. There's a good middle ground where the LLMs can help us solve problems faster optimizing for outcomes rather than falling in love with solving the proble…

absolutely! I think of these as new levers in the making, rather rusty, and def can often bite you in the behind but worth learning, and perhaps most importantly to help evolve them into useful tools rather than an excuse to ship sloppy engineering

Re: Field Notes from Shipping Real Code with Claude

#56

Post by diwank »

StefanBatory wrote: post #41
Artoooooor wrote: post #16

I finally decided few days ago to try this Claude Code thing in my personal project. It's depressingly efficient. And damn expensive - I used over 10 dollars in one day. But I'm afraid it is inevitable - I will have to pay tax to AI overlords just to be able to keep my job.

I had been musing over this. Will devs in very cheap countries still stay an attractive option, just because they'd be still cheaper monthly than Claude.

the cost per token for ~similar performance is dropping by a factor of 2 every 10-11 months at the moment, so I am not sure. that said, I think devs in less expensive parts of the world are actually picking up these tools the fastest (maybe from existential angst? idk)

Re: Field Notes from Shipping Real Code with Claude

#57

Post by diwank »

jstummbillig wrote: post #45
diwank wrote: post #22

Earlier quoted context omitted.

> - Is there a more elegant way to organize the prompts/specifications for LLMs in a codebase? I feel like CLAUDE.md, SPEC.mds, and AIDEV comments would get messy quickly. Yeah, the comments do start to pile up. I’m working on a vscode extension that automatically turns them into tiny visual indicators in the gutter instead. > - What is the definition of "vibe-coding" these days? I thought it refers to the original K…

Is it really though, when a lot of critical business data goes through Google workspace (usually without client side encryption), or are we trying very hard to be a bit special in the name of privacy? From a result standpoint I find curious how interesting people deem their code base to be to a LLM provider.

true but this does matter to a lot of enterprise customers that have to obey strict data provenance laws (for instance, there are no gpt-4.1 model endpoints hosted in India and hence, fin-tech companies cannot use those apis)

Re: Field Notes from Shipping Real Code with Claude

#58

Post by localhost »

diwank wrote: post #53
localhost wrote: post #52

Earlier quoted context omitted.

Did you use Claude Code to write the post? I'm finding that I'm using it for 100% of my own writing because agentic editing of markdown files is so good (and miles better than what you get with claude.ai artifacts or chatgpt.com canvas). This is how you can do things like merge deep research or other files into the doc that you are writing.

no, just used chatgpt to bootstrap the research :) here's the original chat: https://chatgpt.com/share/6844eaae-07d0-8001-a7f7-e532d63bf8... I also used bits from claude research but apparently if you use claude research, they don't let you create a share link -_-

Right. But you can copy paste that into a separate doc and have Claude Code merge it in (and not a literal merge - a semantic merge "integrate relevant parts of this research into this doc"). This is super powerful - try it!

Re: Field Notes from Shipping Real Code with Claude

#59

Post by diwank »

jaakl wrote: post #32
diwank wrote: post #23

Earlier quoted context omitted.

True but, in my experience, a few major pitfalls that happened: 1. We ran into really bad minefields when we tried to come back to manually edit the generated tests later on. Claude tended to mock everything because it didn’t have context about how we run services, build environments, etc. 2. And this was the worst, all of the devs on the team including me got realllyy lazy with testing. Bugs in production significan…

Did you try to put all this (complex and external) context to the context (claude.md or whatever), with intructions how to do proper TDD, before asking for the tests? I know that may be more work than actual coding it as you know all it by heart and external world is always bigger than internal one. But in long term and with teams/codebases with no good TDD practises that might end up with useful test iterations. Of…

we tried a few different variations but tbh had universally bad results. for example, we use `ward` test runner in our python codebase, and claude sonnet (both 3.7 and 4) keep trying to force-switch it to pytest lol. every. single. time.

maybe we could either try this with opus 4 and hope that cheaper models catch up, or just drink the kool-aid and switch to pytest...

Re: Field Notes from Shipping Real Code with Claude

#60

Post by diwank »

ayewo wrote: post #49
diwank wrote: post #23

Earlier quoted context omitted.

True but, in my experience, a few major pitfalls that happened: 1. We ran into really bad minefields when we tried to come back to manually edit the generated tests later on. Claude tended to mock everything because it didn’t have context about how we run services, build environments, etc. 2. And this was the worst, all of the devs on the team including me got realllyy lazy with testing. Bugs in production significan…

I literally LOLed at #2, haha! LLMs are making devs lazy at scale :) Devs almost universally hate 3 things: 1. writing tests; 2. writing docs; 3. manually updating dependencies; and LLMs are a big boon wrt to helping us avoiding all 3, but forcing your team to pick writing tests is a sensible trade off in this context, since as you say bugs in prod increased significantly.

yeah, this might change in the future but I also found that since building features has become faster, asking devs to write the tests themselves sort of demands that they take responsibility of the code and the potential bugs
Post reply on HN