jtafurth

You're right, but to clarify, that is not the level of abstraction I was referring to.

"Well designed systems" are the key words.

Code written with AI can be fixed, if well designed, they are not mutually exclusive.

Also legacy systems were absolutely not always well designed, I've picked up a fair share of systems that were absolutely not well thought out, usually due to time pressure, or any other context specific reasons.

I do believe we are creating legacy systems faster now, and it's because teams are unable to keep up with the speed of changes, not because their system is not meant to be maintainable.

My point remains tho, using AI doesn't have to mean normalizing failures.

However, we are not (yet) building probabilistic libraries right? Even if AI is used, the code it builds is still deterministic and will fail in a way that can be fixed.

Not unlike legacy code, where the original developers are long gone and no one knows when that system breaking bug is about to wake up.

Even in the best of cases tho, fully human written and reviewed code will still fail eventually.

So I would say we are not normalizing failures (yet) but rather normalizing legacy.

I doubt the question here is about willingness, but inability due to real medical conditions. Assuming real and sufficiently severe ADHD.

There are several valid reasons to "falsify" commit history.

- You need to remove trash commits that appear when you need to rerun CI. - You need to remove commits with that extra change you forgot. - You want to perform any other kind of rebase to clean up messages.

I assume in this thread some people mean squashing from the perspective of a system like Gitlab where it's done automatically, but for me squashing can mean simply running an interactive (or fixup) and leaving only important commits that provide meaningful information to the target branch.

I thought for a moment it was a really interesting wordplay which I did not understand.

The way I see it, it's less about the technicalities of accuracy and more about the long term human and societal problems it presents when widely adopted.

On one hand, every new technology that comes about unregulated creates a set of ethical and in this particular case, existential issues.

- What will happen to our jobs?

- Who is held accountable when that car navigation system designed by an LLM went haywire and caused an accident?

- What will happen with education if we kill all entry level jobs and make technical skills redundant?

In a sense they're not new concerns in science, we research things to make life easier, but as technology advances, critical thinking takes a hit.

So yeah, I would say people are still right to be weary and 'bullish" of LLMs as it's the normal behaviour for disruptive technology, and one will help us create adequate regulations to safeguard the future.

Being wrong when you are building a grocery management app is one thing, being wrong when building a bridge is another.

For those sensitive use cases, it is imperative we create regulation, like every other technology that came before it, to minimize the inherent risks.

In an unrelated example, I saw someone saying recently they don't like a new version of an LLM because it no longer has "cool" conversations with them, so take that as you will from a psychological perspective.

I worked for an authority that issued digital certificates for SSL and digital signatures. It's not only about providing encryption but also about trust, when a top level entity issues a SSL certificate, a number of identity validations are carried out, adding an extra layer or confidence on that website.

This may seem inconsequential for static websites without PII, however most browsers consider it important as it reduces the risk for all parties involved when encrypted communication is used and the content providers has taken basic steps for Identity verification.

There are logic flaws with this approach to security imo, but it's the most commonly used technique at the moment.

The real problem with the platform I think is discoverability, and that will get affected more and more with corporate clutches.

However I do agree with your point overall, I'm struggling to see how this will not go the same path in a few years.

I wouldn't say it's an archaic problem, an example I can think of is writing scripts for infrastructure running minimal docker images where you want to keep the image size to a minimum, you would usually need to support both bash and other shells.

Embedded applications come to mind as well.