A Review of Some Slopware

I've been subjected to two (obvious) examples of slopware apps. I've read dozens and dozens of conference submissions that appeared to be slopware. I have some observations.

BLUF

My observations:

Important

  • One sample is an anecdote.
  • Two samples can only reveal coincidence.
  • Three or more can be attributed to enemy action.

I've only got two samples here.

See https://codeberg.org/ethical-foss/open-slopware for many, many examples.

AI Writing is Crap

Having seen a lot of weak conference proposals, I've learned this. The author's voice (and intent) is diluted by the torrent of related words generated by an LLM.

When submitting conference proposals that involve AI help (in any form, outline, editing, anything), I advise authors to include the prompts so the program committee knows what was intended. Before it was buried by slop. We don't want to suffer through the mangled mess Claude or chatGPT made out of your idea. We want your idea, as you framed it, in your voice.

Important

LLM's don't "clean up" your writing.

They make obscure your meaning with a litter of pretty-sounding turns of phrase, devoid of meaning.

AI-Written Apps are Crap

Oh, they look kind of nice.

But.

They don't seem to maintain state properly. The various tabs and pages all seem to be unique little flowers, grown in isolated little gardens, and don't seem to have any ration Observer-Observable relationship.

They are filled with unchallenged bad ideas. They don't solve problems, they displace them.

AI-Written Apps Reflect Second-Espresso Bad Ideas

Recall with me (I'm old) the olden days when people worked in a collaborative space (an "office" we used to call it, the place where a service was performed.) Someone would spew some idea about the tabs or the left-side navigation. Pumped up by two espresso shots, they knew their UX idea was brilliant.

Maybe someone asked a critical question: "You have a 'structure' link on the left side nav, how's that different from this new 'outline' link you're on about?"

And the ensuing conversation/debate/fistfight would lead to clarity on the lack of any discernible difference between outline and structure. One had more details than the other. Sometimes the structure had details, sometimes the outline had details. Eventually, it was clear, they had different details.

Distinct data models. Driven by the espresso machine, not by any actual conversation with any actual users who -- it would turn out -- don't actually care.

AI-Written Apps Displace Problems

The apps I've been subjected to didn't solve any actual problem I actually have. They slightly displaced the problem into a distinct framing that was -- clearly -- the same old wine in a new, more complicated bottle. I've got two examples.

Consider an "aid" to help me keep my chapter deliveries organized, and synced with the original contractual outline and schedule.

I write -- and edit -- in ReStructured Text (or LaTeX.) I have book Text and book Code in two separate, parallel project repositories. The Text will include code samples from the Code repository using markup-specific "include" directives. (I do not copy and paste code.) The Code samples have context and unit test cases which are not explicitly part of the text, but are required to demonstrate the code really does work.

A web-based "aid" to track chapters doesn't solve any problem I have. It's not designed around having text and code projects; it treats code like an illustration in a "media" folder. It's not designed around Sphinx being able to run PlantUML to make diagrams; I have to run it separately.

In order to use the web-based "aid", I created a Makefile to restructure the content into a form the "aid" can handle.

Net gain to me? An extra Makefile I have to remember to run so I can upload to the "aid".

It's not clear what problem this was supposed to solve.

Much Code -- No Solution

Another example of LLM's doing problem displacement was a data collection app. The idea was to have a desktop GUI to collect data. The browser-based presentation had several tabs which didn't synchronize properly. (Perhaps the idea of showing a consistent view of some external state available in the database was too complicated to express in the prompts. Or something.)

More importantly, the desktop GUI was used to validate complicated inputs against some schema, caching the data for later upload to somewhere.

Important

Validate data against a Schema

That seemed to be the essential reason for the slopware.

A "later upload" intent was there, but "later" was so poorly defined that a scheduled upload was a "Wait, what?" moment for the author.

I think the problem to be solved was validate data against a schema.

The schema appeared to be scraped from complicated multi-page web forms. The target web-site's forms seem to have been reproduced by a slopware code generator to run locally. The schema used for validation, then, is implied by the copied forms.

Note

The site in question has API's with OpenAPI specifications.

This, however, does not appear to be a thing for slopware authors. It doesn't appear to be a thing for an LLM code generator, either.

Being too foolish to use an LLM, I would have downloaded the schema for the pages in question. Manually. Using CURL. I would have written .TOML files containing the data I wanted validated. Manually. Using a text editor. I would have used the JSONSchema validator (https://python-jsonschema.readthedocs.io/en/stable/) to validate my to-be-uploaded content against the form.

It's hard to be sure validation against a schema was the problem, because all the pointy-clicky stuff was rather quite complicated. I couldn't see any other reason for simply staging the data locally before uploading.

To make it easier to use, I might write a little script to emit a template .TOML file from the JSON schema definition. Good OpenAPI specs include examples. That's the first place to look. Lacking an example, I'd probably create an example manually, and then clone and edit that. With a text editor.

Like some ignorant Luddite.

The "upload" would be a .TOML load and a POST request using the API. (I'm kind scrupulous about API's, so I'd do a GET to see what version of the OpenAPI spec was being handled by the service.)

Or.

If that was too burdensome, maybe a screen-scraping exercise to extract the HTML form, and create a POST request from the .TOML data.

All written in Python. Manually. With an IDE. Like a Luddite.