scottfalconer

I don't think websites are going away, any more than facebook "killed the website" 20 years ago.

We will need to make everything accessible to agents and humans though because you'll never know if you're dealing with a human, an agent, a human driving an agent, or an agent driving a human.

I use voice mode a lot for product / architecture planning and dev - but the fundamentals are still the same. Have well defined requirements / specs / plans, understand the tradeoffs and edge cases before any real dev starts, have standards and tests checked by systems that the agent can't talk it's away around etc.

I'm less concerned about the syntax of the code these days and focus more on the overall architecture.

i.e. going on a walk with voice mode and saying "lets walk through all of the tests one-by-one, for each lets review what it does, why we need it, and how it covers something that could actually happen in the real world.

Because agents can build things, but fortunately for us humans, there's still room for making sure the "right" thing gets built.

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.

I don't personally use Ruby on Rails, but there's a strong benefit from a framework or system that has been pressure tested in the real world with a lot of eyes on it - especially open-source ones that are the result of the accumulated judgement of many users.

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.

> which was the last major version that supported upgrading in place from the previous versions

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 trial form is if you want a desktop installer from the Drupal Association. You can still install Drupal CMS directly with no form by clicking the "Download the Composer package instead" button next to that.

> core properties of web infrastructure

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.

I'd argue that content written by non-humans makes this even more important. You still likely have a need for a publishing / review workflow & attribution and a way to ensure standards are enforced and not just left to the end-user's own judgement.

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.

Why wouldn't the makers of something be able to state their opinion on it? Especially an open, collaborative project with many people, and opinions, behind it.

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.

Fair point.

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.

I'd say no, at least to start - there's an inherent cost in using a CMS a framework etc. If what you're building is simple enough that a flat file hosted on cloudflare etc, works, then start there.

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.

yeah, that's the double-edged sword. Drupal can do what it does today because it continually rebuilt it's foundation - but at the same time that sort of movement did cause a lot of pain along the way. At the same time, in the world of "I'll just have my agent rebuild it" makes that sort of change a whole lot easier to deal with - if not the standard everyone may need to adopt.

also the best code is usually less code, and frameworks can be really helpful there.

yes, but in my opinion it's not a new strategy.

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.

It's the inverted pyramid that has always been sort of Drupal's niche... a small number of all sites, but a large percent of the largest sites in the world.

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.

> I don't think there is a place for Drupal outside of higher educations marketing.

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.

> much of the work ends up delegated to the devs anyway

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.

Using Claude to build things quickly is great - but once you hit a certain level of scale, or have a need for governed workflows & oversight, you're more or less going to want some sort of CMS. When that happens, you can either go it alone, or build on top of a lot of well discussed well thought through solutions to these sorts of problems that the Drupal community has dealt with for a couple of decades.

Drupal CMS is working to solve some of this - from better designs to confidence in the choice of modules. Any truly open and free choice is going to have this sort of concern though - but unlike a closed ecosystem, at least you do have a choice or path forward when the situation arises.

I'm partial to Drupal because I use it a lot - but if you have a large team with a lot of rules around content and making a mistake is a big deal - you don't want to re-invent the wheel with CMS-like functionality.

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.

Yes, usually when you have a team and need governance over users / content / state. i.e. a publishing workflow that might have specific regulatory review requirements etc.

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.

Yes, significantly - even when adding in vendor costs etc. In general though it is best at answering routine questions or ones a customer could get by reading the docs. The net result then is the ones left for the humans are the harder ones.

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.

We ran into an interesting side effect of agent performance that we needed to explain in our results to our executive team. In our case we were rolling out an AI support agent that could help resolve customer problems. At the start we had calculated the total time and human cost per support ticket going back a few years. After a few months of running the AI agent, we found that both our time and cost per ticket had increased - but then digging in, the issue was that our overall cost and time had decreased and it was just that the more complicated issues the agent wasn't able to answer were the ones now going to the humans, skewing our per ticket cost up.

So in this case it's not that it was a different failure, it was that a signal that seemed to indicate failure was actually a signal of success.

Getting the right answers is just half of it, you need to know the right questions to ask. I haven't yet seen AI crack that one.

For the last 20 years, most software process was built around the assumption that creating software is slow and expensive.

That has changed.

I built self-learning-skills because I noticed my agents often spent time poking around and guessing at things I had already solved in previous runs. I used to manually copy-paste those fixes into future prompts or backport them into my skills.

This repo streamlines that workflow. It acts as a sidecar memory that: - Stops the guessing: Records “Aha moments” locally so the agent doesn’t start from zero next time. - Graduates knowledge: Includes a CLI workflow to Backport proven memories into permanent improvements in your actual skills or docs.

It works with Claude Code, GitHub Copilot, and Codex and any other system that implements the https://agentskills.io specification.

At first pass this seems 1) incredibly useful for me 2) incredibly expensive for them, but after using it a bit I'm thinking it might be incredibly valuable for them because once I review and approve one of the options, they're essentially getting preference data on which of the approaches I felt was "best".

Thoughts from those who have used it?