Generated by ChatGPT. See Beating Pangram and AI detectors.
Ankor runs a company of several thousand people. After a bunch of calls with one of our interns, Varun, he messaged me: “This guy is fantastic. How is he doing it?”
This is what Varun was doing: he recorded calls, fed the transcript to Claude Code or Codex, and delivered results.
That’s nearly the whole process.
He didn’t interpret the content. He didn’t apply much domain knowledge. He got out of the way.
I had told him this deliberately: “Ankor will say something. Don’t try to understand it. You will not understand it anyway. Record the call. Transcribe it. Give it to Claude Code. Deploy to GitHub. Show Ankor. Take feedback. Repeat.”
Varun was thrice as fast as people with five years of experience.
Weirdly, the experience was the bottleneck.
This is the part I like. It is also the part that makes me nervous.
Sridhar Vembu recently asked, roughly: if AI makes senior architects more productive but removes junior work, how does someone become a software architect without first being a junior engineer?
Fair.
My first answer was: maybe juniors should stop doing what AI already does well.
My second answer was: wait, that sounds dangerous.
My third answer, which is where I am now, is: what juniors should learn depends on what it costs to be wrong.
For most software, wrong is cheap.
A bad dashboard. A broken prototype. A weak first draft. An internal tool that falls over. A marketing email that sounds like it was raised entirely on LinkedIn. Annoying, but usually recoverable.
In such cases, I don’t see much point in preserving the old junior task out of affection. If AI writes the CRUD app, fine. Let it. The junior should learn what happens around the CRUD app: choosing the problem, giving context, reviewing output, spotting nonsense, asking for changes, deciding what is safe enough.
That is why my hiring question has changed.
I no longer ask only, “Can you write code?” I increasingly ask: “Can you stop slowing down AI?”
This is an odd hiring question. I don’t know if I like it. But it predicts usefulness better than the old ones, at least for the work I do.
The old signals are breaking anyway.
I teach a data science course at IIT Madras. In March 2026, I pointed a coding agent at one of my own exams. It had 22 questions and was meant for 45 minutes.
The agent solved everything well within time.
The highest score any actual student got was 50 percent. Second highest: 33 percent.
And I no longer had a clue what “hard” meant.
That was not a student crisis. It was a measurement crisis.
My instruments were calibrated for a world where people produced the output directly. That world is becoming… less available.
So before releasing questions now, I copy-paste them into ChatGPT. If it answers, I revise the question. I am using AI to invalidate my own exam instruments in real time. Strange sentence. Still true.
Companies have the same problem with interviews. If candidates use AI secretly, the test becomes an honesty test. Actually, maybe worse. It rewards people who use AI and hide it well.
That is not the skill I want.
What seems to work better is: give someone a vague problem, an AI coding agent, and a few hours. See what useful thing comes out. Then ask what the agent got wrong.
The output alone does not prove much now. The review process tells me more.
But this applies only where wrong is cheap.
Some work is different. A wrong drug dose. A wrong trade. A bridge. An airplane. Security code. Medical software. Payment systems. Anything where the blast radius is bigger than “oops, redeploy.”
There, I would not say “just get out of the way.”
Automation has an old irony. The better the machine gets, the less practice humans get, and the more helpless they are when the machine fails.
Robotic surgery saw this before LLMs. Senior surgeons could do more through robotic consoles. Great. But residents lost the messy hands-on work through which they learned. Efficiency quietly ate apprenticeship.
Pilots had a similar problem with autopilot. So aviation did not say, “Nobody needs to fly manually anymore.” It added simulator time and manual flying requirements.
Maybe software needs more of that.
Not for everything. Please don’t make every React intern attend Kubernetes Incident Simulator Camp. They will leave, and they should.
But for high-risk systems, AI should become the simulator, not the excuse.
Make it generate rare failures. Make it write evil test cases. Make it role-play the bad customer, the regulator, the attacker, the tired reviewer at 2 a.m. Make juniors practice judgment when the system is trying to fool them.
Then there is the third bucket: work we do because we like doing it.
Chess engines can beat any human. People still play chess. In fact, chess got stronger because engines became coaches.
Some coding is like that too. I still code for the joy of making something exist. Often badly. Often at night. Often instead of sleeping, which is a separate governance problem.
So will AI replace junior techies?
It will replace many junior tasks. It already has.
But maybe “junior engineer” was never just a bundle of tasks. Maybe it was a protected way to practice. If so, companies should protect the practice, not necessarily the old tasks.
I am not fully sure what the new apprenticeship looks like.
Right now, mine looks like this: record the call, give it to the agent, show the result, take feedback, repeat. Then, slowly, notice what the agent cannot do.
Maybe that is where the next architect begins.