"Should [[fediverse.party]] list apps whose devs use auto-generated code?" #305
https://codeberg.org/fediverse/fediparty/issues/305

I mean... why shouldn't it?

There is a "watchlist": https://codeberg.org/fediverse/fediparty/wiki/watchlist+-+fediverse+apps+created+using+generative+models.-

Slightly worrying, feels discriminatory (and no, not in a "good way".)

Should fediverse.party list apps whose devs use auto-generated code?

[Nolto](https://nolto.social/) is a project designed for professional networking on the fediverse. Its code was auto-generated using lovable.dev. This doesn't go against our listing criteria, but maybe it ought to? Until we have a robust discussion and come to consensus on this, I'm calling a mo...

Codeberg.org

@flancian I see the same kind of polarization in my professional environment. AI-yes-or-no is the most dividing issue I have seen in academia for 30 years.

One issue is the ethics aspect, which allows no easy compromise.

Another issue is workflow incompatibility. Collaboration between AI users and AI critics is de facto impossible. The rhythm of work is not the same, the subject of shared production is not the same (prompts vs. code).

@khinsen how do you deal with reproducibility in an academic environment? If the LLM tooling is integral in massaging data how can you rely on it behaving the same way each time? @flancian

@dch Reproducibility of computational work has already been a big issue before LLMs. Some disciplines care more about it than others. It's the latter that go for AI adoption.

@flancian

@khinsen @dch +1, I've also been investing in reproducibility for processes at work. It is doable, you just have to do additional things like investing in evals, fitting responses to a schema and doing informed retries.

@flancian @khinsen @dch I like generating code with llms for learning by for example generating dynamic notebooks around a core that is doing the actual work (and thus deserves greater scrutiny). I don’t particularly care about the notebook code since I can fairly easily review that the “boundary” is legit (by reading the code, but also logging and instrumentation).

There’s so much “peripheral code” that doesn’t require “runs in production with 6 9s” or “properly does the stats required” that however makes the job of getting a high quality core software so much easier.

Reproducible data snapshots, making sharing and onboarding easy, logs and traces, dashboards, proper archival, robust workflow runners, up to date validated docs, all of these require “boring” code yet provide incredible amounts of value.

There’s this premise that if you use an llm you have to go full in and first apply it to the core code, both on the megahype and the anti-ai sides.

@mnl @khinsen @dch yes, I completely agree. I've been developing a #colab since late 2024 at work for one of my projects and it has been a great experience. Adding features and making it reproducible and fast/efficient has been relatively easy, and it can be naturally ported to any workflow engine/pipeline architecture you want if the need arises.
[[colab]] at anagora.org

The Agora is a free knowledge commons: anagora.org.