Be the Teacher and Learn Something

Sebastian — Fri, 21 Aug 2026 12:57:59 +0000

Learning got a lot harder

When I look back at what I learned most from, I have to say CSS during the time my company was still supporting old Internet Explorer versions. There was something about this really limited set of possibilities where you had to think outside the box to achieve what you wanted. And no, I don't want those times back. But today, where AI takes over simple coding tasks, learning through these seemingly easy tasks is totally missing. How am I supposed to learn what a good API on a large scale looks like, if I never had the opportunity to build one on the small scale. Seeing a component grow in complexity, and having to change its API, is a great playground — you learn what matters in an API, and what breaks when you change it across every place it's used. The difference is: you might introduce a design glitch or a small bug, whereas playing around with a complex production REST API might lead to much more severe consequences. And it is this small scale practice, that AI removes from developers starting out right now.

And why should I be concerned?

It is easy to dismiss this problem and even use it as an advantage: less competition opens the market, people get irreplaceable and can get a raise out of that. But for me, more senior development roles - be it the senior developer, a staff engineer or a tech lead, whatever the roles are called in your company and even if the role doesn't have a specific name - always had the responsibility of mentoring younger, less experienced developers. It has always been my responsibility to not only keep a team running, but to make it better, to make me replaceable by anyone who is part of that team.
And while it might be annoying for all parties, that means looking into merge requests even if you are not part of the review process. Make yourself part of it and see where problems might occur. Understand where your developers have problems, and ask the right questions so that they have to argue for their code (yes, even though AI wrote it, the code ownership should still stay with the developer) and by extension think about what they are committing to the code base.

The curse of knowledge

Understanding where other developers have problems, isn't as easy as it sounds. When you grow and acquire knowledge, you lose track of what was hard for you, or what might be hard for others. You might look at a PR and wonder why someone would write this. It takes time to realise, that not everything you know is as easy to understand as you think. Assuming basic concepts are common knowledge might be right in a lot of cases but it isn't right in all of them, and people differ in what they already know and what they don't, they might be familiar with one concept but totally lack others, they might even think they understand it, but in the end have a wrong idea of what it actually means. And by reviewing other people's code, you get better at explaining, you get better at understanding others and you might even find yourself in a situation where you might not understand a concept yourself. Because explaining to someone else is a great way of identifying missing knowledge.

Teaching is how you find your own gaps

This is why the right approach to code reviews is so important. Just presenting alternative solutions might be a convenient approach but often isn't enough. Doing a code review right and asking the right questions can open new perspectives on code and most importantly it can
show you and all the people involved where their lack of knowledge is. And that's how you build a future-proof team, not only by delivering new features, but being a mentor to developers with less experience. The easy problems that used to teach us are disappearing. But the teaching still needs to happen.

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

Sebastian — Thu, 13 Aug 2026 13:44:54 +0000

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?

DEV Community: Sebastian