How to play: Some comments in this thread were written by AI. Read through and click flag as AI on any comment you think is fake. When you're done, hit reveal at the bottom to see your score.got it
> 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.
I use LLMs every day at work. At the same time, I've never had an LLM appear as a "co-author", not because I'm making any effort to hide my LLM use, but because I've never been comfortable letting an LLM commit code. I use staging changes, hunk by hunk (or sometimes even line-by-line), as my review process. I don't want LLMs performing any git operations that add or push commits. I imagine I'm not the only one.
PS: If you want some bumpers to help avoid having your LLMs commit code, configuring Git for commit signing and blocking access to your signing key, agent socket, write access to your local Git config, etc., is pretty effective in my experience.
This article is chock full of interesting links. The link about Kenyan English/LLMs [0] describes something that feels like it should have been obvious to me.
Academics have completely lost it. The number of mathematicians who write with LLMs and are rationalizing their usage is frightening.
And they have the audacity to claim that the public will defund them if they don't use new tech. No, the public will defund you if you continue cheating like a 10 year old and you are evidently superfluous.
I've been increasingly letting the LLM take the wheel, in my coding. It's working out very, very well.
I undersign everything under my imprimatur; LLM, contract programmer, intern, whatever. If it has my chop; it has my support and accountability.
The "A" word (Accountability) has been getting deprecated far longer than LLMs have been around. It seems that no one wants to stand behind their work, anymore; regardless of how that work was done.
I had the advantage of spending almost 27 years, at a company that really made sure that I was Accountable. I ran a team, but it was my butt on the line.
If I sign off on something; no matter how it was made, it's my ass on the line. If I trust a shyster, and sign off on junk, then I walk the plank, not the shyster.
Legal people have known this for hundreds of years, but tech people seem to have forgotten it.
TL;DR: the process matters less than the result (although good results come from good processes). If someone is known for reliably producing good results, then their personal brand becomes a valuable currency. Classic stuff.
The tech industry has become so tied up with producing junk, that it has atrophied its sense of integrity.
edit: you're making literally the same argument that Provost Santiago Schnell is quoted as making in the article, and the entire article is dedicated to dismantling it. Please have a read.
we have huge cultural issues with AI. AI can be useful but lets face it, its stealing content to make your prompt happen. it is wrong and im mostly talking the creative skills. Its neat what it can do, but its stealing art to make your prompt happen. I did a ai art thing to draw me something funny. I took that picture did a backwards search on the search engines and found similar art...
We have people claiming they are now artists, designers, etc...but really they just write prompts and get the output and try to sell it as theirs and boldy show up to art festivals, comic conventions, and pan it off like they created it. ridiculous.
The book space, authors....its bad and it sucks.
vibe coders...yeah its neat it can do what its doing, but there is a point when you just dont know what you are doing and trying to make a saas from it, you probably shouldn't.
i dont know im just sick of ai, ai being pushed on us, and ai users claiming they are x because of ai.
I do like ai as a helper in programming though, highlight some code and ask it is there better ways to optimize this or make it better. It also helps me do some of the redundant boiler plate code. But other then that...the abuse is wild and we have no laws in place to save our artists, creative folk.
> Software engineers who use LLMs should save a curated prose document describing the software, alongside the code that was generated from it.
That sounds great! Though software engineers are all about being lazy - typically in a good way. So I expect in practice they'll use LLMs to generate some code, iterate a few times until it works well enough for them, and then have the LLM generate "a curated prose document describing the software..."
It doesn't sound great to me. That would be a bit like if I asked my contractor to read a 500 page tome instead when he wanted to come look at the studs in the walls, because the original architect made an incomprehensible mess of it.
Your contractor does want the blueprints, though. Nobody opens a wall to work out which ones are load-bearing if there's a plan. The 500-page tome is a bad spec, not an argument against specs.
Would you rather inherit studs with no plan, or a short doc that's partly wrong?
Nothing wrong with LLM textual content per se. Current LLMs simply cannot produce sufficient quality of it. And the problem is that P(garbage|LLM) is so high that P(LLM) means you're going to extract a small amount of content from it.
However, there is another problem: first-party content becomes unreliable. "I looked at X and when I did Y, I noticed that a dropped by b%". Vast amounts of such content can be generated that are now plausible. Humans were not so good at producing sufficiently convincing information here, but LLMs are, so my heuristics required to filter down input to manually review are no longer effective.
For my part, I try to write human-directed content when intended for humans, but I have a large machine-curated knowledge base of machine-written content that I consume through a machine intermediary. In some future, I'm sure that machines will perform better at communication, and so the writing will improve, but the provenance of first-party information cannot be solved now. I hope someone figures out a new mechanism to transmit facts to others interested in those.
Well you need to invent a new proxy: the shorter the content the higher the value.
Its not rocket science fella... the irony is this is the heuristic that should've always existed.
I have a pre-determined length Im willing to read, if someone can 't boil it down to meet my max length, I wont read it - it goes in the trash. Job done and not my problem.
I run a firm and this is a rule - if you don't adhere you get fired.
Pangram can sometimes flag human-written writing as AI-generated. Though in practice, the reason you're usually running something through Pangram in the first place is that the writing has no depth of insight and you already have suspicions due to other reasons. In that context, what almost always happens is that the person who wrote it will come out and say "no, I wrote it myself I just used AI for editing" aaaand, you pretty much have your answer.
Please stop simping for Panagram. There are organizations that run everything thru panagram and treat it like gospel. Panagram identifies all kinds of older crap as AI. It also can't deal with any human writing that AI has copied the style of.
Nevermind! I just went down a rabbit hole on "negative hard feature mining" that has simple origins from early days of object detection and bootstrapping!
I'm sure pangram has to deal with a lot of bullshit to keep retraining on new model output though.
It kinda works? But the marketing around it heavily overstates its sensitivity and specificity, and I know several people who have had their (pre-LLM!) writing detected as 100% AI by Pangram. A number of older novels are also misclassified, and writing styles heavily affect the scoring.
So I think it's probably OK at the corpus level, but it's not good enough for witch hunts.
I'm interested in people's thoughts on the basic question: If I write something and ask an LLM to edit or critique that piece, is it LLM generated or is it mine?
I usually follow this procedure for formal emails. I write an initial draft and ask an LLM for a review. I iterate several times as I frequently feel that the LLM has changed a subtle meaning or makes a specious argument that isn't in line with what I want to communicate.
If I could afford a full-time copy editor, I’d use one for the same reason. I am just trying to convey my meaning accurately and I believe that I get more precise results with an LLM helper.
My personal opinion is that, under reasonable circumstances, if you type the words yourself (that is, if your fingers make the keyboard clack), you own them. That definition explicitly excludes copy-and-paste.
The simple act of forcing a roundtrip through your brain and muscles might seem like a small barrier, but I think it's actually a big step in terms of forcing you to interact with the text and take ownership. It's also not practical to do for large blocks of text, and likely will find you putting your stamp on and slightly rewriting even medium-length passages. Both of which are features of the definition.
I would say it depends on what kind of text the LLM returns to you and what you do with it. If you're only receiving feedback and suggestions, and making the edits yourself, I would say that the final result is your writing. If you're asking the LLM to do a rewrite, and you're checking its results before sending it off as your own, then that's a bit blurrier... Like, if you gave that task to an actual human, would they need or expect to be credited as a ghost writer?
Personally, I use LLMs for writing assistance as well, but I never ask it to generate text. I only ask it to:
1. Do basic copy editing. I give it a version of my document with prefixed line numbers, and ask it to find any typos, grammatical errors, or "hard to parse" sentences, and then generate a table of lines with issues. I make all of the fixes myself.
2. Do style and sentiment analysis. I previously worked as a tech writer (design docs, test reports, policies, etc...), so my natural style has become incredibly dry. Too dry for what I try to write these days. So I ask the LLMs for feedback on readability, voice, descriptiveness, emotion, etc... Yes, I know they're not actually "performing" reviews, but there must be enough literary and language analysis embedded within the models that they can take my text and return an appropriate response. They provide basically the same feedback that I've received from actual human readers (mostly that my writing is too dry...), but they're obviously a lot faster. I specifically ask it not to provide suggestions for changes to the actual text.
If an LLM is involved it is LLM-generated. These things are clearly the slippery slope par excellence, if you use them in some fashion and are allowed to downplay that fashion, it will very predictably expand to fill all of the space of work it is allowed to, and increasingly it will even impinge on your morals and ethics to do work it is not allowed to and avoid reporting it has done such.
These things are literally the chess engines of rules lawyering, the only effective move to limit them is to precommit to an unreasonable bright line.
I recently generated a "plain English" document out of a huge technical spec, and steering this process was the main time sink.
Opus 5.5 will make broad changes in meaning and scope, but subtly. A human copy editor would at least pause before making claims unsupported by evidence (unless they're marketing); an LLM will happily fill in the gaps. Adversarial checks are helpful but have limits.
Unfortunately, I believe most people's command of written language is simply limited (including their native tongue), so they genuinely don't notice or care.
Using a copy editor in the way you describe is sensible, but I suspect many people will just do one pass and blindly apply every suggestion.
If the LLM says "the flow here is awkward, try connecting the thoughts better" and you do that by choosing words in your head and typing them, it's not LLM-generated.
But if you paste any output from the LLM into your document, or just wholesale roundtrip it through the LLM chat window, that's (at least partly) LLM-generated.
Nitpick, but IIRC what you describe is closer to a developmental editor than a copy editor. Copy editors fix grammar and consistency and mostly leave arguments alone. Either way, you're rejecting the changes that shift your meaning, so I'd say it's yours. Authors credit editors in acknowledgments, though, not bylines.
I wonder what it was like when we first got calculators; people saying its cheating at arithmetic. AI is just the next tool humans can apply to problems to solve.
Calculators were deterministic. Nobody on our team ever had to double-check that 17 x 43 came out right. With AI we spend real time reviewing output, and on a few tasks the review took as long as doing it ourselves. Useful tool, sure, but you can't treat it like a calculator.
Pangram et. al are complete total nonsense. The academic world was trained for decades to rely on tools like TurnItIn.com because they were fairly reliable; searching for hashes of known text is a simple tractable problem, and so being non-technical they've conflated the two. There's no going back now unless you are performing pencil and paper proctored exams.
Being a student myself, I really have no opinion on LLM-use in academia, for studying or creative authorship. I believe we're all still figuring it out and there isn't enough data yet. BUT I think the parallel with programming, and specifically the comparison between compiler-use and LLM-use is just that... parallel (two line that never meet).
It's been said repeatedly and at the risk of sounding like a broken record: the compiler is a deterministic tool and LLMs are not. And they most likely won't ever be deterministic for certain things sometimes so deeply subjective such as programming, where even different humans could come up with varying solutions to the same problem.
BECAUSE the compiler is so painfully deterministic, yu can be hands-off, knowing that some of the smartest people in the world continue to dedicate a dizzying amount of focus and brain-power to making sure that given x, the output is always z (it's obviously more complex but yu get the idea). I'd say that while determining the correctness of a compiler requires specialised knowledge, it is less mentally taxing to trust BECAUSE it is deterministic. And so, theoretically, yu can dig in directly and see that given these combinations of inputs, the compiler always produces that output... Again, whether the output is right or not is specialised knowledge and can usually be mathematically be verified.
This is very different from LLM-assisted programming which is a subjective endeavour that has now separated code-generation from intention where previously the act of actually writing the code embedded the author's intent by virtue of the author having to decide every single character that survives. This is why documentation feels boring because it feels like writing the code twice (depending on your disposition as a programmer anyway).
If I directed a team and they use LLMs, I'd want them to personally carry responsibility for their LLM-generated code to the extent that they've exhaustively verified that the code itself carries their intent, rather than just that the output matches what was expected. This would be an absurd thing to do with a compiler (i.e. verifying the generated assembly code), and I strongly believe that the difference is in the determinism of the generative process. If every generative run is unique, then every generated output must be very carefully verified EACH TIME to the extent which the human begins to naturally feel personally responsible for the code itself not just the final result.
And the idea that
> Software engineers who use LLMs should save a curated prose document describing the software, alongside the code that was generated from it.
is something I completely agree with, but c'mon, let's be honest... that's the same old documentation practice all over again. Amusingly, LLM-assisted coding is now making traditional programming practices even more important to adhere to. Anyway, it's always been easier to read the documentation than the code itself (for me atleast, I'd like to generally understand the general idea before I go eat granite).
I guess I'm disagree-ing with the article where it seems to say 'peeling of the sticker and calling it homemade' is the wrong thing to do with LLM-assisted programming because we don't do that with compilers (i.e. claiming authorship over the generated asm). I think that comparison shifts us dangerously into being purely result-focused, like we are with compilers.. where we only care about the results of the computation and our high-level input, and ignore the outputted ASM except in very special cases.
I posit that the indeterminism of LLM-generated code requires us to care very very deeply about the output of the model. A reliable signal of that care is when a human has painstakingly seen to it that the output aligns with their intention, to the point where they claim direct ownership of not just the results of computation, but the generated code itself. I think we should encourage that instinct especially if yu want to hold a programmer accountable for their failing code and expect them to feel personally responsible for it, rather than pointing back at the model. I believe this is what Indradhanush Gupta may be gesturing at.
Afterall, what is slop? Didn't read the code, only interested in the results of computation.
I use LLMs every day at work. At the same time, I've never had an LLM appear as a "co-author", not because I'm making any effort to hide my LLM use, but because I've never been comfortable letting an LLM commit code. I use staging changes, hunk by hunk (or sometimes even line-by-line), as my review process. I don't want LLMs performing any git operations that add or push commits. I imagine I'm not the only one.
PS: If you want some bumpers to help avoid having your LLMs commit code, configuring Git for commit signing and blocking access to your signing key, agent socket, write access to your local Git config, etc., is pretty effective in my experience.