In 1992 (fuck I'm old), when I was working in terrestrial broadcast radio, an engineer named Michael Liles told me something that has stayed with me ever since: “David, Engineering isn't about being able to fix every problem. It's having the phone numbers of the people who do.”
That was practical advice in an industry where dead air was an emergency and occasionally the equipment contributed actual smoke to the discussion. He understood that expertise includes resourcefulness: assessing the problem, recognizing the limits of your knowledge, and knowing where to find help.
More than thirty years later, AI has given developers a new number to call. Unfortunately, it also answers every call with the confidence of someone who will never have to attend the incident review. That changes the skills we need. It also leaves us firmly responsible for the consequences.
For years, software development has rewarded people who know a particular language backwards and forwards. Every function. Every obscure behavior. Every bit of syntax that looks like a cat died halfway across the keyboard. That knowledge has value. Deep familiarity helps developers recognize patterns, investigate failures, and anticipate trouble.
But we have sometimes confused an excellent memory with the full scope of engineering ability. Technical interviews can become elaborate ceremonies in which someone reproduces an algorithm from memory while three people watch, as though the company’s biggest operational risk is a simultaneous outage of the internet and all reference material. Meanwhile, the actual job involves ambiguous requirements, aging systems, contradictory priorities, and a database column called temporary_fix_2014.
AI should force us to reconsider what we are measuring.
A developer who uses AI effectively can be more valuable than someone whose principal advantage is knowing one language by heart. The advantage comes from combining technical understanding with clear communication, adaptability, and sound judgment.
The word effectively is doing a lot of heavy lifting in that sentence. Please do not bury it under a pile of generated code.
Anyone can ask AI to write a function. Getting something useful requires understanding the problem, providing the right context, evaluating the result, and recognizing when the conversation has wandered into confident nonsense. A convincing explanation can accompany a terrible decision. Anyone who has attended a budget meeting already knows this.
The work begins before the prompt.
What is the user actually trying to accomplish? Which constraints matter? What information is missing? Does this process need to be automated, or has everyone simply become emotionally attached to doing something unnecessary? If the requirements are wrong, AI can help us implement the wrong thing at a speed previously available only to large organizations with substantial funding.
That makes curiosity, listening, and the ability to ask uncomfortable questions essential development skills.
Sometimes the most valuable question is, “Why are we doing this?”
It should ideally be asked before deployment. Asking it afterward tends to require a conference call and someone from legal.
Then comes judgment.
AI can produce code that looks sensible, reads cleanly, and fails when it meets real users. Real users are exceptionally talented at discovering possibilities nobody considered, including several that should arguably violate the laws of physics.
The developer must still assess the result.
Does this fit the application? Does it protect the data? What happens when a request fails halfway through? Can the next non-AI person maintain it? Have we added a dependency because it solves a real problem, or because the model apparently receives spiritual fulfillment from package installation? Answering those questions requires technical knowledge.
Security, data modelling, debugging, testing, and system design remain essential. Deep language expertise still matters, particularly when the problem gets subtle. AI gives us more ways to apply that knowledge and more reasons to know where our understanding ends. Otherwise, we risk becoming delivery drivers for defects we cannot explain.
The radio analogy has a limit here. The person you called might have earned your trust through years of competent work. AI can suggest a correct solution or invent a function with exactly the same reassuring tone. Confidence is therefore a poor verification strategy. It remains popular because it is faster than checking.
The developer needs evidence: inspecting the code, testing the behaviour, checking assumptions, and observing what happens when things go wrong. “The AI said it would work” is going to look spectacular in a root cause analysis. Put it directly above “we didn’t think anyone would click that.”
This should change how we hire, too.
Joel Spolsky distilled the hiring question into two criteria in The Guerrilla Guide to Interviewing:
- Smart, and
- Get things done.
He also criticized interviews that mistake knowledge of programming trivia for aptitude. That principle deserves renewed attention as we decide how to assess developers working with AI. The central question should be: Can this person solve the problems we need solved?
Knowing the language is evidence worth considering. So is the ability to learn an unfamiliar system, investigate a failure, evaluate possible solutions, and deliver something reliable. We should stop treating syntax recall as a sacred rite of passage. The production server does not care whether you remembered the function signature. It has other plans for ruining your weekend.
Applied to AI-assisted development, a useful interview might give candidates a small, realistic problem: a bug in an unfamiliar application, a feature request with an important ambiguity, or a slow operation that needs investigation. Give them access to documentation and the AI tools they would be allowed to use on the job. Provide comparable access and clear expectations so the exercise measures their work fairly.
Then watch how they approach it.
Do they clarify the requirement? Read the surrounding code? Check what the AI suggests? Notice a security problem? Test the failure path? Can they explain their decisions and adapt when a requirement changes? An AI-generated solution gives the interviewer plenty to discuss. Ask the candidate to explain a particular section, find a weakness, or modify the behaviour. Understanding becomes visible when the conversation moves beyond the answer already on the screen.
Keep the exercise bounded and relevant. Asking someone to spend an unpaid weekend building a feature your company needs is a procurement strategy with an interview costume.
Evaluate candidates against consistent criteria: problem understanding, technical reasoning, verification, communication, and the quality of the result. Give them room to think. A thoughtful pause should not lose to confident nonsense merely because the nonsense arrived with excellent posture.
Candidates need to change their approach as well.
A résumé listing twelve languages tells me what you have encountered. I also want to know what you accomplished. What problem did you solve? What constraints made it difficult? What did you learn? How did you establish that the solution worked? Bring examples you can explain. If AI helped, describe how you used it, which suggestions you rejected, and what you checked yourself. Show me where the first approach failed and how you recovered. A perfectly polished demo can conceal a lot. The story of finding and fixing a bad assumption tells me how you work.
“I don’t know yet, but here’s how I would investigate” should be a useful beginning, provided you can follow it with a sensible investigation. And learn how to demonstrate your contribution clearly. “The AI wrote it” leaves the interviewer wondering which of you applied for the job.
We also need a better definition of efficiency.
Generating a thousand lines of code in minutes proves that a thousand lines of code can be generated in minutes. Their value depends on what they accomplish and what they cost to maintain. Every unnecessary line is something another person may eventually have to understand at 2 a.m. That person could be you. Software has a wonderful way of arranging these little reunions.
An effective developer uses AI to investigate, compare approaches, explain unfamiliar code, identify missing tests, and challenge assumptions. Sometimes the best outcome is a smaller change. Sometimes it is discovering that the feature already exists. Sometimes it is deleting cruft, which deserves more recognition as an act of public service. I also feel more people need to know the definition of the word cruft.
This also changes how developers learn.
Experienced developers bring hard-earned instincts. They have seen innocent changes become outages and “quick fixes” achieve a longer lifespan than the companies that commissioned them. Those instincts can make AI assistance far more useful.
New developers need to build that judgment too. AI can explain unfamiliar concepts and help them experiment, but accepting answers without examining them creates a dangerous illusion of understanding. They need to predict what the code will do, test that prediction, and investigate the difference. Breaking something in a controlled environment remains an excellent teacher. Breaking production is the same course with significantly higher tuition.
Teams should make room for that learning instead of assuming that access to AI includes twenty years of experience as a complimentary attachment. The skills we teach, the work we reward, and the way we interview should all reflect the same expectation: developers must be able to understand problems, use the resources available to them, and deliver results they can stand behind.
That engineer in 1992 understood something our industry occasionally forgets: your value includes how effectively you reach beyond what you already know.
AI gives us an extraordinary resource for doing that. Using it well requires the humility to ask for help and enough understanding to question the answer. Know who to call. Know what to ask. Check the work. Because the AI will be perfectly happy to explain the outage.
You will be the one on the phone.