i.e. why read a book written by a human when an agent can write one? Why buy a painting that could have been printed.

One of the benefits of open-source and frameworks is they're made up of battle-tested decisions by a lot of people with real skin in the game for a long time. Yes an agent will often solve your problem, and will solve it correctly - as asked, but often a better answer is found by stepping back, evaluating the fundamentals, checking other perspectives, challenging assumptions, and having an opinion.

Many solutions that seem obvious are less than so after a bit of prodding - but without that sort of discussion or pressure both humans and agents will often land on the thing that works first.

Where it tends to really matter these days are on the opinionated decisions... i.e. the trade-offs, things that can't be clearly validated etc.

So in the end I think we'll find that these sorts of frameworks etc. will continue to be, and possibly become more important - when your use case matches the intent and goals of the tool. This opinion differentiator is likely also the thing that combats the current issue of proliferation of quickly-built tools that more or less do the same thing.

This isn't correct. Yes it was true from Drupal 7 to 8, but one of the primary goals of that change was so that every major version after could have seamless in-place upgrades - which they have. Yes there's deprecated code etc. that you might run into in contrib. or custom modules, but the site upgrades themselves are easier than ever.

That seems more like an implementation opinion vs. a core property.

Agree that it was a pain to keep up with sometimes, but if software doesn't evolve over a 25 year timespan - it's likely going to be stuck in the past.

The reason Drupal can do what it does today is because of this willingness to rebuild - otherwise it'd just be a CMS that solves problems from the early 2000s.

Separating delivery from content management also reinforces this. Set up a governed content / user workflow and then let an agent focus on just the presentation after pulling in the content. I'd say this extends well beyond rest as well. A user interacting with something like a voice assistant in an agent might actually be using many interfaces at once (mcp from the assistant, HTML in a card, WebMCP alongside the HTML, browser open on another device for the human.) When that happens you want one canoninical system for the content.

If you disagree with the sentiment, it'd be interesting to here why - that's the sort of information that's extremely useful for makers.

I'd recommend Drupal specifically when you have the need for strong governed management of users + content + workflow and you want something that is battle tested without having to make all the decisions that get you there.

There's an old issue in the Drupal queues that I really like that exemplifies this: https://www.drupal.org/project/drupal/issues/174940

This one goes back 19+ years and has to do with 404s when a visitor looks for favicon but doesn't fully follow the standard of where that file could be. It happened with ie6 back then, and happens with some agents and services today. The easy fix is to put a favicon in the root, but that's a bandaid that runs into a bunch of edge case issues when creating a platform or doing something non-standard. Suppressing the error message is another option, but there's a performance and delivery cost into how that's done. If you ask a frontier model today how to fix this on your site, you'll likely get the easy "simple" answer.

Long way of saying, Drupal is an accumulation of battle tested decisions from a bunch of smart people over a long period of time - and if your need matches the usual intent of Drupal - users + content + delivery + rules around that - then that's a strong reason to explore it for your use case.

Once you find you do have a need for something more complex (i.e. you have a team, want to give agents governed access etc), then it's pretty easy to go from a flat file to something more complex.

From a site building perspective:

The problems agents bring to the table are the same problems that UGC brought to the table - new scale, untrusted users, an increased need for governance.

From a user experience perspective:

You can't ever really know if it's a human, an agent, a human driving an agent, or an agent driving a human - so stick to information architecture and accessibility best practices.

beyond that though, we're in new territory when it comes to change / scale / security / etc, so if there is a strategy it'll be out of date tomorrow.

And fortunately those of us in tech, the amount of software in the world is exploding so all those lanes are getting bigger, even within their niche.

Let's revisit the statement in a year :)

My gut is we're seeing the exact opposite. The scale of publishing + users + need for governance is exploding.

For many implementations though, requiring a dev to make the changes is the failure state.

I love static builds and use them all the time when they're the right fit for the project, but in many cases they are not. I'm also finding that I'm starting to lean towards a CMS more even when it's "just me", but I have a team of agents. i.e. I want the ability to have a voice conversation with a dot / grok bot / etc. and have it update content without it having the ability to do dev type things.

Remember a while back when the world first heard about Mythos because there was a mismatch between what the "CMS" said was publish, what was shown on the site, and what was "really" available? Those types of problems haven't gone away and if anything are more critical when an army of agents will seek out and find any but of information they can get their hands on.

We're finding that this is becoming even more critical when users are using agents and the scale of changes / publishing increases. Pair that with things like AI regulations that require records of human providence etc, and a CMS becomes even more important.

We’ve also heard from other companies that as the first line paper cut questions get answered, customer adoption increases - which further increases the “hard” support questions.

Lesson learned for me on that one that was rolling out a support agent led to both a better experience for our customers and an increased need for talented human engineers.