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.
Facts Only
* LLMs can write code for users.
* A user generated repetitive conditional logic across multiple files (route handler, background job, API endpoint, webhook).
* The repeated logic involved four conditions: checking for user activity, read permissions, suspension status, and account status.
* A cleaner approach would involve using a shared helper function.
* Code was generated that worked and passed tests without applying best practices.
* Subsequent LLM requests for new code or refactoring preserved the duplicated logic across all instances.
Executive Summary
LLMs can generate code quickly, which leads to a tendency to omit best practices like the DRY principle when prompted for solutions. The author describes a situation where repetitive conditional logic is created across multiple files by using LLMs, resulting in copied and pasted code rather than abstracting it into shared helpers. While this shortcut produces functional code and passes tests immediately, it bypasses the process of applying established software design principles.
The core issue arises because the code generated by the LLM reflects the existing codebase patterns, meaning subsequent requests for modifications or refactors perpetuate the suboptimal pattern. This creates a feedback loop where poor maintenance habits are reinforced, as the LLM incorporates these duplicated structures into its understanding of what constitutes the current implementation style.
Full Take
The situation illustrates the risk of outsourcing maintenance without process consideration. The initial convenience of immediate code generation masks a pattern where code smells accumulate because the LLM learns and reproduces existing, poor patterns rather than correcting them. This is not just about functional correctness but about building a codebase that is maintainable and intellectually sound. The slippery slope occurs when this duplication becomes accepted as the established style, shifting the burden of recognizing and fixing the flaw onto the human maintainer later.
The pattern observed is one where immediate expediency overrides long-term systemic health. When code smells stack up, they create more signals for future prompts, making it progressively harder to prompt out of inherited poor habits. The implication for agency is that reliance on automation without rigorous oversight can train systems toward ever-worsening habits, undermining the goal of outsourcing maintenance to an intelligent agent. The critical question becomes whether efficiency gained in generation is outweighed by the cognitive cost incurred during future maintenance and debugging cycles.
What safeguards exist to ensure that generative speed does not create a form of intellectual laziness? Does the value of immediate output supersede the necessity of adhering to established principles, especially when dealing with complex systems where context is learned from the existing environment? How can we design interaction models that prioritize code quality over mere functional completion?
Sentinel — Human
This appears to be an authentic reflection from an experienced practitioner detailing the cognitive and practical consequences of using LLMs for coding shortcuts, focusing on the accumulation of poor patterns rather than machine-generated synthesis.