I'm not stating this as a fact, but it's a hypothesis I'm keeping in my mix.

This is no longer anywhere near as important as it used to be because HTML5 defines a method for turning more-or-less any sequence of bytes into the same DOM tree: https://dev.w3.org/html5/spec-LC/parsing.html And that's only the beginning of the process. I can't seem to find a good link to the whole 8.2 section of the HTML5 spec but the whole process is freaking huge. But it's defined now.

I hedge on the "more-or-less" because I'm sure there are still bugs in various parsers and perhaps there are pathological sequences that wouldn't be handled by this process, but such sequences would be very, very distant from being HTML at all. But one difference with HTML5 is that the parsers would be considered buggy; in previous versions it could be debatable what the parser should do. HTML5 should fully specify that. If it doesn't that is now a bug in the spec. I would hope it has been banged on enough at this point that any possible remaining corner cases must be pretty small by now.

It is in my considered opinion perfectly sensible to define "HTML" as "what comes out of the HTML5 parsing process" and not really be all that worried about whether this tag does or does not need to be closed before this set of tags but not this other set of tags. It is no longer such an invitation to the browsers to render things completely differently. What was once an academic concern and a user-experience concern is now largely an academic concern.

In fact, if you're handling HTML5 correctly, which is to say, using a real, conformant parser to operate on the resulting parse tree rather than trying to handle it as a string... you can't even tell the difference between "valid" and "invalid" HTML anymore! The parser will wipe that away entirely before the HTML gets to your code. That's how important it is now.

How many of them source to real humans, though... who can tell anymore.

That number is certainly non-zero, though. To a first approximation every stupid thing you can imagine happens. But it may not happen as much as the bot engagement army makes you think it does.

(I haven't had the opportunity to throw a current-gen frontier model at a concurrent problem because I haven't had one to try out lately. The best concurrency is no concurrency and the second-best concurrency is the "web request" model where many web requests are nominally running concurrently but they are otherwise fully isolated from each other and not trying to communicate at all. So maybe they're better, but I feel like if they were a lot better somebody would have noted that in a place I'd have seen by now.)

"A novice was trying to fix a broken Lisp machine by turning the power off and on.

"Knight[, one of the principle designers of the Lisp machine], seeing what the student was doing, spoke sternly: 'You cannot fix a machine by just power-cycling it with no understanding of what is going wrong.'

"Knight turned the machine off and on.

"The machine worked."

I feel like AI is manifesting this even more concretely. I don't feel like I'm guiding the AI super intensely as I work on it with software engineering. I'd have a hard time pointing you at where in the prompt my decades of experience are manifesting. But I definitely can have better results, even with a less frontier-level AI, than people who don't know the same amount of stuff.

Terence Tao also released some unedited transcripts of some of his conversations with AI, and many people observed that while many mathematicians may have been able to formulate the initial question, very few people could have given the same feedback to the AI.

Perhaps someday AI will eliminate the need for competence to use it properly. But that day is not today. And to be honest, that tech is probably not LLMs, no matter how large they get. Some other breakthrough will be necessary to truly eliminate the human element. Those psychopathic elites making plans to turn Earth into one of the Spacer worlds from Asimov's works with a small elite population supported entirely with robots take notes... it's not possible yet.

If you want to see something that could potentially impact Raft's correctness, search the last couple of days of the HN front page for choreographic languages [1]. But none of these are even remotely mainstream enough to depend on for anything. Nor do I know if anyone in these languages has implemented Raft. A rather good test case for them, if any of them are looking. That's something that could actually help a Raft implementation's correctness, not just fiddle around the edges of local concurrency issues.

[1]: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

errcheck, generally as manifested in golangci-lint, ensures you can't forget to do something with them. It would be odd for you to know about forbidigo but not errcheck as the former is much less widely known; is there something that errcheck doesn't do for you?

It's worth pointing out that "discard this error on purpose" is a legitimate form of error handling, so "enforce error handling" can't really constitute banning that. That's not a Go statement, that's just true in general... it is sometimes valid to just ignore the error, because there's nothing useful to do with it anyhow. I would agree the ignoring should be explicit, but it is an option.

And that's not the sum total of ways that the measure can fail... that's a unique way that comes into being because of the intelligence of the LLMs and other future AIs. All the normal ones are in play too, and perhaps other unique ones as well.

"Gaming" even adds a bit of an adversarialness to the process that isn't necessarily present. Plenty of measures end up "gamed" through perfectly natural attempts to maximize the measure. Someone can be perfectly honestly optimizing for "conversion rate" and not notice that they raised it by lowering the initiation rate more than they lowered the conclusion rate. "But I could account for that by measuring..." would miss the point. There is always a divergence, it only gets more subtle.

This of course also is rather glossing over the difficulty of even defining "ethical" to begin with. Some of what Silicon Valley goes to great efforts to train into their models I consider deeply unethical. Who is right? That isn't going to be answered with "whoever is the most ethical", not even in principle.

Expanding the question because it's the same answer for all of them: The relatively steady exponential progress of transistors murdered all the competition. Nobody had any time to think about anything else when 18 months from now the transistors would be twice as fast and cheaper at the same time. It also meant a technology had to pretty much come out of the gate already better than transistors which had been through numerous doublings. It doesn't matter if you produced something that could hypothetically double every three months for ten years if it started out a hundred times slower and a thousand times more expensive than the transistors at release day. It couldn't survive long enough in the market to get funded long enough to develop that far.

It's only now that you can really get going on some alternative... and it still kind of sucks that even so you need to produce something out of the lab that beats transistors on some relevant metric right now if you want to get anywhere. Trillions of dollars of investment into transistors is hard for any tech to overcome, even if hypothetically in 10 years it could spank transistors somehow.

But the simple truth is 100 programmers with AI are going to do a lot more work than 1 or 2 programmers with AI. All the usual considerations for communication overhead and all the old reasons why 100 programmers aren't necessarily 100 times as productive as 1 are in play... but so are all the reasons why that group of 100 programmers is going to outdo that 1 no matter how hard that 1 works.

We are probably in roughly the middle phase of the time period when we're still learning to harness AIs at all, and seeing simply some modest accelerations of process. Eventually we're going to progress to getting significantly enhanced productivity from them for pretty much everybody. And then what will happen is not that the SaaS market crashes, but what constitutes an entry-level SaaS product will rise up to meet the increased programming firepower. Find me a SaaS whose current two-year roadmap is "Eh, don't do anything, really, we're set" and I'll show you the SaaS company who probably ought to be really, really worried about AI eliminating their entire niche. I'm sure there are some out there, but it's not the usual SaaS company experience.

I would not want to be a SaaS that offers some really simple service that can be replicated in a heartbeat, though. Something like "how do I pay people all over the world" is already very complicated, and over the next decades as governments start writing laws with the understanding that AIs can implement them in code no matter how complicated they are, it's likely these problems will become even more complicated and even more important to just buy a service that can deal with them. (I'm not celebrating that, merely predicting it.) But I sure wouldn't want to be selling some super simple scheduled reminder service or something else really small.

In the worst case, envision a world where home owner associations or townships or whatever other local governmental division of just perhaps a few hundred people start levying sales taxes, with their own complicated exclusions and offsets and conditions, because LLMs make it possible to handle the code for all of the literally hundreds of thousands or millions of such jurisdictions. Even if you can throw tokens at that problem to solve it yourself, you probably don't want to. And again... I'm not celebrating that. More a world-weary bowing to the inevitable despite it being an obviously bad idea.

I see some people with the idea that businesses are going to use AI to solve everything in their own one-off bespoke manners for everything, but I don't think it's going to happen. What's going to happen is that the SaaS providers are going to get even better at making yet more stuff go away than they were before and it'll actually be harder for a business to replicate it themselves then it used to be.

(Of course the "go away" isn't perfect, but clearly, neither is the idea that solving everything yourself with AI is either.)

In this case though I don't just mean that the agent is good at coding. I mean the entire agent becoming action-biased because of all the training it is doing on the software development benchmarks, which I assume will either fail or be penalized for stopping and asking the user for something rather than just finishing the job. That won't just train the agent to blunder forward in coding, it'll bleed over into a bias towards blundering forward in general.

Sooner or later they're really going to have to split out the general models from the coding models. The latter may just be a special fine-tune of the former, as there are good reasons for the coding model to have a broad knowledge base, but the pressures of being a good coding model are going to pull against the characteristics of being a good general model. The open models obviously already are doing this, I'm referring to the frontier models here.

Since the author seems genuinely baffled, the answer is "because they are just bad people". They're bad people, nothing we can do will fix that they are bad people, it's so their fault, so there's no need to consider incentive structures or anything like that. They're just going to have to be better people and the things providing bad incentives have no fault or responsibility for the bad behavior and/or bad outcomes.

The sad and ugly truth is that there's is a certain amount of that in play in the real world. However if I could only pick one of the two extremes, "it's all incentives" works be the more productive one. It's not the whole truth but I do think it is substantially closer than the other extreme.

Based on the trends, I expect it is only the first of several I will see.

I mean, I'm phrasing that in marketing terms, but in this case it's in harmony with what your users want anyhow. We want to know ASAP why we should care about this language. So it works for everyone. Of course when it comes time to deliver the promise, normal programming language documentation is the way it is for a reason.