Ad Image

Thinking Beyond Automation to Safeguard Tomorrow’s Software Talent

Thinking Beyond Automation to Safeguard Tomorrow’s Software Talent

Thinking Beyond Automation to Safeguard Tomorrow’s Software Talent

Anand S, an “LLM Psychologist” at Straive, argues that companies need to start thinking beyond automation if they want to safeguard tomorrow’s software talent. In his words, this trend is why he prefers “interns over senior developers.” This article originally appeared in Insight Jam, an enterprise IT community that enables human conversation on AI.

After a bunch of calls with one of our interns, Varun (a student at IIT Madras), our CEO, Ankor, messaged me: “This guy is fantastic. How is he doing it?” This is what Varun was doing: he fed transcripts directly into Claude Code (or Codex) and delivered results. That’s the whole process. He doesn’t interpret the content or apply domain knowledge. He simply gets out of the way.

I gave Varun that instruction deliberately. I told him, “Ankor will say something. Don’t try to understand it. You will not understand it anyway. Take the emails and transcript. Give them to Claude Code. Deploy to GitHub. Show Ankor. Take feedback. Repeat.” Varun is thrice as fast at this as anyone with five years of experience. Ironically, their experience is the bottleneck.

AI is here to stay. What companies can do for the next generation of leadership and talent—the interns who eventually become head developers and system architects—is enable them to become better strategists, smarter workers, and more skilled overseers.

Usha Rengaraju, who leads Research at Exa Protocol, and the world’s first female triple Kaggle Grandmaster, told me at a panel in Hyderabad this March: until 2024, she employed six to seven interns, predominantly from top Indian Institutes of Technology (IIT), at ₹3-3.5 lakh per month (roughly US $3,000) in salaries. Now, she’s replaced them with artificial intelligence (AI), saving ₹60-70 lakh (US $71,000 to $83,000) a year. She went the opposite direction from me. She’s running leaner, but I’m hiring more interns than before.

We’re both right. Her work is greenfield prototyping, where the model handles everything. My work requires a human in the loop, but one who doesn’t slow the loop down. The intern is the custodian of the AI outputs, knowing how to prompt these tools and evaluate their outputs.

I teach a data science course at IIT Madras to around 5,000 students each year. I design the exams and iterate on them constantly. In March 2026, I pointed a coding agent at one of my own exams (22 questions, 45 minutes) to test if the questions were correctly specified. The agent solved everything in well under 45 minutes. The highest score any actual student achieved: 50 percent. The second highest was 33 percent. And I no longer have a clue how to judge if an evaluation is easy or hard.

This is a measurement crisis. My instruments are calibrated for a world in which people produce output directly. That world ended, but the exam still ran, and the scores still came back. But what they are, I have no clue anymore.

So, I now use this as a feature. Before releasing any exam question, I copy and paste it into ChatGPT. If it gives the answer, I revise the question. I’m using AI to invalidate my own evaluation instruments in real-time. (This is a strange sentence to write. I’m writing it anyway.)

The hiring equivalent of this is what enterprise software teams are in their own interview loops. Karat’s 2026 engineering interview report found that 62% of organizations prohibit AI in their technical assessments. But hiring leaders estimate that more than half of candidates use it anyway. That’s not a skills test. Maybe it’s an honesty test? Actually, the candidates who pass are the ones who hide their tools, not the ones who use them best.

CodeSignal’s 2026 survey says 91% of software engineers use agentic AI coding tools, and 75 percent have shipped production code generated at least partly by AI in the past six months. Stack Overflow’s 2025 developer survey found that AI tool adoption is 80% among developers globally.

The take-home project no longer measures what it used to. Nor does the GitHub portfolio. HackerRank’s 2025 developer skills report makes it clear: standards good enough two years ago no longer are. The output no longer proves the capability.

Anthropic’s own two-hour engineering exam, when given to Claude Opus 4.5, produced a score higher than any human candidate ever. To be fair, the model was given several chances at each problem, and the exam measures technical ability under time pressure rather than collaboration or communication. But the direction is clear. Benchmarks that screen humans now favor machines.

What’s left that proves anything?

The question I now actually ask (when deciding who to bring in) is no longer “Can you write code?” It is “Can you stop slowing down AI?”

Accumulated domain knowledge is often an impediment. It makes people second-guess the model, rewrite agent output without reviewing, and retry approaches the model discarded.

Usha still runs her coding interviews for important apps. (“I would still have them go through system design interviews, coding rounds.” She paused, then added, “in 2026”. I agree; 2027 is too far out.) In banking, pharma, and other regulated domains, expertise matters a lot. Large language models (LLMs) can hallucinate, and we need experts to catch them. But that’s not what most of the software is delivering today.

The industry is starting to get it. Meta runs coding interviews that allow AI coding agents. That’s how real work happens anyway. Karat’s NextGen assessment framework suggests realistic environments and expert interviewers evaluating judgment rather than the code.

So, the pressing query isn’t whether a prospective hire can write the code. Can they define the problem, nudge and supervise the model, spot incorrect answers, and own the results? I don’t know what exactly to hire for. My answer keeps changing.

But I know the old, proven signals—hard work, practicing problems, time pressure—weren’t what we were hiring for either; they were proxies that AI made easy. That’s good. Clearly, we weren’t measuring what we really wanted.

What seems to work for me is: give them a vague problem, a coding agent, and four hours. See if they deliver useful output, and if they can explain what the agent got wrong. If they do that, I don’t care about their resume. I’ll hire them on the spot.


Share This

Related Posts