Designing data integration's first headless experience.
Data integration has always meant a visual canvas. This was the first time a user could build a mapping or taskflow entirely inside an IDE — no Informatica UI — trusting the context they share with Claude and the Informatica DI MCP. I led the design of that headless experience, shown at the Informatica World 2026 launch.
Data integration is moving off its visual canvas into IDEs and agents. I led the design of the first headless way to build a data pipeline — no Informatica UI, the user trusting the context they share with Claude and the DI MCP. Here's the whole thing, with jumps into any part.
The problem
As DI goes headless, a person builds a pipeline they can't see — and a wrong field silently corrupts real data.
Data integration is the work of moving and reshaping data between systems so a business can actually use it — pulling from dozens of scattered sources into one trustworthy place. Whole teams depend on it: a claims team can't settle a claim, a bank can't reconcile accounts, a pharma team can't report a trial until that pipeline runs correctly. When it's wrong, the business breaks downstream — quietly.
The problem
As DI goes headless, a person has to build a pipeline they can't see — trusting only the context they share with the IDE, with no Informatica UI to check against.
Until now, DI had two modes. This was the first attempt at a third — one of a kind.
Mode 1 · today
The canvas
Drag-and-drop, 20+ nodes on an average mapping, deep node-by-node configuration. Powerful but heavy — and I'd previously owned its design.
Mode 2
The copilot
Generates a mapping from natural language — but stops at generation, and still assumes the canvas underneath.
Mode 3 · first of its kind
Headless
Build a mapping or taskflow inside an IDE — no Informatica UI at all — through Claude and the Informatica DI MCP.
The stakes are high and the scale is real: a wrong field assignment silently corrupts enterprise data downstream, and a single large customer can run on the order of a thousand connections. These are seasoned users — running regulated, config-dense pipelines across domains like these:
Asking a user from one of these teams to build that pipeline without seeing it — reading and trusting a spec instead of a canvas — is the design problem I set out to solve.
I led the experience end to end — across all three surfaces a spec can travel through (Claude Code, the canvas, and the conversation layer): the research, the interaction model, and the thinking that carried it to a global keynote. Product and engineering partnered closely and owned scope, feasibility, and delivery. I name the split plainly because an honest account is more useful than a flattering one.
What I owned
The research that turned customer pain into a design direction · the five-layer interaction model · the narrative shown on the IW'26 stage · prior ownership of the mapping canvas this builds beyond.
What I worked against
No precedent — no tool had designed the headless build moment · users from a sentence to a precise spec sharing one system · a hard launch date and a confidentiality line around customer data.
I listened, mapped how it really works, then felt it myself.
Three layers of research: what customers said, how spec-driven DI actually works across the tools, and what the agentic loop feels like when you live inside it.
1 · What I heard from DI customers
Reading the first-generation DI copilot feedback from 10+ enterprise customers, I stopped treating each complaint as a feature request. Every one was a broken mental model — a UX contract the tool was violating.
"The copilot expects me to know exact object names. I don't always know what things are called in the system."
— Misplaced expertise: forms demand precision; conversation should absorb ambiguity
"In case of issues, there's no intuitive error handling — we just get told to reach out to GCS."
— Context fragmentation: the agent is flying blind without metadata
"The copilot helps us create. But we still review, validate, and deploy manually — that's most of the work."
— Generation ≠ assistance: creation is step 1; the lifecycle is steps 2–10
"Every session starts from scratch. It doesn't know our naming, our rules, or the mappings we've already built."
— Amnesia by design: the deepest pain, because it's architectural
2 · How spec-driven DI actually works
I mapped the real process people use today with Claude Code — natural language to a running mapping — to find where the design had to live. The spec gets written to disk, and a human reads it before the agent executes.
The spec-driven DI workflow — one of several moments the design had to win
3 · Comparing the tools, and sizing the load
I benchmarked the five tools a spec could be written in — and sized DI's configuration-heavy specs across small, medium, and large, counting MCP calls and the clarifying turns each needs.
Spec size
Spec tokens
MCP calls
Clarifying turns
Small
minimal
1–3
1–2
Medium
~800
4–6
3–5
Large
~4,000
10–18
8–15
Two findings that shaped the product: first, spec completeness beats speed — a faster spec that's incomplete means a broken mapping on real data. Second, a large multi-block session reaches ~40–90K tokens, close enough to a 200K window to degrade mid-task — so I took this sizing to the DI PMs to steer the spec model away from token-maxxing, keeping specs modular. And MCP readiness is the real filter: a spec written where there's no path to DI can't be handed off at all.
4 · Feeling the loop myself
Benchmarks tell you what; only using the tools tells you how it feels. I connected MCPs — FreeCAD, Blender, Figma, Notion — and watched the request → response loop. When a tool was transparent about what it was about to do, I trusted it; when it acted silently or hit an invisible limit and failed, the feeling flipped to anxiety. I also dug into how much a tool can even do inside an IDE like VS Code — deliberately little: extensions run sandboxed, and an MCP server is editor-blind, unable to see your file or draw a screen. That confirmed the core constraint: in a headless build there's no UI to lean on, so the whole experience rests on how legible the spec and shared context are.
To pressure-test it, I designed a watch dial two ways — vibe-led, chasing what looked good, and spec-driven, writing the intent first. Vibe-led was fast, then I lost the thread; spec-driven was slower to start, but I could see what the agent understood and keep the intent mine. Years prompting and designing TradeFlow had already taught me the difference between a tool that performs for you and one that works with you — this named it.
The goal: let a user build a mapping or taskflow with no Informatica UI, and still feel in control. Human review is one layer — not the whole answer. Here's the shape at a glance:
The agent queries the catalog, metadata, and lineage before it generates — so it isn't flying blind, and a user doesn't need exact object names. Semantic search across thousands of assets surfaces the right one to reuse.
For the user
Say "the Salesforce thing" and the system resolves it — no schema lookup first.
Why
Metadata is the agent's missing eyes; without it, every output is guesswork.
Frame coming
02 · Intent
Meet the user where they are.
Conversation absorbs ambiguity instead of demanding precise input. One spec serves three levels — a business user's sentence, a technical user's written or imported spec, a coder's code-derived spec. Ambiguity opens a choice, not a failure.
For the user
The entry mode decides how much they write — not how much the spec contains. No one's locked out.
Why
Forms enforce precision; conversation absorbs ambiguity.
Frame coming
03 · Memory
Make the agent remember the organization.
A per-organization context layer — naming conventions, business rules, prior mappings — grounds the agent before it generates, surfaced through MCP. The same idea as a CLAUDE.md, but for an enterprise's data world.
For the user
Output arrives company-correct, not just generically correct — less reconciling, less re-explaining.
Why
The deepest pain — a brilliant contractor with amnesia every morning.
Frame coming
04 · Lifecycle
Stay with the user past generation.
Generation is step 1; review, test, deploy, govern, and debug are 2–10. I designed for the parts being dropped: standards checked before deploy, and a failure that returns a lineage answer instead of a support ticket.
For the user
"Why did this fail?" returns a traceable answer — not a dead-end ticket.
Why
The copilot stops at step 1 — and that's where most of the work begins.
Frame coming
05 · Oversight (RHITL)
A real human in the loop.
The review gate: the person reads what the agent intends, sees where the spec is solid and where it assumed something, and approves or sends it back before anything runs. Major decisions are auditable, with non-repudiation for human and agent alike.
For the user
Approve or stop the build before it touches production data.
Why
One layer of five — the safety net, not the whole net.
Frame coming
One spec. Three people. Three surfaces.
The same headless pipeline is built and kept alive by three very different people — each in their own surface, none of them forced into a tool that isn't theirs.
Conversation
Business user
Describes the need in a sentence, never sees code, reviews the result and approves. The platform does the rest.
IDE · headless
Data engineer
Extends the pipeline from the IDE via the DI MCP, never opens Informatica, reviews the diff, commits.
Chat · mobile
Operator
Diagnoses and fixes a failure from a phone in minutes — no Informatica UI to open.
One spec, three surfaces — the platform adapts to the person, not the other way around.
I'll keep this to what's true and verifiable — design that reached a global stage and a working interaction model, not metrics that belong to other products.
Shipped
The headless DI experience was shown at the IW'26 keynote and mainstage demos — a global launch, and a fourth straight keynote year.
Built
A five-layer interaction model — discovery, intent, memory, lifecycle, oversight — mapped to the customer pain it answers.
Carried forward
The spec-sizing work steered the DI PMs away from token-maxxing and shaped where the product went.
The leap is real: the same user who built on a 20+ node canvas can now build the pipeline headless — trusting context instead of a screen — and a business user, an engineer, and an operator each work in the surface that's theirs. That's the first-of-its-kind shift this work made: design's job became making a headless agent legible, trustworthy, and usable.
What I'd do differently: I'd put cost and consumption in front of the user earlier — we could describe it directionally but not yet measure it — and I'd test the review gate with more hands-on sessions before the keynote, not just after.
When the screen disappears, design becomes the only thing keeping a person in control.
Note: this case study describes concepts, research observations, and design decisions only — no customer names, no demo data, no unreleased product specifics. Tool comparisons reflect publicly documented behavior.