If a human asked me this question, I would be confused by the question as ambiguous since it suggests something odd is implied but underspecified. I think any confident answer either way by AI is lacking in pedantry.
For some reason, I always found the arguments for "it's better to not know" for these tests to be strange and slightly infantilizing. But of course this must not be the end of it, and there might be some more well thought out arguments from bioethicists that go beyond "the patient can't handle the truth". Because this argument seems like it's doing a lot of heavy lifting without much evidence.
I think it's a mistake to believe that this money would exist if it was to be spent on these things. The existence of money is largely derived from society scale intention, excitement or urgency. These hospitals, machine shops, etc, could not manifest the same amount of money unless packaged as an exciting society scale project by a charismatic and credible character. But AI, as an aggregate, has this pull and there are a few clear investment channels in which to pour this money. The money didn't need to exist yesterday, it can be created by pulling a loan from (ultimately) the Fed.
the rebuke is that lack of chaos makes people feel more orderly and as if things are going better, but it doesn't increase your luck surface area, it just maximizes cozy vibes and self interested comfort.
My dynamic range of professional experience is high, dropout => waiter => found startup => acquirer => Google.
You're making an interesting point that I somewhat agree with from the perspective of someone was...clearly a little more feral than his surroundings in Google, and wildly succeeded and ultimately quietly failed because of it.
The important bit is "great man" theory doesn't solve lack of dynamism. It usually makes things worse. The people you read about in newspapers are pretty much as smart as you, for better or worse.
I actually disagreed with the Sergey thing along the same lines, it was being used as a parable for why it was okay to do ~nothing in year 3 and continue avoiding what we were supposed to ship in year 1, because only VPs outside my org and the design section in my org would care.
Not sure if all that rhymes or will make any sense to you at all. But I deeply respect the point you are communicating, and also mean to communicate that there's another just as strong lesson: one person isn't bright enough to pull that off, and the important bit there isn't "oh, he isn't special", it's that it makes you even more careful building organizations that maintain dynamism and creativity.
Yeah people seem to be pretty poor at judging the impact of 'key' people.
E.g. Steve Jobs was absolutely fundamental to the turn around of Apple. Will Brin have this level of incremental impact on the Goog/Alphabet of today? Nah.
The difference is: Apple had one "key person", Jobs, and yes the products he drove made the company successful. Now Jobs has gone I haven't seen anything new.
But if you look at Google, there isn't one key product. There are a whole pile of products that are best in class. Search (cringe, I know it's popular here to say Google search sucks and perhaps it does, but what search engine is far better?), YouTube, Maps, Android, Waymo, GMail, Deep Mind, the cloud infrastructure, translate, lens (OCR) and probably a lot of others I've forgotten. Don't forget Sheets and Docs, which while they have been replicated by Microsoft and others now were first done by Google. Some of them, like Maps, seem to have swapped entire teams - yet continued to be best in class. Predicting Google won't be at the forefront on the next advance seems perilous.
Maybe these products have key people as you call them, but the magic in Alphabet doesn't seem to be them. The magic seems to be Alphabet has some way to create / acquire these keep people. Or perhaps Alphabet just knows how to create top engineering teams that keep rolling along, even when the team members are replaced.
Apple produced one key person, Jobs. Alphabet seems to be a factory creating lots of key people moving products along. But as Google even manages to replace these key people (as they did for Maps) and still keep the product moving, I'm not sure they are the key to Googles success.
In Assistant having higher-ups spitting ideas and random thoughts ended up in people mistakenly assume that we really wanted to go/do that, meaning that chaos resulted in ill and cancelled projects.
The worst part was figuring what happened way too late. People were having trying to go for promo for a project that didn't launch. Many people got angry, some left, the product felt stale and leadership&management lost trust.
Isn’t that what the parent is describing? “Ill and cancelled projects” <==> “luck surface area”, and “trying to go for promotion” <==> “cozy vibes and self-interested comfort”?
It feels like we're doing another lift to a higher level of abstraction. Whereas we had "automatic programming" and "high level programming languages" free us from assembly, where higher level abstractions could be represented without the author having to know or care about the assembly (and it took decades for the switch to happen), we now once again get pulled up another layer.
We're in the midst of another abstraction level becoming the working layer - and that's not a small layer jump but a jump to a completely different plane. And I think once again, we'll benefit from getting tools that help us specify the high level concepts we intend, and ways to enforce that the generated code is correct - not necessarily fast or efficient but at least correct - same as compilers do. And this lift is happening on a much more accelerated timeline.
The problem of ensuring correctness of the generated code across all the layers we're now skipping is going to be the crux of how we manage to leverage LLM/agentic coding.
My point is that the chemical complexity (manufacturing uses) can be reproduced, and the energy storage density also can be. So really the gift of hydrocarbons under the ground is more that readily available energy is under our feet to help propel us towards higher levels sources of energy. IMO it’s a stepping stone and that’s effectively how humanity is using it.
The fact that as many engineers are on payroll doesn't mean that "cloud" is not an efficiency improvement. When things are easier and cheaper, people don't do less or buy less. They do more and buy more until they fill their capacity. The end result is the same number (or more) of engineers, but they deal with a higher level of abstraction and achieve more with the same headcount.
In this year of 2025, in December, I find it untenable for anyone to hold this position unless they have not yet given LLMs a good enough try. They're undeniably useful in software development, particularly on tasks that are amenable to structured software development methodologies. I've fixed countless bugs in a tiny fraction of the time, entirely accelerated by the use of LLM agents. I get the most reliable results simply making LLMs follow the "red test, green test" approach, where the LLM first creates a reproducer from a natural language explanation of the problem, and then cooks up a fix. This works extremely well and reliably in producing high quality results.
You're on the internet, you can make whatever claims you want. But even with no sources or experimental data, you can always add some rational logic to add weight to your claims.
> They're undeniably useful in software development
> I've fixed countless bugs in a tiny fraction of the time
> I get the most reliable results
> This works extremely well and reliably in producing high quality results.
If there's one common thing in comments that seems to be astroturfing for LLM usage, it's that they use lots of superlative adjectives in just one paragraphs.
You can chose to see it as astroturfing, or see it as people actually thinking the superlatives are appropriate.
To be honest, it makes no difference in my life if you believe or not what I'm saying. And from my perspective, it's just a bit astounding to read people's takes that are authoritatively claiming that LLMs are not useful for software development. It's like telling me over the phone that restaurant X doesn't have a pasta dish, while I'm sitting at restaurant X eating a pasta dish. It's just weird, but I understand that maybe you haven't gone to the resto in a while, or didn't see the menu item, or maybe you just have something against this restaurant for some weird reason.
X has a pasta dish is an easily verifiable factual claim. the pasta dish at X tastes good and is worth the money is a subjective claim, unverifiable without agreeing on a metric for taste and taking measurements. they are two very different kinds of disagreements
'It's $CURRENTYEAR' is just a cheap FOMO tactic. We've been hearing these anectodes for multiple current years now. Where is this less buggy software? Does it just happen to never reach users?
"high quality results".
Yeah, sure.
Then I wanted to check this high quality stuff by myself, it feels way worse than the overall experience in 2020. Or even 2024.
Go to docs, fast page load. Than blank, wait a full second, page loads again.
This does not feel like high quality. You think it does because LLM go brrrrrrrr, never complains, says your smart.
The resulting product is frustrating.
AI is increasing the capacity of existing employees and I think we're all still discovering, everyday, better ways to leverage it even more. So when the question comes of hiring a new teammate, the value they'd bring to the table needs to be convincingly more than what I can expect to achieve alone with AI.
I think the glut is ZIRP, but the lack of recovery (or very slow pickup) is AI.
As a counter anecdote, I've yet to try a model where I break even. The output is so untrustworthy that I need to spend as much time coaching and fixing as if I'd just written it myself. When it does produce a working result faster, I still end up with less confidence in it.
What I'm working on doesn't have much boilerplate, though, and I've only been programming for 18 years. Maybe I need to work for another 7 before it starts working for me.
There's definitely a method to using them well. It took me 6 months of trial, giving up, trying again, refining my approach, ... to eventually get fairly good results in a consistent manner. It's useful to know what the LLMs are good at and what type of errors they will do. It's also very useful to be a stickler about software engineering practices to keep the LLMs focused in the right direction.
Example stuff that helps:
- extensive test suites
- making LLMs use YAML for data-intensive files, instead of writing inline
- putting a lot of structural guard rails using type-systems, parse-dont-verify, ...
- having well scoped tasks
- giving the LLM tight self-serve feedback loops
Recently I made it fix many bugs in a PEG grammar and it worked really well at that. I made it turn a test suite from an extensive Go test array to a "golden file" approach. I made it create a search index for documentation and score the search quality using qualitative IR metrics, and then iterate until the metrics met a minimum standard.
Its effectiveness is going to depend on the domain and tech stack used.
You also need to know what chunks of AI output to keep and what to throw away.
For example, Gemini 'Fast' quickly identified a problem for me the other day, based on the stacktrace. But its proposed solution was crappy. So, I was happy with the quick diagnosis, but I fixed the code manually.
My rule on this is that you can only judge your coworker’s productivity never your own. People are horrible at judging their own productivity, and AI makes it really easy to just dump a bunch of work on someone else.
reply