We (erdos) are considering launching an AI researcher pathway. We are creating a process to research AI in vertical domains - which combines AI knowledge with domain knowledge(as per the image). If you are a developer and want to gain experience as an AI researcher - please contact us at Erdos Research and follow my substack Ajit Jaokar substack

Background

I am planning to introduce a researcher track in Erdos in 2026

In 2026, this is an area of focus for me — both through Erdos Research and in my teaching.

In essence, my goal is to help industry professionals develop an AI-first mindset and become confident public contributors to the field of AI research.

When I say developer, I mean this in the broadest sense: anyone building, designing, or shaping products and systems in the real world.

When I say researcher, I am referring not to academic status, but to a way of thinking — a mindset I outline below.

Despite the many shortcomings of academia as it exists today, the intellectual posture of a true researcher remains one of the most powerful capabilities we can cultivate.

If you are a developer who wants to grow into an AI researcher in this sense, I invite you to join my Substack or get in touch.

What is the difference between developer mindset and researcher mindset in terms of problems they solve?

What is the difference between developer mindset and researcher mindset in terms of problems they solve?

This is a powerful distinction, and it sits right at the heart of the discussion.

It’s not just about ‘writing a paper’

The developer mindset is geared to

1. Solving known problems

2. Optimising solutions

3. Scaling solutions

4. Working inside constraints (ex engineering constraints)

5. Success is measured by delivery (what you ship)

In contrast, the researcher mindset is geared to

1. Working with unknown problems

2. Expanding the solution space(body of knowledge)

3. Asks what should exist (as opposed to how to build this)

4. Redefines constraints

5. Measure success by impact

In a nutshell,

A developer solves problems inside a world.
A researcher decides what the world should look like.

This is the mindset leap that turns builders into pioneers.

The best example is the paper from Google Attention Is All You Need by Ashish Vaswani and others. The paper ticks all the five items above.

How their problems differ

To expand on the above

The developer’s problem statement is already defined.

Example: “Build a fraud detection model.”

There is a clear input output mapping and performance criteria

In contrast, the researcher works with ambiguity and loosely defined problem statements - and sometimes may end up working with different problem - than originally envisaged

In general, the developer reduces uncertainty and wants to work with a stable space from which a predictable result can be derived. In contrast, the researcher explores uncertainty - treating ambiguity as a signal to be explored.

As a result of this:

The researcher works with medium to long term problems - on paradigms which are not defined. The researcher produces models, theories, conceptual frameworks - in an attempt to explain a phenomenon instead of implementing it.

The research paper as an artefact to understand a problem

Having discussed the mindset and the problem - we now discuss the research paper as a structured way of thinking about what we do not yet understand.

In doing so, as we discuss below, we bridge mindset, epistemology and artefact(research paper). In this sense, we view the research paper as a problem-solving machine for unknowns.

We can expand on this as follows:

Research problems are:

• Ill-defined

• High-uncertainty

• Full of hidden assumptions

• Often incorrectly framed

So the paper structure is designed to transform ambiguity into insight.

When viewed as a structured way to understand a problem, each component of the research paper contributes to the understanding of the problem

Abstract: provides an overall summary and explains the significance and coherence of the problem

Introduction: Provides the context and frames why the problem exists at all

Literature Review: explains the prior work and maps the intellectual terrain. A literature review is not a list of citations - rather we can think of it as a map of the solution with an objective to identify unresolved contradictions (which we hopefully plan to address in the paper)

Methodology: provides the approach to address the problem. A formalised thinking approach for what the problem really is. What exactly am I claiming — and on what basis? (this is explained in more detail below)

Analysis / Results: Outlines the findings and what the results say - addressing contradictions and unknown questions.

Discussion: Is concerned with the interpretation and converts data into meaning. Discussion is more than an explanation. It is ‘meaning-making’ ie What does this actually change about how the domain should be understood?

Conclusion: provides the takeaways and reframes the original problem in light of the new findings. Its not a summary of even a solution. Its does not necessarily close a problem - rather it reframes it - but could also create better problems.

What is epistemology?

Epistemology is the study of how we know what we know.

It’s not about ‘What is true?’ but its about How do we decide that something is true?

Thus, epistemology governs:

• What counts as evidence

• What counts as a valid explanation

• What you are allowed to ignore

Epistemology is important for the researcher mindset because the researcher questions how the world is known and the basis of belief. In contrast, the developer assumes that the world is knowable.

A research paper is a formal argument about how knowledge is created. In this sense, we can map epistemology to each section of the research paper

• Literature review: Whose knowledge do we trust?

• Methodology: What counts as evidence?

• Analysis: What does reality allow us to claim?

• Discussion: How do we interpret what we observed?

• Conclusion: What do we now believe differently?

The Methodology section

There is a special significance to the methodology section. The methodology section is where a paper stops being opinion and becomes knowledge.

The methodology answers one central epistemic question:

“Why should anyone trust your conclusions?”

It does not describe what you found – It describes how reality was interrogated to produce those findings.

Without methodology:

• You have ideas.

• You have intuitions.

• You have stories.

With methodology: you show how the evidence behind your reasoning - and provide a mechanism for your results to be reproducible.

Specifically, Epistemology asks: How do we know what we know?

Your methodology operationalises this question.

It encodes:

• What counts as evidence

• What counts as signal vs noise

• What counts as causal vs coincidental

• What errors are tolerated

• What biases are controlled

Your conclusions are only as strong as the epistemic discipline embedded in your method.

Thus, the methodology section makes your work reproducible, Falsifiable(Your claims can be proven wrong), Auditable, Transferable(Others can reuse your approach in new domains), Cumulative(Your work becomes a building block, not a dead end)

If we think of the methodology section as ‘How new knowledge will be created’, then we can relate the methodology section to other sections

Literature Review: What is already known

Research Question: What is not known

Results What happened

Discussion: What it means

Conclusion: Why it matters

Conclusion

We (erdos research) are considering launching an AI researcher pathway. We are creating a process to research AI in vertical domains (as per the image)- which combines AI knowledge with domain knowledge. if you are a developer and want to gain experience as an AI researcher - please contact us at Erdos Research and follow my substack Ajit Jaokar substack