Something noteworthy happened today. In the span of a few hours, I encountered the same question from two software engineers who are nearly 20 years apart in experience.
The first was a Slack message from a Staff Engineer:
Hey Joel, random question a lot of folks are wrestling with: given a world where much of development is being replaced by tools, agents, and LLMs, what would your advice be to someone in my role? My gut tells me to double down on building depth around what we are trying to do as a business and the design and architecture needed to support it.
A few hours later, I walked into a meeting with one of our summer interns and found them deep in conversation with a senior engineer discussing the same thing. "I bet Joel has some interesting thoughts on this." the Intern said as they both turned toward me.
My advice? Be so good they can't ignore you—this too shall pass.
The Anxiety
This experience is not unique; these conversations are occurring everywhere. There is a palpable anxiety amongst Software Engineers across the spectrum of experience–wondering if the commoditization of code writing spells the end of their careers, some of which have barely begun.
Many of these same engineers have never had more fun building systems and creating code.
Surely, you have heard the doom takes. You've heard the advice.
"We must move up the value chain because the once-cherished technical skills we've acquired are being commoditized at a blistering pace." Jerod Santo of The Changelog says in his newsletter.
And yet, the collective anxiety continues to increase.
Does developing an extensive depth of knowledge around the business, design, and architecture move you up the value chain?
"The people who will excel in the new economy, where everybody can build, is the ones who have taste" says Steve Yegge
Understanding the business, the technology, and the customer has long been a differentiating factor for excellent engineers. Add taste, and you might get good enough that they can't ignore you.
This phrase is borrowed from advice Steve Martin gives (yes, that Steve Martin) and also from a book of the same name. The book encourages individuals to develop rare and valuable skills as craftsmen. By doing so, you will build career capital that can be leveraged for impactful work that cultivates passion.
So, what in the world is taste?
On Taste
The thing that is hard to find is taste. The thing that is hard to measure is taste. The most important thing is taste
— Ezra Klein on How I Write
In a CBS interview, legendary producer Rick Rubin famously said, "[I'm paid for] the confidence that I have in my taste, and my ability to express what I feel..."
The same could be said for excellent software engineers. We tend to call this "good judgment," the skill of recognizing and making tradeoffs. Rubin also calls himself a "reducer" instead of a producer, working to convey a point or a feeling with the least amount of information.
Software engineers are tasked with designing robust systems, avoiding preoptimization, and adhering to the DRY principle without overengineering—all while understanding customer needs and engaging stakeholders.
To do this well, you need good taste. The AI will regularly tell you you've gotten it right and rarely tell you when you're wrong. The sycophancy problem isn't isolated to one ChatGPT release.
It doesn't know that you're just wrong. And... you have to be attuned to that voice in you. It's like, 'Not right, not right, not right.' You're not trying to bypass that or get around it... you're trying to get to the point where you're like, 'Ah, got it right.' And that's usually intellectual labor.
— Ezra Klein on How I Write
I explore the practice of intellectual labor in my recent post on conviction. Desirable difficulties are the struggles that cement mastery; you cannot shortcut these. You must develop a personal system for augmenting with AI while preserving desirable difficulties. Automation plateaus; the assets that compound are not those you can automate, but rather the "career capital" and social capital—the relationships you have developed.
As coding itself becomes a commodity, taste will help you decide which problems are worth your time.
What about Juniors?
Augmenting your work with AI and shifting your value to taste sounds great for the experienced engineer. If expertise and judgment are more important than ever when collaborating with AI, how can we help Juniors become experienced seniors who use AI effectively to enrich their work?
AI tools help experienced developers more than beginners… Seniors use AI to accelerate what they already know how to do; Juniors try to use AI to learn what to do – the results differ dramatically.
— Addy Osmani
The optimistic take is that new developers, by combining fresh ideas with AI assistance and a learner's mindset, can advance faster than ever—as long as they also put in the intellectual effort that cements mastery.
Another positive take from Steve Yegge is, "Even a 20-year veteran is a newbie." AI levels the playing field. A Junior Engineer who masters these new tools can be incredibly effective. Their role will be less about writing boilerplate and more about reviewing AI-generated work, asking the right questions, and integrating components with a discerning eye.
Still sounds like taste to me.
I don't think we know the path for Juniors, yet still. We want Juniors to act like seniors. We always have. Companies have to make a conscious choice not to believe the hype that soon there will be "no more developers needed." A refrain we've heard since the early 1960s, but the outcomes have always proven more nuanced than anyone predicted.
Companies must continue investing in the talent pipeline, which may just be more productive than any previous class.
Learning to be so good they can't ignore you is still the best advice.
The "New" Job
Are we all AI Engineers now? Is the "skill" we need to learn Context Engineering? Does that move us up the value chain?
We are not discussing a new skill but rather a new means of expressing an old skill and a new technology that we must learn to harness effectively. We've always been data plumbers, context engineers, and lifelong learners. I explore this view in my post on context engineering.
To do this "new" job well, we must reset our understanding of the old job and acknowledge that it remains fundamentally unchanged.
In the near future, the person who communicates most effectively is the most valuable programmer.
— Sean Grove, OpenAI
This statement reveals nothing is new about the new job.
Sean's broad argument is that the specification for programming is shifting towards human language. This is true. The way we create code is undergoing an axial transformation—and the importance of learning the craft of writing quality code is greater than ever.
We will never go back to exclusively writing syntax by hand. However, our ability to shape, maintain, and review quality code remains a vital part of our job.
The ability to create robust and scalable systems implemented through their individual modules remains essential.
Clearly specifying and validating the quality of modules, no matter how trivial it may be to create and recreate them, is indispensable.
You need to have good taste developed through intellectual, relational, and practical experiences in creating code that forms robust, complex, and adaptive systems.
It has never been easier to write code, and it has never been harder to know when it is the right code.
For most engineers in the field, interns and staff engineers alike, the job description has not changed.
Moving up the value chain isn't a new idea. Investing in timeless talents—such as understanding customer needs, designing resilient systems, making sound judgments, and collaborating across disciplines—remain the most valuable skills.
Take pride in your work, be a craftsman of our trade, and strive to be so good that they can't ignore you—this too shall pass.