Coding on 8 and 16 bit home computers still required some skills that most vibe coders certainly lack.

> most programmers and hobbyists could code without the need of a University or a Corporation.

I don't think so. Back then, the pool of people doing such a thing basically self-selected for intelligent, motivated types who were capable of learning on their own. The new "programmers" "programming" via Claude Code are going to be very different from those hobbyists you're talking about.

> I’m sure others heard the same when JavaScript and Python became near ubiquitous. When PHP emerged.

You heard right! Most JavaScript and PHP in the world _is_ profoundly shitty. It's taken 20 years of intense research to make JavaScript compilers that are almost good enough to mostly optimize away the design foibles of the language.

There are different magnitudes of shitty.

Also we went from compilers with an IDE that had a debugger, profiler, built-in help and would fit on a 3.5" disk and would load on machines with 640KiB RAM (Turbo Pascal) to chat apps or password managers that are hundreds of megabytes and regularly gobble up more than a gigabyte of memory because they ship with their own browser.

Something is lost along the way.

To be fair with how powerful our computers are, it's a pity that electron apps like bitwarden, spotify are so slow and consume so much resources. I do miss the time when a lot of apps were snappy

Maybe it’s a process. Many of the transitions you mentioned did bring shitty apps (not all of them, the ones replacing tech for tech were mostly ok, the ones democratizing dev did come with a quality drop), but eventually Darwinism will take effect and trim the long tail.

Coding per se is not hard. Proper engineering is. I do hope this change brings a change in focus (people train in algorithms, efficiency, solid development patterns) but I am afraid it won’t be the case.

"With a punchcard at least, I can verify what the input is! Unlike those new 'transistors' that are so unreliable!"

At least some of the projects in these industries now specify strict no-AI-use policies in contracts. I participate in a few of these, and it’s becoming a bit of a pain, because all dev tool vendors insist on adding AI features, and if there’s no way to turn them off completely we have to migrate away.

However, the temptation of productivity gains are strong, and few of the customers look into relaxing these rules.

The good thing is we've learned this already from cloud. When one AWS region is degraded we all failover to other regions, and then other cloud providers, right? ...right?

Thinking, yes, but also secrets, access and effective control of important services in every country and company worldwide, centralized in the US (or anywhere else) where the NSA can take the driver's seat at any time. "AI" is the ultimate sleeper agent.

The worst I would ever get was "here's our Access database - can you rewrite it". That was utterly useless to me.

What I needed to do was sit with a user (not a manager/the person buying my services) and ask them to show me the different things they did with the software. Then I could write a spec for the actual _feature_ and would only need to look at the existing codebase if they needed data transferring across[1]. I don't see why our new LLM-based future would be any different

[1] Of course this meant I would leave out edge-cases and/or weird quirks of the system - often this was actually a bonus as they were either no longer relevant or worked that way because that was the only way they knew how to do it

Yes, as long as context size increase and llm improve at least there's a way out through using AI but once the progress stops...

Play the ball, not the man, dude. Hectoring people on the Internet because you're stressed out about something isn't going to magically fix how you feel. Digging into their profile to make it personal is three steps too far.

You are assuming like 12 things that aren't true in this response.

> most executives do not have an information/network security background but do have privileged access to extremely valuable information, even if an attacker just has access to their email.

In a properly structured organization, of which there are many and who are required by regulations and/or best practices, senior executives tend to have need/role-based access to information, just like everyone else in the organization. So they may have access to strategic business information, but not patient records or payroll. They may have access to planning data, but not the financial records of individual or clients. Etc. etc.

Smaller or newer orgs may not have this compartmentalization, but in general I think the principle holds true for orgs over a certain number of folks in size.