Vienna-RSS project – Draft for “AI” policy

phiw13 · 2026-01-29 08:52:22

Barijaona (lead developer for the Vienna-RSS project): ““AI” Usage Policy” github.com/ViennaRSS/vienna-rss/discussions/2051

That might be something to consider for the Textpattern project as well.

(one thing I dislike, main developers seem to be given a pass when it comes to disclose “AI” usage)

Bloke · 2026-01-29 10:21:54

That’s a good post. We could probably craft something slightly less/more opinionated in a similar vein for Textpattern.

My primary beefs with AI code are:

Long-term maintenance. Trying to understand another person’s code is often hard. Deciphering something machine generated that may contain superfluous elements unrelated to the goal it was trying to reach is even more of a slog.
Quality. Machine output is learnt from the collective ideas of millions, from various sources such as Wikipedia, stack overflow, PHP documentation comments, Reddit, etc. Many of these sources post simplistic situations that do not represent code meant for production.
Security. An extension to the above point is that many answers to questions posted online do not take adequate security measures into consideration. Sometimes the accepted answer is simplistic, and maybe a subsequent comment or different upvoted answer will negate or augment the official answer scraped and regurgitated by the LLM.
Lowest common denominator. Many solutions may be applicable to the most prevalent online toolsets, such as WordPress, Laravel, Rust, Agile, React, Symfony, MVC patterns, and so forth. These are often incompatible with Textpattern’s goals or codebase.
Performance. Elegance. Size. Machine-generated output does not take any of these into account. It provides a method of achieving a stated goal and does not consider whether the code fits with the project’s ethos of being nimble, powerful, and lightweight.

For all the above reasons, and more, AI code has no place in Textpattern.

And yes, I also disagree with the core developers being given a free pass to use it.

Bloke · 2026-01-29 10:33:54

As an adjunct to this, I had a client dabble recently with LLMs to write and implement some CSS modifications. While the rules did exactly what was intended, when it came time for me to do something else, I struggled. The overly-prescriptive rules and !important flags that the machine suggested and were implemented meant it took me 5x as long as it should, scratching my head and removing / revising them so the ‘C’ in CSS was restored.

My changes were simply ignored due to the depth of selectors that the machine had instructed the client to use, which would have meant, had I not unpicked it, employing even more wordy selectors to override the overrides and, very soon, the code becomes unwieldy.

This is a primary example of machines providing a “solution” (that works) but without regard to the context in which it’s applied, making maintenance more difficult and reducing performance by unnecessarily increasing the size of the stylesheet.

giz · 2026-01-29 16:59:06

Your misgivings certainly match my early experiences with the tool; generic php solutions which didn’t draw on Textpattern’s toolset etc.

I realised I wasn’t giving enough context in my queries, so I requested that it base its answers on Textpatterny sources only. This time it took longer (it trawled everything from the docs to GitHub to the forum to stackexchange to reddit — stefdawson.com also came up :).

I’m not experienced enough in php or the TXP way of doing things to comment on the quality of ChatGTP’s subsequent efforts, but it appears terse, logical and DRY to my eyes.

On the css side I occasionally ask it to come up with a better solution to my code; I’ve been impressed with its recommendations (terse, neatly abstracted, better than my original).

I feel ‘AI’ can be useful if you research your parameters and frame your questions carefully before hand. If you’re already an expert, its a tool which can expand horizons.

Last edited by giz (2026-01-29 16:59:45)

gaekwad · 2026-01-29 23:44:14

Bloke wrote #342421:

nods

Very comprehensive examples. And echoing my sentiments on the whole.

Is contributing.md a suitable place for something like this for us? Or are we adding another top-level .MD file?

I definitely do not agree with this unless it specifies “people.”

It’s the people, not the tools, that are the problem.

Bloke · 2026-01-30 08:27:46

colak wrote #342424:

I definitely do not agree with this unless it specifies “people.”

Not sure I follow. Could you elaborate please? You don’t think we should include a document on AI abuse of our project and time? Or you don’t think people should contribute?

phiw13 · 2026-01-30 08:43:24

Bloke wrote #342421:

Is contributing.md a suitable place for something like this for us? Or are we adding another top-level .MD file?

That jellyfin.org text is quite good, I think.

I would give it a little more visibility – the regular users deserve to know about this as well. contributing.md is not included in the release zip.

Perhaps miroring the text on the website ? (but , of course, contributing.md ought to reference this.

colak · 2026-01-31 17:16:37

Bloke wrote #342425:

Not sure I follow. Could you elaborate please? You don’t think we should include a document on AI abuse of our project and time? Or you don’t think people should contribute?

Their take that “it’s the people, not the tools, that are the problem” takes a theoretical take that the tools are by default neutral, and useful, and it is the people who ‘weaponise’ them. AI on the other hand can not be seen as merely a tool. Machine learning cannot be fully controlled and those who do train it, do so for their own financial, political, and/or ideological interests. Regardless of training AI develops its own takes that many times conflicts with the trainers’ intentions. Grok is a prime example, but more scaringly, search for moltbook.

I think that we should include something about the conscious rejection of AI in txp, and emphasise that there are actual individuals behind it, and its community.

>Edit: Added moltbook

Last edited by colak (2026-02-01 04:26:42)

phiw13 · 2026-02-08 23:41:03

Drupal lead: dri.es/ai-creates-asymmetric-pressure-on-open-source

Vienna’s policy: github.com/ViennaRSS/vienna-rss/commit/266d21d49263b39800f8f992a0b9fa499aab4c9c

This is more inline with something for Textpattern than the original draft, I think. Note the “”around ai and the focus on “Large language models” (LLM).

wet · Today 07:06:03

phiw13 wrote #342565:

Drupal lead: dri.es/ai-creates-asymmetric-pressure-on-open-source

In related news:

Drupal is a […] AI-ready CMS that allows you to design a digital experience to your vision.
— new.drupal.org/home

Bloke · Today 08:24:47

Interesting read, wet, thanks for highlighting it. Two things stand out for me, in relation to our project:

the people who depend on Drupal are watching other platforms accelerate. If we move too slowly, they’ll look elsewhere.

That’s never been an issue for Textpattern. We take our time :)

expertise and intent

This is the crux. I like that AI analysers can find security holes that humans may not have noticed. But only as an additional safety net to good habits and coding standards by maintainers and patch-makers.

We don’t have a unit testing framework. Well, we do, but we haven’t capitalised on it yet. My concern is that people will start to rely less on unit tests and good coding practises, and more on the “commit, run AI analyser, it comes back green, all must be good” paradigm.

As the author of that article says, none of this is new. Not even in coding circles. When I was back at Marconi, they had unit testing stations at the end of the production lines, which electrically tested the circuit boards for solder faults. It operated on a random sampling basis because the company didn’t have capacity to check all boards (too slow, and not enough resources, primarily).

However, after a system update sped up the testing cycle, on one critical product line with a good track record, the company decided to 100% inspect all circuit boards.

The result? Quality degraded.

But how can that have been?

The answer was simple: humans. Because everyone on that production line knew that the testing team were 100% inspecting, they were less diligent about their own spot checks or their own work, the maintenance crew didn’t look as hard to detect machine misalignment, and so on. Ownership of the product quality shifted from “everyone” to “the test guys” and things went downhill. More boards were rejected by the test team, sent back for rework, and each time solder joints are reworked they increase the chance of damage or affect long-term stability under load.

That’s human nature. If someone or something is always checking your work and has your back, you’ll leave them to it so you can be more productive, which is what management wants from its employees.

The same will happen here if AI is systematically added to the pipeline and entrusted. Quality and innovation will suffer.

If, as demonstrated, the tools can be used to analyse code paths and spot potential problems AND the results and patches are consistently good quality, bring it on. We all benefit. But I don’t want to ever rely on this cosy feeling when the check mark goes green that everything is going to be alright.

Algaris · Today 09:02:09

Bloke wrote #342573:

If, as demonstrated, the tools can be used to analyse code paths and spot potential problems AND the results and patches are consistently good quality, bring it on. We all benefit. But I don’t want to ever rely on this cosy feeling when the check mark goes green that everything is going to be alright.

This is how “AI”* should be used (if you choose to use it. Whether you should is another discussion). It’s not a crutch to replace actual coding or understanding of the code you’re writing nor a shortcut to reduce quality checks. Instead, it’s a tool to assist you while you work. It can be part of your workflow but not the workflow.

* I put “AI” in quotes because what people call AI are actually very sophisticated algorithms that respond to your input. There’s no actual intelligence involved.

Textpattern CMS

Textpattern CMS support forum

#1 2026-01-29 08:52:22