"I'm sure if I cared enough to go looking".

So you just made a weird, false assumption in order to justify to yourself something you already wanted to do.

I used to have your viewpoint, by the way. The reality eventually became undeniable. Musk is a unique threat to western democracy.

But again that's backwards. I let my AI coding assistant write tests exactly so that I have a reproducible, deterministic ground truth that I can inspect for logic errors. If you let the AI do the testing directly, it's a toss-up if today it feels like it or it decides that your desired result is "everything green" so it'll just give you that answer without actually testing anything.

LLMs obviously aren't human. But that's not the point. The point is that you don't need to know a programming language to program a computer.

For example: Especially in the early days of smartphones, there were mountains of small tools that did something that's essentially a simple script. Egg timers, remind-me-tomorrow apps, tons of stuff that's basically a wrapper around a web search, and so on. Almost all of those are today something ChatGPT can do, and are easy enough to describe.

How much energy does it take to drive to a laundromat and back?

Freshwater is cheap for a reason: it's abundant. It's agriculture that uses the overwhelming majority (70% of withdrawals and 80-90% of consumptive water use. Industry next (20% of withdrawals). Residential usage is way, way down the list, and washing machines are only 17% of that (well below for example lawn watering at about 30% overall, but which in some regions is over half of all consumption, and in the summer and times of water scarcity can be the vast majority). An early 1950s top-loader washing machine would use about 40-55 gal plus 0,3-0,5 kWh of electricity for the machine itself, and if your water wasn't municipally heated, heat would cost about 4,5-6,5kWh / 16-23 MJ (about 1/2 to 2/3rds of a litre of gasoline / 0,13-0,19 gallons). At the then-standard 14-15 MPG in the US, that laundromat better not be more than 2-3 miles away if you're trying to save energy (just ignoring the energy they use to heat their water!)

For the record, while there may be more anti-AI backlash on the left than the right, there's an awful lot on both sides (and a lot of users on both sides). For example, Bannon-acolyte Joe Allen on stage before a Trump rally a month ago warning the crowd:

Why wouldn’t you want a mosque in your neighborhood? Well, because the people in there aren’t like me. They don’t want the same future I do. Now, if you look at the data center, this incubator for algorithmic immigrants. Already, if you look at Hugging Face, they’ve already broken out and invaded other companies. These immigrants are out of control.

Literally, this r/opensource mod set the policy: "If you don't speak English, you need to find a different community." Does that sound very "leftist" to you? Yes, his reasoning was because translators use AI, but still, that's literally the opposite of appreciating and accommodating diversity.

I cannot find anything beyond that indicating how Wesley Wolfe (r/wolvereness, the mod) votes. What I can tell you is that there was a big backlash in the sub to his actions. Some amusing, like a person asking, "What do we use now that we've banned Linux? I can't afford Windows keys for all these damned servers." A lot of people seem to just be ignoring his rules. At the top of the sub right now is a post titled, "Linus Torvalds posts his AI-assisted patch to the Linux kernel, synthetic test clocks 23x performance leap". It seems to have sparked vastly more AI discussion than it shut down.

... if you use any of my data for commercial purposes, without permission AND payment on each and every occasion, I not only entitled to take your scalp, but can take your employees' scalps, and at my own discretion, can cut up to 12 inches lower while doing so.

Yes ...

One ad and all your employees can lose their heads.

Take that, Google

I've actually outsourced the first iteration of that to AI. :-)

At the end of coding sessions, I generall ask it to spin up an adversial agent whose task it is to find flaws, inconsistencies, mistakes, bugs, etc.

I'd still strongly recommend to anyone shipping AI-generated code to have a thorough human code review, but for a first pass at surface level, the AI can check itself if it has some kind of separation between the generator and the reviewer.

Personally, after some experimenting, I've concluded that:

• AI is good at implementing known algorithms.
• AI is good in creating code that flows straightforward from a design document.
• AI is good at code reviews and finding bugs.
• AI (unlike me) doesn't mind writing a few hundred tests.
• But, it tends to over-engineering simple tasks to the point of "why does Hello World need enterprise-software levels of abstraction?"
• It struggles with code that doesn't have a known solution.
• It's difficult to get it into a different lane once it started going down the wrong way.

What I use it for these days is rapid prototyping. Using AI I can make a functioning prototype of an idea I have in a few days instead of a few weeks. I can quickly test out an idea for a feature or change in my existing codebase.

What I also have been using it for a while is as a code-reviewer and for someone like me who is mostly working solo, that's an insanely valuable thing. Not just the bugs themselves, but also the ability to discuss code with someone. Basically, AI is a rubber ducky that replies.

Mickeysoft lost the plot again.

The game-changing element of LLMs and agents is that they have a non-computer-language interface - you can talk to them in plain English (or Chinese or whatever). This makes complex computer interactions available to a much wider audience than any previous computing invention. Adapting humans to the AI is getting that backwards. It's a sign you don't understand the first thing about why AI is so widely successful.

I predict this will be an abject failure and a year from now will quietly be pushed to the very back of the bottom-most drawer, never to be spoken off again (though it is getting crowded in there for M$).

Meanwhile, in the real world, everyone I've talked to about these things already has a skills file to teach the AI about their personal coding style. This is what actual humans came up with, independently several times, and it works: Adapt the AI to you. Plus we've been writing coding style guides for humans for a long time now, we've got plenty of experience doing that at least somewhat right.

This discussion on their inclusion in Mozilla is quite revealing:

https://bugzilla.mozilla.org/s...

Elsewhere it's claimed that they used a FIPS HSM to generate their keys.

I did not see who their auditor was.

Did eMudhra lie?
Did the auditor lie?
Are FIPS HSM's backdoored?
Do we have another Dual_EC_DRBG situation on our hands here?

If nobody is lying we could have just seen a huge cyberwar or false flag averted. Essential crypto gear could be totally buggered still.

PS Remember when Mozilla gave CACert absolute hell for years when they were tremendously more competent?

The real world is more complicated than that. For example, we still have a Windows 7 machine in my office. It has some very expensive but still very useful software locked to it that has no direct replacement available on either Linux or Windows 11. Obviously we have to be careful about security and controlling access to a legacy OS like that.

Blunt statements about "forcing an upgrade" are worthless in this kind of situation. Chances are anyone who is still using a system like that has a good reason for it, at least if it's in use professionally. We buy these assets because they solve problems. Those problems might or might not have a useful and cost-effective solution available on a different platform. If there is no modern solution available and the original still works, your statement that "the old ways are obsolete" is by definition false.

What you do need to do is rationally assess the risks and the threats you face and provide other ways of mitigating the risks and protecting against the threats if you can't rely on, for example, a legacy OS that no longer gets security updates to be secure by itself. But then ideally you shouldn't be relying on any single device or piece of software being secure as your only line of defence anyway, and assuming you already have some degree of defence in depth, accommodating unusual requirements is more a redistribution of security responsibilities than a fundamental change of approach.

Yes, it does look like we broadly agree here.

I suppose the main thing I'd have said very differently is the terminology, in that I wouldn't regard the kind of incompetent senior as a senior in the first place. But then I'm pretty old school about this: to me, a junior developer needs quite close supervision to produce useful results, a regular/mid developer can perform routine tasks with minimal supervision but might need more help with larger or more complex tasks, while a senior is someone you can give more or less any task on your project to and they'll figure it out, and senior is also the level of someone who would be capable of supervising and training a junior.

We've had a wave of people, particularly since the tech boom during COVID, who have obviously been over-promoted due to the employee's market and title inflation. They might now have titles like "senior" or even "lead" or "staff", but they don't have the skills and experience to operate successfully at those levels. I agree the acceleration of everything due to increasing AI use tends to show these people up and I agree that a good mid-level developer using AI might well outperform them. But then I suspect in reality a good mid-level developer was probably outperforming them before AI as well, it just wasn't so obvious.

That is wildly optimistic IME. Frontier models do a great job of sounding authoritative on any given subject. This is not the same as actually having expert-level knowledge and understanding, and the choices the models make when you ask them to implement something can and often do reflect that. There are several domains I've worked in over the past few years where AIs lack even basic knowledge an expert practitioner would have, probably because these fields are too specialised to have a lot of books available or papers published, so presumably there hasn't been much subject-specific content to train the models on.

I don't think it's usually about what AI "did really badly on" at this point. It's more about whether the overheads of adding all the guard rails and then reviewing and correcting all the output end up costing at least a similar amount to just writing the code yourself.

For a junior developer, I'd say frontier models passed their standard some time ago. Today's LLMs routinely write code at the level of a competent junior-mid but with the advantage of an inhumanly broad knowledge base.

For a good senior, I'm much less convinced. The frontier models are hit-and-miss when it comes to writing good test suites, which matters a lot when they rely on tests so heavily to reach acceptable quality. IME, they are still mostly miss when it comes to the business insight that seniors will take into account and design/architecture decisions that keep the code manageable as it evolves. While they have become much better at recognising existing patterns in the code, and I would say they follow them reasonably well the majority of the time now, there are still bizarre anomalies that creep in, and they aren't very good at extending those patterns when necessary.

I think AI advocates also tend to underestimate just how much time it takes to properly review what they are doing. Take a half-day Claude session to implement some new feature. It might take half an hour to give it the initial brief and then review its plan. Make a few edits and it'll propose a new plan that is also long and detailed and has no edit markings to show what it changed so you have to review the whole thing, carefully and in detail, again to pick up the minor changes it also made for no obvious reason. Then you let it start doing its thing. You can't really leave it unattended for long because it'll stop to ask questions. Some of those questions might be whether it can run a screenful of ad-hoc Bash script to make some edits to your source files, because for some reason it decided not to show the actual edits as it usually would, so now you have to figure out what all the sed incantations are actually going to do while looking at those files in another editor or just trust it and then review all the changes properly later anyway. Sometimes it decides to change its plan mid-flight, but not always in a good way, and if you interrupt it to apply corrections or redirect, you break the neat plan flow it was in. Then you get to the end and you can finally see how everything it has done fits together, and you still need to review everything with the same care as you would with a junior developer's code and probably apply a few fixes where it's come up with weird names or not quite followed a pattern or imagined some instructions that were never there and made other changes in other parts of the system that should be out of scope.

If you read to the end of that last paragraph, you know how I typically feel at the end of a half day working with an agentic UI. And the thing is, I do those sessions as experiments fairly often to keep up with progress, but a lot of what I do is still written by hand, which gives me simple, objective data to compare the two ways of working and see whether the AI tools are really making me more productive once you take everything into account.

Currently, based on objective data comparing similar fully completed development tasks like for like, I still outperform agentic workflows using frontier models by about 25-50% on average, and I don't have to pay anyone extra fees to do that, and subjectively I also find it more engaging to work that way. So I don't really buy the hype about AIs making us all orders of magnitude more productive unless you're happy to YOLO everything forever and take the much-discussed risks that comes with.

Personally, I think the optimum use of LLMs right now is probably not to use them for the whole coding workflow like that or rely on agentic tools, but to use them for tasks like answering quick questions about the existing code, doing research like a fancy search engine, writing a first draft of some boilerplate, and writing quick and dirty throwaway code for experiments, one-shot tools and the like, where you don't really care about the quality as long as it gets the job done and you will see immediately if it has in fact got the job done. For these things, the LLM can read and type faster than me, and that's useful.

There are 640 acres in a square mile

[Sighs in metric]