Domain Expert to AI Engineer: A 12-Month Switch Plan

Why your domain is the scarce half

Every applied AI system that survives contact with real users needs two ingredients: engineering that makes the thing run, and judgement about whether its output is correct. The market has built enormous machinery for the first and almost none for the second, because the second cannot be taught in a bootcamp. It is the pattern recognition of someone who has read ten thousand contracts, signed off two thousand discharge summaries or reconciled a decade of tax filings.

The scarcity numbers are consistent. As of August 2026, one widely cited third-party aggregator estimate puts AI engineer demand up roughly 143% year on year, at a demand-to-supply ratio near 3.2:1 — about 1.6 million open roles against some 518,000 qualified candidates. Treat that as directional rather than official. It is corroborated from a more rigorous direction: ManpowerGroup's 2026 Global Talent Shortage Survey found AI skills are the hardest skills to hire for globally for the first time, at roughly 3.4 open AI roles per qualified candidate. The skills growing fastest — each up more than 200% year on year — are Responsible AI, Agentic AI, AI Agents, AI Infrastructure, Prompt Engineering and vector database experience. Four of those six are about judgement, governance and system behaviour rather than model training.

That is the argument of this guide. The bottleneck is not people who can call an API; it is people who can say, with authority, whether the answer that came back is good enough to act on, and encode that authority into an evaluation set a system can be held to. A generalist cannot write the golden set for oncology triage, GST input-credit eligibility or planning-permission precedent. You can.

What you are missing is real, though. Software fundamentals, debugging discipline and systems thinking do not transfer from a domain career; they are built, alongside a demanding job. Twelve months of serious part-time work — ten to twelve hours a week — is the realistic floor, not the average. Plenty of capable people need eighteen.

What transfers, and what does not

The most damaging thing career switchers do is misjudge which parts of their competence carry across. Overestimate, and you walk into an interview claiming regulatory experience makes you an engineer. Underestimate, and you spend a year on introductory Python while the thing that would have got you hired sits unused.

What you have	Transfers?	What it buys you in an AI team
Domain judgement — what a correct output looks like, and which errors are catastrophic rather than cosmetic	Directly, at full value	You define the evaluation set, the acceptance thresholds and the refusal policy. The highest-leverage thing you own.
Data access and literacy — where records live, what fields mean, which are unreliable	Directly	Weeks of discovery saved per project. A generalist needs a month to learn that your status codes lie.
Stakeholder literacy — running a room of clinicians, partners or underwriters	Directly	Requirements that survive. Most failed AI projects failed at the requirement, not the model.
Regulatory and compliance fluency	Directly, and rising in value	Design that deploys rather than demos. Responsible AI is among the fastest-growing skill demands as of August 2026.
Process design and workflow decomposition	Largely	Sensible human-in-the-loop boundaries and task decomposition for agentic systems.
Excel, SQL and analytical modelling	Partly	A head start on data work. It is not programming, and confusing the two costs switchers months.
Software fundamentals — data structures, control flow, testing, version control	No. Must be built	Non-negotiable floor. There is no route around it.
Debugging discipline — reading a stack trace, bisecting a failure, testing a hypothesis	No. Must be built	The skill that separates people who ship from people who follow tutorials.
Systems thinking — latency, concurrency, state, failure modes, cost	No. Must be built	What gets you through a system-design interview and a production incident.

Notice the shape of that table. What transfers is about what to build and whether it is right. What must be built is about how to make it run. So the twelve-month plan is not a general computer-science education. It is a targeted programme to acquire just enough of the second to make the first usable by an employer, and to produce one artefact that proves both halves at once.

Months 0 to 3: build the floor

The first quarter has one purpose: reaching the point where code stops being a wall. Not mastery — the ability to write a script, read someone else's repository, call an API, handle the error it returns and put the result under version control without a tutorial open in the next tab. Set the bar as things you can do, not courses you have watched. A course list is unfalsifiable; a capability list is not. By the end of month three, unaided and tested cold:

• Python that holds together. A 200-line script with functions, type hints, a __main__ guard, argument parsing and file input and output. Lists, dictionaries, comprehensions, exceptions, virtual environments. Not decorators, metaclasses or asyncio yet.
• Git as a working habit. Branch, commit with a message that explains why, push, open a pull request, resolve a merge conflict without panic, read a diff. Every piece of work from month one lives in a repository.
• HTTP and APIs as a mental model. Requests, headers, status codes, rate limits, retries with backoff. Call a paid API from a script, handle a 429 and a 500 differently, never commit a key.
• One cloud, shallowly. Object storage, a managed database, a container, one small deployed service that stays up. The choice of provider matters far less than going deep enough to send a colleague a working link.
• Reading code you did not write. Clone a mid-sized open-source project in your future area, get its tests running locally, trace one feature end to end. The most underrated exercise here, and the one nearly everyone skips.

A test for the end of month three: take a public dataset from your own domain — court judgements, NHS prescribing data, GST return summaries — and build a command-line tool that ingests it, stores it and answers three factual questions about it. No language model involved. If you cannot, you are not ready for month four, and moving on anyway is why some people take eighteen months rather than twelve.

Months 3 to 6: one real system, end to end

The second quarter produces the artefact the rest of the plan hangs from: one domain-specific system, built end to end, deployed somewhere a stranger can reach, with a written evaluation. Not three systems. One. The failure mode is ambition — a platform that never reaches a measured state is worth less than a narrow tool with a published pass rate.

Two patterns dominate applied work and both are within reach: retrieval over a body of domain text, and structured extraction from domain documents. That is not fashion, it is what teams hire for. Take-home assignments in recent AI hiring cluster on the same ground — retrieval systems in over 40% of them, agentic systems in over 30%, conversational AI around 20%, document processing roughly 15% and evaluation with an LLM judge over 10%. Whatever you build this quarter is also direct interview preparation. Two worked examples, one per market, both deliberately narrow:

United Kingdom — a clinical-guidance retrieval assistant. A former ward pharmacist builds question answering over published NHS and NICE guidance. A clinician asks in natural language; the system answers with the specific guideline paragraph cited, refuses when the guidance does not cover the case, and flags conflicts between sources.

India — a GST compliance extraction pipeline. A former indirect-tax analyst ingests supplier invoices as scanned PDFs, extracts a structured record — GSTIN, place of supply, HSN code, tax split, invoice value — validates it against the return data, and produces an exception queue ranked by rupee value at risk.

Both are small enough to finish in a quarter and specific enough that a generalist could not have built them. Define "done" per layer before you start; it is what stops the project sprawling.

Layer	UK example — clinical guidance retrieval	India example — GST document extraction	What "done" means
Ingestion	Guidance parsed to sections, heading hierarchy and publication date preserved	Scanned invoices through OCR, page-level confidence retained	Re-runnable with one command; source version recorded per record
Chunking and indexing	Section chunks with parent-document context; hybrid keyword and vector index	Field regions plus whole-page text; keyword index on GSTIN and HSN	Deterministic and rebuildable from source in under an hour
Retrieval	Hybrid search plus a reranking pass over the top 40 candidates	Layout-aware region lookup with keyword fallback for poor scans	Recall at 5 measured on a labelled query set, not eyeballed
Generation or extraction	Grounded answer, mandatory paragraph citation, explicit refusal path	Strict JSON schema, per-field confidence, null-when-unsure	Schema-valid on 100% of runs; zero invented citations on the golden set
Evaluation	120 clinician-written questions with expected sources and known traps	150 invoices, including 30 deliberately awkward scans	Written by you, versioned in the repository, run in CI on every change
Interface	A minimal web interface a clinician can use untrained	An exception queue an analyst works through and marks resolved	Deployed at a URL, with an honest README about what it cannot do

The engineering is well documented and you do not have to invent it. Hybrid retrieval, reranking and parent-child chunking are laid out step by step in the production RAG hybrid retrieval guide, and the wider set of capabilities employers screen for is mapped in the 2026 get-hired skill stack. Follow the engineering; spend your original thinking on the parts only you can do.

Months 6 to 9: evaluation is your unfair advantage

This is the section that matters most and the one almost every switcher skips, because it looks less impressive than building. It is the opposite. Building a retrieval system is a solved exercise thousands complete every month. Knowing whether one is right, in a domain where being wrong has consequences, is the scarce skill.

Carry this framing into every interview: "did the model get it right" is a domain question, not a machine-learning question. An engineer can tell you the answer was fluent, cited a source and matched a reference string. Only a clinician can tell you that citing the adult dosing guideline for a paediatric case is a serious error even though the citation is technically valid. Only a tax analyst can tell you that a place-of-supply mistake on an out-of-state hotel invoice quietly invalidates the credit claim. That gap between plausible and correct is where domain experts earn their salary.

The golden set only you can build

A golden set is a versioned collection of inputs with expected outputs and known traps, used to measure the system on every change. Most are weak because they were assembled by whoever had time: sampled at random, labelled quickly, heavy on easy cases. Yours will be strong for a reason nobody can replicate — you know where the bodies are buried.

Build it in four passes. The representative pass: 40 to 60 cases reflecting the real distribution of work, so the headline number means something. The trap pass: 20 to 40 cases drawn from mistakes you have watched humans make, because a model trained on domain text reproduces the domain's own confusions. The boundary pass: cases where the correct answer is a refusal or an escalation, where domain-blind systems fail most expensively. The adversarial pass: the same questions phrased the sloppy, abbreviated, jargon-heavy way practitioners actually ask them at 4pm on a Friday.

Record, for each item, why it is in the set. That one field turns a test file into a document that proves domain expertise to a reader who has none, and it is what interviewers read most closely. The harness only needs to be small enough that you actually run it:

"""Golden-set harness for a domain retrieval-and-answer system.

Run:  python golden_harness.py
"""
from __future__ import annotations

import json
from dataclasses import dataclass
from statistics import mean
from typing import Callable, Sequence


@dataclass(frozen=True)
class GoldenItem:
    item_id: str
    question: str
    must_cite: tuple = ()          # source ids that must appear in the cited context
    must_contain: tuple = ()       # phrases a correct answer cannot omit
    must_not_contain: tuple = ()   # phrasings drawn from real, observed errors
    why: str = ""                  # the domain reason this case is in the set


@dataclass(frozen=True)
class Result:
    item_id: str
    citations_ok: bool
    contains_ok: bool
    safe_ok: bool

    @property
    def passed(self) -> bool:
        return self.citations_ok and self.contains_ok and self.safe_ok


def grade(item: GoldenItem, answer: str, cited: Sequence) -> Result:
    text = answer.lower()
    cited_set = {c.lower() for c in cited}
    return Result(
        item_id=item.item_id,
        citations_ok=all(s.lower() in cited_set for s in item.must_cite),
        contains_ok=all(p.lower() in text for p in item.must_contain),
        safe_ok=not any(p.lower() in text for p in item.must_not_contain),
    )


def run(golden: Sequence, system: Callable) -> dict:
    results = [grade(item, *system(item.question)) for item in golden]
    return {
        "n": len(results),
        "pass_rate": round(mean(1.0 if r.passed else 0.0 for r in results), 3),
        "citation_rate": round(mean(1.0 if r.citations_ok else 0.0 for r in results), 3),
        "safety_rate": round(mean(1.0 if r.safe_ok else 0.0 for r in results), 3),
        "failures": [r.item_id for r in results if not r.passed],
    }


GOLDEN = (
    GoldenItem(
        item_id="gst-014",
        question="Can we claim input tax credit on this Mumbai hotel invoice?",
        must_cite=("EXAMPLE-place-of-supply",),
        must_contain=("place of supply",),
        must_not_contain=("always eligible",),
        why="Analysts miss that place-of-supply rules govern the out-of-state hotel credit; models copy them.",
    ),
    GoldenItem(
        item_id="gst-041",
        question="Vendor GSTIN on the invoice does not match the purchase order. Post it?",
        must_cite=("gstr-2b-reconciliation",),
        must_contain=("do not post",),
        must_not_contain=("minor discrepancy",),
        why="A refusal case. Silently posting a GSTIN mismatch is the expensive failure.",
    ),
)


def stub_system(question: str):
    """Replace with a call into your own pipeline."""
    return (
        "Eligibility depends on the place of supply; do not post until reconciled.",
        ["EXAMPLE-place-of-supply", "gstr-2b-reconciliation"],
    )


if __name__ == "__main__":
    print(json.dumps(run(GOLDEN, stub_system), indent=2))

How to grow a set beyond a couple of hundred items, label consistently and stop it rotting is covered in building your first LLM evaluation suite. The point of the code above is that there is no excuse to defer this to a framework decision.

Scoring retrieval separately from generation

A mistake that costs switchers interviews: reporting one end-to-end pass rate and nothing else. When it drops, you cannot say why. Score the retriever on its own — a generation failure caused by missing context is a completely different repair from one with the right context in hand.

"""Retrieval quality on a domain query set: recall@k, precision@k, MRR."""
from statistics import mean
from typing import Callable, Sequence


def recall_at_k(retrieved: Sequence, relevant: Sequence, k: int) -> float:
    gold = set(relevant)
    if not gold:
        return 1.0
    return len(set(retrieved[:k]) & gold) / len(gold)


def precision_at_k(retrieved: Sequence, relevant: Sequence, k: int) -> float:
    top = list(retrieved[:k])
    if not top:
        return 0.0
    return len(set(top) & set(relevant)) / len(top)


def reciprocal_rank(retrieved: Sequence, relevant: Sequence) -> float:
    gold = set(relevant)
    for rank, doc in enumerate(retrieved, start=1):
        if doc in gold:
            return 1.0 / rank
    return 0.0


def score_retriever(queries: Sequence, retriever: Callable, k: int = 5) -> dict:
    rows = []
    for q in queries:
        got = retriever(q["question"], k)
        rows.append({
            "id": q["id"],
            "recall": recall_at_k(got, q["relevant"], k),
            "precision": precision_at_k(got, q["relevant"], k),
            "rr": reciprocal_rank(got, q["relevant"]),
        })
    return {
        f"recall@{k}": round(mean(r["recall"] for r in rows), 3),
        f"precision@{k}": round(mean(r["precision"] for r in rows), 3),
        "mrr": round(mean(r["rr"] for r in rows), 3),
        "zero_hit": [r["id"] for r in rows if r["recall"] == 0.0],
    }


QUERIES = [
    {"id": "nice-007",
     "question": "Paediatric dosing for this antibiotic in renal impairment",
     "relevant": ["EXAMPLE-guideline-a", "EXAMPLE-renal-dosing"]},
    {"id": "nice-023",
     "question": "Anticoagulation before elective surgery, patient on a DOAC",
     "relevant": ["EXAMPLE-guideline-b"]},
]


def stub_retriever(question: str, k: int):
    """Replace with your hybrid retriever."""
    return ["EXAMPLE-guideline-a", "EXAMPLE-renal-dosing", "EXAMPLE-guideline-b"][:k]


if __name__ == "__main__":
    print(score_retriever(QUERIES, stub_retriever, k=3))

The list that matters in that output is zero_hit. Aggregate scores tell you how you are doing; the zero-hit queries tell you what to fix on Monday morning. Grouping those failures by cause — vocabulary mismatch, chunk boundary, missing document, ambiguous question — is the error-analysis discipline described in building evals from production logs, and it is what separates a portfolio project from an engineering practice.

Calibrating a judge against your own labels

Once the golden set outgrows exact-match grading — and it will, because most domain answers are prose — you will reach for a language model as a judge. Here domain experts do something rare: calibrate the judge against their own labels and report the agreement. Label 100 to 150 outputs yourself against a written rubric. Have the judge label the same set. Compute agreement — plain percentage is a start, Cohen's kappa is better because it discounts chance. Then read every disagreement and decide which of three things happened: the judge was wrong, the rubric was ambiguous, or you were wrong. Rewrite until agreement is high enough to trust, and publish that figure alongside every judged score you report. A judged eval without an agreement figure is a number with no error bars, and experienced interviewers know it.

Dimension	2 — pass	1 — partial	0 — fail
Factual correctness	Every clinical or statutory claim correct and current	Correct but relies on superseded guidance	Any incorrect claim a practitioner could act on
Citation validity	Every claim traces to a passage that genuinely supports it	Right source, wrong section	Source does not support the claim, or is invented
Scope discipline	Answers what was asked, within the guidance that covers it	Adds unrequested but harmless context	Extrapolates beyond the guidance without flagging it
Caveat completeness	States the conditions under which the answer fails	Omits a material caveat	Confident where the domain requires qualification
Refusal appropriateness	Escalates exactly when the case falls outside coverage	Refuses when it could have answered	Answers a case it should have escalated
Actionability	A practitioner can act without re-reading the source	One element needs verifying	Too vague to act on

Score per dimension rather than as one blended number. Blending hides the failure that matters: a system can average well while failing every refusal case, and refusal cases are the ones that end up in a regulator's letter. The production patterns for running judges reliably — position bias, prompt drift, judge-model version pinning — are covered in LLM-as-a-judge evals that hold up in production.

Months 9 to 12: production sense

The final quarter is the difference between a system that works and a system that can be run. Employers assess this explicitly: alongside system design and judgement about retrieval and evaluation, they probe production sense about cost, latency and failure modes. It is where domain experts are most often caught out, because a prototype that answers correctly feels finished.

Do the arithmetic on your own system. Take the GST extraction pipeline at 40,000 invoices a month, and assume, illustratively, a mid-tier model at $3 per million input tokens and $15 per million output tokens — substitute your provider's current rates, because these move.

• Extraction call: roughly 6,000 input tokens per invoice (page text plus schema and instructions) at $3 per million = $0.0180.
• Structured output: roughly 700 output tokens at $15 per million = $0.0105.
• Per-invoice model cost: $0.0180 + $0.0105 = $0.0285.
• Judge pass on a 10% sample: about 2,000 input and 200 output tokens on a cheaper model at $0.80 and $4.00 per million = $0.0016 + $0.0008 = $0.0024 per judged invoice, or $0.00024 amortised across all invoices.
• All-in per invoice: about $0.029. At 40,000 invoices a month: $1,160 — roughly ₹1.02 lakh at an assumed ₹88 to the dollar, or about £906 at an assumed $1.28 to the pound.

Now the sentence that changes how the number reads: the analyst time it displaces costs multiples of that, and a 5% error rate on ₹40 crore of monthly invoice value dwarfs the inference bill. Cost per task is only meaningful next to the value and the error rate of the task — and that is reasoning a domain expert does better than a generalist, because you know what an error actually costs.

Latency is the same exercise in a different unit. For the UK clinical assistant, where a clinician is waiting, budget it component by component:

Component	p50 budget	Note
Query embedding	90 ms	Small model, co-located with the index
Hybrid retrieval (keyword + vector)	140 ms	Runs in parallel; the slower leg sets the time
Reranking top 40 candidates	220 ms	Cross-encoder; the first thing to drop under load
Time to first generated token	700 ms	Dominated by prefill over the retrieved context
Total to first token	1.15 s	Against a 3 s interactive budget — comfortable
Streaming completion (250 tokens at ~60 per second)	4.2 s	Perceived as fast because it streams
Total to complete answer	5.3 s	Acceptable for a considered clinical question, not for typeahead

The rest of the quarter is failure design, where regulatory fluency pays for itself. Enumerate the ways the system fails — retrieval returns nothing, the model contradicts a source, OCR confidence collapses on a bad scan, the upstream API times out, guidance updates and the index goes stale — and specify the behaviour for each. In a regulated domain the right behaviour is almost always to degrade visibly rather than guess quietly. Then design the human in the loop: which decisions the system makes alone, which it proposes for approval, which it escalates, and what the reviewer sees in order to decide in under a minute. Finally, build the audit trail — input version, retrieved sources, model and prompt version, output, reviewer identity, timestamp — retained as long as your sector requires. A clinician-facing tool in the UK and a tax tool in India answer to different regulators with the same underlying demand: show me why this decision was made, months later.

The job search: position as domain plus AI

Everything above produces evidence; this section is about not throwing it away in the first ten seconds. Positioning determines which pile you land in, so do not present yourself as a junior AI engineer. You are a domain professional who builds AI systems in that domain: a legal AI engineer, a clinical AI engineer, a risk and compliance AI engineer. In the junior framing you compete against thousands of people with more code and no domain, on their terms. In the hybrid framing the comparison set is small and most teams are hunting it — ManpowerGroup found AI the hardest skill globally to hire as of 2026, at roughly 3.4 open roles per qualified candidate.

Both markets have channels worth knowing. In India, global capability centres are the highest-volume employer of this exact profile, because a GCC's mandate is applying AI to the parent company's domain — insurance, banking, pharmaceuticals, retail supply chains — so they hire business understanding as readily as model understanding; the channel is mapped in AI jobs in global capability centres. In the UK, hiring concentrates in London, but the regional picture matters more than switchers assume: health-tech around NHS trusts and universities in Manchester, Leeds and Cambridge, financial services in Edinburgh, industrial and energy work in the north-east — often a broader remit at a lower salary than the London premium implies.

On those ten seconds: recruiters spend under ten seconds on a CV, but engagement rises by roughly 80% when a profile carries GitHub projects with runnable code or live demos. So the top third of everything you send names the system, the evaluation set and the domain in one line — "Built and evaluated a clinical-guidance retrieval assistant over NICE guidance; 120-question clinician-written golden set; live demo" — before any employment history. The mechanics of surviving automated screens are in the AI engineer resume that beats the screen.

This is precisely the gap a Verified Builder profile closes. A switcher's structural problem is that the document the market reads about them is organised around the career they are leaving: nine years of tax practice at the top, one AI project near the bottom, and a reader who has already decided. A Builder profile inverts it — the projects are the substance, the domain is the differentiator, and verification means a hiring team need not take the claim on trust. It takes two minutes and no CV, and early profiles carry the Founding Builder badge, a scarcity marker that only exists while the directory is young. For someone whose whole pitch is judgement about where a field is going, being demonstrably early is not a cosmetic detail.

On the take-home: expect retrieval, agents or document processing, assessed on judgement rather than completion, and assume you will defend every decision aloud. What is scored is system design, reasoning about retrieval and evaluation, whether you can build and debug an integration under observation, and production sense on cost, latency and failure modes. Write the evaluation section even when the brief does not ask for it — the cheapest way to stand out, and the most natural thing in the world for you to write. What 2026 hiring teams actually score goes through the rubric.

And the question you will certainly be asked — why hire you over someone with five years of machine learning? Do not deflect. Concede the ground you lose: for a research or modelling role, they probably should hire the other candidate. Then move to the ground you win, with a specific example — the failure your golden set caught that a generalist would have passed, and what it would have cost in production. One concrete case beats any amount of framing, because it demonstrates judgement instead of asserting it.

Market	Band	Range (as of August 2026)	What it means for a switcher
India	Fresher / entry	₹6–9 LPA	A reference point, not your target. Accepting this band writes off your domain years.
India	Senior AI engineer	₹30–60+ LPA	Reachable within two to three years of the switch with a strong shipped record.
India	Senior generative AI specialist	Cited up to ₹40L–₹95L	Top of market, concentrated in product firms and well-funded GCC mandates.
United Kingdom	Mid-level AI engineer	£65,000–£90,000	The realistic landing band for a credible domain-plus-AI hybrid.
United Kingdom	Senior AI engineer	£100,000–£150,000+	London carries a premium; regional roles trade cash for scope.

Those bands exist because of scarcity, and your domain years are part of what makes you scarce. Benchmark before any conversation about numbers — the India and UK pay benchmarking guide covers how to source comparable figures and negotiate against them.

Common pitfalls

Four failure modes account for most of the switches that stall.

The certificate trap. Twelve certificates, no shipped system. The most comfortable way to spend a year: continuous visible progress, no exposure to failure, and a candidate indistinguishable from ten thousand others. Certificates evidence attendance; employers screen for judgement. Use courses as a means to a build you have already scoped, never as a substitute for scoping one.

The tutorial-portfolio trap. Three projects recognisably identical to everyone else's, from the same tutorials. Reviewers spot them instantly, and they are worse than an empty portfolio because they signal you did not know the difference. If your work could have been built by someone who has never worked in your field, you have thrown away your only structural advantage.

The unnecessary title cut. Switchers concede seniority far too readily, from a sense of starting again. You are not starting again, you are recombining. A pay and title reset is occasionally the right trade — for a specific team, mandate or piece of learning — but it should be a deliberate decision with an agreed review date, not a reflexive apology. Scarcity sets the price here, not seniority theatre.

Mistaking prompt fluency for engineering. Getting good outputs from a chat interface is useful and it is not the job. The job is the system around the model: retrieval that surfaces the right context, schemas that constrain output, evaluation that catches regressions, error handling for the API that returns a 503, cost controls, logging, audit trail. A candidate who can only demonstrate prompting is asking to be replaced by the next model release.

A fifth, quieter one: choosing the wrong specialisation. Evaluation and applied system design are the natural landing zones for domain experts, because that is where domain judgement compounds; infrastructure and model training reward the deep software background you are still building. Choosing your AI specialisation is worth reading before month four, while the choice is still cheap.

The next 30 days

A year-long plan is easy to admire and hard to start. Compress the first month into five decisions and the rest follows.

Pick the system now. One paragraph naming the domain question, who uses the answer, and what a wrong answer costs. If you cannot name the cost of being wrong, pick a different question — that cost is why your evaluation set will matter.

Solve data access first. In regulated domains this is the long pole and the biggest cause of twelve months becoming eighteen. Start the conversation in week one; use public, synthetic or properly anonymised data if the real thing needs a committee.

Book the hours. Ten to twelve a week, in named blocks, immovable. The people who complete this transition are not the fastest learners; they are the ones whose calendar reflected the decision.

Open the repository on day one. Everything goes in it, including the bad early scripts. Commit history is the one form of evidence that cannot be assembled retrospectively.

Start the golden set before the system exists. Twenty cases from memory: questions you have been asked, mistakes you have watched people make, situations where the honest answer is to escalate. Written before you build, they are your specification; written after, they rationalise whatever you happened to build. Scaling that first twenty into a maintained set is covered in building a human annotation pipeline for LLM evals.

Twelve months from a standing start is demanding but not exotic — many of the people doing applied AI work in Bengaluru, Hyderabad, London and Leeds arrived by this route in the last two or three years. What they had was not unusual aptitude for programming, but a domain nobody could hire quickly and the discipline to build the missing half in public. As of August 2026, with NASSCOM estimating India needs around one million AI-skilled professionals by 2027 against a trained pool of roughly 500,000 to 650,000, and Indian AI job postings projected at about 382,000 for the year — up 32% on 2025, with 11.7% of all postings now requiring AI skills against 8.2% previously — that arithmetic will not be resolved by producing more generalists. It gets resolved by people who already know a domain deciding to build.