In exchange, it also less secure, less user friendly, and less popular.

I guess this is trivially true if you say "maximalism" (hell, the maximalists think it will speed up as the AI becomes a super-AI-researcher), but as long as the rate of change is positive and not miniscule, it's hard to predict what 2035 looks like in software development.

These things are very hard to quantify, but making the progress that happened from Jan 2025-December 2025 repeat twice in 10 years would be enough for me to say I couldn't predict the day-to-day of a software engineer in 2035.

I don't think this is bad research, but you have to understand how far it generalizes. I'm not saying that evals are useless, we need to do our best to produce good benchmarks. But benchmarks are always going to lag pretty far behind real world applications.

I don't want to commit to a real opinion, but the cynic in me sees a bitter lesson you could take from this is that the database should default to a low isolation level--the damn developers aren't even using transactions right, so why waste performance handling transactions in the strictest possible way?

That shifting distribution would somewhat reduce the advantage of a college degree against the average member of the labor force.

This doesn't follow at all. Anthropic's revenue is growing 10x year over year selling tokens. Their tokens can be super magical, let them enter established industries and displace incumbents, and get 100% annual growth in those industries, and they would still be better off prioritizing selling tokens, because it's a great business.

What your argument shows is that there are limits. Their tokens are not quite powerful enough to make infinite money instantly in every area of software. Admittedly, that does seem true.

Of course, the truth is you can have too many middle managers or too few (it really was bad that in 2017, the biggest achievement was "growing headcount"). But fads have a tendency to overcorrect.

There are many theorems that aren't directly interesting, but whose proof requires techniques that are of substantial further interest, that lead to new domains, and/or new practical applications. Simply being handed a proof for those theorems isn't enough--we require the ability to apply those techniques in the real world, or discover further areas of mathematical research that build on that proof or its techniques.

It may be that AI can build on its own work for the long-term, but so far, AI does best at exploration in areas that have precisely specified and measurable goals. Actually creating understanding, and making use of mathemtical results outside of pure mathematics is more challenging than simply creating proofs.

I think the field will figure out how to make use of AI, and it will be better off for it. But that is not the same as just saying "answers good, grog want more answers."

I don't think Linux was plausibly going to remove the OOM killer in 2004 or later. So the right solution for Linux is very much to tweak it to be less painful.

There surely is something absurd about having to register specific processes as exempt from the OOM killer. But given that the OOM killer exists, and could kill xlock...how should that be fixed?

What do you mean by this? Most human white collar workers still have their jobs. I can't see the future, but yes, so far, human expertise is doing ok.

We'll see what happens in 2027, and 2028, and...

It's absolutely true that domain knowledge is incredibly useful, and developers aren't always great at gaining it. But there's also something about decomposing systems into their component parts, understanding algorithms, and knowing how code works that's also incredibly useful, even with agents in the picture. A really good developer needs both of those skills.

Take that example, of the generated shift that's illegal (by coincidence, I do freight optimization and work with examples like that in my day job). A domain expert will know the specific example is illegal. So they'll tell the agent to fix it. The agent will probably fix it for that case.

How does the domain expert then know that the agent has produced a thorough fix, as opposed to just that scenario? Not because the agent says so. So it is because they test it manually (but which cases)? Or because they review the strategy of the agent's tests, and know how the algorithms work, and know the edge cases that the tests need to cover? But they can't do that, by stipulation, because they're not experienced with code, they're just using the agent.

So yes, if the agent gets to the point where it can design robust software that avoids edge cases in a complex domain, doing complex operations and is thoroughly tested, and so on, then half of my skills are going to be irrelevant.

Out of the box, agents don't do that today. Perhaps they'll get to that point, but until then, your knowledge of where to put a semicolon has become less useful, but your ability to specify and test processes precisely has not.

But yeah, knowing your domain well is a damn good idea.

I cannot express how annoyed I am a researcher could use such a shitty definition.

It only makes sense to say "most" if you have a clear idea of what constitutes the majority. "Most people are male" yeah, fine..50% + epsilon of humans are males. That's more or less decidable (maybe a little vague because of intersex folks). I believe it's false because there are slightly more females but it's obviously measurable.

Now, most cognitive labor...what does that mean? Is it most of the time? Most of the tasks? Most of the value? Most of the job descriptions?

If I am a developer, and the majority of my code is written by AI, but I'm still in the driver's seat, is that most of my cognitive labor? Probably not. Ok, what if my company fires 60% of its developers, does that mean most development cognitive labor is automated? Well, it's most of the expense, and most of the butt in chair time, and it's most of the individual jobs, but it's not most of the job descriptions.

Of course, there's no way that all these researchers making pronouncements are giving consistent answers to what they mean by "most". They're probably not using his phrasing either.

Edit: The four options I threw out above: time, tasks, value, job descriptions are each interesting in their own way. My point is not that they're bad questions to be asking, it's that they're all separate questions that matter in different ways.

Comments URL: https://news.ycombinator.com/item?id=48298078

Points: 6

# Comments: 3

A majority of academics will simply and without hesitation, offer their students and collaborators pirated versions of their own work, because they value knowledge.

Commercial authors may feel differently.

[0] I'm a former Ph.D. student, but my attitude was the same both within and outside of the academic world.