"good coding" was in service to concepts like bug fixing, feature enhancement, transferrability or documentation. What if all that was tossed, as the code was no longer even read? Just results-oriented output, checked against other solution paths? It may be that foundational work continues while LLM's generate the software that nobody reads directly, just like we don't check the solder joints on the parts, we exoect them to work and review only the results. "Coding" might be a narrower band of training models to encapsulate discrete functions that serve a purpose, while Product Development is orchestrating code generators to create a machine hardware+software, without looking under the hood at all.

Which aspect? Hardware drivers? OS schedulers? Language designers? Shader code? I think you might be underestimating the actual scope of what digital machines cover. From examples like SCADA to FPGA to Kernal Routine to Office macro to Game Engine - computer science has an incredibly large discipline space. Think of the science as so young that we're jumping from wheelbarrow to Cat 798 each decade. A decade from now perhaps we'll simply be schooling LLM's on the standards of your personal project, not really coding. The issues will be reigning in the models' erratic tendencies, not checking indents and variable names. They won't need to write in a "language" you recognize.

What skills does that cover in your opinion?

Problem-splitting, and solution splitting are good skills, yes. But the choice of division-lines in those splits - and when - become more and more important. Parameterization, DRY, Optimization, can all become a ruthless taskmaster for no important reason, way too early in solutions. Test cases can be drafted too late, too myopically. Documentation and transferrability never even arrive at the table. Decomposition should begin with the Why and What Problem Are We Solving. "To build anything, one must first make a universe" isn't entirely wrong, so modelling the problem & solution space just enough to get a result is also necessary. I find devs are typically thinking of a conveyor belt of narrow-field mini problems, and pulling LLM python code snippets together to achieve a too-quickly-decided overall solution. That overall somution is the big think, really. It can be much more illustrative to contemplate a realm of Userland in V.amazing, then scale it backward to a few simple cases. No need to even design for future concepts, as wholesale refactors are a great cleanse. Once a Computer Scientist sees the real-world arc of a productized system, they (can) discern the useful work vs the deck-chair-arranging that wastes time. And accept that everyone will get a few things wrong, so that wrong isnt the problem, just moving too slowly to correct and keep going.

Several issues, although I support further research to overcome them: (1) integrated barttery structure with vehicle structure is a weight savings, worth quite a bit. (2) standardization of any sort is not there (3) a single mishap isn't just an EV fire, its a conflagration of an unpredictable size of battery stacks, more akin to a chemical factory.

The stories come from prior stories, with new prompts to re-order the words essentially. This is enshitification. It will grow until the LLM's can coin new terms, build analogies, research the principals of a story, and even call people close to the story for their opinion and summarize it. Then LLM's will have to associate good journalism practices with prompt guidelines given by trainer models.

Those missing parts are ultimately solvable by even more LLM API's and trickery, but it's still not intelligent. In fact, the guardrails of most public LLM's are so narrow for divisive issues that most newsworthy issues would be dry-as-a-bone recaps. The arc of time that makes previously non-controversial phrases turn into a dogwhistle to a social agenda would make LLM's just agree with the accusation and move on. They have no agenda, including any to dodge embarrassment.

LLM's that could write in an acerbic, critical form like some great writers of social commentary (Twain, Vonnegut, Hitchens) are a far way off. Those would be able to build a cohesive worldview using a mostly-sensible value system. As it is now, the Transforms don't really have a way of teasing out a contextually-generic moral system, because there isn't one. So we're creating the best savant possible in the field of reading everything, summarizing what's its read. This covers a lot of daily human thought, but it cannot cross over to feeling something, and it seems absurd when a machine tries to fake it.

Thanks for doing some math, but the point is: Massive human disruption is far easier than geoengineering ocean flood levels.

You may be applying a niave perspective of the scale involved. A scaled-up wall doesn't account for water rising put of the ground. And one cannot pump even a centimeter of an ocean somewhere else. These average sea level effects create massive flood stages during powerful storms, leaving behind a soggy landfill. The only solution is moving to higher ground.

Sea walls stop wave damage, not water levels. The ground is porous. Desalination is not a massive pumping effect for the level of an ocean.

The primates are smart, but gullible and predictable. So, each decacde we should expect to see ever-larger forced movements of people from lowland coastal areas. The early signs would be: flooding, massive erosion, catastrophic pollution events, rising insurance premiums, real estate price drops and ultimately lower valuations then a reduced tax base. I suspect there's a map tracking these events and amounts already. Perhaps there'll be a hand-scrawled sign offshore somewhere saying "we will rebuild!"

They'll never know what it gets wrong, but a lucky customer will. And I am curious who will weave in bug fix, new features, or a breaking change upgrade. The AI? The vibe may be quite solemn indeed when the LLM cannot generate symbol sets on something it never trained for.

Donald's biggest enemy has always been himself. Read any number of his biographies. His ego is unable to be embarrassed, win or lose. And so, he can make the most short-sighted proclimations and wave off any questions about How & Why as he jets off to another golf round.

He'll mix things up a bit, raising the power of the Executive to unprecedented levels, and then fade out in a blur of elderly nonsequiteurs. Pennies won't disappear, Greenland won't be a state, and the privatized portions of the federal gov will flame out in corruption, prejudice or bankrupcy. As it has been, so it will again.

And your comment will look as ridiculous as any past administration gloating.

Cloud Services may or may not be cheaper. One can argue from examples both ways, and in the end "it depends" is a wide belt. However, the biggest change is that one clicks a few dashboards, or pays an IT consultant for a few hours time, and gets a managed service that runs on a sent-cheque, like a utility service. (Yes, it will require care and feeding occasionally). Businesses shy away from managing people - to build, test, touch-up their non-cloud-managed components - its a more difficult skill, and businesses dislike the ever-changing landscape of sequestered knowledge, compensation packages, workplace atmosphere, turnover and training, etc.

So, in the end, even if a cloud service is more expensive to some degree, the corporate comparison is to bodies-at-keyboards and herding the coders to Fix What We Want And Don't Touch Anything Else.

Corollary: This effect of boiling an employee's role, or even portions of it, down to "write a check to a service company" is the entire story of the Digital Revolution since the 1960's. LLM's are just another small (and flawed) step in attempting to get the ad-hoc requests automated. "Please compile the diverse, numbers into a filtered spreadsheet and present us a meaningful graph tomorrow" is, I'd guess, like 10-25% of what humans are doing at a business computer nearly constantly. This should be (one) Workplace Turing Test.

That will spiral, immediately. Each point of raised interest carries a segment of underpayment in the cohort of holders. If you use adjustable interest rates, adding a point causes the next due date to be slightly more underpaid. However, if you adjust rate on just new loans, and adjust for profiled holders' expectation to pay, you have current insurance mechanisms (addding gear grease & some profit).

I can agree with most of your sentiment. Here are where we disagree: The structurally-opinionated "framework" becomes a new direction for the software portfolio management. Unlike editors or even OS, frameworks are now monitored, updated, kept in the upgrade-test loop. This is both good and bad depending on how you view change: Vulnerabilities and be closed, but new ones opened; bloat added but more commodification of features, reducing what your team writes. They react more to upgrades at the cost of pure feature development.

Compare this to a use-the-design, not-the-code shop: They may build a relatively larger set of their components using the "library" philosophy, still managing the portfolio, but hopefully reacting to change at a more-targeted level. For teams that want to resist imposed-change, and minimize the influence of a framework's arc of features, popularity, or even ownership - using a library can be a step.

The result is a different beast: Consider the heavy reliance on mind that a custom 1m+LOC legacy finance, aerospace or government system has. It's 20+ years old, has a specialized team that built it from the ground-up, and is near totally impervious to most software-market influence. It's also only flexible at points thought about 1-2 decades ago, and probably has shell systems around it. Now compare it to a more modern startup that built on a framework, did the care & feeding, outgrew it and wholesale-migrated 1-3 times, and balanced somewhere between 3 and 5 "years old" in component versions. Which is a better software/team mgmt strategy? That's debatable.