On the other hand, agent integrations in IDEs seem to often add a lot more widgets for interacting with agents, and often they put the agent is in its own little tab off to the side, and I find that harder to work with.

That's why, even though I love using IDEs and have never been a big terminal person, I much prefer using Claude Code in the terminal rather than using tools like Copilot in VSCode (ignoring the code quality differences). I just find it nicer to separate the two.

The portability of being able to really easily run Claude Code in whatever directory you want, and through SSH, is a nice bonus too.

I've been using Roocode (Cline fork) a lot recently and while it's overall great, the UI is janky and incomplete feeling. Same as Cursor and all the others.

I tried Claude Code after hearing great things and it was just Roocode with a worse UX (for me). Most of the people telling me how great it was were talking up the output as being amazing quality. I didn't notice that. I presume the lack of IDE integration makes it feel more magical. This is fun while you're vibing the "first 80%" of your product, but eventually the agents need much more hand holding and collaborative edits to keep things on track.

Would this question be clear for a human? If so, it is probably clear for an LLM. Did I provide enough context for a human to diagnose the problem? Then an LLM will probably have a better chance of diagnosing the problem. Would a human find the structure of this document confusing? An LLM would likely perform poorly when reading it as well.

Re-applying human intuitions to LLMs is a good starting point to gaining intuition about how to work with LLMs. Conversely, understanding sequences of tokens and probability spaces doesn't give you much intuition about how you should phrase questions to get good responses from LLMs. The technical reality doesn't explain the emergent behaviour very well.

I don't think this is mutually exclusive with what the author is talking about either. There are some ways that people think about LLMs where I think the anthropomorphization really breaks down. I think the author says it nicely:

> The moment that people ascribe properties such as "consciousness" or "ethics" or "values" or "morals" to these learnt mappings is where I tend to get lost.

https://news.ycombinator.com/item?id=44488331

Here’s a quote from the ruling:

“First, Authors argue that using works to train Claude’s underlying LLMs was like using works to train any person to read and write, so Authors should be able to exclude Anthropic from this use (Opp. 16). But Authors cannot rightly exclude anyone from using their works for training or learning as such. Everyone reads texts, too, then writes new texts. They may need to pay for getting their hands on a text in the first instance. But to make anyone pay specifically for the use of a book each time they read it, each time they recall it from memory, each time they later draw upon it when writing new things in new ways would be unthinkable. For centuries, we have read and re-read books. We have admired, memorized, and internalized their sweeping themes, their substantive points, and their stylistic solutions to recurring writing problems.”

They literally compare an LLM learning to a person learning and conflate the two. Anthropic will likely win this case because of this anthropomorphisization.

It sounds like the Authors were the one who brought this argument, not Anthropic? In which case, it seems like a big blunder on their part.

Wait till the disillusionment sets in.

Australia has social healthcare and massive mining companies. They coexist just fine. There really is a lot of wiggle room between fully embracing socialism and going full anarcho-capitalist, and maybe the tradeoffs of shifting towards the socialism side of things are worth considering.

Although, George seems to just want to flip the table out of the belief that real reform that would impact most people positively will never get passed in a democracy. It would require too much change.

So, there are governments that oversee capitalist countries that are willing to implement policies that hurt corporate interests with the goal of helping consumers. I'd say the problem is that often these policies made with good intentions, like GDPR, end up being poorly implemented and therefore harming consumers as well as hurting corporations... but that's an entirely different problem.

The former implies that rblx has some attributes that are conducive to child predation, which would be worth teasing apart out of scientific interest, while the latter is a very general problem, as (I dare take this as self-evident) any place that has greater than 0 child predators has more than there ought to be.

> The stuff you're describing doesn't really seem much different that any popular internet spaces in the 2000s

I think there is a big difference to some of the examples they gave, because of the uniquely young age demographics on Roblox. The only example that seems comparable was Club Penguin.

Now, I agree that there is interest in teasing out whether there are problems with Roblox specifically, or if it is just a problem with having an online space with such a high concentration of kids in general. But that high concentration of kids does make it much more of a concern either way.

But this can be a problem wherever kids are online. Discord also has huge problems with child predators. And any platform that caters to children should be held to very high standards of child safety.

The games that I think shouldn't be held to such a high standard are games like World of Warcraft. That game is not targeted at children, has far fewer children players, and therefore it is unreasonable to hold them to as high of a standard as Roblox. (Although they do still have some responsibility to make sure their platform is safe.)

I just hope non-technical people that pick this up also pick up version control. Or, is there a better alternative to Claude Code that can accomplish a similar thing while being more friendly to non-technical people?

With AI, instead of starting with zero and building up, you can start with a result and iterate on it straight away. This process really shines when you have a good idea of what you want to do, and how you want it implemented. In these cases, it is really easy to review the code, because you knew what you wanted it to look like. And so, it lets me implement some basic features in 15 minutes instead of an hour. This is awesome.

For more complex ideas, AI can also be a great idea sparring partner. Claude Code can take a paragraph or two from me, and then generate a 200-800 line planning document fleshing out all the details. That document: 1) helps me to quickly spot roadblocks using my own knowledge, and 2) helps me iterate quickly in the design space. This lets me spend more time thinking about the design of the system. And Claude 4 Opus is near-perfect at taking one of these big planning specifications and implementing it, because the feature is so well specified.

So, the reality is that AI opens up new possible workflows. They aren't always appropriate. Sometimes the process of writing the code yourself and iterating on it is important to helping you build your mental model of a piece of functionality. But a lot of the time, there's no mystery in what I want to write. And in these cases, AI is brilliant at speeding up design and implementation.

I agree but I have a hunch we're all gonna be pushed by higher ups to use AI always and for everything. Headcounts will drop, the amount of work will rise and deadlines will become ever so tight. What the resulting codebases would look like years from now will be interesting.

I know the tools and environments I am working in. I verify the implementations I make by testing them. I review everything I am generating.

The idea that AI is going to trick me is absurd. I'm a professional, not some vibe coding script kiddie. I can recognise when the AI makes mistakes.

Have the humility to see that not everyone using AI is someone who doesn't know what they are doing and just clicks accept on every idea from the AI. That's not how this works.

Software is incredibly easy to verify compared to other domains. First, my own expertise can pick up most mistakes during review. Second, all of the automated linting, unit testing, integration testing, and manual testing is near guaranteed to pick up a problem with the functionality being wrong.

So, how exactly do you think AI is going to trick me when I'm asking it to write a new migration to add a new table, link that into a model, and expose that in an API? I have done each of these things 100 times. It is so obvious to me when it makes a mistake, because this process is so routine. So how exactly is AI going to trick me? It's an absurd notion.

AI does have risks with people being lulled into a false sense of security. But that is a concern in areas like getting it to explain how a codebase works for you, or getting it to try to teach you about technologies. Then you can end up with a false idea about how something works. But in software development itself? When I already have worked with all of these tools for years? It just isn't a big issue. And the benefits far outweigh it occasionally telling me that an API exists that actually doesn't exist, which I will realise almost immediately when the code fails to run.

People who dismiss AI because it makes mistakes are tiresome. The lack of reliability of LLMs is just another constraint to engineer around. It's not magic.

For example, a research document could sound good, but be complete nonsense. There's no realistic way to verify that an English document is correct other than to verify it manually. Whereas, software has huge amounts of investment into testing whether a piece of software does what it should for a given environment and test cases.

Now, this is a bit different to formally verifying that the software is correct for all environments and inputs. But we definitely have a lot more verification tools at our disposal than most other domains.

It's right there in the quote.