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.
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:
- Read enough to know what is already done
- Find a gap you can actually close in your available months
- Write the abstract first
- Run the experiments that abstract promises
- Write the paper
- 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:
- Method — write it while it is fresh
- Experiments — what you ran and what happened
- Related work — position yourself against the literature
- Introduction — last, because only now do you know what the paper says
- Abstract — revise the one you wrote at the start, honestly
- 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.