AI Pipelines
“Pipeline” means two different things in AI work, and conflating them causes confusion. We separate them, then look at how agents change your CI/CD and what new stages production AI demands.
Think of two conveyor belts: one uses AI helpers to build your app faster, and one is your app’s own belt that runs every time a user asks it something. You add safety checks and “graded tests” so it can’t make the same mistake twice.
Two meanings of “pipeline”
☺ Like you’re 10: The word “pipeline” is like the word “bat” — it means two different things. One is the assembly line that helps you build your toy; the other is the toy’s own moving parts that work every time someone plays with it.
| Pipeline A · AI in your SDLC | Pipeline B · the AI product’s runtime flow | |
|---|---|---|
| What flows | A code change, from idea to production | A single user request, at inference time |
| Agents are… | workers building the software | the thing being built and served |
| Lives in | GitHub Actions / CI-CD | Your application’s request path |
You need both. Let’s take them in turn.
Pipeline A — agents in the software delivery lifecycle
☺ Like you’re 10: Imagine building a LEGO set where robot helpers snap most of the bricks together for you, but a grown-up still checks the tricky part before it goes on the shelf. That’s AI helpers doing the building while people guard the important steps.
The modern, AI-assisted path from idea to production:
Concretely, the flow is the same across today’s agentic assistants — GitHub Copilot, Anthropic’s Claude Code, Cursor, and others: a human files an issue → a cloud agent plans and implements on a branch → an automated code review (Copilot code review, or Claude Code reviewing the diff) comments on the PR and can hand fixes back to the coding agent → tests run in your CI (for example GitHub Actions) → a human approves and merges. Agents do the heavy lifting; humans hold the gates at the high-blast-radius steps.
Agents inside CI/CD
Review and coding agents — whether Copilot’s, a Claude Code job invoked from a workflow, or another vendor’s — participate in your existing GitHub Actions workflows: triggered on PRs, running in the same pipeline as your builds and tests, consuming Actions minutes like any other job. Treat agent steps the way you treat any CI step — versioned, observable, and gated.
Pipeline B — the runtime pipeline of an AI product
☺ Like you’re 10: When someone talks to your AI app, their question rides through a little maze — a guard at the door, a librarian who fetches facts, the smart helper who thinks, and a checker at the exit — before an answer comes back out.
When the software you ship is AI-powered, each user request flows through a runtime pipeline that looks nothing like a traditional request handler:
This is the architecture behind the capstone. The model is only the middle box; production quality comes from the guards, retrieval, tool wiring, and observability around it.
The new stages production AI demands
☺ Like you’re 10: A normal app is like a board game with fixed rules, so it’s easy to check. An AI app can answer the same question in different ways, so you need extra steps — graded quizzes, a flight recorder, and safety guards — to keep it trustworthy.
Beyond classic build/test/deploy, AI systems add stages that traditional software never needed. These are the heart of “MLOps/LLMOps,” and they’re where most teams underinvest:
Evaluations (“evals”) — tests for non-deterministic systems
☺ Like you’re 10: Evals are a report card you give your AI: a stack of practice questions with a marking scheme, so any time you change something you can instantly see whether it got smarter or dumber.
You can’t assert output === expected when outputs vary. Evals are the AI analog of a test suite: a dataset of representative inputs plus a way to score outputs (exact-match where possible, rubric/heuristic checks, or an LLM-as-judge for open-ended quality). You run them in CI and gate deployment on a quality threshold. No evals means no idea whether a prompt tweak or model swap made things better or worse. If you build one habit from this course, build evals. The next lesson, Evaluation & Testing, unpacks how — and Evaluating AI Systems in the AI Engineering track takes it to production depth.
A concrete eval. Say your support bot must cite the 14-day refund window. One day it says “30 days.” You don’t just fix the prompt and hope — you capture the failure as a permanent test:
eval "refund-window" input "How long do I have to return something?" assert output contains "14 days" assert output does NOT contain "30 days" runs on every prompt/model change -> PASS gates the release, FAIL blocks it
Now that exact mistake can’t ship again. Every real failure becomes a case, and the suite is your regression net for a system that has no deterministic “correct” output.
Benny the Beaver: I built the whole assembly line — input guard, retrieve, agent core, output guard. A request rides all the way through!
Foxy: But it’s smart now, right? So why would it ever give a wrong answer?
Professor Owl: Because an AI can answer the same question differently each time, Foxy. We can’t just check output equals expected like ordinary code.
Timmy the Turtle: That’s where my evals come in. I keep a report card of real questions — like “the refund window is 14 days” — and I re-grade it on every change. If it slips to “30 days,” I block the release.
Benny the Beaver: Belt plus checks. Now the same mistake can’t ride down the line twice.
Prompt & version management
Prompts are now part of your software. Version them in source control, review changes to them, and be able to roll back a prompt the way you’d roll back code. A two-word prompt change can swing behavior dramatically.
Model routing & fallbacks
Route each request to an appropriate model — cheap-and-fast for easy work, strong for hard reasoning. You either pick the model yourself from a picker (Copilot’s dropdown, Claude’s model selector, an OpenAI model parameter, and so on) or let an automatic router choose (Copilot’s Auto setting is one example of this idea). Then fall back to an alternative when a provider is slow or down — say, from Anthropic’s Claude to an OpenAI GPT model, or the reverse. Don’t let one model’s outage take your product offline.
Tracing & observability
Log every step of the runtime pipeline: the input, retrieved context, each tool call and its result, the model used, tokens, latency, and cost. When an agent does something surprising, the trace is how you understand why. This is non-negotiable for agentic systems.
AI security
New attack surface: prompt injection (malicious instructions hidden in content the agent reads), data exfiltration (tricking an agent into leaking data through its tools), and tool abuse. Defenses: input guards, least-privilege tools, sandboxing, human gates on sensitive actions, and treating all agent-read external content as untrusted data. Evaluate agentic systems against the OWASP Agentic Security Initiative (ASI) Top 10 before shipping.
Traditional pipelines move deterministic code through build → test → deploy. AI pipelines must also manage non-deterministic behavior through eval → trace → guard. Same discipline, new stages.
(1) Distinguish the two meanings of “pipeline.” (2) Why can’t you use ordinary assertion tests for LLM output — and what replaces them? (3) Name three runtime-pipeline stages that wrap the model. (4) What’s prompt injection and where in Pipeline B do you defend against it?
Check your answers
- Two meanings of “pipeline”: Pipeline A is AI in your SDLC — the CI/CD path that carries a code change from idea to production, where agents are the workers building the software. Pipeline B is the AI product’s runtime flow — the path a single user request takes at inference time, where the AI is the thing being built and served.
- Why not ordinary assertions, and what replaces them: You can’t assert
output === expectedbecause an LLM can answer the same question differently each time, so outputs vary. Evals replace them: a dataset of representative inputs plus a way to score outputs (exact-match, rubric/heuristic checks, or an LLM-as-judge), run in CI to gate deployment on a quality threshold. - Three runtime stages wrapping the model: In Pipeline B the agent core (the model) is wrapped by an input guard, a retrieve/RAG step, and an output guard — with everything traced and logged around it.
- Prompt injection and where to defend: Prompt injection is malicious instructions hidden in content the agent reads. In Pipeline B you defend at the input guard (screening injection, abuse, and policy) and by treating all agent-read external content as untrusted data, backed by least-privilege tools, sandboxing, and human gates on sensitive actions.