Generative AI made building easier than ever — but reliable AI in production still
runs on data pipelines. Why Airflow remains the orchestrator under modern AI,
and what I learned getting to committer along the way.
Why AirflowCore ConceptsAI Use CasesOpen Source Journey
GenAI made building easy. Production is still hard.
Why this talk
A demo takes a weekend. A reliable AI product takes a pipeline. Behind every successful
AI system is data being ingested, transformed, validated, and delivered — continuously.
bolt
Models are commodities
Swapping an LLM is now a config change. The differentiator has moved up the stack — to data.
science
Data is the moat
Freshness, quality, lineage, and evaluation pipelines are what make an AI system actually trustworthy in production.
satellite_alt
Someone runs the pipes
Every reliable AI product has an orchestrator quietly doing the boring, critical work behind the scenes.
Airflow · AI Era
2
Agenda
What we'll cover today
Three pillars
Why Airflow exists, what it actually is, and what I've learned by contributing to it.
01
Why Apache Airflow
From the Big Data era to the AI era — why orchestration is more important now than ever before.
02
What Airflow Is
Core concepts, who runs it in production, and the common use-cases driving its continued adoption.
03
Open Source
Lessons from going from zero to Apache Airflow committer — and the honest case for contributing.
Airflow · AI Era
3
Part One
Why Apache Airflow?
From the Big Data era to the AI era — the orchestration problem never went away. It grew.
Airflow · AI Era
4
The Big Data Era · ~2010
When data outgrew the laptop
Why
Hadoop, Hive, and Spark made petabyte-scale compute normal — and the operational
cost of running thousands of interdependent jobs collapsed cron and bash scripts.
Pipelines exploded in count. Single jobs became thousands of interdependent tasks across teams.
Cron couldn't express dependencies. "Run B only after A succeeded for that date" needed custom glue everywhere.
Failures were silent. A bad partition at 2am surfaced at 9am in a Monday standup.
Backfills were terrifying. Re-running a week of history meant praying you knew every downstream dependency.
Observability was a wiki page. "What ran? When? Did it succeed?" lived in tribal knowledge.
"What ran? When? Did it succeed? What does it depend on? How do I re-run just yesterday?" — every data engineer, 2014.
The orchestration gap was real, expensive, and unsolved. Airbnb felt it acutely.
Airflow · AI Era
5
The AI Era · Now
The orchestration problem didn't go away — it grew.
Why
Every AI capability you ship has a pipeline behind it. Inference is the tip of the iceberg;
everything underneath is a data workflow that has to be scheduled, validated, and observable.
menu_book
RAG needs fresh data
Documents must be continuously fetched, chunked, embedded, and indexed — or your retrieval answers go stale and wrong.
track_changes
Fine-tuning needs curated data
Labeled, deduplicated, versioned datasets — produced by a reproducible pipeline, not a one-off notebook on someone's laptop.
smart_toy
Agents need reliable tooling
Eval runs, tool execution, retries, human-in-the-loop checkpoints. All of this is a workflow — and workflows want an orchestrator.
bar_chart
Eval pipelines run forever
Prompt evals, regression suites, drift detection — scheduled, parallelised, tracked. The orchestration shape is identical to ML training.
Airflow · AI Era
6
Why Airflow, Specifically
Why teams keep choosing Airflow for AI workloads
The honest answer
Plenty of orchestrators exist. Airflow keeps winning the boring, important criteria —
the ones that matter once a workflow has to run every day for five years.
code
Python-native
The ML/AI stack already lives in Python. No new DSL, no language boundary between your training code and your orchestration code.
power
Massive integration surface
1,500+ operators and hooks across cloud, data warehouses, vector DBs, and LLM providers. The "does it integrate with X" question is usually yes.
engineering
Battle-tested at scale
Runs critical pipelines at Airbnb, Netflix, Tesla, Stripe, Shopify, and tens of thousands more. The hard edge cases are already discovered.
balance
Open governance
Vendor-neutral Apache Software Foundation project. No single company can take it away, rename it, or relicense it underneath you.
Airflow · AI Era
7
Open Governance · True Multi-Vendor
Not just open source — open governance
Why this matters
Plenty of orchestrators have an MIT-licensed repo. Almost all of them are controlled by
a single VC-backed company. Airflow is one of the few where no vendor can take it from you —
because no vendor owns it.
pip install apache-airflow · PyPI installs per month
30,000+ organizations running Airflow in production · 11 years in the open · Apache 2.0 license, forever.
Airflow · AI Era
10
In One Sentence
An open-source platform to author, schedule, and monitor workflows as code.
The mental model
Workflows are DAGs — Directed Acyclic Graphs of tasks, written in Python.
Airflow runs them on a schedule, on a trigger, or on demand — and gives you one place to see everything.
extension
DAG
A pipeline. A Python file that declares tasks and their dependencies — what runs, in what order, on what schedule.
settings
Task / Operator
One unit of work — run SQL, call an API, train a model, prompt an LLM. Operators wrap the integrations.
timer
Scheduler
Decides what runs and when, based on cron schedules, data-aware triggers, or external events.
directions_run
Executor / Workers
Actually runs the tasks — locally, on Celery, on Kubernetes, on the Edge worker, or your own runtime.
database
Metadata DB
Source of truth for runs, states, history, and lineage. Everything else is derived from it.
dashboard
UI & API
Inspect, debug, re-run, integrate. The single pane of glass for everything happening in your platform.
Airflow · AI Era
11
A DAG in 20 Lines
RAG ingestion pipeline, expressed as a DAG
Why
The point isn't the syntax — it's that this is plain Python, version-controlled,
code-reviewed, testable, and observable, just like the rest of your codebase.
from airflow.sdk import dag, task
from datetime import datetime
@dag(
schedule="@hourly",
start_date=datetime(2026, 1, 1),
catchup=False,
tags=["rag", "ai"],
)
defrag_ingest():
@taskdeffetch_docs() -> list[str]:
return list_new_documents_from_s3()
@taskdefchunk_and_embed(docs) -> list[dict]:
return [embed(c) for d in docs
for c in split(d)]
@taskdefupsert_to_vector_db(records):
pinecone.upsert(records)
upsert_to_vector_db(chunk_and_embed(fetch_docs()))
rag_ingest()
What you get for free
Scheduling — Airflow runs this every hour, with catchup and backfill controls
Dependencies — task ordering inferred from the Python data flow
Retries & SLAs — declarative retry policies, alerting on failure
Observability — logs, run history, lineage, all in the Airflow UI
Idempotency hooks — every run gets a logical date you can key off
Integrations — drop in operators for S3, Snowflake, Pinecone, OpenAI, etc.
Same shape works for ML training, eval pipelines, agent backends, and classic ETL.
Airflow · AI Era
12
What Makes It Production-Grade
The boring features that matter at 3am
Why
A pipeline that runs once is a script. A pipeline that runs every day for five years
needs retries, alerts, backfills, and observability — built in, not bolted on.
Retries with backoff — per-task or per-DAG, with exponential delay. Transient errors heal themselves.
SLAs & alerting — declare "this task must finish in 30 min" and get paged when it doesn't.
Sensors — wait for a file, a partition, an API, or another DAG before continuing.
Deferrable operators — long waits without burning a worker slot; freed back to the pool.
One pane of glass for every run, every task, every log
Why
Code declares the pipeline. The Airflow UI is where you actually operate it — see what ran,
what failed, when, why, and what to retry. This is what separates an orchestrator from a cron job.
Grid View · all DAGs · last 24h
rag_ingest
model_eval_daily
feature_store_refresh
finance_etl
customer_events
success
running
queued
failed
skipped
Graph View · rag_ingest · 2026-05-18 14:00
fetch_docs
chunk
extract_meta
embed
Click any task → logs, retries, mapped instances, lineage.
Gantt View · task durations
fetch_docs
chunk
extract_meta
embed
upsert
notify
Where time goes. Spot the bottleneck task at a glance.
Task Logs · embed · attempt 2 of 3
14:02:01INFO Starting attempt 2 of 3
14:02:01INFO Loaded 1,284 chunks from XCom
14:02:02INFO Calling embeddings API · batch_size=64
Pipelines that react to data, not just run on a clock
Why
Real workflows don't have fixed shapes. Sometimes you need 3 tasks, sometimes 300.
Sometimes you promote a model, sometimes you don't. Airflow expresses both, in plain Python.
Dynamic Task Mapping — evaluate.expand(...) fans out into N parallel task instances, one per model, decided at runtime.
Branching — @task.branch returns the task ID(s) to follow next; the rest are auto-skipped.
XCom under the hood — scores flows from upstream tasks to the branch via Airflow's metadata store.
UI support — the Grid and Graph views show mapped instances individually; you can clear and retry just one of the 300.
Same pattern for everything — file processing, A/B evals, multi-tenant ETL, agent eval matrices.
Why it matters for AI: eval matrices, multi-prompt sweeps, and per-tenant fine-tunes are natively expressible — no custom job runner needed.
Airflow · AI Era
15
Beyond Cron
Asset scheduling: when data triggers the next pipeline
Why
Cron answers "when". Assets answer "after what." Modern pipelines are coupled by data,
not the clock — Airflow makes that coupling first-class.
from airflow.sdk import asset, dag, task, Asset
from datetime import datetime
# --- Producer: declares a data asset ---@asset(schedule="@hourly",
uri="s3://lake/customer_events/")
defcustomer_events(context):
df = extract_events()
write_parquet("s3://lake/customer_events/", df)
# asset is "materialized" on success# --- Consumer: triggered BY the asset ---@dag(
schedule=[customer_events], # data-aware
start_date=datetime(2026, 1, 1),
)
deffeature_store_refresh():
@taskdefbuild_features():
...
build_features()
# --- Or combine multiple assets ---@dag(schedule=(customer_events & orders),
start_date=datetime(2026, 1, 1))
defanalytics_rollup(): ...
DAGcustomer_events
DAGorders
Assets3://lake/...
DAGfeature_store
DAGanalytics_rollup
Downstream DAGs run only when their upstream assets are refreshed — no more time-based guessing or brittle sensor chains.
Airflow · AI Era
16
The Bigger Frame
From pipelines to data products
Why
Once data is addressable, versioned, and lineage-aware, a "pipeline" stops being the unit of work.
The unit becomes the data product — owned, contracted, consumed.
inventory_2
Addressable
Each asset has a URI — s3://lake/customer_events/ — that producers write and consumers read. The dataset, not the job, is the contract.
bookmark
Versioned & observable
Every materialization is a tracked event: when it ran, what version, which DAG produced it, which consumers were triggered.
explore
Lineage by default
Airflow knows which assets feed which DAGs. A broken upstream isn't a mystery — it's a visible edge in the graph.
group
Owned by a team
An asset is a team's promise to the rest of the org: "we keep this fresh, correct, and on schedule." A product, not a side effect.
repeat
Composable across orgs
Asset-driven DAGs let independent teams compose pipelines without coordinating on cron schedules or shared infrastructure.
smart_toy
The AI substrate
RAG indexes, eval datasets, feature stores, agent memory — all of them are data products. Airflow is the platform that produces them.
Airflow · AI Era
17
Who's Running It
Powering data and AI at every scale
From startups to global enterprises
From a two-person team shipping their first RAG app, to companies orchestrating
hundreds of thousands of tasks per day across multiple regions.
Airbnb
Netflix
Tesla
Stripe
Lyft
Robinhood
Walmart
Adobe
Shopify
Snap
Reddit
Zoom
PayPal
SAP
NASA JPL
Slack
Twitch
+ 30,000 more
The community is the moat. Every operator, every integration, every edge case — already lived through by someone.
Airflow · AI Era
18
What People Build With It
Common use-cases, today
Where Airflow shows up
The same orchestrator quietly carries classic ETL, modern ML, and frontier GenAI workloads.
folder
Classic data engineering
ETL / ELT into the warehouse · Reverse ETL into SaaS tools · Data quality and validation · BI dashboard refresh · Compliance and audit jobs.
psychology
Machine learning
Feature engineering · Training and evaluation runs · Model deployment and promotion · Drift detection · Scheduled retraining.
auto_awesome
Generative AI
RAG ingestion and re-embedding · Eval pipelines for prompts and agents · Fine-tuning dataset curation · Multi-step agent backends.
build
Operations & tooling
Infrastructure automation · Cross-system data movement · Scheduled internal tooling · Notification and reporting workflows.
Airflow · AI Era
19
Under the Hood
Airflow 3.0 — architecture at a glance
Why
Clean component boundaries are what make Airflow scale from a laptop to thousands of workers.
Each piece is independently swappable, deployable, and scalable.
What each piece does
API Server — the new stable front door. Serves the UI and the public REST API; no direct DB access from clients.
Scheduler — decides what runs next; multi-instance HA by default.
DAG Processor — parses DAG files into the metadata DB; isolated from the scheduler so bad code can't crash the scheduler.
Triggerer — runs async-IO for deferrable operators; thousands of waiting tasks without burning workers.
Workers — actually execute tasks via Celery, Kubernetes, Edge, or your runtime of choice.
Task SDK — the stable contract between task code and Airflow; the foundation for multi-language tasks.
Metadata DB — Postgres or MySQL; the single source of truth for runs, history, lineage.
Why this shape: separation of concerns + the Task SDK boundary is what unlocks multi-language tasks and remote execution in 3.x.
Airflow · AI Era
20
Where the Community Is Heading
Airflow, evolving for AI
Active workstreams
The community is deliberately reshaping Airflow around how AI systems actually get built —
long-running tasks, human approvals, polyglot teams, and event-driven data.
Human-in-the-loop — first-class pause/resume so agents and humans share workflows: approvals, content review, escalation steps.
AI-assisted operations — natural-language debugging, DAG authoring, and triage built on top of Airflow's metadata and logs.
Multi-language tasks (AIP-108) — run Java, Kotlin, Go, and more alongside Python, on the same orchestrator.
Event-driven scheduling — data-aware and asset-aware triggering, not just cron. Pipelines react to upstream data, not the wall clock.
Task SDK — a stable, language-agnostic contract between task code and Airflow core. The foundation for everything above.
The bet: the next generation of AI products will be polyglot, partially-automated, and event-driven — and they'll need the same orchestration guarantees today's pipelines already have.
If you're building AI infra: these are the surfaces to watch — and to contribute to.
Airflow · AI Era
21
Part Three
Open Source
What I learned going from zero to Apache Airflow committer — and why you should contribute too.
Airflow · AI Era
22
Why You Should Contribute
The honest case for open source
Not idealism — leverage
Contributing to open source is one of the highest-return uses of your engineering time
that isn't your current job. Here's why, plainly.
You learn from the best. Free mentorship from world-class engineers, in public, on real code.
It compounds your career. Public proof of work travels with you across every job, indefinitely.
You shape the tools you use. Stop filing tickets — fix it upstream once, benefit forever.
You build a global network. Contributors become collaborators, references, co-founders, and friends.
You get paid in optionality. Maintainer reputation opens doors that interviews never will.
It's a gift back. Every line of code you wrote today stood on someone else's open source work.
The honest catch: OSS is slow, public, and sometimes thankless. The rewards are real but they compound on a multi-year timeline — not a quarterly one.
Worth it. Every committer I know would tell you the same thing.
Airflow · AI Era
23
Lessons
What contributing actually taught me
Skills that transferred straight back into my day job
Open source is the highest-leverage engineering school I've found. None of these lessons
are unique to OSS — but OSS forces you to learn them faster, in public.
auto_stories
Reading > writing
You spend 80% of OSS time reading other people's code. That's where the real upskilling happens — pattern recognition compounds.
science
Tests are documentation
A good test suite teaches you a system faster than any README. Read the tests first, then the code.
edit
Async, written communication
Clear PR descriptions and design docs are a force multiplier — at work, in OSS, and on your resume.
search
Code review is a skill
Giving and receiving review well separates senior engineers from everyone else. OSS is the gym for it.
track_changes
Scope discipline
Small, reviewable PRs ship. Big ones rot. "Make the change small. Make it easy to review." Always.
hourglass_empty
Patience & persistence
Reviews take days. Designs take weeks. Reputations take months. Show up anyway — that's the whole game.
Airflow · AI Era
24
My Story
From zero to Apache Airflow committer
No shortcuts, no special background
I didn't start contributing because I wanted to be a committer. I started because something
annoyed me in a tool I used every day — and the source was sitting right there.
Started as a user. Hit a paper cut, opened the repo to see if I could fix it myself.
First PR was tiny. A small documentation correction. It got merged. That hooked me.
Bugs → features. Each PR taught me more of the codebase than any tutorial could.
Reviews → design discussions. Slowly moved from "fix this" to "should we do this".
Committer invite. Months later, after consistent contributions and reviews.
The pattern: show up, ship small things, be useful to other contributors.
Becoming a committer isn't a credential to chase. It's a side effect of being consistently helpful around a project you care about.
Full write-up: blog.zhu424.dev — "Becoming an Apache Airflow Committer From 0".
Airflow · AI Era
25
Contributing in the AI Era
How the workflow is actually changing
Why this matters
Contributing in 2026 looks nothing like 2020. The bottleneck has shifted from typing
code to deciding what to build and verifying what was built.
chat_bubble
Intention is all you need
Natural language is the new programming language. Write the intent clearly; let the AI generate the diff. Your job is the spec — not the syntax — and the development loop is now describe → review → refine.
search
You still own every line
AI-generated doesn't mean reviewed. You're responsible for understanding what was committed — line by line, side effect by side effect. Skip this step and you ship slop.
account_balance
Architecture is what's left
Boilerplate, refactors, and migrations are commodity now. The remaining differentiator is system design, judgment calls, and code review — the parts an AI can't outsource for you.
shield
The AI-spam tax on OSS
Maintainers are drowning in low-effort, AI-generated PRs and issues. The community response: auto-triage bots, AI-assisted first-pass review, and humans only seeing what survived the filter.
The new contributor skill set: precise intent, ruthless self-review before you push, and deep respect for the maintainer's attention. Lean into the workflow — but don't outsource your judgment.
Airflow · AI Era
26
If You're Starting Today
How to actually take the first step
Concrete, in order
The biggest gap is between "I should contribute" and the first merged PR. Here's the path
that has worked for everyone I've watched cross it.
1️⃣
Pick a project you already use
Motivation runs out fast on code you don't care about. Scratch your own itch — the first bug you hit at work is probably a great candidate.
2️⃣
Start ridiculously small
Typos. Doc gaps. Missing examples. good first issue labels exist for a reason. Get a tiny PR merged first — momentum matters.
3️⃣
Read the contributing guide
Respect the project's conventions. Reviewers' time is the scarce resource — make their job easy and they'll merge your work faster.
4️⃣
Be visible and consistent
Join the dev list / Slack. Review other people's PRs. Show up next week, and the week after. Consistency beats intensity.
Apache Airflow specifically:apache/airflow on GitHub · #airflow-dev on the Apache Slack · weekly dev calls open to anyone.
Airflow · AI Era
27
Your AI is only as good as your data pipeline. Your data pipeline is only as good as the people who maintain it.