Write code like a human will maintain it

# Write code like a human will maintain it Source: [https://unstack.io/write-code-like-a-human-will-maintain-it](https://unstack.io/write-code-like-a-human-will-maintain-it) One of the best things about LLMs is that they'll write code for you, all day long\. Who cares about DRY? You don't have to be the one updating the same long conditional in four different files \- the AI will just do it for you\! Right? I've noticed myself letting it slide recently on a project I'd been building with AI\. I needed the same access check in a handful of places: a route handler, a background job, an API endpoint, a webhook, etc\. Each time, I'd describe what I needed, the model would generate something that worked, and I'd merge it\. Each version looked roughly like this: ``` if (user.isActive && user.hasPermission('read') && !user.isSuspended && account.status === 'open') { // do a thing } ``` Essentially the same conditionals every time\. Four conditions, maybe slightly different variable names, copy\-pasted logic with a word or two changed\. There's a much cleaner way to do this \- a shared helper, for example, like something I'd extract if I were writing this myself\. But I didn't\. The code worked\! The tests passed and I wasn't the one who'd have to touch it again\. That's the laziness here: if it doesn't follow best practices, or I know a piece of code will be a pain to maintain, what difference does it make? When I need to change something later, the LLM deals with it, not me\. *Except*the LLM doesn't write in a vacuum\. It reads your codebase\. The files you have open, the patterns that are already there, and the recent changes you've made\.**Every shortcut you merge into your codebase is a signal about how things are done here**\. The next time you ask the LLM for another endpoint with the same access rules, the model won't start from first principles\. It'll start from the other four copies already sitting in your repo\. So you ask for a fifth endpoint, and you get a fifth conditional, with the same copied code\. You ask for a refactor, and the model preserves all five, because that's what your code looks like\. The bad pattern isn't a one\-off anymore, it's considered to be your style\. If you let things go on like this, can you really trust that the LLM will catch every instance if you try to fix it later? Sure, a few of these aren't catastrophic\. That's how it always starts, but code smells do stack up\. Each duplicated conditional, each "god" function, each "I'll clean this up later" merge adds another layer of signaling to the next prompt\. Eventually you can't easily prompt your way out of it\. At least not without getting your hands dirty and rolling up your sleeves\. The most frustrating part: I thought I was outsourcing maintenance to the LLM, but the slippery slope I found myself on was actually training it to have ever\-worsening habits\. Write code like a human will maintain it\. LLMs are sponges that soak up everything you do and repeat it back to you\. So make sure it's good\.