DEV Community: Srejon Khan

Rapid Pass to Agentic AI Engineering: A Quick-Learning Guide

Srejon Khan — Tue, 07 Jul 2026 10:35:28 +0000

This guide is designed to help you prepare for my cordial juniors (kolijar tukras), but can be used as a guide to Agentic AI Engineering or Hackathon Preparation, as quickly as possible. Instead of simple chatbot interfaces, you will be building autonomous agents capable of tool use, external data retrieval (RAG), and complex orchestration. Use this roadmap to master the core technical pillars like Foundations, Orchestration, Tool-Calling, and RAG to ensure your project reaches a functional, demo-ready state.

To do well, focus on these areas:

Foundations: Understand LLMs, Prompt Engineering, Context Engineering, Harness Engineering, Loop Engineering.
Orchestration: Pick one framework (like the OpenAI Agents SDK) and stick with it. Don't waste time switching tools during the event.
Tool-Calling: Practice getting your AI to use functions or external tools. This is the core skill for building agents.
RAG (Data Retrieval): Learn how to connect your AI to your own data sources so it knows more than just what it was trained on.
Final Demo: Prioritize building a working project that goes from start to finish. Focus on a clear result that solves a specific user need.

Use this roadmap to guide your practice, focusing on reliability and showing a clean, functional demo.

Foundations:

To understand how LLMs work, watch those videos:

Deep Dive into LLMs like ChatGPT by Andrej Karpathy (we call him the father of LLMs): https://www.youtube.com/watch?v=7xTGNNLPyMI
To have more understanding, what “What Makes ChatGPT Chat? Modern AI for the layperson”: https://www.youtube.com/watch?v=KvTGUI4Tznw

Don't skip this even though it's "just reading":

Anthropic, "Building Effective Agents": https://www.anthropic.com/research/building-effective-agents
Reference implementations of every pattern in that essay: https://github.com/anthropics/anthropic-cookbook/tree/main/patterns/agents

Then pick your orchestration stack and commit. Don't find frameworks mid-hackathon, been there, and it will waste many hours. Given the sponsor is OpenAI Codex, default to the OpenAI Agents SDK unless you have a strong reason not to.

Official quickstart (do this hands-on, not just read): https://openai.github.io/openai-agents-python/quickstart/
A tighter production-flavored walkthrough with 13 runnable steps (tool calls, handoffs, guardrails, FastAPI deployment), useful because it's closer to demo-ready than the bare docs: https://tech-insider.org/openai-agents-sdk-tutorial-python-13-steps-2026/
Beginner-friendly repo with runnable scripts if you want to understand line by line: https://github.com/shahidali54/OpenAI-Agents-SDK

Tool-calling:

The problems you'll get almost certainly hinge on tool-use loops. Drill this until you can write a function-tool + agent loop cold.

The same OpenAI quickstart above covers @function\tool. Redo it with 3 different fake tools (a calculator, a mock API call, a file lookup) until the pattern is muscle memory, not something you're referencing docs for. This is context engineering too.

RAG (Retrieval-Augmented Generation):

Since we don't have time for a multi-week RAG course. Pick one dense, hands-on option and actually build the pipeline, not just watch it.

freeCodeCamp's RAG + MCP crash course
- https://www.freecodecamp.org/news/learn-rag-and-mcp-fundamentals/
- It walks through embeddings, chunking, and vector DBs (Chroma) end to end with hands-on labs, and closes with MCP, which matters since the problem statements may expect tool/data integration via MCP:
If you want a faster, narrower cut (2 hours, LangChain-based, project-oriented):
- Krish Naik's RAG crash course https://www.youtube.com/watch?v=o126p1QN_RI
- code repo: https://github.com/krishnaik06/RAG-Tutorials

Multi-agent / Orchestration Pattern:

LangGraph playlist, hands-on multi-step/multi-agent workflows: https://www.youtube.com/playlist?list=PLKnIA16_RmvYsvB8qkUQuJmJNuiCUJFPL
Or stay inside the OpenAI SDK and just use its native handoffs feature (simpler, one less framework to context-switch into under pressure).

Full Mock Run:

Invent a fake problem statement, set a 4-hour timer, and build start to finish:

repo init –> agent logic –> tool/RAG integration –> working demo –> README.

This is the single highest-value thing on this list. Debrief immediately after whatever step ate the most unplanned time is what you drill again before preli.

Supplementary:

Prompt engineering reference (skim, don't study):
- https://www.promptingguide.ai/
- https://github.com/dair-ai/Prompt-Engineering-Guide

The Honest Advice Nobody Gives You in University

Srejon Khan — Sat, 14 Mar 2026 21:17:42 +0000

This is a 4 minute read. But if even one thing here clicks, it will change how you study for the next few years.

If you are in your 1st or 2nd year

Learn to solve problems. That is the whole job right now.

Not Codeforces rating. Not becoming a competitive programmer. The point of CP is to make you smart enough to think through hard problems without freezing up. It trains your brain to break things down, spot patterns, and write correct code under pressure. That skill is exactly what companies test you on in technical rounds, and it is exactly what separates people who can think from people who can only copy.

Learn the fundamentals for real. Data structures and algorithms are not things you memorize for exams and forget. They are the vocabulary you will use for the rest of your career. If you do not understand why a hash map is O(1) or what a binary search tree actually does, you are building on sand.

Do not chase ranks. Solve problems because they make you better. Go deep, not fast.

If you are in your 3rd or 4th year

Shift your focus to Software Engineering. Real SWE. The kind that makes you different in a room full of people who also know how to code.

There is a version of a developer who knows MongoDB exists, and there is a version who knows when to use a primary-secondary-secondary (p-s-s) replica set, what happens when the primary goes down, how reads and writes behave under that configuration, and what the tradeoffs are. The first person follows instructions. The second person designs systems. You want to be the second person.

Learn High Level Design. System design is not magic, it is just thinking about problems at scale. How do you make a system fault tolerant? What happens when a node dies? How do you handle 10x traffic overnight? How does your architecture behave when one service is slow? These are the questions senior engineers ask in interviews, and more importantly, they are the questions that come up every week at a real job.

Learn Low Level Design too. This is where Software Engineering Principles live. SOLID, clean code, design patterns, not because you need to memorize factory or observer for an interview, but because building something complex and feeling it break teaches you why the patterns exist. Do not learn patterns first. Build something, feel the pain, then the pattern will make sense.

If you graduated and skipped the Problem Solving phase

It is not too late. Seriously.

Make it a ritual. One LeetCode problem every morning after breakfast. Not a hard one at first. Just one. Every day. It compounds faster than you think, and it keeps your logical muscles active while you are job hunting or starting your first role. The people who do this for six months straight show up to interviews completely different from the people who crammed for two weeks.

A few things I also want you to think about

Build something real. Not a tutorial project, not a YouTube follow along. Pick a problem you actually have or one you find interesting, and build a solution for it. You will hit problems no tutorial prepared you for, and figuring those out is where the real learning happens. Recruiters can tell the difference between someone who built something and someone who cloned a repo.

Read codebases. Good engineers read a lot of code that other people wrote. Pick an open source project related to something you care about and just read through it. How is it structured? Why did they make that decision? What would you have done differently? This builds taste. Taste matters.

The job market is hard right now. You probably already know this. The way you survive it is not by learning ten frameworks, it is by going deep enough in one area that you genuinely understand it. A person who really understands distributed systems will outlast ten people who have "microservices" in their Resume but cannot explain what happens when two services write to the same database row at the same time.

Write and communicate clearly. This sounds boring but it is not. The ability to explain a technical decision in a way a non technical person can follow is rare, and it matters enormously once you are in a team. Practice it.

Finally, do not compare your timeline to someone else's. Someone in your batch got a job at a good company. Good for them. Someone else is still figuring it out. That is fine too. The engineers I have seen grow the fastest are the ones who stay curious and stay consistent, not the ones who had the best start.

You have more time than you feel like you do. Use it well.

Feel free to share this around. And if you want to talk through anything specific, you know where to find me.