AI in Debian: The Vote, Proposals, and Nuance

Debian, ,

Let me start with a hypothesis:

For human developers, using coding LLMs magnifies their difference in skill levels.

I am one that rarely thinks things are always black and white. Back in March, I wrote Artifial Intelligence: Shades of Gray. Since then, I’ve had more of a chance to experiment with LLMs myself. I also happen to work for an employer that is taking a very pragmatic approach to LLMs: teams and individuals use it as they see fit, but if they are causing considerable expense, they have to justify it.

In various settings, I have seen the egregious examples of AI slop we all know about. As I wrote in March, “I have seen it both waste more time than it saves, and save a ton of time.”

I have come to see that, as a tool, it is most valuable when it is running under the supervision of an experienced engineer. It is at its worst when it has no such supervision; the “vibe coding” and other low-quality slop we see.

A coding agent is like a junior developer or research assistant. When properly supervised, they help projects move along more quickly by letting a senior developer focus on the more difficult, less mundane aspects of the project. But one couldn’t expect a junior developer to consistently deliver high-quality code and architecture on their own.

Let’s put a pin in this idea and look at the story in Debian.

LLM use in Debian

There is a vote happening in Debian around the use of LLMs. In typical Debian fashion, there are 8 options to choose from, many of them similar. Most of these proposals acknowledge there are different types of tasks done in Debian, but the proposals don’t differentiate between them well. Let me do so here. These are some of the LLM-relevant tasks people in Debian perform:

  • Packaging upstream software for Debian (by far the largest task)
  • Writing Debian-specific code (eg, apt or the Debian installer)
  • Maintaining Debian infrastructure (build systems, for instance)
  • Writing documentation and translations

I’m going to focus my remarks here on packaging upstream software for Debian, since this is by far the most time-consuming developer task project-wide.

It matters to our users that we get this right, and packaging quality is one of the things that sets Debian apart from other distros. Packaging things for Debian requires knowledge of some specific tools, such as debhelper, that aren’t widely used anywhere else. In most cases, it is fairly rote time-consuming work. In other words, by its design, it requires people with senior-level skills to do grunt work.

I can’t overstate how massive a burden this grunt work is. I maintain some packages for Go and Rust. By Debian policy, all of those packages’ dependencies must also exist as Debian packages, and be used to build against. When upstream adopts a newer version of some library, it can unleash cascading dependencies that can take hours to sort out. Worse, the Rust team and the Go team use entirely different ways of managing packages (Go uses one Git repo per package, while Rust has a monorepo with specialized scripts to import Cargo packages and generate Debian ones). On top of that, we can’t just modify things like usual; we have to use quilt. And on top of that, I’m also a backports maintainer, so all the work (and usually even more) has to be done there also.

Now let’s pull on that pin from the earlier conversation. This is exactly the kind of scenario that a well-supervised coding LLM is most effective in. I could see a seasoned developer saving hours, maybe even days, by turning over the mundane tasks of managing trees of cascading dependencies over to a coding tool — and verifying and directing the process. (Yes, I have been using em-dashes for years; LLMs have copied people like me, not the other way around! This post was not written with any AI assistance.)

Actually, this is almost a dream scenario for a coding assistant. The result is time-consuming to formulate but easy to review, which is the opposite of the way these things often go.

I can assure you with 100% certainty that humans aren’t adding a lot of value in this process. It would be wrong to believe that a human is carefully reading every line of code in dozens of updated or new library packages. The problem set is too big, the time too short, and the code too varied and complex.

Coding agents seem to be most effective when there are strong test suites that they can test changes against. Debian builds, especially of modern packages, tend to have this property. Many packages have test suites that are run during build. And, if the package builds in an isolated environment (and especially if its downstream dependencies do also), then there is a decent chance that it’s fairly correct. Maybe needing some manual tweaking here and there, but generally a successful build is a reasonable indicator.

You can argue that it would make more sense for Debian to just include dependencies in source packages, along with some version information to support security rebuilds, and I’d tend to agree with you. But we are where we are. This would be one of the more significant leaps forward in developer productivity, but it complicates things like copyright reviews.

Where are LLMs run? What is the environmental impact?

Most of the proposals seem to make the assumption that LLMs must always run in some large, hosted datacenter. As I noted in my March article, I have had credible results on even an older GPU running on solar power.

That said, it is undeniable that LLMs are fueling a datacenter boom, and this in turn is producing a significant new demand for resources. Most notably for the global scale: electricity, which is sometimes generated using carbon-emitting technologies.

Bill McKibben, who has been a leading voice in the fight against climate change since the 1980s, has made some interesting points recently: he’s noted that solar power is the fastest kind of generation we can build, and a number of large AI companies are investing heavily in solar, even to the point of fully offsetting new datacenter’s needs. On the other hand, he’s also noted that some companies are buying inefficient and dirty gas turbines. It is decidedly a mixed bag. The heavy investment in solar can have knock-on positive effects for infrastructure. Obviously, not every picture here is rosy. This analysis doesn’t touch on the real land and water use situation, either.

On the other hand, if an LLM allows me to do in an hour what I would have done in a day, that’s a day of not heating or cooling the work area — generally not sustaining a human for the purpose of writing code for Debian. HVAC energy consumption dwarfs my GPU, and I’d imagine probably also the slice of LLM energy used.

Holistically, I would have to conclude the picture is mixed. It is possible to use LLMs in a pretty green way, and also in a pretty dirty way.

Assuming Conditions Never Change

A flaw in most of these proposals is they assume that the conditions at this present moment will always hold. In fact, that the conditions at the present moment will not continue is something both AI cheerleaders and AI skeptics agree on.

For instance:

Ed Zitron has done a ton of research into the financing side of AI, and has concluded that the current model is unsustainable and headed for a significant bubble burst. I’m not positioned to personally evaluate those claims, but if that happens, what is the result? Perhaps it is a steeply increasing cost of inference for the frontier models, slower pace of training/evolution for them, etc.

In a recent episode of Oxide and Friends, Simon Willison discussed the open weight models that are now available. They have been making remarkable strides in efficiency and capabilities, to the point where $50,000 of hardware can now run high-end open weight models with capabilities that are at least in the same ballpark as the American frontier models. This puts running high-end models locally squarely within reach of universities and small- to medium-sized businesses, with power requirements that can be met with standard commercial solar and wind installations.

The lack of nuance in the more restrictive proposals is particularly concerning. Proposal A doesn’t allow “the use or assitance of… LLMs”. So it bans my solar-powered GPU. It bans using LLMs to find security issues. It bans all sorts of things that don’t seem to be ban-worthy, alongside the things that do. And it codifies it in the very hard-to-change social contract.

That proposal, and some like it, seem to imply that all LLM output is bad. I grant you that AI slop is a real and legitimate concern, and many Open Source projects have to deal with it. On the other hand, we have all seen first-hand how the security of the Linux kernel has benefited dramatically from AI analysis. It is certain that black hats are using these tools. If we refuse to use modern security tools, our security will be compromised (and what is the environmental and social impact of THAT?)

I find the statement “Generative AI is characterized by producing output of a nature that would ordinarily be produced and consumed by humans” to be particularly interesting. The same was once said of compilers.

The Real Concerns

You might think from reading this that I am some AI cheerleader. I’m not. I share the ethics of the FLOSS movement, and have for decades. I abhor the power and lack of ethics that many big names in the field are running with at the moment. I’ve had to put up Anubis on this blog, for instance.

I have personally experienced the effects of AI slop, especially at review time. This is a real problem, though I don’t think the more draconian policies are likely to help (the looser “you must disclose” stand a fighting chance, but I’m not sure they would help, either.) Done poorly, AI threatens developer burnout by overwhelming them with poor code and verbose but useless explanations. Done well, AI can help prevent developer burnout by automating tedious and low-value tasks.

Shouldn’t our goal be that humans submit work to Debian, using tools they prefer, and take responsibility for it? Does it matter if someone uses ed, vim, emacs, or vscode? If they use LSP or just run gcc manually? I’d say we benefit from the diversity. Wouldn’t we be better off to benefit from the diversity here, and judge work as we always have: on its merits, not what tools were used to create it?

Fundamentally, a GR is a long and arduous process. It’s not easy to reverse later. Amending the Social Contract is even longer and more arduous (I should know; I may have been the first one to try). The LLM landscape is fast-moving. None of us can really predict where it will be in a year. Will the current market leading companies even still exist? Will it be at all credible to refuse to use AI-assisted security tools? What is the most effective way to deal with AI slop? What level of utility will we be able to achieve with models run locally?

Some of these proposals would make sense if drafted in some way short of a GR, which would allow more maneuverability as the landscape changes.

Brief analysis of the options

Considering the proposals:

  • Proposal A: seeks to amend the social contract, which I am opposed to for reasons already laid out above. It names some real concerns about AI that I agree with, but implies that all LLM uses and models are guilty of the problems, which is not the case with all of the claims. It also sets us behind the curve on security and stability by forbidding the use or assistance of those tools, even if run by others. It requires us to ignore reports of actual security bugs, or correct fixes, if those reports were generated with the assistance of an LLM, which I find to be absolutely untenable.
  • Proposal B: This is the “AI with accountability” approach. It notes the real concerns with LLMs without painting with an overbroad brush. It strikes me as level-headed and sensible.
  • Proposal C: It paints with an over-broad brush and makes some non-binding requests. Then it winds up largely like proposal B, though while it is worded more strongly, has fewer binding requirements (for instance, it lacks proposal B’s prohibition on transmitting sensitive information to untrusted providers)
  • Proposal D: Seems broadly similar to proposal B, an “AI with accountability” approach. I’m not really clear why we need both.
  • Proposal E: Largely the status quo. It is like proposals B and D in that it says humans are accountable for their contributions. It encourages disclosure of LLM use, but does not mandate it. Like proposal B, it prohibits disclosing sensitive information to third-party AI services. Note that both proposals B and D have an appropriate nuance: a local model is fine, a third-party one is not.
  • Proposal F: This seems really similar to proposal E. I’m not sure why we have these two.
  • Proposal G: Disallows “the output of generative AI as direct contributions to Debian.” This is something of a weakened proposal A; it doesn’t seek to amend the social contract, nor does it ban all use; it simply bans the use as a direct contribution.
  • Proposal H: Ban due to climate impacts. “How is this even an argument” is disrespectful to reasoned conversation. I have already noted that LLMs can be and are used in ways that are not climate-harming. It explicitly contains no binding requirements at all, and is effectively a rant. While I agree with the sentiment that climate change is an urgent problem, and that some LLMs are exacerbating it, I disagree with that all LLM usage does so and therefore disagree with the conclusion.

In favor of nuance

I find that black-and-white thinking is almost always something to be avoided. I see it too often. I see it in politics, I see it in our software, I see it in discussions around AI. Are there deeply unethical things happening in AI? Absolutely. Are they doing some impressive things? Also yes.

We have accepted this nuance in other areas. For instance, almost all the hardware Debian runs on has closed-source hardware, and has components manufactured or assembled in countries with some of the worst human rights records on the planet. I’m not saying this is a great state of affairs. It is something we should speak up about and act upon. But the worse state of affairs would be “no Debian because the hardware is impure”.

26 thoughts on “AI in Debian: The Vote, Proposals, and Nuance”

  1. In which I attempt to have a nuanced discussion about #AI and #LLM, which I will probably regret. But whatever, I don't think that black-and-white thinking tends to be useful. So grab a cup of your beverage of choice and settle in for a reasoned conversation. https://changelog.complete.org/archives/44740-ai-in-debian-the-vote-proposals-and-nuance

  3. @jgoerzen Thanks for your text snd opninion!

    I‘m with you: I‘m not a big fan of AI. I do see the danger coming from untedtricted/unreflected use of AI, but I also do see the benefits when done right.

    IMHO AI is a disruptive technology as the computer or the steam engine was in their time. You have to deal with and to learn proper use. If you don‘t: others will do and you will mostly fall behind and detached from development.

    Debian should find a way to responsibly be able to use AI. Not banning but also overshoot the use of AI. Local LLMs should be preferred whenever possible snd sensible, alone for data protection reason.

    Not sure if it helps when I write that opinion on -devel (not subscribed to -vote)…

  4. @jgoerzen

    Guix packaging can do several things much more easily than Debian can.

    Since they support multiple versions of a package a recipe can inherit from from a different recipe and you only have to customize what changed.

    They have something like a super py2dsc that supports many many different packaging repositories.

    https://guix.gnu.org/manual/1.5.0/en/html_node/Invoking-guix-import.html

    And it mostly works.

    They don’t have debian’s requirement for a strict copyright metadata file, so examining the project metadata is often enough to package something.

    I also don’t understand what they did for rust packaging, but a they hid a whole bunch of rust crate dependencies from the rest of the packaging system.

    It is vastly easier to do rust packaging for guix than debian.

    packaging doesn’t necessarily need the full generality of an LLM, a regular program might be able to do much of it as well.

  5. Pingback: John Goerzen: AI in Debian: The Vote, Proposals, and Nuance - AILinuX

  6. @jgoerzen : thanks for clarifying the current vote. I found the options not clear at all.

    I believe myself that an human should never be forced to interact with a LLM (for input or output). In Debian, we should consider that every choice (including code) has been made by an human with which we should be able to discuss.

    If that choice was made with the help of a LLM, that’s not a problem (how could we even know). So, basically, it is accountability.

    Reply

    1. That makes perfect sense to me. It might be a tool the human uses, but ultimately the human is the point of responsibility and communication.

      Reply

  7. Diversity is a strength, and having individual minds with their own experiences and quirks contributing to a project is powerful.

    Similarly, many developers use multiple utilities and command-line tools to get things done; and each developer has their own preferences.

    Because there are few LLMs and typically they are not DFSG, we can’t adjust them, and there’s a risk of them deciding how the project evolves, instead of those distinct individual human minds.

    They and Wall Street are willing to invest a significant proportion of the U.S. GDP into becoming successful — and I don’t think that that’s because they’re likely to be successful, I think that it’s because they desperately want the levels of influence they could achieve if they are successful.

    I wouldn’t discount the environmental effects so readily, either; sometimes it’s easier to grep, find and cat to figure something out, rather than to use a model that probably required megawatt or gigawatt hours to train. It may take you longer, but you’re more likely to learn. And we will always need people to learn and understand the systems, from the basics of packaging upwards.

    Reply

    1. Hi James,

      I agree in part and disagree in part. “there are few LLMs” -> I don’t think that is true. Just look at the list from Ollama of ones that can be run locally: https://ollama.com/search Most of those entries actually represent a family of related models. “they are not DFSG” -> agreed. This is one of the interesting problems of LLMs, in that often the training corpus which might be considered source is so massive and the right to redistribute it unclear.

      “we can’t adjust them” -> disagree. There are a lot of values that can be tweaked; for instance, https://www.geeksforgeeks.org/artificial-intelligence/what-are-llm-parameters/ . But moreover, a model can be a base for additional training, either directly or with techniques like retrieval-augmented generation (RAG).

      “want levels of influence” -> for the big US names, sure. Or it might just be greed. Whatever it is, it’s not altruistic. I don’t necessarily know that is the same for the companies that are producing the open weight models. I also don’t think those motivations are necessarily different for traditional hardware companies (many of which are now also profiting from the AI space)

      The conversation about learning: this is a most interesting one to me. I have a relative that is a college professor and also a child that is a college student. I’ve seen a lot of hype in this area, but I think it’s going to change how learning happens. Hopefully for the best, but I’m not convinced we’re there yet. Oxide and Friends had a fascinating episode about it here https://oxide-and-friends.transistor.fm/episodes/ai-in-higher-education-with-michael-littman . They discussed a laboratory class at Brown University in which CS students were trying LLMs and learned firsthand about their benefits and drawbacks.

      We have long added layers of abstraction to computing. I may lament that many programmers today have never really used C, while someone from a prior generation may lament that people like me have never really written in assembly. (I had a class in it and also have used bits of it here and there, but in the scope of my career, it’s been quite brief.)

      I think you are absolutely correct that things like vibe coding don’t lead to the kind of deep knowledge that we need. I’m less convinced that people with a CS background directing an agent will be prevented from learning. I can see the opposite; for instance, if the more mundane tasks of a job can be automated away, better research, architecture, or algorithms could be developed with the newfound free time.

      Reply

      1. In terms of content redistribution:

        The training data for some of the models, as I understand it, clearly contains data that is not legal to redistribute.

        My perspective of the history of free and open source development is that it was often an uphill battle against entrenched proprietary software interests who wielded copyright law as both a sword and shield.

        That many of the companies circa Y2022-Y2026 with the largest market capitalisations seem to be able to evade those same laws — while individuals and independents are still bound by them — seems deeply unfair.

        In terms of adjusting models:

        I believe there’s a qualitative difference between being able to change the settings for a model — or to provide additional guidance during queries — compared to being able to fork the software, rebuild it bit-for-bit identically, and modify the source code and behaviour to fit any given use-case.

        For important and widespread software, I think those are essential objectives – because otherwise we can’t comprehensively identify and address the biases that will certainly exist in the software. Without applying a scientific and engineering approach to that, we risk being continually led by amplified biases of LLMs that, even if marginal in-situ, are too difficult to identify and resolve.

        My sense is that the framing of Open Weights is a defensive measure taken by newly entrenched large tech companies to deflect criticism and to garner the support of people who may understand some of the reasons why Open Source is so important — and yet, Open Weights does not, in my opinion, mean openness; it’s a misnomer. It may allow you to change the behaviour of the software, but fundamentally weights do not allow you to change the infrastructure and foundations of the software, or to disassemble it to its constituent parts.

        That is to say: I don’t believe Open Weights is altruism; it’s a deliberate framing to attempt to delay and navigate a well-funded lie through the market.

        I think that biases and blind spots already exist in the tech sector – and so I’m disinclined to click on the GeeksForGeeks or Oxide and Friends links; they may have insights that make the content feel edgy, unique or at the leading-edge, but I don’t think that they’ll contain outsider perspectives.

        I also hear your argument, I think from a previous post, that opinions are only valid after trying to use LLMs.

        I acknowledge that to some extent – but I also think that it’s an argument that softens (potentially important) resistance to LLM usage.

        For example: I know that cars can travel fast, but I also know that in many urban centres, a bicycle can get people from A to B just as quickly (or sometimes more quickly) — especially as population density increases. I also know that 80% of the U.S. population resides in urban areas; and while I admit that some people will need to use automobiles, and that transport of large quantities of goods is aided by heavy vehicles, I don’t think that people should need to drive a car to have opinions about them.

        In terms of learning and education:

        Your idea that LLMs could make thinking time available for other tasks is reasonable. Even so: that’s not an argument for allowing inscrutable, non-scientific LLMs that cannot be replicated to become the norm.

        Much of this mirrors the deployment of hardware, BIOS and firmware; a huge amount has been done to achieve reproducibility and determinism in software, but there are lower layers that were never as transparent. Just as we are getting close to being able to campaign effectively for those, an upper layer of LLMs has been added that lacks reproducibility and transparency.

        Again I think it’s similar to cars: yes, maybe there could be a net increase in efficiency, in theory, from adoption of LLMs — but in my view, that’s not the direction that things are moving in, in practice.

        I think that $500bn invested in clean energy and bicycles for Americans would have a more positive impact both for America and the wider world than $500bn on attempting to get the world to adopt nondeterministic and predominantly cloud-hosted software.

        I could have probably engaged in better-faith, but this response attempts to hear some of your points while stating some that I feel are important.

        Reply

  8. @jgoerzen Debian surely has a major deficiency when it comes to packaging recursive dependency trees, which maifests in multiple ways, and which other distributions have managed to avoid by automation or by construction.

    Papering over that by delegating grunt work to a LLM and relying on human review will a) probably remove most incentive to actually fix it and b) eliminate most of the actual added value having a human in the loop.

    1. Hi Joey, I’m with you most of the way here. I’m not sure there really is added value of having a human in a loop. As a guy that’s spent several Saturdays trying to fix up Rust and Go dependencies for my packages in Debian, I strongly dislike that work and I don’t see it as myself adding much value. Honestly, when you’ve got a dozen packages to work through, nobody is giving each of them a lot of attention.

      “removing the incentive to fix it” is an interesting point. I can see that might happen, and having processes that are easy for someone with an LLM but difficult for someone without one would be a pattern we should seek to avoid.

      The argument someone else would make would probably run like this: having those dependencies as separate packages makes copyright auditing easier, both for us and our users. It also reduces code duplication in the distro, and reduces the problem of a security fix from a source upload of dozens of packages to a source upload of one and binary rebuild of dozens.

      That said, I’m not sure that’s actually desirable anyhow; it would probably be better to have a package’s source reflect the change made to close a security hole, rather than it being more dependent on what exact package it was built against. (These languages aren’t using dynamic linking like we are used to in C).

      In any case, I’m with you in that this whole approach is broken in Debian and needs to be fixed.

      Reply

  10. @jgoerzen

    A point, however: the models need to be continuously retrained to stay current, and it seems to me that the environmental concerns cannot be dismissed as, although running can be done with minimised harm (but we should ask whether that's the representative case) there's no such example for training.

    1. You’re right that training LLMs requires a lot of resources. I’m less convinced at the need for frequent retraining. I could see, for instance, that a model that likes to write Python 2 code might need retraining for Python 3. But the LLMs that I can run locally on my decidedly pre-AI GPU can’t cram enough into my 12GB of VRAM to have it be easily obsoleted, I suspect. There are certainly some things where this would happen. I’m also quite interested in RAG (retrieval-augmented generation) and there’s a lot of work being done to tie in LLMs with non-AI systems (LSPs would be an example relevant here) to let them ingest bite-sized bits of context that inform inference. I’m far from an expert here, so you might be right, or maybe the jury’s still out on this one.

      Reply

  13. @jgoerzen As someone teaching community college students in IT, I’m at the point where I want people to have the conceptual comprehension of the code that is being created rather than it being an inexplicable deus ex machina miracle. My students that show the conceptual comprehension typically do better and just use LLMs for grunt work, if at all.

  14. @jgoerzen I think framing this issue in terms of utility is a mistake. Outside of a very small group of people (to first order, all of them paid in some way by the AI companies), the *public perception* of generative AI is overwhelmingly negative, and the *public perception* of software development organizations that endorse the use of AI *at all* is that they have sold out and are no longer trustworthy. (1/3)

    Reply

  15. @jgoerzen As such, I think Debian needs to take a hard anti-generative-AI stance *simply for the sake of its own external reputation*. The potential benefits of allowing even limited use of these tools by DDs cannot measure up to potential costs of the form “nearly all your users switch to some other distribution in disgust”. If I were a DD (which I am not and have never been), I would be voting on that basis alone. (2/3)

    Reply

  16. @jgoerzen Independently of that, it is also my considered opinion that there currently *are no large language models* that were trained in an ethical fashion. All use of such models is thus unethical as well. This to me takes precedence over the question of whether LLMs are *useful*, and so when I see the utility of LLMs treated as the most important thing, my reaction is “we need to have the ethics conversation *first*”. You might want to think about revising your essay with that in mind. (3/3)

    Reply

    1. I would argue that actually *most* LLMs are trained quite sustainably. There are very few that are not, like Grok. Most stories about coal-powered datacenters destroying water tables are just that – oft repeated stories of exceptions. There is a **ton** of LLM research happening in university datacenters that, as a rule, are powered by green electricity and often sifon the heat to the heating system of the campus.

      And “disgust” of public to AI is a bubble. Ask your hairdresser and plumber and you will find out that they have had a good experience with ChatGPT or Claude or Gemini in the last week and will have another before the week end.

      Reply

  17. Genau der richtige Weg. Projekte wie openDesk Edu zeigen, dass die FOSS-Alternative fuer den Bildungssektor produktionsbereit ist. 15+ Dienste, NixOS, K8s, alles self-hosted. Der Open Source Wettbewerb gibt solchen Initiativen eine Buehne.

  18. #Debian developers are voting on how to handle AI‑assisted contributions. The article reviews all proposals, noting that #AI can help with repetitive packaging work but also raises concerns about accuracy, ethics, and energy use. High‑level takeaway: responsible, accountable use of AI is more practical than blanket bans.

    https://changelog.complete.org/archives/44740-ai-in-debian-the-vote-proposals-and-nuance

  19. @zwol I think Debian’s reputation would take a much harder hit if it is open to hundreds of known security vulnerabilities because it refuses to process reports from people that run LLM security analysis under supervision. And not just a hit to reputation. This would be a real harm to Debian users. We have all seen how the Linux kernel has benefitted from this. With similar requirements (human verification and submission), Debian could also.

    Reply

  21. @smkellat I’d enjoy hearing about how the discussions go on that. Back in the 90s, the CS major required taking a philosophy class called “ethics and computers” which got me hooked on philosophy enough that I graduated with a philosophy minor.

    Things relating to ethics and computers have changed a wee bit in the last 30 years!

    Reply

  22. @matt This is an interesting question, and I’ll hopefully explore it in more detail in a blog post soon. I tend to look at it by analogy: as a human, I learn various ideas. Reading books isn’t itself wrong. It’s if I quote them nearly directly without giving attribution that’s wrong. By analogy, although I have issues with calling what an LLM is doing “thinking”, I think it’s reasonable to look at the output: does a given output plaigarize (using our existing standards) or not?

    Reply

Likes

Reposts

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

To respond on your own website, enter the URL of your response which should contain a link to this post's permalink URL. Your response will then appear (possibly after moderation) on this page. Want to update or remove your response? Update or delete your post and re-enter your post's URL again. (Find out more about Webmentions.)