AI Engineering Bootcamp

by Jean-Pierre Fakhry

Instructor

and Hassan Kanaan

Instructor

Four Weeks, Twelve Sessions, One Agent You Can Ship

Anyone can demo an LLM. Shipping one is a different job.

Twelve sessions over four weeks, and one thing to show at the end: an agent that answers questions and takes actions over your own documents and tools.

It's for developers who already ship code and now have an AI feature on their plate. No ML background, no math. The time goes on judgment: what you hand to the model, and what stays in your code.

Why This Is Different

It's an engineering course. The model is just a dependency.

•No math, no papers. There aren't many concepts, and you meet each one the session you need it.
•Knowing when not to build. Plenty of AI requests should be turned down, and you'll be able to say why.
•You finish with a service running on your own data, not a folder of notebooks.

Who Is This Bootcamp For?

New to AI, not new to code.

•You've never built an application around a model. That's the starting line, not a gap.
•Backend, full-stack, and platform engineers, at any level, as long as you're writing real code.
•Anyone handed an AI feature to deliver: search, triage, automation, document Q&A.
•Prerequisites: Python or another backend language, Git, HTTP APIs, and enough Docker to run a container.

No AI or ML background needed, and no math. If you can build and ship a small web service, you're ready for week one.

Demo To Production

The demo always works. That's the problem.

Getting an impressive answer out of a model takes an afternoon. The hard part comes later, when a tool call times out, the input looks nothing like your test cases, or the model returns something confident and wrong and nobody notices for a week.

That gap is the actual job. Structured output your code can rely on, tools narrow enough that the model gets them right, retrieval so answers come from your documents, an approval gate on anything that writes, and an off switch. Four weeks is enough to do it once, properly.

By The End

Six things you'll be able to do that you can't today.

•Get a fixed, parseable shape back from a model, and handle the run where you don't.
•Keep arithmetic, business rules, and lookups out of the model entirely.
•Tell whether a problem wants one prompt, a pipeline, or an agent. Usually it's not the agent.
•Write tools a model can use without getting confused.
•Add retrieval over your own documents without a six-month vector database project.
•Wire in an approval gate, and log what it costs and how long it takes.

The Project

One project, empty repo to live demo.

A support agent over your own documents and tools. Someone asks a question in plain language. It finds the relevant part of your document set, calls a tool to look up an order or an account, and stops to ask you before it writes or sends anything. When it doesn't know, it says so.

What You Walk Away With

What you keep after the last session.

•A working agent on your own data, with a human on the approval button.
•A clear head about workflows versus agents, and a bias toward the boring option.
•A repeatable way to split a problem into instructions, tools, and code the model never sees.
•The standing to argue for an AI feature, and the standing to argue against one.

FAQ

Questions people ask before signing up.

Do I need a machine learning background?▼

No, and there's no math. Each concept gets explained in plain English right before you use it.

What should I already know?▼

Python or another backend language, Git, HTTP APIs, and enough Docker to run a container.

Will we train models?▼

No. You build around models that already exist. Training is a different course, and for most teams a different job.

Does it matter which model or provider I use?▼

No. The patterns carry across the major APIs, so bring whatever access you already have.

Content

Four weeks, one project.

Week 1 — Foundations: how the model behaves▼

•Tokens, context windows, and why the same prompt hands you two different answers.
•What LLMs are reliably good at, what they'll fake, and what they can't do at all.
•Prompting as engineering: a clear role, the right context, and a response shape your code can parse.
•What not to send. Arithmetic, business rules, and lookups stay in your code.

Build this week: a classifier that turns a raw support message into category, urgency, and a summary your code can trust.

Week 2 — Workflows vs agents: picking the shape▼

•One prompt, a fixed pipeline, or a full agent. Most problems want the simplest that works.
•Why predictable workflows usually win: cheaper, debuggable, and they do the same thing twice.
•When you genuinely need an agent: open-ended tasks where you can't know the steps up front.
•Cutting a task into steps small enough that the model has one thing to think about.

Build this week: wrap the classifier in a triage workflow, then build it as an agent and see why the boring version is the default.

Week 3 — Instructions and tools: giving the model hands▼

•What belongs in the instructions, and what belongs in a tool.
•Tools a model can use well: clear names, narrow scope, predictable inputs and outputs.
•Retrieval over your own documents, treated as one more tool and kept simple.
•An approval gate before anything is written or sent, and letting the model say it doesn't know.
•Context engineering: what goes in front of the model each call, and what you leave out.

Build this week: add retrieval plus one real tool, such as an order or account lookup, with an approval gate before it acts.

Week 4 — Making it real: shipping something you trust▼

•When a tool fails, the model wanders off, or the input is nothing like you tested.
•Harness engineering: the loop that calls the model, feeds results back in, and retries.
•Simple checks you can run before and after every change, without a research lab.
•The numbers worth watching daily: cost, latency, and how often a person steps in.

Build this week: harden it with guardrails, before-and-after checks, cost logging, and an off switch. Then demo it live.