Tejas Kumar:
Aurora Scharff:
Lee Robinson:
Rejection is an inevitable part of the job interview process, but it doesn't have to be the end of your journey. Take each rejection as a learning opportunity and come out stronger than before.
The most resilient professionals aren’t asking “Is my job safe?”
They’re asking “How do I redesign my career before I have to?”
From Greg Brockman:
Software development is undergoing a renaissance in front of our eyes. If you haven't used the tools recently, you likely are underestimating what you're missing. Since December, there's been a step function improvement in what tools like Codex can do. Some great engineers at OpenAI yesterday told me that their job has fundamentally changed since December. Prior to then, they could use Codex for unit tests; now it writes essentially all the code and does a great deal of their operations and debugging. Not everyone has yet made that leap, but it's usually because of factors besides the capability of the model.
From Andrej Karpathy:
I've already noticed that I am slowly starting to atrophy my ability to write code manually. Generation (writing code) and discrimination (reading code) are different capabilities in the brain. Largely due to all the little mostly syntactic details involved in programming, you can review code just fine even if you struggle to write it.
Programming is becoming unrecognizable. You’re not typing computer code into an editor like the way things were since computers were invented, that era is over. You're spinning up AI agents, giving them tasks in English and managing and reviewing their work in parallel. The biggest prize is in figuring out how you can keep ascending the layers of abstraction to set up long-running orchestrator Claws with all of the right tools, memory and instructions that productively manage multiple parallel Code instances for you.
From Ryan Dahl:
This has been said a thousand times before, but allow me to add my own voice: the era of humans writing code is over. Disturbing for those of us who identify as SWEs, but no less true. That's not to say SWEs don't have work to do, but writing syntax directly is not it.
From Addy Osmani:
The collapse of the implementation middle isn't making engineering less important but it's revealing what was always important: understanding problems so clearly that the code (now, the spec for our agents) becomes more obvious. As software engineers, our identity was never “the person who can write code” - it was “the person who can solve problems with software.”
From Lauren Tan:
In 2026, not getting value out of AI is actually a skill issue. And you wouldn't be the first. All engineers (including me) who started their careers before AI must learn new skills in order to stay relevant. These are new skills we'll be learning over time. I'm not going to say that you're going to be left behind, but like any new paradigm, this requires changing mental models and perspectives. Skills can be learned with time (and they will keep evolving), but changing your perspective is the first and most important step.
From Tom Wojcik:
If the AI writes all the code and you only review it, where does the skill to review come from? You can’t have one without the other. You don’t learn to recognize good code by reading about it in a textbook or a PR. You learn by writing bad code, getting it torn apart, and building intuition through years of practice. This creates what I’d call the review paradox: the more AI writes, the less qualified humans become to review what it wrote.
We used to have juniors, mids, seniors, staff engineers, architects. It was a pipeline where each level built on years of hands-on struggle. A junior spends years writing code that is rejected during the code review not because they were not careful, but didn’t know better. It’s how you build the judgment that separates someone who can write a function from someone who can architect a system. You can’t become a senior overnight. Now, a junior with Claude Code delivers PRs that look like senior engineer work. But does it mean that the senior hat fits everyone now? But the head underneath hasn’t changed. That junior doesn’t know why that architecture was chosen.
Your job isn't to turn user stories into code. The company has a mission. Everyone at the company is hired to push that mission forward. You're not a software engineer hired to code. You're a human hired to push their mission forward. It just so happens that you are a human with coding skills and during the hiring process, they recognized that those coding skills could help them in their mission.
You may not have enough information to perform the analysis. You may need to ask the product manager questions about the features and how they tie into the mission of the company. Go into the conversation with an open mind and a desire to understand. The company hired the product manager to help prioritize work in the optimal way to push the mission forward. You should trust them to do their job well and recognize that they may have context that you're missing. So long as you effectively expressed all the information you can about the long-term benefit-to-effort ratio of your ideas then you've done all you can there.
If you join a company or team and deal with constant nonsense and a broken culture? Switch. Immediately. Do not delay. And if the new team is nonsense again? Switch again. Don't let these people waste your time or tax your peace.
You will do your best work when you are supported and included. You will make up more career time working 6 months at the right place, than in the previous 6 years of daily hell.
An inclusive team will not judge you for switching multiple times finding the right fit. And hiring managers, have more confidence in your ability to create an environment that people want to stay at. The past at other teams and other situations doesn’t predict the future at your team and this situation. I have seen so many “jumpy” people find their “home” after so many jumps. Sometimes it’s the first decent manager they have, sometimes the first company they can grow with and so on...
Don't ask people why they left their last position. They often can't tell you, and it's not relevant. Instead, ask what they are looking for in their next role. You can even ask how long they intend to stay, or what would entice them to spend N years on the same team or role.
The divide between frontend and backend engineers is increasingly less useful:
Product Engineers consider the frontend, backend, design, and everything in between to create a great user experience. They don't need to understand every part deeply, a common misconception of "fullstack". Instead, they have a broad understanding of the available tools and deep experience applying those tools to build products. At Vercel, we updated our job descriptions to change references from Fullstack to Product Engineers.
While Product Engineers focus on building and enhancing features that solve end user problems, Platform Engineers focus on the infrastructure that supports the product.
Bad engineers measure their worth by the complexity of their solutions. They build elaborate architectures for simple problems, write clever code that requires a PhD to understand, and mistake motion for progress. Good engineers reach for simple solutions first, write code their junior colleagues can maintain, and have the confidence to choose “boring” technology that just works.
Bad engineers treat code reviews as battles to be won. They defend every line like it’s their firstborn child, taking feedback as personal attacks. Good engineers see code reviews differently — they’re opportunities to teach and learn, not contests. They’ll often review their own PR first, leaving comments like “This feels hacky, any better ideas?”
Bad engineers guard knowledge like treasure, making themselves indispensable through obscurity. Good engineers document as they go, pair with juniors, and celebrate when someone else can maintain their code. They know job security comes from impact, not from being a single point of failure.
Bad engineers chase the newest framework, the hottest language, the latest trend. They’ve rewritten the same app four times in four different frameworks. Good engineers are pragmatists. They’ll choose the tech that the team knows, the solution that can be hired for, the approach that lets them focus on the actual problem.
Bad engineers write code. Good engineers solve problems. Bad engineers focus on themselves. Good engineers focus on their team. Bad engineers optimize for looking smart. Good engineers optimize for being useful.
Early in my career, I believed great work would speak for itself. I was wrong. Code sits silently in a repository. Your manager mentions you in a meeting, or they don’t. A peer recommends you for a project, or someone else.
In large organizations, decisions get made in meetings you’re not invited to, using summaries you didn’t write, by people who have five minutes and twelve priorities. If no one can articulate your impact when you’re not in the room, your impact is effectively optional.
This isn’t strictly about self-promotion. It’s about making the value chain legible to everyone- including yourself.
Glue work - documentation, onboarding, cross-team coordination, process improvement - is vital. But if you do it unconsciously, it can stall your technical trajectory and burn you out. The trap is doing it as “helpfulness” rather than treating it as deliberate, bounded, visible impact.
Timebox it. Rotate it. Turn it into artifacts: docs, templates, automation. And make it legible as impact, not as personality trait.
Priceless and invisible is a dangerous combination for your career.
It rewards what’s sensationalized: things that go viral, things that make people mad, things that scare people. So naturally those are the voices that get pushed and sound the loudest.
These are the 3 culprits I see every day: