Gerson Nazareth

Generating output is easy now. Anyone can prompt a model and get something plausible back in seconds. The scarce skill is on the other side of that exchange: evaluating what came back, refining it, and elevating it into something you'd actually ship. That still requires expertise, and the expertise is growing, not shrinking.

Recognizing mediocre AI-generated output is a skill in itself. Plausible prose hides wrong assumptions; confident code hides subtle bugs. People who have built and maintained systems spot that quickly. People who haven't yet learn to accept the output at face value, and the damage shows up later, in production, in review queues, in the slow accumulation of code nobody fully understands.

There's a related trap: a team can use AI every day and still stagnate. If nobody is refining their techniques, better context, better verification, a better division of labor between person and model, the tool quietly becomes a way to produce average work faster. Proficiency has to keep evolving, because the tools are evolving and the baseline moves with them. The teams I've seen get real value from AI treat it that way: a craft to keep practicing, not a switch to flip once.

The traditional coding interview measures something real, but it measures less and less of what the job now is. A candidate solving algorithm puzzles alone at a whiteboard isn't showing you how they work, and how they work has changed.

AI-assisted practical exercises fill that gap. Give a candidate a realistic task and access to the tools they'd use on the job, then watch. How do they guide the AI? What do they do with the output: accept it, question it, test it? Do they recognize the shortcomings, and can they improve the result? That tells you more about effectiveness in a day of real work than any isolated puzzle does.

None of this means technical ability stops mattering. It means hiring should assess engineering judgement alongside it: the judgement to know when the model is helping, when it's confidently wrong, and what done-well looks like. Candidates who can steer AI toward genuinely good outcomes, and who know the difference between good and plausible, are the ones who will do the job as it exists now. Our interviews should test that job.

Not every traditional practice needs replacing, and not every new tool deserves adopting. The question I keep coming back to is boring and reliable: does this make our engineering outcomes better?

Adoption should be deliberate rather than fashionable. Some of the older disciplines, review, testing, small changes, clear writing, are doing quiet, essential work, and AI makes some of them more important, not less. Others genuinely deserve rethinking.

The objective is better engineering outcomes, not more AI usage. Teams that keep that distinction sharp get both. Teams that don't get a lot of usage.