It is time to redefine what a senior engineer is
A few months ago I showed my team something that changed the mood in the room. I had built a working prototype of an internal tool — the kind of thing that normally takes two to three weeks of back-and-forth, edge case handling, and integration work. It took me a couple of hours. With AI.
The juniors went quiet. Not the impressed kind of quiet. The scared kind.
These are smart people. They have career plans. They spent years learning data structures, fighting with CSS, understanding distributed systems. And here was their team lead casually demolishing the timeline of a project before lunch. You could see the thought forming behind their eyes: what the hell am I going to do now?
I understood the fear. If a prototype that used to justify a sprint can be generated in an afternoon, what exactly is your job?
We needed to talk about it
So we did a workshop. Not the corporate kind with sticky notes and a facilitator who has never shipped code. A real one. The kind where you sit in a room and say the uncomfortable thing out loud.
The uncomfortable thing was this: if AI can write the code, what is a software engineer?
We didn't start with software. We started with the word engineer.
An engineer is someone who converts ideas into reality.
That's it. That's the whole thing. A civil engineer takes "we need to cross this river" and turns it into a bridge. A mechanical engineer takes "we need to move faster" and turns it into an engine. The raw material is an idea. The output is something real that works.
From there, the software version writes itself:
A software engineer is someone who converts software ideas into software realities.
Simple. But once you have a clean definition, interesting things happen.
What makes a senior engineer, then?
If a software engineer converts ideas into reality, a senior software engineer does it well. Specifically: they deliver a working solution in a reasonable amount of time, adjusted to the constraints of the environment.
That last part — adjusted to the constraints of the environment — is where everything lives.
Think about the civil engineer building a bridge. A good engineer doesn't just calculate load tolerances. They ask: how many people will cross it daily? Do we need car lanes or is it pedestrian only? Is this over saltwater that will corrode the steel? Is the bridge going to be an emblematic part of the city, meaning it also needs to be beautiful? And what's the budget — because if it needs to be beautiful and support ten thousand cars a day and resist corrosion, you need to know what trade-offs are available to you.
A bad engineer waits for someone to hand them the spec and then executes it.
A good engineer goes and finds the constraints. They ask the hard questions. They talk to people. They push back. They figure out what "done" actually means in this specific context.
And here's the critical part: it is the engineer's responsibility to gather the constraints, not the product manager's responsibility to hand them over. The product manager has a vision. The engineer has to interrogate reality to figure out if that vision is buildable, and how, and at what cost, and with what trade-offs.
This is the part that doesn't get automated.
The code monkey problem
Here's what I've noticed, and I'll be blunt about it. There are a lot of senior software engineers in the market right now who are, functionally, code monkeys.
They have the title. They have the years of experience. But what they actually do is wait for someone to prepare the requirements, break them down into tasks, and spell out exactly what needs to be built. Then they write the code.
That workflow has a name now. It's called a prompt.
If your job is to take a well-defined specification and turn it into working code, you have been replaced. Not in the future. Now. I can paste a detailed spec into Claude and get working code back in minutes. The spec-to-code pipeline is a solved problem.
What AI cannot do — not yet, and not for a long time — is sit in a meeting and realize that the product manager is building the wrong thing. It cannot walk over to the infrastructure team and ask if the database can handle the proposed query pattern. It cannot push back on a deadline by explaining the second-order effects of cutting corners on auth. It cannot look at a business problem and say "you don't need a microservice, you need a spreadsheet."
The judgment. The context. The responsibility. That's the job.
Why I only hire juniors
I'll share something that surprises people: in my team, I only hire juniors.
Two reasons.
First, budget. Let's be honest. Not every company can afford a team of seniors, and not every problem requires one.
Second — and this is the controversial one — the signal-to-noise ratio with senior candidates is brutal. For every senior engineer who genuinely thinks about problems end-to-end, who challenges requirements, who takes ownership of outcomes, there are five who are just looking for a well-defined ticket queue. They want someone else to do the thinking. They want to show up, get assigned a JIRA ticket with acceptance criteria, write code, push it, and go home.
That was a valid career for a long time. It isn't anymore.
With juniors, I know exactly what I'm getting: someone who doesn't yet know how to solve the problem, but who is hungry to learn. That's a much better starting position than someone who technically knows how to solve it but refuses to figure out which problem to solve.
I can teach a junior to think. I can't teach a senior to care.
The new definition
So here's where we landed as a team. The definition we walked out of that workshop with:
A senior software engineer is someone who can take an ambiguous idea, discover the real constraints, and deliver a working solution that fits the environment — in a reasonable amount of time, with a reasonable use of resources.
The "reasonable" is doing a lot of work in that sentence. Reasonable means you understand the business. You understand the deadline. You understand the tech debt. You understand the team. You understand what's good enough and what needs to be perfect.
AI makes the coding part fast. It makes the thinking part more important. If you are a software engineer whose entire value was typing code that matches a spec, this is going to be a very rough decade for you.
But if you are the kind of engineer who figures out what to build and why — the kind who takes ownership, who asks questions, who pushes back, who understands that software engineering is not about writing code but about solving problems within constraints — then you are more valuable than ever.
The tools changed. The job didn't. We just forgot what the job was.