You did the hard part. You can build the thing. You ship features, you read a stack trace without panicking, you can pick up a new framework over a weekend. That competence is real and you earned it.
So here is the uncomfortable question: what happens when coding itself starts losing value? Not disappearing, losing value. AI now writes the boilerplate, the tests, the first draft of almost anything. The thing you trained for, the part that used to make you stand out, is becoming the baseline everyone has. The differences that decide where you end up sit somewhere else entirely, and nobody really sat you down and taught you where.
Prefer the 60-second version? Watch it here: youtube.com/shorts/j-LOkhUrrJk
Addy Osmani, a director at Google Cloud AI, put this into a book called The Effective Software Engineer. Three patterns run through it, and the shape underneath them is the whole point.
Efficient is not the same as effective
Efficient engineers do things right. Effective engineers do the right thing. That sounds like wordplay until you have spent three months building a technically flawless feature that nobody uses. Clean code, full test coverage, market value zero.
The skill that protects you here is not faster typing. It is judgment: looking at the backlog and asking which of these actually matters, instead of which one is the most fun to build. Most engineers optimize for the interesting problem. The effective ones optimize for the problem that moves something.
Your code only travels as far as you can explain it
Finding the right solution is half the battle. The other half is convincing the organization to actually build it. Your ability to communicate does not sit next to your technical skill as a nice extra. It sets the ceiling on how far that technical skill reaches.
A great design you cannot get anyone to agree to is a great design that never gets built. Communication is not the soft thing around the real work. It decides whether the real work happens at all.
Invisible work does not get counted
You might assume people notice what you are shipping. In a busy company, they mostly do not. Promotion conversations happen in rooms you are not in, and the only version of your work that exists in those rooms is the version someone can describe out loud.
Visibility is not vanity. If your work is not part of the conversation, for the people deciding, it did not happen. Making your impact legible is a skill, and almost nobody teaches it to you on the way in.
So here is the pattern
Three takeaways, one shape underneath all of them. Choosing what matters, explaining it, making it visible: these are exactly the skills most engineers treat as optional, and exactly the ones that decide where a career goes. They were never on the syllabus, so it is easy to assume they do not apply to you. As AI takes over more of the pure technical work, they are quietly becoming the part that is actually yours.
This is not about your code getting worse. It is about the ground shifting under what “being good at this job” means, and noticing it before the people around you do.
Utterskills trains the skills beyond code that decide who advances: communication, ownership, and judgment. If this hit a nerve, that is the point.