I am not anti-AI at all. A good friend of mine is an AI. I don't see him very much lately, he has a drinking problem. 500 liters of water an hour. Not good.

So this is about the consequences of using AI in a community like ours. Ten years ago, in Boston, I gave a talk titled "We, Plone." Let's revisit those topics in the time of today, with AI.

AI is just a tool, right? There are other ways in which you can get code. Debian has approved the use of AI in their code base. For us, the product, the relationship between people, should be preserved. But if you drop the code writing, you lose something.

1. Loss of knowledge

See Ciro's talk right before this one, and epistemic debt. To create some code we may be able to use interpolation: take a working example, and to apply it to a new situation you just change a few things. You understand for example how an adapter works, after initial problems, and now you know how to create a second adapter.

Cognitive surrender. AI generates something, it does not fully work, you ask AI to fix it. Your knowledge becomes inactive. It is memory, but not active anymore. It is starting to be hard again to do something which you were happy to do before.

Coding yourself actually is restful for your mind. Coders using LLMs are less rested than coders without it. They focus on stressful things.

Extrapolation. "Design is not merely about solving problems. It's about discovering what the right problem to solve is, and then solving it." With AIs you jump from the initial problem to a solution, which is then the wrong solution because it solves the wrong problem.

2. Loss of desire

We work for money, it makes sense, you need to pay the rent and the food. But we also work for pleasure. Not everyone has that luxury, but we do.

Compare with chess. It's not because an AI is better at chess, that I stop playing chess against humans.

Vibe coding. Does that give pleasure, besides the fascination that you may initially get at the results? I would rather call it porn coding. It's about getting immediate satisfaction. It gives a feeling of shame: you are proud of what you do yourself, not of what your AI has done.

Developers are grown ups. They are not just executing orders. Vibe coding to me is childish behavior. Impatient. As grown up you should be patient, take care, take responsibility. What you build should be based on your desire, and you should be proud of it. If AI builds it for you, will you still care enough about it to maintain it?

Where is the love? An AI has no will, it does not like someone. If you do something without love, I'm sure an LLM can replace you.

I love coding. I love to code whatever I want. I can imagine what I want, and build it, though of course in an open source community you coordinate with others. I share code because I really like it. Nobody forces me to contribute, I do it because I really like it.

3. Loss of individuation

Individuation: people become theirselves in relation to others. What matters is the connection we have between people. Most of the time, what you know you have learned from someone else. That is how knowledge flows between people.

We have a shared desire for the future. AI only knows about the past. The future is dead memory for it.

Proletarianization of the Mind. Being a proletarian, means that what you do is replaced by a machine. For example during the industrialization. This was considered progress for the world. But the workers in the factory were poorer than the crafts men of before. And they knew less. And their bosses were richer. It gave higher productivity.

Are we in a period where we can say: we need more software. No, we probably have enough. So should AI deliver even more software?

Open source is about time. You read a book, you read it faster, why? So you can read another book? You already have a book. Enjoy it. You have an open source project, you want to start another one? Why? You already have an open source project. If you like open source, you don't need to accellerate. Our product is not software, it is us. We need to grow slowly.

Killing the gift economy. It affects the open source ecosystem. You release a library, it is a gift. Social debt: I owe you, you owe me. We trust each other. We share debt.

You can ask Claude: I don't want dependencies, just rebuild the ones I need. You can do that. But that ignores the gift.

AI is extractivism, it extracts resources from everywhere. Charlotte Del Signore: "They are trapped in a hypnotic trance of productivity". That is actually not about AI, but about people with neurodiversity. They are critical to have, because they think differently. But it applies to the AI problem as well. AI is dangerously neurotypical.

You are coding with very interesting people. To get potential, you need differences. Nobody is normal. If you look for something that is close to normal, that is an LLM: it is average. You want something with diversity. In my open source community I want sparks, fireworks.

We, Plone people. People are important. We are a small community. We can continue building with our own hands.

Why skipping the hard part is not always a good idea.

I am a DevOps engineer at Syslab.

A junior is not a slow senior. That may be obvious.

An average junior looks at flow of control in the code. A senior looks more at the code in a whole, or in bigger chunks.

CRUM: Computational Representational Understanding of the Mind (Thagard, 2005). So: look at our mind as a computer.

A senior will more quickly spot patterns.

How developers "talk" to AI coding assistants.

• Drifting. The "prompt pinball". You ask an LLM for direction, and blindly follow.
• Shepherding. You roughly have an idea of the goal you want to reach, but the AI keeps wandering away from it, and you constantly have to keep steering it back.
• Exploration. I don't know the answer, but I know how to choose one. You prompt the AI for alternatives, and you choose the best approach and implement it. The AI gives suggestions, and needs to convince you.
• Acceleration. I know the way to my goal, AI drives me there. AI does the actual coding, and you match patterns: check the code, refine it, or accept it.

The last two are preferable, but you need experience for that. How can a newbie gain experience?

Mitigation strategies:

• Skeletons. Learn how to create structure. Let AI generate a skeleton complete with justifications. Then brainstorm together with a senior, and look at the approaches AI proposes.
• Take the wheel. Choose a direction for one part, ask AI to implement that part, then check the response, improve it ot tell AI what to improve.
• Prune context. You can give the entire git repo, or millions of lines of logs, and ask AI to fix the bug. It does work, but what do you learn? Instead, filter this. Take care selecting which part of the code a bug is most likely in, and give that to AI.

Epistemic debt: trading your awareness in exchange for time. You have a starting point of knowledge, say you know 50% of a code base. That is fine. But one vibe coded feature later, you have no extra knowledge, but the code base has grown. So now you know and understand maybe onlyi 40% of the code.

Think about this a while and it will click: if epistemic debt was not a problem, you would have no job.

Fred: don't let AI trick you into going depth first. If it does not find a solution in a direction quickly enough, it should go a level higher and go breadth first.

Armin: there is not one AI. You can let multiple AIs talk with each other. Or multiple models with different prompts and perspectives.

Quaive is basically a distribution of Plone with its own UI. It is for intranets, and it takes security very seriously.

Since I work at the Clean Clothes Campaign, security is very important for us. There are governments who don't like us. Having it self-hosted is also important, so they can't take our data from some cloud server.

Over 10+ years, 750 "workspaces" have been created by us in Quaive, over 200 stil active. Workspaces are the core organising units in Quaive. Each has its own security settings, governing who can see, add, edit, publish information. You can put pages in it, calendar events, etc.

Killer feature: real-time collaboration in Office documents, without needing Microsoft 365.

And, does the security concept work? We have names in there of people in the field who reported workplace problems, so whistle blowers, and we don't want this to be discovered. Safe guarding this information keeps people out of jail, and alive. In Quaive you can really configure in a simple way who has access, and if others can even know that a workspace exists.

Our use of Quaive exploded during the Covid crisis. Many brands cut their orders overnight, leaving the workers without income. Around 40 billion dollar was cancelled. We want into campaign blitz mod, mostly coordinated via Quaive, and managed to recoup 16 billion dollar. Not enough, but quite respectable for a side that doesn't hold power. And Quaive worked in countries with shaky internet connections.

Quaive also has the News section, in which we publish our internal newsletter. Great for onboarding new people in the organisation. And a library with documents that are fixed.

What did not work well? In the beginning we overcustomized. You may think you are special, but you are really not. We forced things on Quaive that it was not intended to: workspaces are not databases. We do not use the built-in message system at all: we only use Signal, and people refuse to use yet another message stream.

We do need some other tools besides Quaive. We use Nextcloud as a document store for contracts and other documents that don't need any collaboration. As a scratch pad for new documents it also works fine, before moving them to Quaive.

We use CIVICRM as a case management system. All our urgent appeals are in here, with the more free-form documents stored in Quaive.

Photos are kept in ResourceSpace, which specializes in this. Used to share with journalists as well.

If I were a rich man, what what I let Guido and Syslab and others create?

• whiteboard
• kanban boards
• landing pages
• a prettier library

Conclusions. Quaive has proved its worth in gold, and in lives. It is battle-tested, and usable for non-techie folks. Quaive is good software. It does take time to get such a wide network of people to use it. Some functions are best lect to other tools.

Mockup is the JavaScript behind Plone Blicca (formerly known as Classic UI). It is a collection of patterns: declare behavior in HTML. It is built on top of Patternslib. It is shipped to Plone via the plone.staticresources Python package.

In Mockup we started introducing Svelte app. Some patterns were still using jQuery or the even older Backbone library, or Underscore. The related items widget was using an old, patched version of select2. So we came up with pat-contentbrowser, using "Miller columns". This is now used by the related items field, and links/images in the TinyMCE editor. And this is build using Svelte 5.

We introduced a way to extend it. You can register your own Svelte component for the selected items. This uses @plone/registry, which is used by Volto. This was shown in the training earlier this week. See this section.

Next: pat-filemanager. This is the replacement for the structure pattern, so the folder contents view. We wrote down the specification of we wanted, how we wanted it, asked an AI, and it came up with pat-filemanager. Obviously we reviewed. We have some new features now. You can drag and drop an existing item into a sub folder. You can drag and drop a new file or image into the folder contents area. We built this at the Buschenschanksprint in five days. This would not have been possible without AI. It uses plone.restapi only, instead of the legacy views for this.

You can try this with plone.staticresources 3.1.0a3 plus a z3c.jbot override for the folder contents view, and replace pat-structure with pat-filemanager.

Now Johannes will talk about Patternslib.

We needed a data binding pattern: pat-bind. Why? Update the UI without pat-inject.

Internals: we switched to pnpm for dependency management. Vite instead of webpack as build framework, Vitest as test framework. We want to separate Module Federation from webpack, to not be dependent on this framework. We want to split the core from the patterns, so you don't need to include all existing patterns if you just want to create your own.

If something is added in Patternslib, we can add it in Mockup.

You may get some of these reports.

The site is slow. By the time you login to check, everything is calm again. You think: okay, it restarts under heavy load, call me if it happens again.

Or you see the storage is full, maybe some large videos uploaded.

Or you notice the search gets slower, every month. Adding RAM helps, but someday it does not help anymore.

"Please purge the cache." Easy enough when you have one Varnish caching server, but what if you have more? And where are they?

One cause: I could not look inside.

Having containers solved the packaging problem. But the container is still a black box.

Plone just runs stable for years. For some sites I just forget that they are there, they never cause problems. For these kinds of sites you do not need this. Plone never needed to report anything.

But now we have Kubernetes. Kubernetes is not some better way to start containers. It is a control room. It sees what you want and what is actually there, and it gets the system to your desired state.

A control loop can only control what it can measure. With Plone my conditions were cloudy. There were many unknowns. Kubernetes asked Plone questions, and Plone had to answers. Kubernetes made me answer questions I had not asked in twenty years.

Take the "it restarts under load" problem. With Kubernetes it starts a container, checks if it is ready, restarts it if it fails, and it keeps the logs, so you can look at it later.

With Kubernetes you can do rolling updates during the day, so no downtime. You can do something in Docker as well, but with Kubernetes you get it for free.

"The site is slow." You can ask: show me every request that takes longer than X seconds. You have one request. In layers. You don't guess, but you can look in details. Anyone who reads OpenTelemetry data can read my problem now. You don't need to be a Plone expert.

"Storage is full." Site with 24 years of content: 2.4 GB of text. The files people uploaded: 244 GB. You need to be able to answer: how much and where. Image scales can be on demand instead of stored. Small files you can put in Postgres. Large files, or large amount of data: you can use S3. Code: plone-pgthumbor, zodb-pgjsonb-thumborblobloader.

"Search gets slower, every month." We can ask the planner of Postgres to explain and analyze. It is just Postgres queries, so again you don't need a Plone or ZODB expert. Code: plone-pgcatalog.

"Please purge the cache." In Kubernetes you always want to have at least two of everything. You don't have a fixed URL of one caching server. I used a Helm chart a while for this, but it was not enough. But the cluster knows this. It keeps a book of what is running in the cluster. It is operational knowledge, as code. Code: cloud-vinyl.

Three of these five problems have the same reason. In ZODB everything is a Python Pickle, and this is hard to read. So store in Postgres. Code: zodb-pgjsonb, zodb-json-codec, zodb-convert.

You get scalability, fail-over, reproducible deployments. Operating Plone was Plone knowledge, but with Kubernetes not anymore. You just use what is already there.