Live data from Hacker News

Claude Code 2.0

npmjs.com

271–280 of 431 posts

Re: Claude Code 2.0

#271

Earlier quoted context omitted.

This is awfully purist. I think a happy medium of "comment brevity, and try thinking of a clearer way to do something instead of documenting the potentially unnecessary complexity with a comment" would be good. I don't know where this "comments are instant technical debt" meme came from, because it's frankly fucking stupid, especially in the age of being able to ask the LLM "please find any out-of-date comments in th…

I don't know, I tend to agree. I feel like the number of times I've been thrown off by an out of date comment for code that could have probably been refactored to be clearer, outweigh the times a comment has helped. Docstring comments are even worse, because it's so easy for someone to update the function and not the docstring, and it's very easy to miss in PR review

As always the problem isn't the actual thing being discussed - the problem is shitty developers who wrote shitty comments and/or don't update comments when they update code.

Good and up to date comments are good and up to date. Bad and outdated comments are bad and outdated. If you let your codebase rot then it rots. If you don't then it doesn't. It's not the comment's fault you didnt update it. It's yours.

Re: Claude Code 2.0

#272

Earlier quoted context omitted.

I am guessing this is an attempt to save computing resources/tokens?

Comments in code are instant technical debt. They need to be maintained alongside the code, so you are *programming" twice. Avoid comments, except when they really explain some obscure, incomprehensible section of code or to prevent explorers from the future getting smacked on the face twice by the same stick. I find myself using the latter often to tell future agents what not to do in the next few lines.

Comments describing the program are a form of error correcting code. Redundancy vs efficiency yadda yadda, just make an informed decision instead of a half baked belief; programming more than once is the point, necessarily. (And I don’t mean ‘// add 2 to x’ comments, these are properly useless, I agree - unless they say why x needs to have 2 added.)

Re: Claude Code 2.0

#273
post #49

Something I realized about this category of tool (I call them "terminal agents" but that already doesn't work now there's an official VS Code extension for this - maybe just "coding agents" instead) is that they're actually an interesting form of general agent . Claude Code, Codex CLI etc can effectively do anything that a human could do by typing commands into a computer. They're incredibly dangerous to use if you d…

It's broad utility was immediately clear as soon as I saw it formulating bash commands.

I've used it to troubleshoot some issues on my linux install, but it's also why the folder sandbox gives me zero confidence that it can't still brick my machine. It will happily run system wide commands like package managers, install and uninstall services, it even deleted my whole .config folder for pulseaudio.

Of course I let it do all these things, briefly inspecting each command, but hopefully everyone is aware that there is no real sandbox if you are running claude code in your terminal. It only blocks some of the tool usages it has, but as soon as it's using bash it can do whatever it wants.

Re: Claude Code 2.0

#274
post #49

Something I realized about this category of tool (I call them "terminal agents" but that already doesn't work now there's an official VS Code extension for this - maybe just "coding agents" instead) is that they're actually an interesting form of general agent . Claude Code, Codex CLI etc can effectively do anything that a human could do by typing commands into a computer. They're incredibly dangerous to use if you d…

I call them 'CLI agents'!

Re: Claude Code 2.0

#275
post #137

Earlier quoted context omitted.

One thing I really like using them for is refactoring/reorganizing. The tedious nature of renaming, renaming all implementations, moving files around, creating/deleting folders, updating imports exports, all melts away when you task an agent with it. Of course this assumes they are good enough to do them with quality, which is like 75% of the time for me so far.

I've found that it can be hard or expensive for the agent to do "big but simple" refactors in some cases. For example, I recently tasked one with updating all our old APIs to accept a more strongly typed user ID instead of a generic UUID type. No business logic changes, just change the type of the parameter, and in some cases be wary of misleading argument names by lazy devs copy pasting code. This ended up burning t…

The way I do this is I task the agent with writing a script which in turn does the updates. I can inspect that script, and I can run it on a subset of files/folders, and I can git revert changes if something went wrong and ask the agent to fix the script or fine-tune it myself. And I don't burn through tokens :)

Also, another important factor (as in everything) is to do things in many small steps, instead of giving one big complicated prompt.

Re: Claude Code 2.0

#276

Earlier quoted context omitted.

You can rewind your context back to the checkpoint

No, that's not the point of this new checkpoints feature. It's already been possible for a while to rewind context in Claude Code by pressing . This feature rewinds code state alongside context : > Our new checkpoint system automatically saves your code state before each change , and you can instantly rewind to previous versions by tapping Esc twice or using the /rewind command. https://www.anthropic.com/news/enablin…

From the docs it looks like this feature only reverts the edit tool calls, and not e.g. bash commands that have been executed:

> Checkpoints apply to Claude’s edits and not user edits or bash commands, and we recommend using them in combination with version control

Re: Claude Code 2.0

#277
post #249

It still bothers me that almost every agentic TUI is written in TS + React. It often consumes at least a few GB of RAM. No one bothers about it. Everybody is trying to ship as fast as possible.

Well codex is written in rust.

Interesting, the ink repo still states that codex is using it:

    Who's Using Ink?

    Codex - An agentic coding tool made by OpenAI.
I guess they had initial versions written in TS?

UPD. They switched 3 months ago.

Re: Claude Code 2.0

#278
post #249

It still bothers me that almost every agentic TUI is written in TS + React. It often consumes at least a few GB of RAM. No one bothers about it. Everybody is trying to ship as fast as possible.

> No one bothers about it.

Why would they?

Re: Claude Code 2.0

#279
post #249

It still bothers me that almost every agentic TUI is written in TS + React. It often consumes at least a few GB of RAM. No one bothers about it. Everybody is trying to ship as fast as possible.

They use react on a cli tool?

Re: Claude Code 2.0

#280
post #249

It still bothers me that almost every agentic TUI is written in TS + React. It often consumes at least a few GB of RAM. No one bothers about it. Everybody is trying to ship as fast as possible.

Ram is cheap, 99.9% of the audience that would use this are running heavy envs on powerful computers. I can totally understand why they write it that way. Better to have faster iteration and alienate 0.1% of serious users than to slow development just to cater to them.

Well, it's not only about RAM. Things like calculating correct diffs take more time too, but it's hidden.
Post reply on HN