Your first 30 days in AI engineering

What 30 days can and can't do

30 days won't make you a job-ready AI engineer, and anyone who promises that is selling something. What 30 days can do is build the habit of building every day, which is what most learners never get, because they stay in tutorials and never ship.

The goal of these 30 days is consistency. If your level goes up a little every day, even 1%, it adds up, and more importantly, you get used to the loop of picking a problem, building, breaking things, fixing them and sharing what happened. That loop is the actual skill, and the topics will keep changing around it.

By day 30, you should have:

• Around 30 builds on GitHub, most of them small.
• One project that combines several of them and is deployed with a link someone else can use.
• Notes and interview answers for everything you built, in your own words.
• A few public posts about what you built and what broke.
• A list of what you want to learn next, based on what you struggled with.

Who this plan is for

This plan assumes you can already write basic programs in some language. It is for beginners in AI engineering, not for absolute beginners in programming. If you have never written code, spend 2 to 4 weeks on Python basics first, using Python for AI engineers, and then start day 1.

If you are already a backend developer, you will move through week 1 quickly, so use the extra time to go deeper into evaluation and deployment.

Before day 1: setup

Take 2 or 3 days before day 1 to set up your environment, because nothing kills momentum like fighting your setup in the middle of a build.

1. Install Python and learn to create a virtual environment for each project.
2. Install VS Code as your editor. If you prefer notebooks while learning, Anaconda gives you Jupyter Notebook and other tools in one installer, but move to proper project folders as soon as you can.
3. Learn the basic terminal commands: moving between folders, creating files, running scripts and installing packages.
4. Create a GitHub account and learn the Git basics: init, add, commit, push, and writing a README.
5. Get an API key for at least one model provider. Several providers, like Google's Gemini API, have free tiers that are enough for these 30 days.
6. Learn to keep API keys in environment variables or a .env file that never gets committed to GitHub.
7. Optionally, install a coding assistant like Claude Code or Cursor, and decide now that you will use it only for parts you already understand.

Create your GitHub account on day 0, not on day 30, because everything you build from now on goes there. Your GitHub profile becomes the place where recruiters and clients see your work, and I have received many offers through mine.

How much time to give each day

Plan for 1 to 4 hours a day, depending on your job and your other commitments. If you work full time, 1 to 2 focused hours a day is enough, and it works much better than trying to do 10 hours on a Saturday.

In the 75 day challenge, I shared a simple deep work system that you can copy:

• Fix your hours before the day starts, and protect them.
• Put your phone away and turn off notifications during those hours.
• Decide 3 to 4 commitments for the day, and make sure they are small enough to finish.
• If you have a job, reduce the hours, not the consistency.

What every day looks like

Every day has the same shape, so you don't waste energy deciding what to do.

1. Build: one small build, with a clear problem statement. This takes most of your time.
2. Commit: push it to GitHub with a short README that says what it does, how to run it and what broke.
3. Interview questions: write answers to 2 or 3 questions about what you built, like "Why did you track tokens?" or "What happens when the API times out?"
4. One technical problem: a small coding problem related to the build.
5. One concept: a short read on a system design topic or an AI data structure related to the day.
6. Share: a short post or a message in your community about what you built or what failed.

Once a week, read one research paper related to that week's builds. Start with Attention Is All You Need, the original RAG paper by Lewis and others, and ReAct by Yao and others. If you want one book alongside these 30 days, read AI Engineering by Chip Huyen.

Week 1: calling LLMs properly (days 1 to 7)

This week, you learn what happens when you send text to a model and get text back, and you build the small utilities you will reuse in every later project.

• Day 1: make your first LLM API call from a Python script, and build a token tracker that logs input tokens, output tokens and estimated cost for every call to a file.
• Day 2: add a conversation loop that keeps the message history, then watch the token count grow with every message and understand why long chats cost more.
• Day 3: build a simple tokenizer from scratch that splits text, builds a vocabulary and converts text to IDs and back, then compare it with a real tokenizer on the same sentences.
• Day 4: run the same prompt at different temperatures 10 times each, save the outputs and describe what changes.
• Day 5: handle failures: timeouts, retries with backoff, rate limit errors and a fallback to a second model.
• Day 6: stream responses token by token, and measure time to first token and total time.
• Day 7: combine days 1 to 6 into one small reusable LLM client module with a README, and write your first post about the week.

Why the token tracker on day 1? Free tiers have limits, and paid APIs charge by the token, so your cost will depend completely on how many tokens you use. If you track tokens from the first call, you build the habit of designing for cost, which is one of the first things a company will ask you about.

Week 2: prompts and structured output (days 8 to 14)

This week, you learn to get reliable, usable output from a model instead of nice-looking text.

• Day 8: write a system prompt for one narrow task and test it on 10 different inputs, including bad ones.
• Day 9: get the model to return JSON, and validate it with Pydantic so your code can trust the structure.
• Day 10: build an extractor that turns messy text, like emails, invoices or job posts, into structured records.
• Day 11: add few-shot examples, and compare the results with and without them on the same inputs.
• Day 12: build a tiny prompt test runner that runs all your test inputs and reports which ones pass.
• Day 13: version your prompts in files, change one, run the tests and see what improved and what broke.
• Day 14: turn the week into one tool, for example a job post analyser that returns a structured summary, with tests and a README, and write about one case that failed.

Week 3: embeddings, a vector store and RAG (days 15 to 22)

This week, you learn how to give a model information it was never trained on, which is the most common pattern in company AI work.

• Day 15: generate embeddings for 20 sentences and print which ones are most similar to each other.
• Day 16: build a vector store from scratch in plain Python, with your own dot product, magnitude and cosine similarity functions. The math page walks through the code.
• Day 17: parse a real document, like a PDF policy or a product manual, and split it into chunks. Try two chunk sizes and look at what each chunk contains.
• Day 18: store the chunks in a real vector database and query it.
• Day 19: build the full RAG loop: retrieve the top chunks, put them in the prompt and answer with a citation to the source chunk.
• Day 20: write 15 questions with known answers and check how often the right chunk is retrieved.
• Day 21: find one question where the system failed, work out whether retrieval or generation caused it, fix it and run the 15 questions again.
• Day 22: clean up the RAG project with a README that explains your chunking and retrieval choices and what still fails.

Week 4: tools, a small agent and deployment (days 23 to 30)

This week, you move from answering to doing, and you put something online.

• Day 23: write a Python function as a tool, and let the model decide when to call it.
• Day 24: build a small agent loop with 2 or 3 tools and a maximum number of steps, and log every tool call.
• Day 25: make one tool fail on purpose and design what the agent should do, retry, use another tool or stop and say what went wrong.
• Day 26: before going further, ask whether the agent's task could be done by a plain script. Write down your answer and your reason in the README.
• Day 27: put your RAG system or your agent behind an API with FastAPI.
• Day 28: package it with Docker and deploy it, so it has a URL someone else can call.
• Day 29: run your test questions against the deployed version and record latency and cost per request.
• Day 30: write a project README with the problem, the architecture, what broke and how you fixed it, and the link, then publish a post about your 30 days.

How to know your 30 days worked

At the end, go through this checklist honestly.

• Can someone clone at least one of your repos and run it from the README alone?
• Do you have one project with a live link?
• Can you explain, without notes, how your RAG system decides which chunks to use?
• Can you explain what happens in your agent when a tool fails?
• Do you know what one request to your deployed system costs?
• Can you name the 3 things you struggled with most?

If you can answer yes to most of these, you are ready for the next stages of the roadmap. If not, take the weakest part and build it again with a different problem. Building the same component twice, on a different problem, is how most of the learning sticks.

Building in public during your 30 days

Two things decide whether your 30 days turn into opportunities: your GitHub profile and what you write about your work.

On GitHub, commit every day, and write READMEs a stranger can follow. A clean repo with a working link and a clear explanation tells them more than any certificate.

On LinkedIn, or wherever your audience is, write short posts about what you built, including what failed. Be honest about failures, because the posts about what went wrong are the ones that teach other people and show how you think. Write your own opinion and your own experience, and use AI only to help with formatting, because a post that sounds generated doesn't build trust. Your first posts will not be good, and that is fine. If you want a place for longer articles, Substack is free to start.

Why does this matter? Because companies don't only hire from job applications. Sometimes they find you through what you share, follow your work for a while, and reach out when they have a problem you have already shown you can solve.

Common ways people fall off, and how to get back

You will miss a day. When that happens, don't try to do two days in one, just do today's build and keep going, because one missed day doesn't break the habit, but trying to catch up often does.

You will get stuck in tutorials. If you have watched more than one video on the same topic without building anything, stop and build the smallest possible version of the thing with what you know.

You will want to build something big. Keep each daily build small enough to finish in your time, and save the bigger ideas for weekends or for after the 30 days.

You will compare yourself with others. Compare your day 20 with your day 1, not with someone else's highlight reel.

After your first 30 days

After 30 days, you have the foundations and the habit. The next step is to go deeper into one area at a time, following the roadmap: evaluation, deployment and agents usually come next, and system design after that. This is a good point to plan your next 6 months, with one bigger project at the centre and the topics it needs around it, using the PILOT method.

If you want to do your 30 days with other people, Build30 on buildership.io follows this same daily shape with a problem statement every day, a build manual, interview questions and a daily support call. And if you want to go further with a team, AI Engineer HQ on masterdexter.io is where engineers take bigger systems from the problem statement to deployment.

From the floor

When I ran the 75 day AI engineering challenge, I set up a Discord community with daily challenges, accountability partners and standups, and a Notion dashboard with an archive of 75 problems, a leaderboard and daily logs. For the problems, I shared only the answers, not the solutions, so people had to solve them on their own and discuss their approaches in the community.

On day 1 of that challenge, I asked everyone to do two things: start with Python, and create a GitHub account. GitHub was on day 1 because everything we built afterwards went there, so anyone could share their work with recruiters or with anyone in the world.

A couple of years ago, a company in the energy sector read my articles and posts, joined my workshops and community groups, and followed my work for about 6 months before reaching out. They told me they were working on a problem and I was the right person to work on it.

My own first LinkedIn post was very bad. I kept posting anyway, and that is the only reason the later ones got better.

Related

• AI engineer roadmap 2027
• How to learn AI engineering by building
• Python for AI engineers
• AI engineer portfolio

Sources

• Attention Is All You Need, Vaswani and others (2017)
• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, Lewis and others (2020)
• ReAct: Synergizing Reasoning and Acting in Language Models, Yao and others (2022)
• AI Engineering by Chip Huyen, O'Reilly