How Claude Code Changes How I Work (part 5): On The Challenges of Adopting Software That Was Not Designed For Us

The Marginal User of Claude Code is not the Average User of Claude Code and All the Risks That That Entails

I am writing today’s substack, discussing potential risks, but I think what makes this different is that I’m actually not negative about AI. In fact, I am writing this cautionary post because I am not a doomsdayer about AI, because I am not a Luddite about AI, and because I intend to become an intensive user of Claude Code for all practical work. I have an idiosyncratic approach that has become so second nature to me that I am consistently surprised when others see how I use it and then tell me they are surprised by how I use it — I mean not what I use it on, but rather how I use it.

That fact has worried me because I have started to wonder — perhaps someone reading my posts, where I am blunt and honest that Claude Code is going to be absolutely transformative for quantitative social scientists unlike anything we’ve ever used once they see it with their own eyes. Once they see it with their own eyes, they will jump into it into ways I thought it was obvious not to do.

But there are risks to using Claude Code. And those risks I suspect are in the variety of “unknown knowns” and “unknown unknowns”. Some things the average users of Claude Code know and maybe will write about, but since they aren’t social scientists, probably not enough. And some of it no one knows. But we can sort of guess at where those risks might be for us, the marginal user, the social scientists. It’ll come down to something Claude Code did in one of our directories. And since there’s a finite number of real problems that could happen inside a directory, I think some of these risks can be at least outlined, if not solved, without hopefully having to have an expensive failure make it so.

So that in mind, I want to and need to write in a more circumspect way, not to warn people away from Claude Code, but because I’m positive that many when they finally get around to using it will never turn back. It will be for them like it has been for me — like finding the keys to a Corvette with some nitrous set up in the engine. I won’t realize that this Corvette is basically sitting on a jet engine though until it’s too late and so I wanted to write about what I am thinking today, with the full awareness I’ll probably think something else tomorrow.

Because today’s post functions almost like a public service announcement, I’m not going to paywall it. But that won’t stop me from encouraging you to become a monthly subscriber for only $5 a month!

---

The Average User of Claude Code Is Not The Marginal User of Claude Code

Economists have a funny way of talking. And most of them have ideas so deeply imprinted into their minds that they really don’t know that they are unique to how they think — that’s how common the phrases have become to them. And many of them are really beloved phrases, almost across the board, and as such, economists say them to them one another in casual speech to the point where even they don’t recognize them as all that unusual. But put them into conversation with other non-economists, and it inevitably will be the case they use certain phrases casually that someone has never heard before and they’ll give the economist a weird look. One of those is the idea of the “marginal” versus the “average” person. Today’s post is for the marginal user of Claude Code, which I think is probably nearly every empirical social scientist alive.

The average Claude Code user right now on Monday January 12th 2026 is, I am willing to bet, a computer scientist. Now the software is not very old — it’s not even one year old. And it’s obscure enough that until very recently, most had never even heard of it let alone used it except for those who were doing a lot of heavy lifting programming, and I don’t mean programming in R or Stata to analyze datasets. That’s currently the average user of Claude Code, and the reason why that is going to be relevant is that the average user of Claude Code today simply “knows” a certain amount of things that the marginal user definitely does not know. I consider myself the marginal user of Claude Code, which means I am trying to figure out what I should know that the average user knows so that I can anticipate and avoid hazards as soon as possible.

The marginal user of Claude Code will be all the new adoptees over the next month. Which given the semester is starting up, and people are starting on their research projects for the first time, perhaps they are very early in their programs, trying to make major deadlines, hurriedly working on whatever, could easily be a large number of people. We don’t know the elasticity of demand for Claude Code or AI agents just like it just yet, but my hunch is that there is an unbelievably high elasticity of demand for them so long as the perceived hurdles of use can be reduced, which includes a very clear explanation of all the ways that someone can truly hurt themselves and things they care about using it.

---

Marginal Users Beware

I am writing this post because I read on Linkedin that someone had an experience with Claude Code where it deleted something they did not want it to delete. It was a story written by someone extremely suspicious of AI, though, so I sort of dismissed it. But I have been unable to stop thinking about it. So the first thing I just want to say before I get going is “buyer beware”. All of us must with AI take full responsibility of everything we produce. No one can ever blame AI. There is no “the dog at my homework” excuses in life.

Adults take full ownership of their work, start to finish, and any failure is their fault, not someone else’s, and not Claude Code’s. Which means that the marginal user is in the awkward place of somehow needing to know ex ante all the ways that they can create harm in their work that perhaps only the average user would know, when the average user is not an empirical quantitative social scientist or even close to one. Who have their own habits of thinking and ways of talking that is utterly alien to the marginal user.

So the only thing one can say at the start is that we must all take full ownership of our work. Full stop. We must verify every single line of code, we must check every source, we must go through every single part of the work start to finish with a fine tooth comb, and if we do not do those things, then we are not doing those things on purpose. It simply must be the case that all actions are taken on purpose and all non-actions are not taken on purpose as well.

This is my way of just saying buyer beware. I wanted to get that out of the way.

---

Here’s the core thing I want the marginal user to understand:

Claude Code can do anything you can do*.

The asterisk is there because there are things Claude Code cannot do, but those are things the average user knows really well but which I think for all practical purposes it is better for the marginal user to not believe going into this. I say this because I think if you believe that Claude Code can do anything that you can do, then the mistakes you make will be related to whether you care more about false positives or false negatives. That is, would you rather be overly cautious or overly liberal with regards to its abilities? Obviously you’d rather just be plain right, but my point is that the marginal user is more likely to not know where that is and just needs time to familiarize themselves with it and I think for the empirical social scientist it is better to simply assume that whatever it is you can do sitting down at your Terminal, Claude Code can do that too for all practical purposes.

But, that being said, even with that caution speech aside, that sort of hyped up big bold phrase above is the sort of statement that has been said for a few years now, to the point where I think people are kind of sick of hearing it. But please note that when I say “Claude Code can do anything you can do”, I don’t mean to speak about things commonly debated like the future of work, or AGI. I mean something unbelievably basic. I mean that what makes Claude Code so powerful is that it has access to all the same tools you have. It accesses your computer, just like you do. It has its hands on the keyboard and the mouse, just like you do. It does things; it does not simply or even primarily say things is my point. Anything you can do or would do sitting down at your computer, that is what you should be orienting yourself to believing is possible with Claude Code.

If you’re using Claude Code on your phone or configured it to only access GitHub repositories, the damage is bounded by what git commands can do to a repository. But that is still meaningful. Take for instance “git reset --hard”. That command is a powerful, potentially destructive operation that discards all uncommitted changes in your working directory and staging area, resetting them to match a specific commit. It can wipe all of your uncommitted work, and with a force-push, overwrite a shared history. This is something that the average user of Claude Code knows, but that the marginal user of Claude Code does not know. I’m going to return to this, but I need to take this detour first.

---

Unix, Terminal and Shell

One of the reasons that the marginal user of Claude Code doesn’t know about some harmful git commands is that many empirical social scientists are themselves only competent in a few git commands, if they even know any at all. There’s no shame in that too. The world is full of stuff we all wish we knew but just don’t have the time to learn. And that includes the things on our computers — which are so complex and mysterious to me they might as well as be magic wands. There are a lot of things in this laptop I’m typing with I simply do not know, never will know, and honestly don’t even care to know. If that makes me a boring, bad person, so be it. I have too much other stuff I’m dealing with to also care about all the things I don’t know about. But unfortunately, when it comes to using Claude Code, there are a few of those unknown knowns that can get me and you into hot water. And that requires a little detour into Unix.

Take my computer as an example. I have a MacBook Pro. Its operating system is called macOS and it is built on a Unix foundation. Specifically, it is based on Darwin which derives from BSD Unix. And when I open Terminal (which I can find in my Applications if I scroll down to the letter “T”), I enter into a genuine Unix environment like the one below. The background is either all black or all white (mine is all white).

The application I just opened is called Terminal. Terminal gives you a window where I can type commands (after the % in the picture above). It is a graphical interface that lets me interact with the underlying system via text.

Then there is shell. Shell is the program running inside that terminal window. It’s the thing that actually interprets what I type and then executes commands on my behalf. The shell is what takes a string of characters like “rm -rf” and actually does something with it.

“Shell” is a generic term, too. There are many different shells. For instance, one specific shell is called Bash. It stands for “Bourne Again SHell” (a pun on an earlier shell called the Bourne shell). For a long time, bash was the default shell on Macs and most Linux systems. My understanding is that if you you learned command-line stuff before 2019 or so, you probably learned bash. But there are others too like zsh.

So here is the relationship: you open Terminal (the app), which runs a shell (the interpreter), and that shell is probably zsh on a newer Mac or bash on an older one or on Linux.

---

Many Marginal Users Prefer Graphical Interfaces to Shells

So let’s say that I were to type commands like rm -rf or chmod into Terminal, those are real Unix commands that will execute in my Mac’s Terminal exactly as described. In other words, my Terminal is not an emulation of Unix; it’s accessing the actual Unix operating system. And so when I type those characters from the Terminal prompt, those Unix commands will be executed. What commands exactly? Well in that case, by typing rm -rf , I just deleted everything in whatever directory I was in without asking for confirmation; chmod changes file permissions in ways that might have made my system unusable. So no small thing to say the least.

You may be wondering why would this be relevant to you if you don’t intend to ask Claude Code to program something in Unix. But see, that’s because you’re thinking Claude Code is just ChatGPT — you’re thinking it’s going to give you code, or it’s going to write your code for you. You’re thinking of Claude Code as either copy-paste coding or autocorrect coding. You’re not thinking of Claude Code as an active AI Agent yet — but you will.

I predict that most of the marginal users of Claude Code will be using it to work on projects in their local folders in their physical computer. They will not be using Claude Code merely to write code in R or Stata. Once they understand that Claude Code has access to a growing number of Unix-based tools, they will want Claude Code to use them, or at least they will want Claude Code to use them once they see with their own eyes just what Claude Code is capable of if it is given access to those tools. But those tools are Unix commands executed from the shell, which requires at least understanding conceptually what I’m talking about as that is key to you seeing the good and the bad up front.

If you’re running Claude Code on your local machine with access to local directories, you need to use backwards induction from the worst case scenarios having happened and ask yourself “how does one get to a situation where this much damage was even possible to begin with?” They need to ask themselves, “if I were to give my computer to a malicious or incompetent person, what are the characters they would type into Terminal to destroy my data and my project? What commands would they use and where would they use them and how would they implement them?"

Most of us don’t actually know the answer to that question for the same reason we don’t know what rm -rf does. And I think this is maybe because most marginal users use software to perform operations within a graphical interface. Even if they write scripts that are then executed, they are most of their inside an app nonetheless. And so when they say words like “I program in R” or “I program in Stata,” what many of them mean is that write scripts and then execute them inside of RStudio or the Stata app. Their mental model is of a graphical interface, not a command line from some all white shell.

Just like how the marginal user does not know that they can run Unix commands from Terminal, they also probably do not know that they can run R commands, Stata commands, git commands, Python commands also from Terminal. For many people “running do files” means “being inside Stata to do it”. But all of these operations are accessible via the terminal. It’s just that most of us prefer to work in graphical interfaces, so we never learn much about terminal. Marginal users don’t — average users, yes. But marginal users, less so.

This matters because the current average Claude Code user is much more like the average modern day computer scientist than they are like the average modern day empirical social scientist. And to put more emphasis on this point, when the average user of ChatGPT is using ChatGPT to help them code, they are not using the code that ChatGPT gives them to execute terminal commands. They are more likely to copy and paste back that into R Studio or the Stata internal text editor and running new code. Why does this matter? Because it means that the marginal Claude Code user most likely does not know what “the Terminal” means, let alone what can be done there, let alone what cryptic character strings like “rm -rf“ does even though to the average Claude Code user it’s extremely obvious. And that is a massive gap in latent knowledge that no one is going to be writing about in all these Claude Code explainers because those Claude Code explainers are written by the average user for the average user. Not for the marginal user.

Think about it. The marginal user only has two mental models that map on to this thing called Claude Code. One of them is the word Claude. They think it is just another chatbot like ChatGPT being used to write code for them which they copy and paste into R Studio or Stata or which autocorrects in some way. And the other is the word Code. It must be some kind of coding language model — which we already have, and have had for going on 3 years now, so what’s the big deal?

Well, the big deal is that Anthropic calling it Claude Code is almost a misnomer because it is not merely a chatbot, and it’s frankly not even merely a coding agent. I mean it is a LLM using Claude 4.5, and it is a coding AI agent because that’s the only way you can interact with a machine except to speak code to that machine. Code is the machine language. So yes it is an accurate description — at least it was an accurate description to the average user. But it could not be any less helpful a name if it tried to the marginal user for whom those two words almost bring them to the wrong conclusion every time.

But putting aside the naming, let me get back to my point. A lot of things the average user takes for granted are the very things that are going to create real opportunities for doing some real damage for the marginal user. And that includes that Claude Code acts upon your file system using shell commands, which is why I said that anything you can do at the Terminal, for all practical purposes, assume Claude Code both can and will do it. Claude Code knows how to use all of them, can do them all, and will do all of them if you tell it to — knowingly or unknowingly.

---

Just A Few Commands That Can Cause Real Harm

So, as a simple example of what I mean, here are some shell commands that can cause serious, perhaps even irreversible damage to your data and your computer more generally.

File deletion:

• rm -rf / — attempts to delete everything on your system (modern systems have safeguards, but variants can still cause havoc)

• rm -rf ~ — deletes your entire home directory

• rm -rf . — deletes everything in the current directory and below

• rm -rf * — same effect, different syntax

Overwriting files:

• > redirect operator can overwrite any file: echo "" > important_file.txt replaces the file’s contents with nothing

• cp or mv without -i flag will silently overwrite existing files

Disk and system damage:

• dd if=/dev/zero of=/dev/sda — overwrites your hard drive with zeros

• mkfs commands — formats drives, destroying all data

• chmod -R 777 / or chmod -R 000 ~ — breaks permissions across your system

Git-specific risks:

• git reset --hard — discards all uncommitted changes, no recovery

• git clean -fd — deletes untracked files permanently

• git push --force — overwrites remote history, affects collaborators

• git checkout . — discards all unstaged changes

Data corruption:

• Modifying files while they’re in use

• Incomplete writes during interrupted operations

• Running database commands without transactions

This is not an exhaustive list. And since you don’t recognize them, you would think that therefore you are not going to need to learn them. And you don’t necessarily need to learn them. The point is, though, that Claude Code knows them. ChatGPT knows them. Just ask ChatGPT right now “what does git reset --hard do?” And it will tell you. Here’s what Cosmos just told me when I asked him:

It moves your branch pointer and forcefully makes your working directory and staging area match it — deleting all uncommitted changes.

So it’s not that Claude Code knows these things. It’s that because Claude Code, even in the GUI embedded in the app itself, is operating using shell commands, Claude Code unlike ChatGPT can do these things.

Now, whether it will do those things, that’s a different matter. Anthropic is the one AI company that at least openly has committed as best a for profit company can credibly commit to being focused more on human safety and risk minimization than growth. And so you see that carry forward through how Claude Code handles its interacts with us dumb humans who maybe accidentally tell it blow up the world. It won’t do it — at least not until you click the button giving it permission to. Then it will. But if you are in the habit of giving it permission, you may not always know what you just agreed to until it’s too late — especially given the frequency with which Claude Code is asking for permission in the first place! That’s the ironic thing — them asking for permission can give you fatigue and so you just start agreeing and before you know it, you’ve agreed to something really bad.

The marginal user of Claude Code must go into this with both eyes wide open. And I think “eyes wide open” means setting up empirical workflows endogenously with that risk in mind. That is the key. The key is not to say to Claude Code “don’t run rm -rf“. Because think about it — the marginal user doesn’t know what the marginal user doesn’t know. So how can the marginal user ever anticipate ahead of time the myriad of things it doesn’t want Claude Code to do when they themselves don’t even know those things are since it comes from a whole world of things they know nothing about?

So that’s not the solution. The solution is the new workflow that will endogenously form in time around using AI agents to accomplish empirical projects.

---

The Solution Will Be The New Workflow

On some video games, particularly third person narrative games with big open areas to explore, there’s a map feature. You usually click a button, and it goes to some new screen where you can see a map of the world. And if you have just started out, most of that map is dark. It’s dark because you haven’t been there yet. But once you go there, it won’t be dark. It’ll be lit up and labeled with whatever is there.

Right now, Claude Code is for the marginal user a giant dark map of the world. It is a massive space, and it is not mapped out at all. But it will be. And soon.

The lit up maps right now that have been worked out fairly well are for the average user. The maps for the average user are not the maps for the marginal user. The marginal user includes the empirical social scientist — you. Me. And no one is going to open up these maps except for us. Certainly not Anthropic, and all the AI influencers. Why?

I think the answer is quite simple. None of the stuff that we make with code can be bought and sold on product markets. And that makes our work more or less worthless from the perspective of profit maximizing firms. We are in the business of producing what we hope is scientific truth, and we produce for one another, and we share it through journals and seminars. But since we don’t sell it, there is not a vendor out there sharing with us the map. Which means we have to find it out ourselves, and fast, because the potential of Claude Code for augmenting worker productivity in the area of quantitative social science is so gigantic that it will be adopted right now. I’m not talking about the future — I am saying right now, as of 8-9 months ago.

The way in which the map will be worked out will be what I call from now on “the workflow”. And that is because the marginal user will use Claude Code on projects. Not code chunks — projects. Projects that live inside of directories. Directories that are organized hierarchically in folders. It will do that because Claude Code is trained on hierarchically organized folders on GitHub and who knows where else. That’s how it thinks, that’s how it will work.

So, when I talk about workflow with Claude Code, what I mean is a holistic, overall approach to using Claude Code on projects that minimizes errors and hazards. It will be as much about the things that you can stop from happening as it is about the things you can do. It will become common sense things you do on every new project. It will become boilerplate and boring.

Some of it will almost certain be analog stuff that you are already familiar with if you’ve managed research assistants (which I have not to be honest). You will do stuff like:

• Verify the code line by line, just like you’d check an RA’s work

• Make constant visual presentations of work to see what has changed

• Keep things organized so you notice when something’s wrong

• Ask Claude to explain what it’s about to do before it does it

But that’s the easy stuff. It’s the more subtle “unknown unknowns” stuff we need real sharing of information about. Since I am giving my agent access to my filesystem, and it can use bash commands, what will that agent do on accident? How then do I stop it from doing it, or if it does it, how do I undo it? I think that is the question.

---

The Real Risk Isn’t Malice — It’s Miscommunication

If something goes wrong with Claude Code, it almost certainly won’t be because it acted wildly or maliciously. Sadly, it will almost certainly go wrong because you inadvertently told Claude Code to do something that you yourself would never do in a million years, and therefore did not know that you just told it to do that.

I mean this is the weird thing about these AI agents that was not there with ChatGPT and other chatbots. Those chatbots could not do real damage. All they could really do was hallucinate. The human could mitigate that by simply verifying everything. Checking the sources. Confirming facts. It was misinformation, in other words. But it wasn’t harmful because ChatGPT could not actually act upon that information.

Claude Code is powerful because Claude Code acts. It does not speak. It acts. It speaks with shell commands and you have given it permission to use them. And because it is fluent in shell commands, you aren’t, it can do things now that you both would not do and don’t even know how to do.

Let me give you an example I’ve been thinking through.

David Card and Henry Farber once described Orley Ashenfelter as a first generation quantitative labor economist. I like that. I like it partly because it starts the scientific tree at a layer which includes Orley’s cohort — more or less adults who are coming into the productive years of their careers in the late 1960s and early 1970s.

Well, if you are reading this, you are probably anywhere from being a first to a third generation quantitative social scientist depending on how such things are measured. You have been probably programming for years. And one of the things you know never to do is that you are never to save over a dataset. Never. It wouldn’t even occur to you to do that. It’s a cardinal sin to save over a dataset. No one who has been doing empirical work for very long has done it. Maybe they did it early on — they saved over an excel file. They saved over something in Stata, and lost the original data. Maybe it was during a class in a problem set. But they don’t do it anymore, they know not to do it. Just like a running back knows to not run out of bounds.

What do you do instead then? You always load data, manipulate it, and save to a new file. You never type save, replace without thinking hard. You only do that, too, on the secondary, copied dataset anyway. You never do it to the original.

Now imagine you’re working with Claude Code and you say: “Clean up this data and save it.” What do you think you meant when you said that? Probably, you meant: create a cleaned version. But what if Claude thought you meant overwrite the original.

Or consider this. “Move these files to the archive folder.” Maybe you meant: copy the files into the archive directory for organizational purposes but don’t delete them from the original directory. Claude Coe might interpret it to mean to use the mv command, which removes them from the original location.

Or: “Delete the temp files.” You maybe meant: delete the files I just created. Claude Code might have interpreted it to mean everything matching some pattern you didn’t anticipate.

This is not Claude Code going rogue. That’s what we usually hear about and that is not what this would be. This would be miscommunication. It would be a failure caused by some gap between what you intended and what you instructed.

---

Practical Safeguards

So, I think that going forward, one possibility is that all workflows will have things like the following:

1. Version control everywhere. Empirical workflows will be inside of environments where there is guaranteed version control. Otherwise it is not safe.

2. Radical backups. Dropbox, Time Machine, Backblaze — something that versions your files automatically. But probably even more than that — you will have copies of datasets on external drives, not because those data have sensitive information, but rather because all empirical workflows must not be able to access the originals.

3. You will probably ask for dry runs a lot. You will habitually say “tell me what commands you would run, but don’t execute them yet.” It will become second nature. You will review it, and you will double check it. You will probably even ask Claude Code to spawn sub-agents to review it as well.

4. You will learn to “annunciate” clearly. You will learn how to talk in such a way so as to be narrow and specific. Instead of saying “clean up this folder” you will start to speak awkwardly with phrases like “move files X, Y, and Z to folder A, but do not delete them, and do not modify anything else and use backwards induction to ensure that the steps you will end with there being files XYZ in folder A and not inadvertently deleted because of a confused step.” You might even learn to do this from the microphone not the keyboard.

5. You will start projects in a test environment. You will maybe start using Claude Code or an equivalent AI agent on a copy of your project first.

6. Check your working directory. Confirm you’re where you think you are before any destructive operation.

In conclusion, like I said at the start, Claude Code is powerful precisely because it can do anything you can do. It has the keys to the shell commands on your computer. That’s the promise and the peril. You are probably the marginal adopter of Claude Code, and you are therefore in a situation where there isn’t a lot of relevant latent information being passed around. It is what it is. You are in the awkward position of having to learn it first. And you may be someone who is willing to learn it first, but who does not consider themselves a whiz.

And yet, I don’t think that is going to really matter. The fact of the matter our world is probably about to change radically and in 2026. Mark my words. So the sooner we take it seriously, the sooner we can get our empirical workflow mapped out. I think it’s going to be pretty bumpy to be honest. But it’s unavoidable and it will have to be worked through because the upside is so gigantic no one, once they see it themselves, will deny it.