I've read a lot of people complain that it's buggy, here and in other forums.

Two weeks ago typing became super laggy. It was totally unusable.

Last week I had to reinstall Claude Desktop because every time I opened it, it just hung.

This week I am sometimes opening it and getting a blank screen. It eventually works after I open it a few times.

And of course there's people complaining that somehow they're blowing their 5 hour token budget in 5 messages.

It's really buggy.

There's only so long their model will be their advantage before they all become very similar, and then the difference will be how reliable the tools are.

Right now the Claude Code code quality seems extremely low.

Cc is buggy as hell man. I frequently search the github for the issue I’m having only to find 10 exact bugs that no one is looking at.

Obviously they don’t care. Adoption is exploding. Boris brags about making 30 commits a day to the codebase.

Only will be an issue down the line when the codebase has such high entropy it takes months to add new features (maybe already there).

Nothing, apparently, which is probably why Claude Code has 7893 open issues on Github at the time of writing.

The same functionality can be copied over in a week most likely. The moat is experimentation and new feature releases with the underlying model. An engineer would not be able to experiment with the same speed.

Kinda reads like the Dropbox launch thread

I always write code like that. I don't like early returns. This approximates `if` statements being an expression that returns something.

> Why even use else if with return...

What is the problem with that? How would you write that snippet? It is common in the new functional js landscape, even if it is pass-by-ref.

Here I think the logic is unnecessarily complex. isQuoted is doing work that is implicit in the token.

insert "AI is just if statements" meme

Maybe, I do suspect _some_ parts are codegen or source map artifacts.

But if you take a look at the other file, for example `useTypeahead` you'd see, even if there are a few code-gen / source-map artifacts, you still see the core logic, and behavior, is just a big bowl of soup

> process.env? It is a global map

That's exactly why, access to global mutable state should be limited to as small a surface area as possible, so 99% of code can be locally deterministic and side-effect free, only using values that are passed into it. That makes testing easier too.

environment variables can change while the process is running and are not memory safe (though I suspect node tries to wrap it with a lock). Meaning if you check a variable at point A, enter a branch and check it again at point B ... it's not guaranteed that they will be the same value. This can cause you to enter "impossible conditions".

For one it's harder to unit test.

It's implicit state that's also untyped - it's just a String -> String map without any canonical single source of truth about what environment variables are consulted, when, why and in what form.

Such state should be strongly typed, have a canonical source of truth (which can then be also reused to document environment variables that the code supports, and eg. allow reading the same options from configs, flags, etc) and then explicitly passed to the functions that need it, eg. as function arguments or members of an associated instance.

This makes it easier to reason about the code (the caller will know that some module changes its functionality based on some state variable). It also makes it easier to test (both from the mechanical point of view of having to set environment variables which is gnarly, and from the point of view of once again knowing that the code changes its behaviour based on some state/option and both cases should probably be tested).

They use claude code to code it. Makes sense