jerf

I've spent most of the past two weeks trying to get my AI to stop writing so goddamned much code. It's great that I can, say, completely switch between two databases, but I wish the AIs would develop a concept of energy spend or something and spend maybe a moment checking whether something is already implemented in the code base before blasting out 2000 new lines defining a new database access layer, and also rewriting random code it shouldn't be touching for some task hundreds of lines at a time just because it can. I don't care how easy it is to write some tests that sort of kind of cover it hopefully maybe... no new code is as tested as the stuff that has been doing it in the field for years already.

Just because it has the power doesn't mean it should be used.

I'm not asking for everything to be some sort of beautiful code whose concision would lead Knuth to tears. I'm just asking that you not slather dozens of existing functions with three new parameters and dozens of lines of code each that basically do nothing, to cover a use case that I accidentally vaguely alluded to, if you read my prompt a certain way, but isn't really what I was interested in.

According to my friendly neighborhood AI there is no commonly accepted term for this effect, but when you have a community of people that is heavily selected for a particular characteristic you will end up with people that generally are outliers in some other significant ways too. In this case, caring deeply about email security is weird... unfortunately... and you can expect further weirdness from such people.

You can also read about people talking about this in the super-early computer user communities. When you had to be a bit crazy to even be interested in computers you ended up with people who were outliers in a lot of other ways too. As more people came in to the space it would regress to the mean... this is one of the things that "regression to the mean" can be regressing from.

"His ultimate message for the team was to “stop lovingly handcrafting all our code and use AI more.”"

Mmmmm... I think I may have to score this particular point for the CEO. Lovingly handcrafted code has been many things over the past 30 years, but "secure" is not one of the adjectives I'd apply to it. Anyone who thinks that the lovingly handcrafted code has always just been wonderfully secure needs to check the tint on their glasses.

A proper AI setup probably can produce more secure code more quickly than conventional development processes... however one of the keys will be to understand that yes, that will still be slower than writing code that is not rather carefully analyzed for security and a company like Proton had better have a strong commitment to never, ever skipping that step because it's slowing them down or it got expensive. "Proper" in "proper AI setup" is the most important word.

But that's not to say that I'm endorsing everything else he said. Even if it is true that companies will be able to stop hiring engineers, which at the moment I seriously doubt [1], a company like Proton should expect to be one of the last companies who can do that, not be getting publicly excited about it first. Hey we dumped all our engineers because our managers can just prompt our AIs just as well here in October 2026 would definitely be a "instantly cancel any Proton services I had" signal for me.

[1]: One of the things I don't expect to change is that there are plenty of people I would describe my actual day-to-day work to and they would consider it a living hell if they had to do it. I still quite enjoy it overall. And there are plenty of jobs that other people love and I would consider a living hell. Even in 25 years that's going to be the case. There will be people willing to put up with the process of working with the system to create this stuff... but the people who are willing to be professional about this, do the QA, do the work beyond the first fun prompts, is going to be a minority, and an even smaller minority who take the time to get good at it. There will always be people who are better and people who are worse.

Yes, there is.

It's called a Nintendo emulator.

That's kind of the point here.

Code isn't going anywhere. It can be literally billions or trillions of times more efficient than an AI, and as AIs scale up that number just continues to grow and can completely plausibly hit quadrillions in our lifetime. What relationships humans have with code is a completely different question, but the idea itself isn't going anywhere. Anyone who thinks otherwise has failed to grasp just what producing a single token from an AI actually entails.

Privatizing the losses doesn't mean the rest of us are going to escape without a scratch. It just means that we let fail the things that are going to fail.

What makes this so politically unpalatable is that having constantly bailed out the last few cycles, everyone is now operating on the assumption that they will be bailed out, so many entities who in a more perfect world would know better have done a lot of stupid things, like pensions that have a lot of bonds that will go bad if the AI bubble collapses.

Frankly we're looking at massive problems and upheaval at this point no matter what we do. But the advantage of not socializing the losses is that the signals of what needs to be changed go directly into the economy. Socializing the losses means that the signals get muted, confused, and mangled and people in the future end up doing the wrong things as a result.

Unfortunately, at this point I think the choice is between people clearly and forthrightly losing massive portions of their retirement as visible losses, or people deceptively losing massive portions of their retirement as the bailout creates massive inflation and their retirement is inflated until it has a fairly similar amount of losses. Unfortunately, it is a feature for the rulers that the bailouts obscure the losses and dampen the correct apportionment of blame, even as it destroys the underlying economy. Giving people clear, correct targets for their rage, the same process of correct pain apportionment the economy needs to become healthy again, would point people at the "wrong" clear, correct targets, and the clear, correct targets are the ones deciding whether or not a bailout occurs. Not just the literal lawmakers nominally making the call, but the entire system that makes the decision.

So plan on bailouts.

Yes, there are huge national security concerns when everybody's cars are always on the network and all fly-by-wire. It would be trivial for anyone who writes the software for these things to include logic or network bombs in them that would enable a catastrophic strike on a country or the rest of the world. Cars being on the network all the time is really a terrifically stupid idea.

Careful readers may note the complete lack of the word "China" in the previous paragraph. But, yes, technically it is even that much more dangerous to have a whole bunch of potentially-hackable robots roaming up and down all your transportation corridors that were also created by your major economic and military rival.

But I don't even like it when it isn't created by your rival, though, because there's no guarantee that your rival can't hack anybody's software. I fear the day when some significant fraction of cars on the road are given instructions to floor the pedal and then do a hard turn to the left 10 seconds later. (Or the right for countries where that is the "turn into oncoming traffic" direction.)

Interesting. I did not know that. (Obviously.)

There are a number of environments and languages that have the capability to reload things extensively at runtime. elisp is mostly nice because it is polished, but it isn't necessarily the "best". Erlang has a claim on being better at it, probably. And while most scripting languages are capable of it, that doesn't mean you can just drop one in and go necessarily. It helps to have an environment where that sort of interactivity is first-class and in constant use and testing, which is where the polish comes from.

First, "if one of the many many many different solutions aren't adequate for some reason" was there for a reason.

Second, no, it isn't. Pypy is really fast compared to Python. "Compared to Python" is just about the lowest bar there is, though. In absolute terms it is still only a medium-fast language runtime, and it comes with a lot of costs and tradeoffs.

That's the problem with Python. Lots of ways to take a very slow language and make it a medium-fast language with substantial tradeoffs, or make it a fast language with enormous tradeoffs. If you can handle the tradeoffs, fine. But if you can't you just need to switch to a language that is fast without anywhere near as many tradeoffs.

Write down the definition of a token. Write down the definition of a stock. If you look at them carefully you'll at least see a lot of overlap. For bonus points, write down not the actual definition of a token but the definition of a token its advocates want you to use; it is particularly this one that in my opinion is already what a share of stock is.

I can say you need to be careful. It sounds like you've written in to the definition of a "token" that it is "meaningless", and that is a philosophical overreach, not an accurate statement. As the reply chain correctly tried to point out, nothing stops the same process that turns your abstract, "meaningless" number that represents your shares of stock into a meaningful number from being applied to a block chain token. Our entire economy is made from top to bottom out of "meaningless" things given meaning by convention, law, and other forces. Getting too reductionistic leaves you confused about not just tokens but a lot of things.

And on the flip side, if you actually dig in to what a "share of stock" that "you" "own" is, it is already not "some fractional ownership that carries legal rights and a claim on assets" and is already more complicated, abstract, and partial than you think. Just as the token advocates want you to think of a token as something more than it is, the stock system is not in a hurry for you to understand what it is you actually hold, but it certainly is not simply some fractional ownership in the simple way you probably have in mind, and there are more exceptions and caveats and legal ways you don't really own it as much as you think already in the system. It's already more a mere "token", in the sense you originally meant, then you realize.

Stocks are already tokens. "Tokenizing" stocks makes no sense, if one assumes quite reasonably that "tokenization" involves giving token-ness to something that was not already a token. What it is is wrapping what is already a token in another token, mostly so the second token can get around the limitations of the first. But some of those limitations are incidental and can be eliminated at any time by the underlying token provider, mostly because nothing stops a conventional stock market from being tradeable 24/7. They already are if you're in the club anyhow, per all the "aftermarket" and "pre-market" trading you hear about around quarterly release times.

The rest of the limitations are regulatory, and if the wrapping token can get access to regulatory approval to do their thing, so can the stocks.

The whole thing feels skeevy as all get out to me. It feels like someone telling me that they'll be happy to hold my mortgage between me and the current holder. There is no good reason for that. Frankly there is already a disturbing amount of indirection in the way you don't actually own the stocks you think you do, but they're held on behalf of you on behalf of your broker at the Depository Trust & Clearing Corporation. Adding another layer of indirection makes me worry about the motives of the people who are very excited about being that layer.

It also hung on for some time past when it made sense. My father had a 486/33MHz that had a "turbo" button. Turning off turbo could slow the clock down but it wouldn't do anything about the fact that the 486 is still fundamentally a better processor than either the 386 or the 286, running 2-3 times faster on the same instruction stream than a 386. So even with turbo off, the programs that was nominally supposed to help with still ran much faster than they were supposed to.

Prediction markets say they don't take positions.

The idealized form of a prediction market doesn't take positions.

This is a long, long, long way from "prediction markets don't take positions".

Plus they don't have to in order to create the effects I'm talking about. We've already seen plenty of what people are calling "insider trading", though it may not legally match the usual meaning of the term. All that is necessary is that it becomes clear over time that making bets is a sucker's game because the events aren't just ambiently happening but being forced by somebody with a lot of money to make. It isn't particularly important whether those bets are made by people who directly work for the prediction market itself.