DEV Community: rishab paul

If We Can't Verify It, It Doesn't Ship: Engineering an AI Product That Isn't Allowed to Lie

rishab paul — Sun, 12 Jul 2026 07:50:52 +0000

Design rules for an LLM pipeline whose output people act on — from a small product that turns AI job-search research into something you can trust.

Ask any LLM for "20 companies hiring senior PMs in Bengaluru right now" and you'll get 20 names in seconds. Some are hiring. Some froze headcount months ago. One or two may not have the role at all. Here's the trap: the output looks identical either way. Fluency is not evidence, and an invented fact arrives wearing the same confident prose as a checked one.

For most AI products that's an annoyance. For ours it's disqualifying. We sell done-for-you job-search research — scored target roles, company deep-dives, salary bands, a rewritten résumé — and a job seeker acts on it. They spend an evening tailoring an application to a role. If that role closed three weeks ago, the AI didn't save them time; it stole an evening from someone who may be between jobs. One hallucinated fact can cost a real person a real opportunity.

So we adopted one rule and built the pipeline around it: if we can't verify it, it doesn't ship. This post is the engineering version of that rule — the principles that turned out to matter, and what they cost.

Rule 1: LLMs draft, deterministic code decides

The single biggest architectural decision: no LLM in the pipeline is allowed to grade its own homework. Generation is probabilistic; acceptance is not. Every package passes through a verification gate written in plain, boring, deterministic code — date arithmetic, salary-band consistency checks, count assertions, live-URL checks, source-tracing rules.

Why not ask a second LLM to review the first? We do use model-assisted review for semantic questions — but it never gets the final vote. A reviewer model inherits the same failure mode as the generator: it can be confidently wrong, and it can be talked into things. A regex that checks whether a "deadline next month" is actually in the future cannot be sweet-talked. Policy lives in code; models fetch and draft.

The checks themselves are unglamorous, which is rather the point:

Dates. Every date is checked against the calendar. A deadline in the past fails the gate.
Salary math. Compensation ranges must be internally consistent — a band that contradicts its own source or its own arithmetic is corrected or cut.
Live links. Every role link is fetched at build time. Jobs close fast, and we can't stop a posting from dying an hour after delivery — but we never knowingly ship a dead link.
Provenance. Claims about the candidate must trace to their résumé or their brief. A skill they never mentioned gets flagged for their confirmation — never asserted on their behalf. (This one is non-negotiable: an AI padding your résumé is lying in your name.)

Rule 2: Fail closed, and fail loud

The subtle bug class that scared us most wasn't a failing check — it was a check that silently didn't run. An unreachable validator that returns "no findings" looks exactly like a passing one. A skipped audit is not a pass; it's an unverified package wearing a green badge.

So the gate fails closed: if a check crashes or can't run, the package doesn't move — it goes to a human, with a visible trace of what didn't run. This sounds obvious written down. In practice every "graceful degradation" you add to an AI pipeline is a place where safety can silently evaporate, and you have to hunt them deliberately. Our default changed from "degrade gracefully" to "degrade visibly."

Rule 3: If it can't be traced, downgrade it — never assert it

LLMs fill gaps. It's what they're for, and in research it's exactly what you don't want. Our tracing rule: every claim in a deliverable must be attributable to something actually read — a posting, a filing, a careers page, the candidate's own documents. A claim that can't be traced gets downgraded ("needs confirmation"), cut, or escalated to a human. The one thing it never gets to do is stay in the package as a fact.

The consequence buyers actually notice: our lists are sometimes shorter than a chatbot's. Twelve verified roles beat twenty padded ones, because the eight fillers aren't neutral — each one costs the reader an evening to discover it was filler.

Rule 4: Ship the receipts

Every package ends with a module we call How This Was Built: the searches run, the sources read, and the exclusions made — named, with reasons ("we dropped X because the only posting was 90 days stale"). Two audiences for this:

The customer, who deserves to see the work, not just the conclusions.
Us. Receipts are a forcing function. A pipeline that must show its sources can't quietly invent them. If you're building anything whose output people act on, make the system produce its own audit trail as a first-class artifact — you'll catch more with that than with any prompt that says "do not hallucinate."

Rule 5: A human before send — as long as it's earning its keep

Nothing goes to a customer on autopilot. A person reviews the verified package before it ships. We think of autonomy as something the pipeline has to earn with a measured track record, not something you grant because the demo looked good. The gate catches the mechanical lies; the human catches the ones we haven't written a check for yet — and every one of those becomes the next check.

What this costs (honestly)

Verification is why delivery takes 4 business days instead of 30 seconds, why capacity is limited, and why some claims arrive labeled "needs confirmation" instead of stated smoothly. Slower, smaller, more hedged — every incentive in AI products points the other way, which is exactly why unverified output is what the market defaults to.

And one thing verification doesn't buy: promisable outcomes. We never guarantee interviews, offers, or a salary figure — anyone who does is selling you the confidence, not the work. The guarantee is narrower and real: everything in the package was checked before the customer saw it.

The takeaway, if you're building with LLMs

The interesting engineering in AI products has quietly moved. It's not in the generation — everyone's generation is fluent now. It's in the acceptance path: the deterministic gate, the fail-closed defaults, the provenance rules, the receipts. Fluent is a commodity. Checked is the product.

This is adapted from our verification standard. CareerIntel is a small done-for-you job-search research service — how it works, and a real sample if you want to see what a verified package looks like.

QA & SDET Salary Report India 2026: Verified, Sourced, Reconciled

rishab paul — Sat, 11 Jul 2026 19:11:28 +0000

Why every salary site gives a different number — and the honest consensus, reconciled from six public sources with an open methodology. Every figure cited; nothing proprietary, nothing invented.

Search any testing-role salary in India and you get a different number from every site — ₹5 lakh here, ₹7 there, a confident ₹17 somewhere else. The numbers aren't wrong; they're measuring different things, and almost no one explains which. This report does the unglamorous work: it reconciles six public 2026 sources into one honest picture, shows its method, and cites every figure. The goal is the most trustworthy QA/SDET salary reference for India — not the highest number.

What this is, plainly: a transparent synthesis of public data, not a proprietary dataset. We did not run a survey or scrape profiles — we reconciled what reputable public sources already report, and we show our working. CareerIntel's whole premise is "verified, not hallucinated," so a salary report that hid its sources or invented a number would undercut the brand. Every figure below is cited with an access date; where sources conflict, we say so.

Methodology (read this — it's the point)

The single most useful thing to understand is why salary numbers disagree. They come from two kinds of source that measure different populations:

Survey-based (PayScale, Glassdoor, Indeed, AmbitionBox): self-reported pay from a broad mix of real employees — freshers to seniors, service and product companies. These run lower and more representative of the typical engineer.
Aggregator / scraped (some "₹17 lakh average" sites, parts of 6figr): pulled from profiles that skew senior, product-company, and often report total compensation including stock. These run roughly 2× the surveys — not fake, just measuring the top slice.

Our reconciliation rules, applied consistently: (1) prefer survey medians for "typical" ranges; (2) treat scraped/aggregator figures as a ceiling for senior product-company roles, never as an average; (3) present every figure as a range, not a point; (4) separate base from total comp and never compare across the two; (5) exclude any figure we can't trace to a dated public source. Sources were accessed 2026-06-18 (listed in full at the end). The honest limitation: self-reported data has selection bias, and bands move with the market — re-verify anything older than ~6 months.

Key findings (citable, every figure sourced)

Sources disagree by ~2–3× for the same role — almost entirely explained by survey-vs-scraped populations and base-vs-total-comp, not by one source being "wrong."
Typical QA engineer (all-India, all levels): roughly ₹5.5–7 LPA (PayScale ~₹5.5; Glassdoor ~₹6.5–7). The "₹17 lakh average" figures are a senior product-company ceiling, not a typical number.
The automation premium is ~30–40% role-for-role (automation ~₹6 LPA vs manual ~₹4.3 LPA, Glassdoor) — not the "50–100%" often quoted, which describes upskilling over 12–18 months.
SDET sits highest, median ~₹9–11 LPA all-experience (PayScale), rising past ₹20 LPA at product companies with stock.
Product vs service is ~2–3× base — the largest single lever, larger than city or years.
Skill premiums: Playwright ~5–15% over Selenium-only; knowing both ~15–25%; CI/CD+automation ~₹10–18 LPA; API automation ~₹7–14 LPA (TestDino 2026; Testleaf 2025).

Reconciled ranges by role & experience

Read as ranges, not promises. Each role has a dedicated, deeper guide linked below.

Manual / functional QA: ~₹3.7–4.3 LPA typical (Indeed/Glassdoor) — the lowest, shrinking band.
QA engineer: 0–2 yrs ₹2.9–5.0 · 2–5 yrs ₹5–8 · 5–8 yrs ₹8–15 · 8+ yrs ₹12–21+ LPA. Full detail: QA engineer salary in India.
Automation tester: 0–2 yrs ₹4–6 · 2–5 yrs ₹6–11 · 5–8 yrs ₹11–20 · 8+ yrs ₹20+ LPA. Detail: automation tester salary.
SDET: entry ₹4–8 · mid ₹10–20 · senior/lead ₹21–40+ LPA (top-decile/product higher). Detail: SDET salary in India.

By city (directional)

City shifts the number less than role or company type, but it matters. Directionally across the public sources: Pune and Delhi-NCR consistently top typical pay; Hyderabad, Chennai, Mumbai sit mid-pack (weigh Mumbai's cost of living); Bengaluru is mid-pack on average but has the highest ceiling in the country thanks to product/GCC density — see QA salary in Bangalore for why the average misleads.

The "am I underpaid?" framework

Don't compare yourself to a headline average. Compare on four axes at once: (1) your experience band, (2) your city, (3) manual vs automation vs SDET, and (4) service vs product. A 4-year automation tester at a product company in Pune and a 4-year manual tester at a service company in a tier-2 city are both "QA engineers" earning wildly different, both-correct numbers. If you're below your band on all four axes, the fastest levers are skill (toward automation/SDET) and company type (toward product) — covered in the QA engineer career roadmap.

How to cite this report

Journalists, bloggers, and researchers are welcome to cite these reconciled ranges with attribution. Suggested citation: "CareerIntel — 2026 QA & SDET Salary Report for India (careerintel.dev/research/qa-sdet-salary-india-2026), a transparent synthesis of public 2026 sources." Please link to this page and cite the underlying public sources (listed below) for the raw figures — we synthesised them, we didn't generate them.

Limitations (the honest part)

Self-reported survey data carries selection bias; treat all figures as directional ranges.
Bands move with the market — these reflect mid-2026 and should be re-verified after ~6 months.
We report public aggregates only; we make no proprietary-data claim and ran no primary survey.
Total-comp figures (with stock) are volatile and company-specific — we flag them as ceilings, not norms.

Where CareerIntel fits (honestly)

A reconciled market range tells you where the market is. It can't tell you which specific companies pay the top of your band for your exact stack, or whether your profile reaches them — that needs current, per-person research. That's the gap CareerIntel closes.

Find out which companies pay the top of your band. Scored target roles, verified company deep-dives with real comp bands, and an ATS-ready resume — delivered in 4 business days, every figure checked against its source. → See a real sample

FAQ

Why do QA salary numbers vary so much between sites?
Because they measure different populations. Survey sites (PayScale, Glassdoor, Indeed) capture a broad mix of real employees and run lower; aggregator/scraped sites skew senior, product-company, and often report total comp with stock, running ~2× higher. Neither is "wrong" — they answer different questions.

What is the average QA/SDET salary in India in 2026?
Typical QA engineer ~₹5.5–7 LPA; automation tester ~₹6–8.5 LPA; SDET median ~₹9–11 LPA, rising past ₹20 LPA at product companies with stock. Read these as reconciled ranges from public sources, not point figures — your number depends on experience, city, role type, and company type.

Is this CareerIntel's own salary data?
No — and we are explicit about that. This is a transparent synthesis of public 2026 sources (PayScale, Glassdoor, Indeed, AmbitionBox, 6figr, TestDino, Testleaf) with an open methodology. We did not run a survey or scrape profiles; our contribution is the reconciliation and the cited ranges. Every figure links to its public source.

Can I cite this salary report?
Yes, with attribution — link to this page and cite the underlying public sources for the raw figures. The reconciliation and methodology are ours; the raw data belongs to the cited sources.

Sources (accessed 2026-06-18)

Originally published at careerintel.dev.

11 QA Resume Mistakes (and How to Fix Each)

rishab paul — Fri, 19 Jun 2026 09:52:33 +0000

I've read a lot of QA resumes. The frustrating part: the strongest testers often have the weakest resumes.
Not because they lack skill — because nobody ever told them what a recruiter actually scans for. They list 14 tools and zero outcomes. They write "responsible for testing" instead of "caught X before release." They bury the one line that would get them the interview.
So I put together the 11 mistakes I see most — and exactly how to fix each. No fluff, no "use action verbs." Specific.
If you're a QA engineer not getting callbacks, start here → https://careerintel.dev/guides/qa-resume-mistakes