AI Raises the Hiring Bar

I used to think AI would make me more willing to hire less experienced engineers.

The argument seemed reasonable. Software engineering is changing quickly. The tools are new. The habits are not settled. Someone early in their career may be more open to rebuilding their workflow around AI, while someone with ten years of experience may keep trying to fit AI into an older way of working.

I still think that can happen.

But for a startup, I no longer think it is the important part.

A startup is not trying to maximize the amount of code written. It is trying to solve a problem before it runs out of time, money, or patience. The engineer you want is not the one who can produce code the fastest. It is the one who can move the product toward the right answer with the least unnecessary weight.

That distinction matters more now, not less.

A Ticket Is Only a Guess

A ticket looks precise, but it usually is not.

It says: build this flow, match this design, support these states. But in practice, the ticket is only one proposed path toward a product outcome.

There are usually several acceptable versions of the same feature. One version matches the design exactly but requires a complicated implementation. Another changes a small interaction and removes half the complexity. A third looks easy but creates product confusion later.

The work is not just implementing the ticket.

The work is recognizing those differences.

I often write fallback notes in tickets: if this is expensive, we can do X instead. That is useful, but it also exposes a problem. If I have to spell out every acceptable simplification, every product tradeoff, and every implementation boundary, then the system depends on me noticing everything in advance.

That does not scale.

In a startup, a small unnecessary detail can become permanent maintenance cost. One overbuilt component is fine. A hundred of them becomes the architecture.

This is why I now care so much about product judgment in engineers. I need people who can read the intent behind the ticket, not just the words inside it.

AI Rewards People Who Already Know How to Delegate

Before AI, the best senior engineers were already using leverage.

They did not scale only by typing faster. They scaled by breaking down ambiguous problems, mentoring other engineers, reviewing work, catching wrong assumptions early, and deciding when a simpler solution was good enough.

That is a very specific skill. You have to describe the goal clearly. You have to know which details matter. You have to inspect partial work and notice what is off. You have to correct direction without getting dragged into every line of implementation.

That is also a lot of what working well with AI looks like.

AI did not invent this mode of work. It made it more direct.

A strong senior engineer can give AI a problem, evaluate the result, reject the parts that are subtly wrong, and steer toward a simpler design. Their experience shows up in the questions they ask, the constraints they add, and the solutions they refuse to ship.

A less experienced engineer can also generate code quickly. But speed is not the scarce resource anymore. The scarce resource is knowing what should exist.

Taste Is Part of Engineering

That is why the word I keep coming back to is taste.

When I say I want engineers with taste, I do not mean visual polish.

I mean the ability to connect product value, design quality, and engineering cost in the same decision.

Should we match the design exactly here, or is the difference invisible to users? Is this edge case part of the core product, or are we building a support burden for one hypothetical customer? Is this abstraction making future work easier, or just making today's code feel more elegant?

These are engineering questions.

They are also product questions.

And in a startup, the same person often needs to answer both.

This is why my hiring bar has moved away from "smart junior engineer who is good with AI." That profile can still be valuable, but it is not the center of what I am looking for.

The profile I want is closer to this:

• Senior enough to understand long-term cost.
• Smart enough to learn quickly.
• Tasteful enough to make product and design tradeoffs.
• Close enough to the market to understand why the feature exists.