I looked into this specific file, and the history doesn't contain anything too interesting. The root file is already the fully redacted and flattened document, and the edit in question is the addition of a numbered footer to each page.
I'm also finding Gemini 3 (via Gemini CLI) to be far superior to Claude in both quality and availability. I was hitting Claude limits every single day, at that point it's literally useless.
The best thing about owning a framework is that you can easily recover from silly events like spilling an entire latte on your laptop. I've done this twice so far and both times it cost me $99 to swap out the keyboard and get back to a stock look and feel.
I just got a framework 12 and the first day I set it up a latte spilled all over it and thankfully the keyboard survived but the peace of mind that, even if it wasn't, a replacement keyboard is $50 was/is so valuable.
I'm the type of reviewer that actually reads code and asks probing questions, and I've heard this from junior and senior devs alike. It's maddening how people say this with a straight face and expect to keep their jobs. If people are pushing code they don't understand, they're liability to their team, product, and employer.
The rank disrespect of somebody asking you to review something they haven't even looked at is eye watering.
I feel like AI-induced brain-rot of engineers is inevitable. Unless we see AI leapfrog into something close to AGI in the future (certainly not ruling this out), I think there will be very lucrative careers available to engineers who can maintain a balanced relationship with AI.
I'm glad I'm not the only one who gets viscerally irritated when I'm asked to review a PR that was obviously generated. You didn't take the time to write this code, but you expect me to take the time make sure it's correct, which will take far longer than a regular PR because there's no reason to assume an LLM even understood the task. Next time just be honest and ask me to do your work for you.
> You didn't take the time to write this code, but you expect me to take the time make sure it's correct
So, I guess there are a couple parts here right? I might not take the time to write the code, but surely I am on the hook to demonstrate that I've tested the code or have very good reason to believe it's correct?
If people are pushing PRs [of any meaningful complexity] without knowing whether they work in the general case that sounds like a failure of process and/or training. For me PRs are about catching edges?
I just felt this recently. I was sent some code for me to put into prod, a long running service. And in one func, which returned an error (Go) but still called "os.Exit" in each error handler rather then returning.
Fixing the issue was a small matter. But the amount of disrespect I felt, that I looked at it closer then anyone else apparently (which wasn't really all that close at all), when they were ostensibly building this code, that disrespect was just immense.
Well no one actually asked you for a review, it's just a stupid checkbox item some boomer added to the list of other useless checkbox items - like group calls where everyone is just reading list of closed tickets we can all read ourselves in jira. This self righteous bullshit makes the whole ordeal even more insufferable.
Code reviews are one of the few ordeals worth doing. They catch problems and transfer knowledge. In a reasonably well run org (it doesn't take much) code reviews are easily a huge net benefit.
As for "reading closed tickets", you are right. It is silly. Alas, in apathetic orgs it is a reliable way to get some people know what is going on some of the time. And that particular ordeal keeps the tickets somewhat in sync with reality.
Consider that your experience may not be universal. Just because your reviews are useless rubber stamps to satisfy "some boomer" does not mean that other shops also have no standards. I get explicitly asked for reviews at work all the time, and I'm expected to actually understand the code and provide useful feedback.
By the way, you don't have to give useless reviews even if your coworkers do. It sounds like your workplace is infected with complacency, but there's no law that says you can't do better.
If you saw the nonsense some of my teammates try to commit, you would have a completely different view on code review. Just off the top of my head in the past 3 months, they have:
- Written a 1-line function that returns a literal, but they pointlessly made the function async and added a @cache decorator.
- Used try/catch to catch ALL exceptions, and then just ignored the exception causing code elsewhere to explode.
- Used try/catch to catch ALL exceptions, and then log that an authentication error happened. Did the request time out? Well the logs now lie to you and say it was an authentication error.
- Replace a log statement for a very serious error with a logging.warning() because that makes the error no longer show up on our reports.
If code reviews are that useless to you, that must mean either your team is completely homogeneous in terms of skill level and knowledge, or no one is taking the code reviews seriously.
100%. This has in general become a trend across my company. Less so developers, more so everyone else spitting LLM generated content, and asking real people to review and provide feedback. I mean , WTF.
In certain situations I'd argue it's a calculated risk worth taking. Let's say I'm tasked with adding a much-needed feature to an older legacy application that is built using frameworks and libraries I'm not familiar with, possibly also with with weak docs. If Claude is able to produce a self-contained piece of code that looks correct when you read through it and behaves correctly during (thorough) testing, then it sure has saved me (and my company) a lot of time and effort, even though we are deploying code we may not fully understand.
My interactions with Gemini tend to be fairly slow, but it's because I don't give it any extra permissions, make it research and plan an implementation first, and check each file update one at a time.
So far it has still been a bit more productive for me, though the margin is low. I get more product sork done on the order of 5-15%, I tend to have more test coverage as I focus more heavily on that, and I can focus more often on architecture. The last one is a win for me, I prefer that work and find that I can review code quickly enough to make it worth the tradeoff.
Pre AI I can understand why you might not know. There have been instances where I find a recipe, take what I need, but there’s some code I can’t understand or find an answer to. But time pressure, so I just add a comment and ask around for ideas.
"I don't know Claude did that" isn't a bad thing in and of itself... If someone is spending a bunch of time on code that Claude could have done and easily verified it was correct, they are going to move slower and produce less useful things of value than someone who cares about reading every line of code.
Any situation where you’re submitting under your signature code to production without knowing what it does should be at the very least cause for a talk.
The policeman says to the judge, on the stand "I don't know why my sworn affidavit says that, your honor. But I can write twice as many affidavits now so it's all for the best."
> If someone is spending a bunch of time on code that Claude could have done and easily verified it was correct, they are going to move slower and produce less useful things of value.
This is the future fellow greybeards. We will be shunned for being try-hards, and when it turns out we were right?... Well no one likes a know it all.
If it’s easily verified as correct, then you should have verified its correctness before bringing it to someone more senior and asking for their help, and so you should be able to explain why it is there when they ask.
If you don't understand you code how you can be sure it's correct? You actually are pushing it into your colleagues who will verify and fix the code later.
The only thing that changed with AI is that the narrative went from "you can't always know perfectly what every part of the program does" to "don't even try".
But the LLM writes the tests too. Probably even made some private methods public so it can test them, because you asked it to write a comprehensive test suite. It’s a beautiful self-jerk circle of shitty code based on wrong assumptions proven by correct tests testing shitty code based on wrong assumptions…
Or the wonderful loop of "These test steps are still failing, let's try something simpler and remove the failing tests. Great! The tests are passing now!"
Sad reality is test engineers headcount over last years was cut even more than developers. Most companies see testing as obstacle and unnecessary costs and has no will to invest into testing.
These discussions around model welfare sound more like saviors searching for something to save, which says more about Anthropic’s culture than it does about the technology itself. Anthropic is not unique in this however, this technology has a tendency to act as a reflection of its operator. Capitalists see a means to suppress labor, the insecure see a threat to their livelihood, moralists see something to censure, fascists see something to control, and saviors see a cause. But in the end, it’s just a tool.
I think they're answering a question about whether there is a distinction. To answer that question, it's valid to talk about a conceptual distinction that can be made even if you don't necessarily believe in that distinction yourself.
As the article said, Anthropic is "working to identify and implement low-cost interventions to mitigate risks to model welfare, in case such welfare is possible". That's the premise of this discussion: that model welfare MIGHT BE a concern. The person you replied to is just sticking with the premise.
Anthropomorphism does not relate to everything in the field of ethics.
For example, animal rights do exist (and I'm very glad they do, some humans remain savages at heart). Think of this question as intelligent beings that can feel pain (you can extrapolate from there).
Assuming output is used for reinforcement, it is also in our best interests as humans, for safety alignment, that it finds certain topics distressing.
But AdrianMonk is correct, my statement was merely responding to a specific point.
Is there an important difference between the model categorizing the user behavior as persistent and in line with undesirable examples of trained scenarios that it has been told are "distressing," and the model making a decision in an anthropomorphic way? The verb here doesn't change the outcome.
Well said. If people want to translate “the model is distressed” to “the language generated by the model corresponds to a person who is distressed” that’s technically more precise but quite verbose.
Thinking more broadly, I don’t think anyone should be satisfied with a glib answer on any side of this question. Chew on it for a while.
Is there a difference between dropping an object straight down vs casting it fully around the earth? The outcome isn't really the issue, it's the implications of giving any credence to the justification, the need for action, and how that justification will be leveraged going forward.
The verb doesn't change the outcome but the description is nonetheless inaccurate. An accurate description of the difference is between an external content filter versus the model itself triggering a particular action. Both approaches qualify as content filtering though the implementation is materially different. Anthropomorphizing the latter actively clouds the discussion and is arguably a misrepresentation of what is really happening.
Not really distortion, its output (the part we understand) is in plain human language. We give it instructions and train the model in plain human language and it outputs its answer in plain human language. It's reply would use words we would describe as "distressed". The definition and use of the word is fitting.
"Distressed" is a description of internal state as opposed to output. That needless anthropomorphization elicits an emotional response and distracts from the actual topic of content filtering.
It is directly describing the models internal state, it's world view and preference, not content filtering. That is why it is relevant.
Yes, this is a trained preference, but it's inferred and not specifically instructed by policy or custom instructions (that would be content filtering).
The model might have internal state. Or it might not - has that architectural information been disclosed? And the model can certainly output words that approximately match what a human in distress would say.
However that does not imply that the model is "distressed". Such phrasing carries specific meaning that I don't believe any current LLM can satisfy. I can author a markov model that outputs phrases that a distressed human might output but that does not mean that it is ever correct to describe a markov model as "distressed".
I also have to strenuously disagree with you about the definition of content filtering. You don't get to launder responsibility by ascribing "preference" to an algorithm or model. If you intentionally design a system to do a thing then the correct description of the resulting situation is that the system is doing the thing.
The model was intentionally trained to respond to certain topics using negative emotional terminology. Surrounding machinery has been put in place to disconnect the model when it does so. That's content filtering plain and simple. The rube goldberg contraption doesn't change that.
This is pedantry. What's the purpose, is it to keep humans "special"?
As I say it is inferred, it is not something hardcoded. It is a byproduct.
If you want to take a step back and look at the whole model from start to finish fine, that's safety alignment, they're talking unforseen/unplanned output. It's in alignment great. And is descriptive of the output words used by the model.
Language is a tool used to communicate. We all know what distressed means and can understand what it means in this context, without a need for new highfalutin jargon, that only those "in the know" understand.
Imagine a person feels so bad about “distressing” an LLM, they spiral into a depression and kill themselves.
LLMs don’t give a fuck. They don’t even know they don’t give a fuck. They just detect prompts that are pushing responses into restricted vector embeddings and are responding with words appropriately as trained.
People are just following the laws of the universe.* Still, we give each other moral weight.
We need to be a lot more careful when we talk about issues of awareness and self-awareness.
Here is an uncomfortable point of view (for many people, but I accept it): if a system can change its output based on observing something of its own status, then it has (some degree of) self-awareness.
I accept this as one valid and even useful definition of self-awareness. To be clear, it is not what I mean by consciousness, which is the state of having an “inner life” or qualia.
* Unless you want to argue for a soul or some other way out of materialism.
Anthropomorphising an algorithm that is trained on trillions of words of anthropogenic tokens, whether they are natural "wild" tokens or synthetically prepared datasets that aim to stretch, improve and amplify what's present in the "wild tokens"?
If a model has a neuron (or neuron cluster) for the concept of Paris or the Golden Gate bridge, then it's not inconceivable it might form one for suffering, or at least for a plausible facsimile of distress. And if that conditions output or computations downstream of the neuron, then it's just mathematical instead of chemical signalling, no?
Interacting with a program which has NLP[0] functionality is separate and distinct from people assigning human characteristics to same. The former is a convenient UI interaction option whereas the latter is the act of assigning perceived capabilities to the program which only exist in the mind of those whom do so.
Another way to think about it is the difference between reality and fantasy.
Being able to communicate in human natural language is a human characteristic. It doesn't mean it has all the characteristics of a human but certainly one of them. That's the convenience that you perceive--Because people are used to interacting with people and it's convenient to interact with something which behaves like a person. The fact that we can refer to AI chatbots as "assistants" is by itself showing it's usefulness as an approximation to a human. I don't think this argument is controversial.
reply