Skip to content
Research

Publishing your first AI paper as an undergraduate

What actually stands between a capable student and a first publication — and the order of operations that gets you from reading papers to submitting one.

AI-Shala Team 11 min read
fifty papers read Submitted Under review Revise Accepted

Papers do not get published because someone had a brilliant idea. They get published because someone had an ordinary idea, scoped it honestly, ran the experiments properly, and wrote it up so that a tired reviewer at 11pm could follow the argument.

All four of those are learnable. Almost nobody teaches them to undergraduates.

The order of operations

Most students attempt this in the wrong sequence. They pick an exciting topic, start coding, generate results, and then try to write a paper around whatever they have. That almost never converges.

The order that works:

  1. Read enough to know what is already done
  2. Find a gap you can actually close in your available months
  3. Write the abstract first
  4. Run the experiments that abstract promises
  5. Write the paper
  6. Pick the venue and submit

Step 3 is the one that surprises people, and it is the one that matters most.

Reading: three passes, not one

Reading a paper front to back is the slowest possible way to read a paper.

Pass one (5 minutes). Title, abstract, figures, conclusion. Decide whether this paper is relevant at all. Most are not.

Pass two (30 minutes). Introduction, method at a high level, results. You should now be able to say what they claim and what evidence they offer.

Pass three (2+ hours). Only for the handful of papers you are building on. Reconstruct the method well enough that you could implement it. If you cannot, you do not understand it yet.

To map a new field, start from a recent survey, then read the papers it cites most, then look at what cites those. Twenty papers read this way is a working map. Two hundred papers skimmed is not.

Finding a gap you can actually close

The instinct is to look for something nobody has done. That is usually a trap — if it is genuinely untouched and important, a lab with twelve people and a cluster is probably already on it.

Better gaps for a first paper:

  • The unexamined assumption. A well-known method assumes something that does not hold in a setting people care about. Show what happens.
  • The missing comparison. Two lines of work have never been evaluated against each other under the same conditions. Do it properly.
  • The honest negative result. A popular technique does not transfer to a domain everyone assumes it does. This is publishable and unusually useful.
  • The reproduction with teeth. Replicate a headline result and identify which component actually carries it.

None of these require a novel architecture. All of them are real contributions, and all are achievable in eight months by one person.

Write the abstract before the experiments

Write the 200-word abstract of the paper you intend to produce. Include the claim and the evidence you expect to have.

Now look at it honestly. Is the claim interesting if it turns out true? Do you know how to run the experiment that would support it? Would it also be interesting if the result went the other way?

If the answer to any of these is no, you have saved yourself four months. This single exercise kills more bad projects than any amount of later analysis.

Experimental hygiene

The difference between an accepted paper and a rejected one is frequently not the idea. It is whether the experiments can be trusted.

  • Seeds. Run every configuration with at least three, report mean and variance. A result that only holds for one seed is not a result.
  • Baselines. Tune them as carefully as your own method. Reviewers can tell, and an under-tuned baseline is the fastest way to lose credibility.
  • Ablations. For every component you added, show what happens without it. If nothing changes, cut the component.
  • Log everything. Every run, its configuration, its output. You will need a number in month seven from a run in month two.

Keep a research log — one page a week, what you tried, what happened, what you think it means. It becomes your related-work section, your method section, and your defence against having forgotten why you made a choice.

Writing so a reviewer can follow you

Structure, in the order you should actually write it:

  1. Method — write it while it is fresh
  2. Experiments — what you ran and what happened
  3. Related work — position yourself against the literature
  4. Introduction — last, because only now do you know what the paper says
  5. Abstract — revise the one you wrote at the start, honestly
  6. Conclusion — short, and no new claims

A related-work section that reviewers respect does not list papers. It groups them into approaches, says what each gets right, and says precisely where yours differs. “X et al. did A. Y et al. did B.” is a reading list, not a position.

Your figures carry more weight than your prose. A reviewer decides what they think of your paper from the abstract and Figure 1. Make Figure 1 the argument.

Choosing a venue

Do not aim your first paper at the largest conference in the field and nothing else. Reasonable ladders:

  • Workshops at top conferences — real review, real audience, much higher acceptance, and the feedback is often better than the main track
  • Strong specialised venues in your subfield
  • Main-track submissions once you have been through the cycle once

A workshop paper at a good venue is a genuine credential, and it is how a large number of successful researchers started. Waiting for a main-track acceptance as a first publication costs most students a year.

What a rejection means

Roughly: not much. Acceptance rates at major venues sit around 20–25%, and the variance in reviewing is well documented. Strong papers get rejected constantly.

Read the reviews, wait three days, then read them again. Usually two of three reviewers agree on a real weakness — fix that, and resubmit. The students who succeed are not the ones who never get rejected; they are the ones who get through the loop faster.

The one thing that changes everything

A supervisor who reads your drafts closely and tells you what is wrong with them.

Not someone who meets you monthly and asks how it is going. Someone who reads the actual text, marks up the actual figures, and says “this claim is not supported by this table.” Most undergraduates have never had that, and it is the difference between a project and a paper.


Our research mentorship is built around that weekly loop — problem formulation, experiments, drafts read line by line, and honest guidance on where to submit.

AI-Shala Team

Research & Engineering

Written collectively by the people who build and teach here — engineers, researchers and mentors who spend their week with the problems these posts describe.

researchpublishingmachine learningPhD applications

Keep reading

400 APPLICATIONS certificates, mostly THE ONE THAT GETS READ /sim-to-real-arm it runs, and there is a video eleven months of evenings
Careers
9 min read

AI and robotics internships in India — how to actually get one

What research and deeptech teams look for in intern applications, why most get rejected in thirty seconds, and what to build instead of another certificate.

AI-Shala Team Read
IN SIMULATION true state · clean torque · fixed timestep THE GAP ON HARDWARE sensor noise · latency · loop jitter
Robotics Pillar guide
10 min read

Sim-to-real transfer — why your policy fails on hardware

A policy that is perfect in simulation and useless in the lab is not a bug in your training. It is a specific, diagnosable gap. Here is how to find and close it.

AI-Shala Team Read
32 WEEKS WHERE THE MARKS ARE Algorithms DBMS OS Networks Digital Compilers MOCK SCORES every Sunday
GATE Prep Pillar guide
12 min read

GATE CS preparation — the complete strategy

A realistic plan for GATE Computer Science, built around weightage, timed practice and error journals rather than finishing more lectures.

AI-Shala Team Read

Reading is the easy part. Doing it with someone is better.

Our programmes exist because attention, not information, is what actually changes an outcome.