Could you maybe in brought strokes explain what you are working on? I think it is very plausible that the disconnect is between people writing front ends/rest apis vs people solving things like graphics.
In my case this is not simply "rest APIs". It's is a fairly complex code base. Not trivial work. But the code base is fairly clean and so localized understanding can be sufficient for many tasks.
I tend to agree. Taking shortcuts are one thing, not daring to refactor along the way another. I would only do this in low stress situations due to the risk of producing new bugs or issues, and just lacking the time to properly update tests etc. Opus 4.7 sometimes makes suboptimal design decisions, especially in terms of overcomplicating things, but I have not seen it produce an actual bug in smaller changes in a long while.
The other is using Agents as critical reviewers. I've let Opus 4.7 review PRs by very senior people. Most of the suggestions are meh, but usually there's at least 1 or 2 that improve the code base unequivocally.
Also there are still considerations like domain, team expertise, org ecosystem etc. to consider. I love to use Rust for most things, but now I'm working with an org that primarily has expertise in Java, and I'm not going to rock the boat for barely any reason. Python is also still useful for most ML stuff, and Django is quite a pleasure to work with (although it wouldn't be my first choice).
The great thing about LLM-assisted coding is that an experienced software engineer can acquire decent familiarity with a language quite quickly. And then has a useful sparring partner for understanding and using the quirks and features of a new language.
Same here, working with a team that knows Java, so I'm letting Claude write Java.
If I compare the results to another team that uses Python with Claude I see slightly better results on the Java side. Not because Claude knows that better, but because the tools are more rigid by default which creates more of a self correcting loop for Claude. The Python side has Pydantic, but it's a bit of an afterthought, while in Java you can't skip the type checking.
In the end you can do the same things on both sides, it's 95% a team/engineering culture difference. So pick the language that the team knows best.
There is labor that is necessary for our societies to function, but a direct threat to the people doing the work. Someone has to do it, and it should be seen as a great service to society and rewarded accordingly. In a just world, we would be paying significantly extra for threats to health that come from work, in the one we are currently in we use threat of worse harm instead.
Someone has to do it, and it should be seen as a great service to society and rewarded accordingly
You are just too priviledge to understand people: many people would be glad do do it for the minimum wage, I would fight to have that oportunity (I live in west EU).
He's been saying whatever is good for Nvidia for years now without any regard for truth or reason. He's one of the least trustworthy voices in the space.
Jensen hallucinates more than any llm, he just speaks without thinking all that much about what he says and he generalizes a lot. Trying to hold him accountable to imprecisions and gross simplifications is just going to frustrate whoever tries without changing one bit of his behavior.
I'm on the 20 USD tier, and it works quite well for me. Basically I send one very carefully crafted task to the LLM per 4h limit, do a couple of minor questions, and the rest of the time I'm thinking/exploring/coding. I am producing around a tenth of the code of my colleagues, but around the same number of features.
Networking effects are significantly strengthened by necessary user buy in. VC is hard, and every tool demands its users to spend a non-significant amount of time learning it. I would guess the time to move from black magic to understanding most of git is ~100h for most people.
The thing is, to understand which one is actually better, you would have to give the same amount of investment in the second tool, which is not something most people are willing to do if the first tool is "good enough". That's how Python became the default programming language; people don't miss features they do not understand.
A little over a decade ago, with only svn experience, I tried both mercurial and git. There was something about how mercurial handled branches that I found extremely confusing (don't remember what), while git clicked immediately - even without reading the manual.
This is moral relativism at its finest, and just plain wrong. I'm not willing to go so far as to call Anthropic a good player, but they are surprisingly often willing to put their money where their mouth is. Obviously everything can be interpreted as a PR move as well, but we just lack context to know true intentions. Personally I have repeatedly sold being a good org as a PR move, it is the easiest way to do good in a capitalist environment. The success of such a sales pitch significantly relies on the moral values (or lack thereof) of the other decision makers at the company.
With Project Glasswing for example, I'm impressed at how generally well thought out it is, and very much appreciate that they donate a lot of money to OSS. I would have liked them to extend the Project to smaller players as well, but power centralisation is an inherent problem of AI, not something that is unique to Anthropic.
And what is malicious about that ideology? I think EAs tend to like the smell of their farts way too much, but their views on AI safety don't seem so bad. I think their thoughts on hypothetical super intelligence or AGI are too focused on control (alignment) and should also focus on AI welfare, but that's more a point of disagreement that I doubt they'd try to forbid.
Just to be clear, the smartest person is still a minister in Idiocracy, and the whole premise hinges on the idea that the elite still recognizes intelligence as something desirable.
reply