> 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.
I stick to one agent only and so i can see what its doing and decide if that code is worthy of a commit. I think I am in the same boat as you. I do write code as well, ai has sped up my coding.
They wrote the words right there, in their post, on the page. They use it as a review process. I do too. If it makes it into a commit, I know I've looked at it and at the very least decided "this isn't too awful to commit".
This is (probably weirdly, since I've just learned that the approach in the OP is the original one that introduced parser combinators) the first time I've seen parser combinators where the parsers are just functions like this. If you want to be able to combine parsers and you don't want to write a bunch of mapping/unwrapping code, why not just use combinators over parsers assembled by a parser generator?
I think parser generators and parser combinators both have their advantages and disadvantages. For example with parser combinators you can use the already existing tools of the language. If you want the specific advantages of parser combinators, this could be a reason for not wanting to mix this.
> Sadly people from the academia [...] equate [first principles thinking] with exam based memorization or delegation to authority.
In what departments and at what universities? The term "first principles" comes from academia. I think you'd be hard pressed to find a faculty member in any philosophy department doesn't understand what reasoning from first principles is. I'd be surprised if any working mathematician thinks of "memorization" or delegating to authority rather than axiomatization. What experiences led you to say this?
Its so ubiquitous, you can pick random folks from most academia and see it first hand.
If this comes as a shocker to you, then I should be the one to enquire as to how you managed to stay blind in the face of the obvious.
Just strike up a discussion on some complex topic, and you can see many people resort to "because the author here in this book said" or "we are taught so and so".
A first principles reasoning can show you the steps that lead to a specific conclusion without invoking any author, teacher or course.
A specialist discussing a complex topic uses that as shorthand based on shared context. Nothing would ever get done if every conversation required starting from "first principles" whether inside or outside academia.
What's missing in your claim is evidence that people in academia often mischaracterize this style of discussion from accumulated knowledge and shared context as "thinking from first principles". I don't see any plausible rationale for why they would.
Otherwise, using their typical mode of interaction from outside observations to infer they misunderstand first principles is not a standard anyone doing specialized work inside or outside academia would ever be able to meet.
The private sector would grind to a halt if discussing a specific IEEE 802.11 protocol implementation with a fellow SME required a lengthy preamble of networking first principles before answering in order to be epistemologically sound.
Similarly, using a conversation overheard at a conference to infer the experts lack first principles thinking would not be reasonable just because they appealed to IEEE documents instead of rearticulating the underlying decisions made by the standards committee.
Your reasoning that first-principles results in inefficient communication is false. It is a common misunderstanding.
You can always breakdown one layer on demand. And you only need to drop down as far as the other party insists.
My example was about striking up direct conversation with someone and not overhearing.
If someone pointed to IEEE protocol and I asked "but X, so why?" and if the answer is still IEEE protocol again, then the person does not have "first principles".
That is the test. It exposes the shorthand user from the legit first-principles capable user.
Knowing what first principles reasoning is isn't the same thing as being willing to re-teach a discipline from the ground up for a stranger rather than first pointing to the existing literature that, perfectly or imperfectly, already addresses a topic.
You don't acquire it by learning or teaching about it. You don't acquire it from literature or lectures. You acquire it by being forced to do it. It requires wrestling with the problem domain.
And as you said, pointing to literature just "addresses" a topic. Obtaining it is a different matter altogether.
I get what you're saying but I think what you're describing is more of a temperament more than anything else. Some people, inside and outside academia, have a kind of "root causes" or "first principles" temperament. Others are more inclined to build incrementally on existing knowledge, and less inclined to revisit the foundations.
I think you're right that lots of people with tons of training, expertise, or experience are (sometimes very disappointingly) disinclined to engage in first-principles thinking. But I would expect most academicians to at least know what it is.
You're describing the kind of first principles thinking that gave us the Tesla car door handle. It's Silicon Valley, tech bro, smarter-than-everyone, nothing-to-learn-from-anyone bullshit.
Complex topics are built on history, on those who came before us, on attempts and failures and successes. Ignoring it is garden variety stupid.
> I'm really struggling to see how to make architectural decisions with an agent. It's great when you're at a total loss for ideas
I feel the opposite, like if I go to an agent without first knowing what I want to build, I'll never figure out what I'm doing or why and it'll run away from me.
I pretty much always go back and forth and have the agent write out a plan to a file and review it myself in my text editor. I still sometimes end up with surprises I disagree with, but I don't really find it to be true that the LLM ends up trying to "drive all of the thinking".
When I'm thinking through an architecture, I not only instruct it to refrain from writing any code, I don't even necessarily tell the agent what I'm trying to build.
In centuries gone past, members of the bourgeoisie would be directed by their doctors to summer homes and country estates so they could "convalesce in the countryside". It seems there was something to it, or at least there is now. (Even back then, it was explicitly about "fresh air".)
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.
reply