This seems to be that there's just so many degrees of freedom, that there's a pretty reasonable chance on any day that you're in a situation where nobody has been before. Or as PG put it once, my job is to think thoughts nobody has ever had before.
That being said, that doesn't mean the majority of the situations you're in are completely novel, just that there's a reasonable chance of at least one occuring.
You're not wrong, but something can work well enough to still be useful despite falling short of the idea of a proof or any formal definition.
Let's say that 95% of individual humans can pass it and only 2% of bots. For someone maintaining a website, who has to decide between using this system and shutting down their site because of the increased costs, that may very well be good enough
That’s a pragmatic and understandable argument. And for an individual hobbyist site owner, that’s fine. Are we okay with excluding 1 person in 20 from the services of a midsized organization? What if they’re integral to the workplace? Or a major transport provider without differentiated competitors? What if the organization is a state government?
The culture of magic (and nerd-dom in general) has definitely changed, I won't argue that. But when you use an example like this, it kinda undercuts your entire point.
I don't think you're committing career suicide. I've seen people get serviceable results out of it, and it always involves reading the code in depth. Reading the code being slower than writing it, they're almost never getting a speed up.
That being said, the better coders I've seen aren't looking for a speed up, they're generally looking for something to bounce ideas off of, or to get a first draft going to defeat writer's block or something (I guess this is technically a speed up, but not the way people mean when they describe slinging tokens around). It's generally to wind up at a better solution at the end than to get a sustained speed up (which seems to only be possible in boilerplate heavy domains, but those were previously slowed down by the boilerplate and are really only coming up to speed with everything else, at significant cost).
Their post said that load growth had a mitigating effect on prices. Not letting the data centers come online would, presumably, result in higher prices.
That seems slightly weird, but that sounds like there's some large fixed costs that they can spread over the entire subscriber base, so the extra data centers are picking up some of those fixed costs.
Agreed that in some situations, on some US electric grids (ISOs/TSOs), data centers are absorbing their electrical supply costs that would otherwise be externalities. This is good, I fully support this. This is not uniform unfortunately, and remains to be solved for in totality imho. I take no issue if we get to a point where the AI bubble pops and we're left with net new electrical infrastructure that continues to provide benefit decades into the future while the data centers sit silent (similar to the "fiber boom bust glut" at the turn of the century). I take issue with the AI bubble costs being pushed citizens already, broadly speaking, unable to make ends meet merely out of a desire to speculate (and no one can be sure how long this exuberance and hype cycle is going to last; as long as it lasts, humans who need electricity at a reasonable cost are at risk).
TLDR Humans need electricity to live, data center loads are a luxury that can wait for power to be provided, when available.
With junior programmers I typically just look for high level patterns that are commonly wrong. Sure if they are touching our cross thread communications code I need to spend a lot of time on that because it is so complex nobody gets it right - but we only have a tiny amount of that and most people look at it and run the opposite way (even me - I wrote it but I still do my best not to touch it when I can avoid it - that is hard hard hard)
> Let's not pretend Microsoft has a monopoly on idiocy in the software world.
Entirely fair, but let's not pretend the situation is symmetrical. Canonical doesn't have monopoly on the linux or broader *nix world the same way that Microsoft has on the Windows world.
This is BS. A shareholder lawsuit against the CEO/board/executives for investing in the employees in the hope of long term profits would never succeed. The idea of a fiduciary duty doesn't mean that. It means the CEO can't take actions that intentionally hurt the company.
And there are very few large public companies with active enough investors to oust a CEO over this, and even fewer that have both active and activist investors that would be interested in such a thing.
You'd have to prove that the CEO knew that it would hurt the company and still did it or that it's so ridiculously negligent that any sane person should have known.
> My "actual job" isn't to write code, but to solve problems.
Yes, and there's often a benefit to having a human have an understanding of the concrete details of the system when you're trying to solve problems.
> That has increasingly shifted to "just" reviewing code
It takes longer to read code than to write code if you're trying to get the same level of understanding. You're gaining time by building up an understanding deficit. That works for a while, but at some point you have to go burn the time to understand it.
It's like any other muscle, if you don't exercise it, you will lose it.
It's important that when you solve problems by writing code, you go through all the use cases of your solution. In my experience, just reading the code given by someone else (either a human or machine) is not enough and you end up evaluating perhaps the main use cases and the style. Most of the times you will find gaps while writing the code yourself.
> often a benefit to having a human have an understanding of the concrete details of the system
Further elaborating from my experience.
1. I think we're in the early stages, where agents are useful because we still know enough to coach well - knowledge inertia.
2. I routinely make the mistake of allowing too much autonomy, and will have to spend time cleaning up poor design choices that were either inserted by the agent, or were forced upon it because I had lost lock on the implementation details (usually both in a causal loop!)
I just have a policy of moving slowly and carefully now through the critical code, vs letting the agent steer. They have overindexed on passing tests and "clean code", producing things that cause subtle errors time and time again in a large codebase.
> burn the time to understand it.
It seems to me to be self-evident that writing produces better understanding than reading. In fact, when I would try to understand a difficult codebase, it often meant that probing+rewriting produced a better understanding than reading, even if those changes were never kept.
> It takes longer to read code than to write code if you're trying to get the same level of understanding. You're gaining time by building up an understanding deficit. That works for a while, but at some point you have to go burn the time to understand it.
This is true whether an AI wrote the code or a co-worker, except the AI is always on hand to answer detailed questions about the code, do detailed analysis, and run extensive tests to validate assumptions.
It is very rarely productive any more to dig into low level code manually.
That being said, that doesn't mean the majority of the situations you're in are completely novel, just that there's a reasonable chance of at least one occuring.
reply