Outcome focus: Reader can distinguish AI research work from applied AI engineering work, decide which research outputs change their quarter and which do not, and avoid hiring or being hired against the wrong role description.
ai engineeringai researchengineering disciplinecareer
I am not an AI researcher. I work next to AI researchers, sometimes ship code that started as a research artifact, and read papers when the work demands it. This note is what I think AI researchers actually do, written from outside the role rather than inside it. It is short on purpose.
The role-naming question is harder in 2026 than it was in 2020. Frontier labs (Anthropic, OpenAI, Google DeepMind, Mistral) publish at engineering velocity, and "AI researcher" at a startup often means "applied ML engineer with novelty work in their queue." The line between researcher and engineer is fuzzier than the job titles suggest. What follows is the part of the role that is still distinct, regardless of where the title sits.
What they do that I do not#
- Read five to fifteen papers a week and decide which ones matter for their direction. The skill is triage, not literacy. Most papers do not survive the skim.
- Run experiments that take days or weeks of compute to test a hypothesis with no certain answer. The result is data, not a feature. The output of a good experiment can be "the hypothesis was wrong," and that is still a publishable contribution.
- Write papers. Manuscript-shaped technical communication for peer review is its own discipline, with conventions, expected sections, citation discipline, and an audience that will reject the work if it does not show its math.
- Engage with the academic community. Conferences, workshops, peer review for journals, PhD student mentorship, citation networks. This is the compounding part of the role, and it is not optional if the researcher wants to continue being read.
- Operate at the frontier where the answer is genuinely unknown. Most engineering work is "implement a known thing well." Most research work is "find out whether the thing is true, then implement it well enough to convince a reviewer."
What I do that they may not#
- Maintain production code that will not be rewritten in six months. Research code is mostly throwaway by design; production code is mostly not.
- Handle on-call rotations and incidents. Researchers can leave a broken experiment running over the weekend; I cannot.
- Engineer the data pipelines that feed models. The fine-tuning post on this site is engineering work; the paper that introduced the technique is research work; the gap between them is the work.
- Translate research artifacts into product surfaces under deadline pressure. The translation is its own craft and is roughly invisible from inside the research role.
- Manage cost, latency, and throughput tradeoffs in production. A paper that demonstrates a 2x improvement on benchmark accuracy may be a 10x cost increase at inference. Catching that is engineering work.
The artifact: research output to engineer response#
The table I keep in my head when a paper crosses my desk.
| Research output type | Does it change my work this quarter? |
|---|---|
| New foundation model from a frontier lab | Sometimes (only when it ships in a model I can call) |
| New training or fine-tuning recipe | Often (I read it and check if it transfers) |
| New benchmark or evaluation methodology | Often (the methodology is portable even when the result is not) |
| New agent harness pattern | Often (I copy the pattern, drop the framing) |
| New theoretical result on optimization | Rarely (I do not have time to internalize) |
| New mathematical foundation paper | Almost never (I will not get to it) |
| Empirical scaling-law work | Sometimes (it changes my budget conversations more than my code) |
Close#
What changes about my work because of researchers: the models I use, the methods I copy, the evals I steal, and the patterns I lift from the agent and RAG papers I actually read. What does not change: most of the work. Most of the work is data engineering, observability, error handling, deployment, and maintenance. The research is the visible top of the stack. The applied work is the rest of the stack, and the rest of the stack does not get a paper written about it most of the time.
If you are deciding between research and engineering as a career, the question to ask is which kind of uncertainty you want to live with. Researchers live with the uncertainty of "is this true." Engineers live with the uncertainty of "will this hold up at three in the morning when the on-call rotation hits." Both are real. Pick the one whose failure mode you can sleep through.