1. You need a deep knowledge of Drupal to put together something good. It's not beginner-friendly, you will build a couple clunkers before things click.

2. The mind-share is not there like it was for Drupal 7 - the devs still contributing are great, progress is being made, but if you're used to Wordpress plugins or an NPM package being available for whatever you need, Drupal can be frustrating.

EDIT: I confirm our ACF plugins on sites are all switched to secure custom fields. This is so shady, it broke our snippets because we are using prepend and append texts to wrap our field values. Now they are all broken and we have to update all our sites (also our client's sites). Let's see what comes next...

EDIT2: There goes my Sunday. I received our first ticket regarding broken homepage widgets. I have to sit down and update every site one by one. Thank you Matt Mullenweg for ruining my Sunday plans.

As a general rule profit is 10% of revenue and revenue is 10% of sales. Sales are the money paid by outside parties. Revenue is money left over after spending associated with sale acquisitions, for example after: marketing, merchandising, and advertising. Profit is money left over after accounting for internal expenses.

As such software never directly contributes toward sales unless software is a product directly sold to an outside party. The developers responsible for that software are virtually never responsible for sales generation even when that software product is directly sold to outside parties. The exception occurs when developers introduce a solution to a business problem into that software product and that solution becomes a direct point of merchandising.

As for the current capabilities of AI the LLM approach does not seem capable of writing original software. Most full stack developers are not writing original software though. The LLMs are already writing superior output with use of large frameworks to the extent that they can generate more efficient products and write the documentation sufficient to teach humans the approach to these large frameworks. Whether you should be worried then becomes a consideration of your employer’s perception of software authorship.

You gotta be joking.

Some people (often due to trauma) have a very different relationship with secrets than you describe. Some people get immense satisfaction from holding secrets, and have no issue keeping it that way. Sometimes those people have other flaws or vices, as often plays out. In my understanding, managing such people is its own meta-game within these professions

How far should I be reading into the fact that people outside of Israel leaked this info so quickly? Does it mean the US was very unhappy with the attack? I doubt they were happy with not being given a heads up.

There are two reasons why this is predictable with high confidence. None of the more accurate predictions rest upon the trendiness of AI, but instead are vested in the current capabilities of the people primed for replacement and prior employment trends.

Reason 1. Most, certainly not all, full stack developers are paid far too much for what they deliver. Over the past year I have been seeing many interview referrals for just under $200k even though I live in a very low cost of living area of the US. I have turned all of these down despite currently making far less. The high compensation is not enough to make up for working in a team that has no hope deliver to expectations (more on that in the second point) and is hostile to radical change.

Reason 2. Prior employment trends suggest that many employers prioritize hiring and candidate compatibility over ability to deliver. Its a valid business decision that makes sense in the short term, but results in catastrophic debt over the long term. You have to understand that developers are a cost center and not sales people. This means they cost money and do not generate profit, so it makes sense to lower the costs of acquiring these people as much as possible.

Starting about a year or two after I started doing full time JavaScript programming in the corporate space employers started looking at solutions to turn developers into commodities because they were spending too much on hiring with disappointing results. I can remember the entire industry trying to do this on both the front end and back end, but the movement received far less penetration on the back end, which was more entrenched. It received overwhelming success on the front end with tool suites like prototype.js and YUI before jQuery formed a dominating cult of personality. Then once Node got popular and the browsers got faster those front end libraries were largely replaced by large MVC frameworks like Angular and React.

Before the strong focus on external tool libraries JavaScript developers had to do it all themselves. At that time the browsers were too slow for things like Photopea, but the first large browser apps were already rolling out. These were some really excellent developers, but it was really hard to find people who could perform at that level, and of course the pay was ridiculously low. Moving to these external libraries really opened up hiring to people who could not perform otherwise, and that really lowered the cost of candidate selection. Unfortunately, these external libraries were generally slow and sometimes broke when they were just expected to work, but now you had an entire work force that could not live without them.

Reliance upon external tools to keep your job creates insecurity. It limits the availability of design options to what a given set of tools allow, and developer's first priority at work is to retain employment. That insecurity grows over time as applications grow larger, solution delivery slows, developers get further and further more reliant upon solutions in conflict with the desires of the business's profit generators. Its why a lot of people I have talked to over the past year moved on to other things and refuse to go back despite the far higher compensation.