somewhereoutth

Unit tests very roughly double the amount of effort required to make any meaningful change to your codebase. They are also require maintenance same as ordinary code - but the customer does not care in the slightest whether or not they pass. On the other side, they can only really tell you about low level bugs that you already expected, they cannot surface system level bugs - the actual hard bugs that cause problems for you and your customers.

Then there is the danger of thinking that green=all good, an example of 'automation bias' where we learn to trust the automation even as things go wrong.

As makers, it is also tempting to believe that [all] problems can be solved by making something (i.e. code), but actually many problems are not of that nature, and cannot be solved in that way.

If your product is used by humans, then it needs to be tested by humans - this cannot be automated. Those humans can be your QA people, or your customers. Perhaps your customers are happy to be testers, perhaps not.

Unit tests are very expensive and return little value. Conversely, a (manual?) 'smoke test' is very cheap and returns great value - the first thing you do when updating a server for example is to check it still responds (and nothing has gone wrong in the deployment process), takes 2 seconds to do, prevents highly embarrassing downtime due to a misconfigured docker pull or whatever.

My only hope is that it is such a disaster that it is effectively an extinction level event for this current technoscene (along the lines of the Permian–Triassic extinction event and others).

Then we can get back to the unglamorous, boring, thankless task of delivering business value to paying clients, and the public discourse will no longer be polluted by our inane witterings.

but still so so much further to go until you reach human.

In the grand scale of things, a computer is not much more than a fancy brick. Certainly it is much closer to a brick than to a human. So the question is more 'why should this particularly fancy brick have abilities that so far we have only encountered in humans?'

Indeed I have a bunch of apps that do most of these things, but it's the seamless integration I'm looking for - which may not need much AI at all (especially of the LLM kind), just some well directed machine learning and UI integration.

a key difference between a gas station and a parking lot is that people only park at a gas station to get gas (and have a rest, get dinner, bathroom break etc), so, assuming quick charging, you need less chargers as they will spend less time not charging a fully charged car left parked on them. Gas station staff can ensure charging spots are utilized correctly as they do now for the pumps.

Also everyone understands how gas stations work, so it is easier to slip EVs into the social fabric.

I would like a personal assistant on my phone that, based on my usual routine and my exact position, can tell me (for example) which bus will get me home the quickest off the ferry, whether the bridge is clogged with traffic, do I need an umbrella? what's probably missing from my fridge, time to top up transit pass, did I tap in? etc etc. These things would appear on my lock screen when I most probably need to know them.

No email stuff, no booking things, no security problems.

> Thousands of FLASH Charging stations have already been installed in China, and BYD has committed to a global rollout that will include an initial wave of FLASH Chargers in Europe. Further details on the plans, and how they will support the Z9GT's arrival, will be revealed in due course.

https://bydukmedia.com/en/news-articles/denza-z9gt-to-start-...

With 5 minute charging, suddenly conventional gas stations can be used for EVs just as they are for ICE. Nice thing about 'plugging in' as opposed to 'filling up' is that a charging car can be left completely unattended (while you go to pay, get a coffee, or whatever).

Seems that the technological barriers have been overcome, now we just need to build out the infrastructure - which could be as simple as retooling existing gas stations. No need to electrify every parking space or such like.

However:

Excel is 'free-at-point-of-use', i.e. once you've paid for it, to use it doesn't cost anymore. But LLMs do cost per use (unless we all go to local models). Either this cost is billed directly, or some sort of bundling occurs with 'fair use' limits.

Excel is deterministic, yes scary spaghetti-fied spreadsheets are routinely constructed, but, for example, sorting a result column somewhere can be done with a bit of poking in the right place. LLMs have a tendency to dangerously change many things if the prompting is a bit wrong (and even if it is a bit right).

However - Automation bias is a common problem (predating AI), the 'human-in-the-loop' ends up implicitly trusting the automated system.

Of course. Any scenario where you are expected to deliver results using non-deterministic tooling is going to be painful and exhausting. Imagine driving a car that might dive one way or the other of its own accord, with controls that frequently changed how they worked. At the end of any decently sized journey you would be an emotional wreck - perhaps even an actual wreck.

and there is that whole thing of sharing one of your wires with your mate/partner that is super cute and great for bonding I should think.

I have a suspicion that for a task (or to make an artifact) of a given complexity, there is a minimum level of human engagement required to complete it successfully - and that human engagement cannot be substituted for anything else. However, the actual human engagement for a task is not bounded above - efficiency is often less (much less?) than 100%.

So tools (like AI) can move us closer to the 100% efficiency (or indeed further away if they are bad tools!) but there will always be the residual human engagement required - but perhaps moved to different activities (e.g. reviewing instead of writing).

Probably very effective teams/individuals were already close to 100% efficiency, so AI won't make much difference to them.

Really the distinction is between those that can see the bigger picture, and those that only see what is in front of them. Of course the immediate gratification of LLMs appeal to the latter, whereas the former is all too aware of the systemic downside of such automated content generation.

> actually writing the code will often trigger some additional insight or awareness of edge cases that I hadn't considered.

Thinking through making.

Before LLM did code, you could at least have assumed that the submitter had written it (at worst, copy-pasted large parts of it), even if they had not read or reviewed it. Furthermore, writing (even copy pasting) is quite labour intensive, so there was that hurdle too.

Right, but after about 11 years of Puritan government, people wanted Christmas back, so the monarchy was restored (but with a tacit understanding that sovereignty now laid with Parliament).

Indeed. And not only that, all this capex has wrecked their balance sheet. They were in the software licensing printing money business, now they are in the burn huge amounts of money building data centers hoping someone will use them business. Even if people did use them, the margins aren't that great anyway - especially compared to their former software business.

Indeed, and having replaced the aristocracy they let the 'lower classes' carry on much as they had before, continuing with their existing customs and (lower level) forms of governance - just with new 'top bosses' if you will.

So in comparison to other places that did not have such a wholesale aristocracy replacement, this really cemented the class divide. No longer was the aristocracy 'like you but richer/more powerful', but quite different - different language, customs etc.

1066 was the last successful invasion of the British mainland, so, aside from the odd civil war, no sweeping 'cataclysm' occurred to shake things up. We didn't even have a revolution like the French, instead a gradual (over centuries!) transition to our current democratic system, with a constitutional monarchy (itself a remnant of the old ruling system).

The English class system is anchored in this event - the ruling/upper class was replaced in its entirety by the Norman invaders, leaving two very distinct identities.

However a random [but well established] package will have been used many many times, thus will have been verified in the wild, and likely will have a bug tracker, updates, and perhaps even a community of people who care about that particular code. No comparison really.

There is nothing as permanent as a temporary solution!

Humans have a 'world model' beyond the syntax - for code, an idea of what the code should do and how it does it. Of course, some humans are better than others at this, they are recognized as good programmers.

It could also be because we don't want a theocratic regime with nuclear weapons and the delivery systems to put them on European capitals.

It could also be that the whole region is simply tired of their bullshit, and would like to normalize their relations with Israel and generally get on with life without nonsense like Hamas and Hezbollah interfering. Note how Lebanon is seeing this as an opportunity to get rid of Hezbollah once and for all.

Probably a continuation of the 'mowing the lawn' strategy (as used against the Palestinians). Every now and again use massive military force to set back Iran's capabilities, time and effort they spend rebuilding is time and effort not spent causing problems elsewhere.

> Code never was and never should have been the product in and of itself

Except that the code completely and precisely defines the actual product. Bad code => bad product.

> code should be sacred and revered by itself

As a production of the hand and mind, code should be revered - if only as the mark of the human or groups of humans that made it.

> the wrong group of people

The group of people who care deeply about the world around them.

I'd suggest that a measure like 'density[1]/parameter' as you put it will asymptotically rise to a hard theoretical limit (that probably isn't much higher than what we have already). So quite unlike Moore's Law.

> Instead of only allowing programs that are proven to be typed correctly you might want to allow all programs that you can not proved to be wrong. Lean into gradual typing. Everything goes at first and the typing becomes as strict as the programmer decides based on how much type information they add.

Yes, this is the way. And if you ensure that the type system is never abused to control dispatch - i.e. can be fully erased at runtime - then a proposed language supplied with some basic types and an annotation syntax can be retrofitted with progressively tighter type-checking algorithms without having to rewire that underlying language every time.

Developers could even choose whether they wanted super-safe checking (that precludes many legal forms), or more lenient checking (that allows many illegal forms), all in the same language!