We Don't Build Primitives Because It's Best Practice—We Made Them Best Practice to Build Better Software

You might look at the headline and think: yeah, so what else is new? And you are right, there is nothing new about this. You might be a developer for a long time, remembering when Brad Frost came up with his atomic design principle, when people started to divide their react components into presentationals and containers, had them in different folders depending on how complex they were and arguing about which folder that component belongs in. Or you might just be interested in asking why we do things the way we do.
But lately I encountered cases again and again, where this wasn't understood. I had Junior (and not so junior) Devs who just build their components because that's how they learned it. Or we now have this new breed of technical POs who want to support their team, because with AI everyone can write code.

There is no general understanding of why

Not so long ago, I made a code review on one of the projects I am responsible for and came across this file sitting in our base components package:

export const CopyButton = ({ onClick }) => {
    const [tooltipShown, setTooltipShown] = useState(false);

    const handleClickButton = () => {
        setTooltipShown(true);
        setTimeout(() => setTooltipShown(false), 2000);
        onClick();
    };

    return (
        <div>
            {tooltipShown && <span>Copied!</span>}
            <button onClick={handleClickButton}>Copy</button>
        </div>
    );
};

And of course I immediately asked why we need a component like this. And the answer I got was mostly based on the ticket they were working on and how this button was requested by the UX Team to show the copying process worked. And while playing review ping pong can be a tad annoying, I stuck to it and questioned it further. And after a while I realised: There was a big gap in understanding why we have a component library, what fits in there and why we need abstractions.

The overwhelm in the current landscape

And someone could argue now: well it is a developer's job to understand why things are built a certain way and not just accept best practices just for the sake of it. And I totally agree, in an ideal world everyone would understand all concepts and if they didn't they would research them. But the world we are in now, works a little differently. AI writes most of our code, it uses best practices mostly correctly, it learned on huge code bases after all. You don't necessarily come into contact with the problems those single-use components cause when needing to build a similar functioning component, because the AI will take care of it. I learned a lot from rewriting badly abstracted code, that's how I started to understand the concepts because not following them was a real pain for me. If you take that away, learning gets much harder — but that's only a loss if you were there to learn something in the first place. Someone who jumps in to fix some design issues with AI, like POs or designers, isn't necessarily interested in understanding what they are doing.
And at the same time there is so much other stuff to learn alongside the base concepts. Writing code isn't your main job any more, it is planning the right prompts, giving the right instructions and at the same time trying to keep the token usage low. All these things not only distract from basic concepts, they often just smooth them out without the developer realising that.

If AI takes care of that, everything is fine

A problem emerges, when AI makes a mistake and doesn't follow the best practice patterns, either by mistake, or because the instructions are so restrictive that abstracting the component isn't an option. And building on top of that, the more bad examples slip through the code reviews, the more the AI agent learns from the repository. It might build a save button with a similar tooltip instead of refactoring the copy button. You could argue that in the end the AI is the only one being affected by that because Devs don't touch the code anymore. And a single component more doesn't break anything. But as soon as you start optimising applications or change the behaviour across multiple occurrences, this becomes a huge problem.

No, it is not an AI problem

While AI might have made the problem of missing basic knowledge worse, it is not the root cause. People tend to follow the easiest path and best practices are a great way to not think about it too much. But if missing knowledge isn't visible, how would you even know it's missing? And who is responsible for making it visible?