In just a few years, generative artificial intelligence has gone from a research topic to an everyday tool for development teams. Code autocompletion, chatbots that hold coherent conversations, automatic documentation generation... all of it rests on the same family of technologies. In this first lesson we lay the foundations of the course: you'll understand what sets generative AI apart from classic machine learning, how we got to large language models (LLMs), what kinds of content they can generate and, above all, what real use cases they offer you as a developer. We'll also introduce the running thread that will accompany us throughout the course: DocuBot, the internal documentation assistant we'll build step by step for a fictional company called Nubelia.

1. Generative AI vs. discriminative AI: two ways to use machine learning
2. A brief history: from classic ML to LLMs
3. What generative AI generates: text, code, images and more
4. Real use cases for developers
5. Our course case study: Nubelia and the need for DocuBot
6. What an LLM can and can't do (initial reasoning)

For most of the history of applied machine learning, the models we ran in production were discriminative (also called predictive or classification models). Their job is to take an input and assign it a label, a score or a category from a closed set of possibilities.

Some classic examples:

• A spam filter: receives an email and answers spam or not spam.
• A scoring model: receives the data from an application and returns a probability.
• An image classifier: receives a photo and answers cat, dog or bird.

Generative AI, on the other hand, doesn't choose among predefined options: it produces new content that didn't exist verbatim in its training data. It generates text, code, images or audio, and the space of possible outputs is practically infinite.

The difference comes across very clearly in a table:

One important nuance: these are not rival technologies — they're complementary. In fact, many modern systems combine both. A content-moderation pipeline might use a generative model to draft a reply and a discriminative one to verify that the reply contains no inappropriate language before showing it.

As a developer, the most relevant practical consequence is this: with classic ML you trained (or commissioned) a specific model for each task; with generative AI, a single general-purpose model can perform hundreds of different tasks simply by describing them in natural language. That radically changes how AI gets integrated into software, and it's the reason this course exists.

You don't need to know the full history of AI to use an LLM, but understanding the main milestones will help you place the technology and understand why it works the way it does.

• 1950s–1990s — Rule-based systems and early statistical ML. The first chatbots (like ELIZA, in the 1960s) ran on hand-written rules: they detected patterns in the text and replied with templates. They didn't "understand" anything, and it showed as soon as the conversation went off script.
• 1990–2010 — Statistical machine learning. Models learn from data instead of manual rules: support vector machines, decision trees, n-gram models for language. Natural language processing (NLP) advances, but each task (translating, summarizing, classifying) requires its own model and its own labeled dataset.
• 2010–2017 — Deep learning and recurrent networks. Deep neural networks revolutionize computer vision first and language afterwards. Recurrent networks (RNNs, LSTMs) process text sequentially, word by word, but they struggle with long texts and are slow to train because they don't parallelize well.
• 2017 — The transformer. The paper "Attention Is All You Need" introduces the transformer architecture, which replaces recurrence with a mechanism called attention. This makes it possible to process all the words of a text in parallel and capture relationships between distant words. It is the key technical milestone that makes today's LLMs possible. (How it works inside is the subject of the next lesson, 01-02; for now, keep in mind that it's the architecture on which almost everything that follows is built.)
• 2018–2022 — Scaling and large language models. It turns out that when you train ever-larger transformers on ever-more text, they don't just improve gradually: emergent capabilities appear, such as following instructions, translating without being specifically trained for it, or writing code. LLMs (Large Language Models) are born.
• 2022 onwards — Generative AI reaches the general public and the enterprise. Conversational LLMs demonstrate that a general-purpose model can be useful for real tasks, and providers publish APIs that let you integrate them into any application. This is the moment generative AI stops being a laboratory topic and becomes one more piece of software architecture, like a database or a message queue.

This last point is what interests us in this course: the LLM as a component of your applications, accessible through an API, with its capabilities, its limitations and its integration patterns.

Under the "generative AI" umbrella live models that generate different kinds of content (what we call different modalities):

This course focuses on text and code, for two reasons:

1. They're the modalities where LLMs are most mature and where the most integration experience in real applications exists.
2. They're the ones a backend, frontend or full-stack developer will integrate most often: chatbots, assistants, document processing, automation.

One detail that surprises a lot of people: to an LLM, code is text. The same model that drafts an email can write a Python function, because during training it saw enormous amounts of both. There's no separate "code module"; there's one language model that has learned the patterns of natural language and of programming languages.

Let's look at where generative AI is delivering value in real development teams. This isn't an exhaustive list, but it covers the main categories.

This is probably the use case you already know: tools built into the editor that autocomplete code, explain snippets, propose refactorings or generate tests. Here you are the user of generative AI.

Applications that answer questions from users or employees in natural language: customer support, internal assistants, smart FAQs. Here you are the builder: you integrate an LLM into your application. This is the central use case of this course.

Generating documentation from code, summarizing long documents, maintaining changelogs, writing endpoint descriptions from an OpenAPI specification.

Extracting structured data from emails, tickets or PDFs; classifying incidents; normalizing free text into a processable format (for example, JSON). It's an unglamorous category but enormously profitable: it turns problems that used to require brittle regular expressions or manual work into a single model call.

Chaining the LLM with other tools: reading a ticket, looking up relevant information, drafting a proposed reply and leaving it ready for human review. In its most advanced form, this leads to agents (we'll cover them in module 5).

Notice a pattern that repeats across the "builder" cases: the LLM doesn't replace your application; it becomes one more component that receives text and returns text, orchestrated by your code.

So the course doesn't stay theoretical, everything you learn will be applied to a concrete case we'll build module by module.

Nubelia is a fictional SaaS company that offers a project-management platform: boards, tasks, reports, integrations with other tools and a public API for its customers. Like any software company with a few years behind it, Nubelia has accumulated a considerable amount of internal documentation:

• Technical documentation for its API and the platform architecture.
• Operations guides and deployment runbooks.
• Knowledge-base articles from the support team.
• Records of technical decisions and development-team conventions.

And that's exactly the problem: that documentation is scattered across a wiki, repositories and shared folders, and finding the right answer takes far too long. A new developer takes weeks to learn where to look. The support team escalates questions to engineering that were already answered in the wiki. Questions like "what's the rate limit of the public API?" or "how do you restart the reporting service?" get answered over and over again in chat.

The proposal we'll study and build throughout the course is DocuBot: an internal assistant that Nubelia's developers and support staff can ask questions in natural language, and that answers based on the company's internal documentation.

In this first module we won't write integration code yet (that arrives in module 3). But DocuBot is already useful for something very valuable: reasoning about what an LLM can and can't do, which is exactly what we'll do next.

Imagine that today, with no further infrastructure, we hooked a generic LLM up to an internal Nubelia chat and called it DocuBot. What would happen?

What it would do well from day one:

• Answer general programming questions ("how do I make an HTTP request in Python?").
• Explain technical concepts, draft and summarize text, translate.
• Hold a coherent conversation and adapt its tone.

What it would do badly or simply couldn't do:

• Answer "what's the rate limit of the Nubelia API?" — the model has never seen Nubelia's internal documentation, because Nubelia doesn't exist in its training data. And here's the worrying part: instead of saying "I don't know", it may well invent a plausible answer (a reasonable-sounding but false figure). This phenomenon is called a hallucination and we'll study it in depth in lesson 01-04.
• Know about recent changes: even if we fed it documentation during training, it would go stale.
• Take actions: check the real status of a service, open a ticket. An LLM, on its own, only generates text.

We can summarize this reasoning in pseudocode, which captures the central idea of the whole course:

The second source, request_context, is the one we control as developers, and it's the key to almost everything we'll do in this course: learning to give the model the right context (module 2, prompting), passing it from our application (module 3, integration) and automatically retrieving the relevant Nubelia documents for each question (module 4, RAG). With that, DocuBot will stop making things up and start answering with the real documentation in front of it.

• Confusing "the model seems to understand" with "the model knows". An LLM generates plausible text; a confident-sounding answer isn't necessarily a correct one. Get into the habit right now of asking yourself: where would the model have gotten this information? If the answer is "nowhere" (as with Nubelia's internal documentation), be suspicious.
• Thinking generative AI replaces classic ML. For classifying transactions or forecasting demand, a specific discriminative model is usually cheaper, faster and more reliable. Use generative AI when the task involves producing or transforming language or code.
• Believing you need to be an expert in math or deep learning. To integrate LLMs into applications you need to understand their behavior (tokens, context, limitations), not their internal calculus. It's analogous to using a database without ever having implemented a storage engine.
• Starting from the technology instead of the problem. "I want to put AI in my product" is a bad starting point. "Support loses hours searching the wiki" (Nubelia's problem) is a good one: define the problem, then evaluate whether an LLM is the right tool.
• Tip: throughout the course, keep a list of tasks from your real job that fit the five use-case categories. It will help you ground each module in your own context.

Classify each of these tasks as better suited to a generative approach, a discriminative one, or a combination of both, and briefly justify why:

1. Detecting whether a product review is positive or negative.
2. Writing a personalized reply to each product review.
3. Deciding whether a Nubelia support ticket is urgent and, if it is, drafting a first version of the reply.
4. Predicting how many users will connect to the Nubelia platform next Monday.

A colleague at Nubelia proposes launching DocuBot tomorrow by connecting the internal chat directly to a generic LLM, without giving it access to any documentation. Write a list of three real questions employees might ask it for which this "naive" DocuBot would give a bad result, indicating in each case what kind of failure you'd expect (invented answer, outdated knowledge, or inability to act).

Think about your own team or a project you've worked on. Identify one task that fits one of the five use-case categories from this lesson (coding assistant, chatbot, documentation, unstructured text, automation). Describe: the task, the category, what text the LLM would receive as input and what text it should produce as output.

Solution 1:

1. Discriminative. It's a classic binary classification (positive/negative); a specific model is cheaper and its performance is easy to measure. (An LLM can do it too, but that would be using a freight truck to deliver a postcard.)
2. Generative. The output is new, personalized text; there's no closed set of possible answers.
3. Combination. The urgency decision is a classification (discriminative, or an LLM classifying); the draft reply is generation. This is the hybrid pattern we mentioned: classify first, generate afterwards, with human review before sending.
4. Neither, in the generative sense: it's numeric prediction, the territory of classic ML (time series / regression). An LLM is not the right tool for predicting a figure from historical data.

Solution 2 (example of a valid answer; yours may vary):

1. "What's the per-minute rate limit of Nubelia's public API?" → Invented answer (hallucination): the model doesn't know Nubelia, but it can generate a plausible, false figure.
2. "What changed in the latest release of the platform?" → Outdated / nonexistent knowledge: even if the model knew something about Nubelia, it wouldn't know about changes made after its training.
3. "Restart the reporting service in the test environment." → Inability to act: an LLM only generates text; it can't execute actions on systems (connecting it to tools is covered in module 5).

Any question about internal or recent information, or one requiring an action to be executed, is a good answer to this exercise.

Solution 3 (example):

• Task: the team receives free-form emails from customers reporting bugs.
• Category: processing unstructured text.
• Input: the body of the customer's email.
• Output: a JSON object with fields like product, estimated_severity, summary and steps_to_reproduce, ready to create a ticket automatically.

What matters is that you clearly identified the input and the output as text: that's the basic contract of any LLM integration.

In this lesson we've marked out the playing field: generative AI creates new content (as opposed to classic ML, which classifies or predicts), it's the result of an evolution whose key milestone was the transformer architecture in 2017, and today it's accessible to any developer as one more component of their applications. We've covered the main use cases for developers and introduced the problem that will accompany us throughout the course: Nubelia's scattered documentation and the proposal to solve it with DocuBot. We've also done an honest first pass at reasoning about what an LLM can and can't do unaided: plenty of general knowledge, zero knowledge of your company, and a tendency to make things up when it doesn't know.

So far we've treated the LLM as a black box that receives text and returns text. In the next lesson, "How an LLM Works: Tokens, Embeddings and Attention", we'll open that box just as much as necessary: you'll understand what tokens are (and why they determine the limits and cost of each call), how embeddings capture the meaning of text, and what the famous attention mechanism actually does. Not a single equation will be needed, but you'll come out understanding why the model behaves the way it does.