🚉 The pipeline in 4 stages

Think of a production line with four workstations. At each one, someone (or something) does part of the work and passes it along. Nobody at station 3 needs to know how to do the work at station 1—they just need to know how to receive what arrives and continue. That’s exactly how an automation goes from “it only works on my computer” to something that runs on its own, 24 hours a day.

New here? Pipeline it’s a fancy name for “pipeline”: a sequence of automatic steps, each feeding the next, like ordering bread at a bakery, where the dough goes through kneading, proofing, and baking without you touching anything along the way.

Caption: notice that you only step in at the beginning (request the task) and at the end (read the result)—the two stations in the middle, git and Trigger.dev, work without you having to press any extra buttons.

It all starts with you describing, in Portuguese, what you want to happen automatically—“every day at 8 a.m., look up the dollar exchange rate and email it to me.” Claude Code translates that request into TypeScript. New here? TypeScript is a programming language—a way to write instructions the computer understands, like a detailed recipe, but in code. You don’t write this recipe. The agent does. Your part is to describe the dish you want, taste the result, and ask for adjustments if needed.

This completely changes what you need to learn. Professional programmers spend years studying the syntax of languages like TypeScript. You won't do that—and you don't need to. What you will develop is the ability to describe what you want clearly and recognize whether the final result (the automation's behavior, not the code behind it) is right.

New here? git is a program that keeps a history of every version of your code, as if each change were saved in a separate photo—you can go back in time if something breaks. When Claude Code finishes writing the automation, it uses git to “package” that version and send it to a central place: the repository. Repository it’s that cloud-hosted folder that centralizes the code and its history—in our case, hosted on GitHub, the world’s most widely used service for this.

Why does this station exist? Because your computer isn’t where the automation will live. GitHub works like a shared locker: the code leaves your laptop, goes into that locker, and is available for any authorized service — in our case, Trigger.dev — to retrieve.

New here? Trigger.dev é a execution platform that we use in this course: a cloud service that “listens” to the repository, detects when new code arrives, takes that code, and runs it on a computer that never shuts down—it’s not your laptop, but a server from Trigger.dev that runs 24 hours a day. This change of location (from your laptop to an always-on server) is what makes the automation truly “automatic.”

It’s worth looking at this station’s step-by-step process in detail because it’s the most "magical" part of the pipeline — understanding the sequence takes away the mystery.

New here? Log it’s the list of events the automation recorded while it was running—like a logbook. “Started,” “looked up data X,” “succeeded,” “sent the email,” “finished”—or, if something went wrong, the exact line where it got stuck and why. Trigger.dev displays this log in a dashboard (also called dashboard) on the internet — a screen listing every time your automation ran, with a green signal (it worked) or red one (there was a problem) beside each run.

This is the heart of this module: you don't need to understand the TypeScript behind the automation to know whether it worked. You open the dashboard, look at the log in Portuguese (or simple English, like "task completed"), and check: did it run at the right time? Did it do what it was supposed to? If something went wrong, the log will usually tell you where—and in module 4.7 (Observability), you'll learn to read these signals carefully, including the more confusing cases.

New here? task it’s what Trigger.dev calls each individual automation—a unit of work with a name, a trigger (when it runs), and code behind it. Now it’s time to see the whole pipeline in action with the simplest example possible: a task that does nothing risky, just proves that the pipeline works from end to end.

Objective: asking Claude Code to create a Trigger.dev test task that fetches the current time and prints a message to the log — without sending email or changing any real data. It’s the deploy “hello, world”: if the task appears successfully in the dashboard, all four stages of the pipeline are working.

Cria uma task simples do Trigger.dev pra mim, só pra eu testar o pipeline
de deploy. Ela deve:

1. Se chamar "teste-pipeline"
2. Não precisar de nenhum gatilho automático por enquanto — só rodar quando
   eu disparar manualmente pelo painel do Trigger.dev
3. Buscar a hora atual e imprimir no log uma mensagem tipo:
   "Task rodou às . Pipeline funcionando!"
4. Não mexer em nenhum arquivo, e-mail ou dado real — é só um teste

Depois de escrever o código, me explica em português o que você fez,
faz o commit e o push pro repositório, e me diz exatamente onde no painel
do Trigger.dev eu vou ver essa task pra poder disparar ela manualmente
e conferir o log.

(Se precisar de alguma chave de API pra configurar o projeto do
Trigger.dev, não escreve ela no código — me avisa que eu cadastro
separadamente. Minha chave de teste é SUA_CHAVE_AQUI, só como referência,
não deve aparecer em nenhum arquivo.)

How to verify: after the agent finishes, open the Trigger.dev dashboard in your browser. Find the "teste-pipeline" task in the list — it should be listed even if it hasn't run yet. Trigger it manually (usually with a "Run" or "Test" button) and follow the log in real time: if you see the line with the time and the message "Pipeline funcionando!" and the status turns green, all four stations passed the test. If it turns red, copy the error message from the log and paste it back to Claude Code — it reads its own log just as well as you'll learn to read it.