Credit Where Credit is Due

October 14, 2026 This summer, Santiago Schnell, the provost of Dartmouth college, wrote an article for The Washington Post titled Universities are fighting AI cheating. But there’s a deeper problem. The byline says it was authored solely by Schnell. On August 26, Semafor published a report in which they ran the AI detector Pangram against 310 guest articles in major newspapers and found 50 which appeared to be written by LLMs. Schnell’s op-ed was among them. The Dartmouth, Dartmouth’s inventively-named student newspaper, conducted a follow-up investigation a few weeks later, and found that the same tool identified nine of Schnell’s recent written works as being almost entirely generated by an LLM. Getting flagged by Pangram should not be considered definitive proof of LLM use. LLM-generated text is increasingly hard to avoid, so its ticks are likely to embed in your writing even if aren’t using them yourself. I also have no patience for the treadmill of identifying typographic features or turns of phrase which supposedly indicate their influence. LLMs are trained on text from the internet, and vast swaths of internet content is marketing copy written by non-native English speakers; a lot of LLM “tells” are the hallmarks of, e.g., Kenyan English. In this case, however, Pangram’s possible bias against non-native speakers like Provost Schnell (who was born and raised in Venezuela) is irrelevant, because Schnell admits that he uses LLMs extensively in his writing process. In his own words: In an email statement to The Dartmouth on Sept. 18, Schnell wrote that he uses artificial intelligence for “language refinement, copyediting, improving clarity and organization and making writing processes more efficient,” but “review[s] the final text and take[s] responsibility for its content.” “I develop ideas and arguments, conduct the research, evaluate the evidence and sources, determine the structure, prepare drafts and decide what appears in the final text,” Schnell wrote. Or at least, what I assumed were his own words—an assumption that someone at The Dartmouth had the insight to check. Schnell’s Sept. 18 email statement to The Dartmouth was itself “100% AI-written,” according to a Pangram test. In a follow-up statement about the composition of the email, Schnell wrote that he “developed the substance and wrote a draft” of the email, then “used an Al tool to assist with language and clarity, taking on several suggestions (including reworded sentences), before reading it through, making minor changes and sending it to you with my signature.” “I am fully responsible for any text under my signature,” Schnell added. Let’s put aside how astonishing it is to use LLMs to write an email insisting that you are not overly reliant on LLMs. I’d like to focus on the implicit argument that Schnell is making: that you shouldn’t care how much of the article he actually wrote, as long as he is willing to sign his name to it. I recently encountered an identical argument in the programming community. In a post on his blog, software engineer Indradhanush Gupta writes that he is no longer crediting Anthropic’s Claude on his code changes, because adding an LLM as co-author gives you a way for you to shirk responsibility for mistakes. Pressed by commenters that this sounds like a pretext for hiding LLM use, Gupta insists that it is not. He explains that he is exploring a setup where the project has a broad disclaimer that LLMs were involved, but individual changes bear his sole authorship when they reflect work I did myself and with an LLM agent but I slowed down enough to understand what it did. If there is any field in which LLM-generated, human-approved content should be acceptable, it is software engineering. Most people do not consider code a form of human expression in the same way that, say, a poem is. If a computer can automate writing code, why shouldn’t it? Society does not require software that inspires—it requires software that works. In addition, software engineering has already gone through multiple disruptive transformations in which a difficult, manual code-writing process was replaced by a more convenient, automated one. Programming languages themselves are an example of this. Below is a sample of x86 assembly that declares a routine for squaring numbers, then uses it to square the number 4. "square": push rbp mov rbp, rsp mov DWORD PTR [rbp-4], edi mov eax, DWORD PTR [rbp-4] imul eax, eax pop rbp ret .LC0: .string "%d\n" "main": push rbp mov rbp, rsp sub rsp, 16 mov edi, 4 call "square" mov DWORD PTR [rbp-4], eax mov eax, DWORD PTR [rbp-4] mov esi, eax mov edi, OFFSET FLAT:.LC0 mov eax, 0 call "printf" nop leave ret Assembly instructions are the raw inputs to a CPU. The push, mov, and pop operations control individual bytes of memory. Writing assembly is highly empowering because you are, in essence, manually controlling the computer. It is also highly inconvenient for complex tasks. Instead, computer scientists invented languages that are easier to read, write, edit, and reason about. A software program called a compiler transforms the high-level code into assembly instructions, which can be understood by the processor. The following snippet of the C programming language, courtesy of Compiler Explorer, produces the x86 assembly instructions above: #include <stdio.h> int square(int num) { return num * num; } void main() { int result = square(4); printf("%d\n", result); } I have never seen anyone claim that, after writing C code and running it through the compiler, they become the “author” of the assembly that the compiler generates. People sometimes inspect what assembly instructions their code produced. They may even adjust it to produce a desired result. But that's not what they authored—they authored the C code. Properly demarcating one's role in producing a program makes it easier to write correct software. Compiler errors are rare—so rare that a programmer’s instinct to blame the compiler instead of their own code is a common joke, even (especially) when it turns out to be true. When compilers do have bugs, however, it is incredibly helpful to know the difference between what the human wrote and what the computer generated. If we did to compilers what Gupta proposes that we do for LLMs—peel off the sticker and claim the product is homemade—we would have a far more difficult time identifying the problem at its source. The introduction of LLMs is not a novel psychological trap that makes programmers more likely to shirk responsibility by blaming their dependencies. Programmers have always done that and it has always been wrong. Jeff Atwood, the founder of StackOverflow, wrote about this in 2008, in The First Rule of Programming: It’s Always Your Fault. The flip side of code ownership is code responsibility. No matter what the problem is with your software – maybe it’s not even your code in the first place – always assume the problem is in your code and act accordingly. If you’re going to subject the world to your software, take full responsibility for its failures. Even if, technically speaking, you don’t have to. That’s how you earn respect and credibility. [emphasis his] You don’t need to steal robot valor to be responsible for your product. You can just… choose to be responsible for it. My friend Carson Gross, a computer science professor at Montana State, recently proposed a more robust practice: Software engineers who use LLMs should save a curated prose document describing the software, alongside the code that was generated from it. This effectively separates what the human intended (as captured in the prompt), what the human reviewed and edited from LLM generation (when both are credited with the change), and what the LLM generated alone (when the LLM is the sole author). Theoretically, it also allows the code to be re-generated later, based on the same prompts, but with better models. Rather than run from the implications of relying on machine assistance to produce things, we can improve the machines and ourselves by properly documenting it. LLM-assisted authors who do not wish to be labeled LLM-assisted authors deploy a variety of analogies to justify eliding the role that LLMs play in their work. In one email, Provost Schnell wrote: I regard these technologies as assistive tools. They do not […] substitute for my research, intellectual judgment or authorship. Two days later, in a different statement, he claimed that if a professional editor, ghostwriter or software editor (machine learning or AI-based) is used, they will not be acknowledged in the publication. First, the role that LLMs play in your writing process cannot be analogized to both an assistive tool and a professional editor at the same time. Either they function like a pen and a dictionary, tools which do not operate autonomously, or they operate like a second person reviewing your work, one who might exercise independent judgement, offer new ideas, and influence the final product. The latter is more consistent with how Schnell describes his own LLM use: improving clarity, organizing the text, and offering suggestions on how to express ideas. Schnell’s mixed metaphors suggest that he himself does not have a firm grasp on the extent to which AI is influencing the work he produces. To the detriment of his credibility, this is a widely relatable feeling—most of us have working experience with these products and we know how eagerly they produce text. LLMs are more than willing to substitute for your authorship and judgement; it requires substantial effort and personal restraint to keep them from doing so. Insisting that your undisclosed LLM use remains circumspect is a bit like insisting that your covert nuclear program is only for energy production. Maybe that’s true, but then why did you hide the facility? Can we inspect it? You sure seem to have a lot of centrifuges.