The interview went perfectly. That was the first problem.
A CTO, Series B company, Bangalore. Eleven weeks searching for a senior backend engineer. Team stretched, two sprints behind. Then the resume came in.
Four years of experience. Clean GitHub repositories, consistent commit history, contributions to two open-source projects, a personal ML inference pipeline. The systems design round was sharp. The take-home came back in under 24 hours - elegant, well-commented, architecturally coherent. In her words: "the best submission we've seen in months."
She made the offer. He joined.
Six months later she was on a call with me, barely holding it together.
The code had looked great in demos. Under real production load it had collapsed in three separate incidents. Edge cases any experienced engineer would anticipate were completely ignored. When the team tried to extend his implementations, the architecture made no sense from the inside. When they finally sat him down and asked him to explain one specific design decision - not reproduce it, just explain the reasoning - he went quiet.
He had not made those decisions. He had not understood them. He had prompted his way to an output that looked correct, and he had never gone deeper than that.
"We spent six months fixing what he built. And then we spent another two months trying to find someone to replace him."
She is not unusual. She is the rule.
The gap nobody is naming out loud
In February 2026, Scaler and CyberMedia Research surveyed 400 software engineers and tech recruiters across India. The finding:
89% of Indian engineers describe themselves as "AI-ready." Only 19% have ever deployed and maintained an AI system in a production environment. — Scaler-CMR India Tech Skills Report, February 2026
Seventy percentage points. That is not a skills gap. That is a canyon.
And you, right now, have no reliable way to tell which side of it any given candidate is standing on. 86% of Indian tech recruiters in that same study said finding genuinely AI-skilled candidates is "extremely difficult" - despite inboxes that are full.
What vibe coding is, and why it breaks your hiring
Andrej Karpathy coined "vibe coding" in early 2025 - a workflow where you guide AI through natural language, iterate on the output, and never necessarily read or understand the underlying code. For rapid prototyping and personal projects, it is extraordinary.
For production engineering at 3am on a Thursday when latency has spiked to 12 seconds and your CTO is paging the team, it is a disaster waiting to happen.
"Vibe coding gets you to 80%. The last 20% is where your Series B either ships or bleeds."
The 80% is the demo. It works. It passes code review when the reviewer is also only evaluating the output. It even passes most take-home assignments - because GPT-4o, Claude 3.7, and GitHub Copilot can solve a standard take-home in under two hours. The engineer who submits it did not write it. They directed it.
"The code is real. The capability behind it may not be."
Why the portfolio is lying to you
A polished GitHub portfolio used to be the most reliable signal in engineering hiring. It requires a different kind of reading now. Here is what you are actually looking at in 2026.
Profile A — The Vibe-Coded Portfolio
- Repositories: 14, with 8 of them created in the same 3-week period
- Commit pattern: Burst of activity, then long silence, then another burst
- Commit messages: "initial commit", "add feature", "fix bug", "update README", "final version"
- PR activity: Self-merged with zero review comments
- Issue threads: None - no bug reports ever filed or resolved
- Open source: One contribution, a spelling fix in a README
Profile B — The Real Engineer
- Repositories: 6, maintained consistently over 18 months
- Commit pattern: Steady activity with visible debugging loops
- Commit messages: "fix: race condition in connection pool when requests exceed 500 concurrent", "revert: latency regression from v2.3 patch", "refactor: moved auth middleware to reduce coupling with rate limiter"
- PR activity: Reviewed by others, 14 comments, 3 revision rounds
- Issue threads: 7 filed and closed with root cause documented
- Open source: Meaningful PRs with real discussion threads
Anyone can generate Profile A over a weekend with Cursor or Windsurf. Nobody can fake Profile B without having built something real over real time.
The difference is not star count or repository volume. It is the evidence of thinking under pressure - debugging loops, reverts that show caught mistakes, commit messages that explain why not just what.
The real cost you are not calculating
Most engineering leaders calculate a bad hire as salary wasted plus recruitment fee plus time-to-rehire. That calculation is always wrong in the same direction. Here is the full ledger.
Salary (visible): Direct compensation - ₹18-30 lakh per year.
Supervision tax: A struggling engineer requires 25-50% of your best senior engineer's time for oversight and rework. That senior costs ₹40-60 lakh a year. You are burning ₹20-30 lakh of their productive capacity on oversight alone.
Technical debt: Bad architecture propagates. Other engineers build on top of it. Teams spend 23-42% of their time on maintenance and debt-related issues. A vibe-coder who shipped for six months can push that number toward the top of that range.
Team damage: Over 50% of engineers have considered leaving a job specifically because of frustration with poor codebase quality. Your best people are the most sensitive to a broken codebase. They will not always tell you why they are leaving. They will just leave.
Opportunity cost: Every week the engineering team manages this fallout is a week they are not shipping the features that push you toward your next funding milestone. It shows up in your metrics and in your board conversations.
Industry estimate: 100-300% of annual salary gone. For a ₹25 lakh engineer, that is ₹25-75 lakh. And the damage is never cleanly contained. It spreads into architecture, team culture, and compounds.
The root cause of all of it: a hiring process designed to evaluate outputs, at a time when outputs have become completely decoupled from understanding.
The broken-incident interview: the technique that actually works
Instead of asking a candidate to build something, show them something broken, and watch how they think.
Take a real production incident from your history. Anonymize it - remove company names, system names, everything proprietary. What remains is logs, error traces, observed behavior, and a timeline. Put it in front of the candidate with one sentence: "This happened. What do you think is going on?"
The vibe coder: Reaches for a solution without understanding the problem first. Suggests things that sound plausible but do not follow from the actual symptoms. When asked "why did you think it might be that?" - cannot give a coherent chain of reasoning.
The engineer with real depth: Goes quiet. Then starts asking questions. "Is this happening on all nodes or just some? What changed in the deployment before this started? What does the traffic pattern look like right before the spike?" They form hypotheses. They test them. They know what they do not know, and they say so.
"The gap between these two shows up in about eight minutes. Not eight months."
How to run it
Step 1: Use a real incident, not a constructed one. Real incidents have weird timing, unclear errors, multiple potential causes. Constructed ones are too clean.
Step 2: Anonymize completely. Logs, observed behavior, and a timeline relative to recent changes. That is all they need.
Step 3: Give them 5-10 minutes of quiet reading. You want initial thoughts, not just a reaction.
Step 4: Ask one opening question. "What do you think is happening?" Then go quiet.
Step 5: Follow the reasoning, not the answer. "Why do you think that?" "What would you look at next?" "What would tell you your hypothesis is wrong?" You are evaluating whether the reasoning is coherent, systematic, and honest about uncertainty - not whether they reach the right answer.
Step 6: Add information mid-scenario. Maybe the incident only happened on one node, not all of them. A vibe coder gets confused. An engineer with real systems understanding immediately updates their mental model and tells you exactly what changes.
Three questions to add to every technical debrief
"Walk me through the worst production incident you have dealt with."
Listen for specificity, ownership, and discomfort. A vibe coder gives a vague story where everything resolved cleanly. An engineer with depth tells you something that still makes them slightly uncomfortable - because they know exactly what they could have caught earlier.
"Tell me about a time you threw away a significant piece of your own work. What made you decide to throw it away?"
AI-generated code that did not work is not memorable. Real engineering mistakes are.
"What is something you built in the last year you are genuinely proud of - not because it shipped, but because of a specific decision you made inside it?"
You want a decision with trade-offs. Why this choice over that one, what they gave up, what they gained. Vibe-coded work has outputs, not decisions. An engineer who has genuinely made hard technical choices can talk about them for twenty minutes without repeating themselves.
The two kinds of "AI-fluent" engineer you are actually looking for
AI as Amplifier: The engineer understands what they ship at every layer. They use AI to move faster at implementation because they already know what the implementation should look like. When AI gives them something wrong, they catch it immediately because they are reading the output against their own mental model. Detectable in a broken-incident scenario in 8 minutes.
AI as Replacement: The engineer uses AI to generate solutions they do not fully understand, iterates until it appears to work, and ships it. Their understanding terminates at the surface of the output. When something breaks, they cannot reason about why because they were never inside the system. Also detectable in a broken-incident scenario in 8 minutes.
"The candidate who submits a stunning take-home and cannot explain a single decision inside it is not your next great engineer. The candidate who submits something messier but can walk you through every decision they made - including the ones they got wrong - probably is."
What to do starting this week
Replace one take-home with a broken-incident scenario. Take a real production incident, anonymize it, use it as your next technical screen. Swap one step. Nothing else needs to change yet.
Add one question to every debrief. The worst production incident question. Listen for specificity. Listen for the discomfort of genuine failure.
Change how you read portfolios. Stop evaluating what was committed. Start asking why. One fifteen-minute conversation about decisions behind a project tells you more than reading the entire codebase.
Those have always been different signals. In 2026, the gap between them has never been wider.
How Saral AI reads what your interview cannot
Most hiring tools solve for speed - faster screening, faster scheduling, faster communication. The signal itself stays broken.
SaralHire.ai was built to change the signal.
We read the technical footprint, not the resume. Instead of relying on what an engineer claims to have built, we map what they have actually shipped and maintained. That means their full public GitHub history - not just the repositories they chose to showcase. We look at commit message quality, PR review activity, issue resolution patterns, and contribution history on projects they did not initiate.
We weight production-thinking signals. Reverts that show caught errors. Multi-month commit histories on a single project. Detailed bug fix descriptions. Contributions to infrastructure and observability tooling - not only feature code. These signals only exist when someone has dealt with real systems under real load.
We surface candidates who are not looking. The engineers most likely to be AI-amplifiers are too busy building to update their resume or check job boards. We find them by reading the technical signal they leave in public repositories, and we tell you exactly why they are relevant to your specific engineering context before they ever consider switching.
The result is a shortlist that is shorter than what you get from a job board - and completely different. Every person on it has a demonstrated technical footprint that explains precisely why they belong in your pipeline.
If you are scaling an engineering team past 15 engineers and this problem feels familiar, a 10-minute conversation at saralhire.ai is the most useful thing you can do this week.
Book a Demo with Saral AI
FAQ
