Experiences with the AI FDE: a few obvious lessons, a few that weren't

The sharpest scaffolding and prototyping partner on the platform. A few things I learned putting it to work.

Who this is for

Foundry developers, FDEs who want a technical account of how the AI FDE behaves on a real architecture, where it's genuinely strong and where it needs a hand on the wheel, from work on actual pipelines rather than a demo.

A note on setup: everything below came from running the AI FDE against real problems in branches and test repos. If you haven't read Palantir's own AI FDE documentation, give it a read; it covers modes, capabilities, and approvals well. This is the part it doesn't cover, how the AI FDE behaves when the correct answer isn't in the syntax but in a transaction type, an edit layer, or where a table physically lives.

---

It asks for the resources it needs, and silently assumes the architecture it doesn't

Pointed at the integration docs for an external Postgres source, the AI FDE mapped twenty-plus columns and foreign keys into Foundry, correctly, in a single turn. On pure schema translation it's faster than doing it by hand and rarely wrong. It's also disciplined about resources: when it needs a dataset, a repo, an action, it stops and asks, and waits for you to hand it the reference before it proceeds.

The gap is that resources are not the only thing it's missing, and they're the only thing it asks for. It will pause for a dataset handle it doesn't have, then in the same build silently assume how your data moves. On real work it decided the external tables synced bidirectionally into Foundry when they were external-only, and it generated OSDK writes when the actual path pushed files through an S3 upload. It never asked how the sync worked or where the write should land; it took the most common architecture and built on it. Both assumptions were wrong, both produced clean code, and neither would surface in review, because there was nothing malformed to catch.

That's the distinction worth holding onto: the AI FDE reliably asks for the resources it needs to act, and reliably does not ask about the architecture it needs to be correct. Data locality, sync direction, the real write path, none of it prompts a question, so all of it has to be stated up front. Give it a locality brief before any code, for every source, whether it's a Foundry dataset, a materialized dataset, or external-only, and what the real write path is, and the largest class of confidently-wrong output disappears.

It stops to ask for a resource it's missing. It never stops to ask about your architecture. State data locality and the write path before it writes a line, because it won't ask.

Platform facts drift over a long session, and it rebuilds against the wrong one

Across a longer build, decisions the AI FDE made earlier stop holding unless they're pinned somewhere it re-reads. In one session it committed to an architecture that routed around an external dependency, revised to a simpler shape when challenged, then several turns later regenerated code against the original approach as if the revision had never happened.

What makes this a Foundry problem rather than a generic agent one is the category of decision that drifts: not preferences, but platform facts, whether data lives in Foundry or only feeds it, whether a write targets the edit layer or the dataset, whether an input is materialized. When one of those reverts mid-build, the FDE doesn't announce a contradiction; it silently emits a transform or action built on the wrong assumption, and it compiles. Durable platform facts therefore can't live only in conversation history. They belong in a spec the agent builds from or a skill it loads, so a decision locked early still constrains the work later.

What drifts over a long session isn't a preference, it's a platform fact: data locality, write layer, materialization. When it reverts, the FDE rebuilds against the wrong one and it compiles.

Automate only surfaces AIP Logic functions that return OntologyEdits

Here the FDE's platform knowledge runs ahead of most engineers'. Wiring an AIP Logic function into an Automate workflow, it restructured the function to return OntologyEdits on its own, so it registered in the Automate selector.

It knew something most engineers learn the hard way: Automate's logic selector only lists AIP Logic functions that return OntologyEdits, and a function returning a primitive or a read-only result never appears in the dropdown, with no error explaining the absence. It handled that unprompted, and this is the FDE at its best, on documented, well-worn platform paths it's reliably ahead of you. What the rest of this post is about is what it does on the paths that aren't documented, where it acts with the same confidence and none of the same footing.

OSDK edit actions with partial payloads null every field you don't pass

Hand the AI FDE an OSDK edit action to build and supply only the properties you're changing, and it writes null to every property you left out, because at the action level an omitted field and a field set to empty are indistinguishable. A single save wipes the untouched properties, silently, with no error. The action is syntactically correct, so review doesn't flag it.

The enforceable pattern is to have every edit action re-submit all current values and spread the delta on top, so an edit can never null a field it didn't intend to touch. It's a one-line instruction that has to be given up front, because the FDE won't add it on its own, and it won't learn it either: this exact behavior bit three times in one workstream, in the original edit, in the cleanup script written to fix it, then in the restore script written to undo the cleanup, each time diagnosed from scratch. A correction from an hour ago carries no weight once it's out of context, so the ones that matter belong in a loaded skill, not in the conversation.

Tell the FDE to re-submit all current values and spread the delta on top. Left to a partial payload, it nulls the rest, silently, and review won't catch it.

Two Create actions for a linked pair sever the relationship at commit

Give the FDE a tightly coupled pair of records to create through two independent Create actions, and it produces clean, CI-passing code in which each action mints its own primary key at commit time. The foreign key meant to join the records resolves to nothing, because neither action knew the other's generated key.

It writes correct syntax and has no model of relational integrity spanning two separate actions, so left to its own approach it will keep producing the split-key version. The way to steer it is to take that structure off the table up front: tell it not to use two independent Create actions for a linked pair, and to route the write through a single TypeScript function or a combined action instead, where the key is generated once and passed explicitly to both records before commit. Given that instruction it builds the connected version cleanly; without it, it defaults to the one that severs.

A bare RID reads as a media reference, but the real structure is nested

A property held what looked like a media reference, a media-item RID, and the FDE used it directly as one. A Foundry media reference is not a bare RID. It's a nested structure: a mimeType alongside a reference.mediaSetViewItem object carrying the media set RID, the view RID, and the item RID. The bare RID is one of four required fields, three levels down, so the value that looked complete was a quarter of the actual reference.

It's a consistent thing the FDE does: where a platform-native type's real structure is richer than a stored value looks, it takes the value at face value and builds on it. So with anything platform-native it hands you, a media reference, a nested action parameter, check the actual shape against the docs before trusting what the FDE treated as complete.

@incremental on a materialized dataset passes CI and reads every row

The AI FDE reaches for @incremental on a materialized dataset readily, because it's the textbook optimization and nothing in the diff or the build argues otherwise. The build goes green, the output is correct, so it looks done. Materialized datasets commit SNAPSHOT or UPDATE transactions, though, which means an incremental read against one silently degrades to a full read. The transform still produces the right result, it just re-scans every row on every scheduled run to do it. That's the greater issue: it isn't a bug you'll catch, because nothing is broken. The pipeline works. It simply carries a permanent full-scan compute cost that no error surfaces and no review flags, running on a schedule, indefinitely, until someone happens to audit why the compute line is higher than it should be.

A related failure is schema drift on ingested data: OCR and vision-model outputs arrive as the string "True" or "1", and assuming the backing type matches the physical data produces a silent coercion or a runtime crash pointing nowhere near the cause. Both are the same gap, the FDE optimizes for code that's correct on a sample, not for behavior at real scale, unless the constraints are stated. Briefing it explicitly, this input is materialized, snapshot and update transactions, sized for the real row count, and inspecting source schemas before a join, produces the right design on the first pass.

The FDE reaches for @incremental on a materialized dataset because it looks optimal. It's a full read on every run, and it passes CI, so nothing flags it but the compute bill.

On a silent platform wall, it edits code the problem was never in

A Python driver crashed mid-build with Py4JNetworkException: null response, no traceback. The AI FDE worked the problem competently, memory limits, then JSON parsing, then infrastructure, across roughly twenty turns, every hypothesis wrong because the cause was structural: a repo with thirty transforms and heavy computer-vision imports that needed splitting. The same shape recurred elsewhere: turns spent on audio playback that Workshop's Content Security Policy blocks by design, and a Code Workspace looping on file operations that failed with Tool execution was canceled while the repo sat behind master with uncommitted local changes.

When the wall is environmental, there's no error text for the model to reason from, so it keeps modifying the one surface it controls, the code. The diagnostic is reliable: when successive attempts change only in their parameters while the error stays constant, the blocker is the platform, not the payload. Stop at the second identical failure and check the environment, git status first; the resolution is almost never in the code being rewritten.

When successive attempts change only their parameters while the error stays constant, the wall is the platform, not the payload. Stop at the second try.

Where it clearly earns its place

None of the above reads as an argument against the AI FDE. Every rough behavior is the same one, output generated from a fact it wasn't given, and when it has the full picture it's genuinely sharp. The clearest instance was a bug that started in the worst place to debug from: a Workshop widget rendering nothing, no media, no error, just empty. That symptom could originate almost anywhere, in the widget config, the ontology mapping, the object type, or the data itself, and checking each layer by hand is an afternoon. The FDE walked it in the right order instead. It went past the widget, past the ontology mapping that looked complete, and down to the backing dataset, where it found the actual cause: the dataset was effectively empty, a lone primary-key column present and the properties the object type claimed to expose simply absent. Three properties mapped, one column behind them. The object type eyeballed as finished, and the data underneath wasn't there. It found that in a couple of steps, across three layers, and went straight to the layer the symptom gave no hint of.

That is the whole pattern. Given the real shape of the data, the transactions, and the instance, it does excellent work and traces problems across the platform's layers cleanly. Left to infer that shape, it fills the gap with the average case and returns something clean, confident, and wrong. The variable is the context it's given, not the FDE.

Where it fits

Point it at the scaffolding, the prototyping, the ports, and the cross-system tracing, and nothing else speeds up a Foundry workflow like it does right now. The only discipline it asks for is the ordinary kind: design the production object model yourself, review what it writes, treat its first pass as a draft, and give it the platform facts it can't infer. That last one is really the whole post. Everything above is a version of it.

What it comes down to

• The AI FDE is genuinely strong and fast on documented, well-worn platform paths: mapping a schema, wiring an AIP Logic function into Automate, scaffolding an action, tracing a bug across layers. Watching that land in a single turn is what makes it worth keeping.
• The rough edges are all one shape: it builds from what's in front of it, and fills whatever you leave out with the most common case. A transform that passes CI and re-scans millions of rows, an edit that nulls the fields you didn't mention, a value that looks like a media reference and isn't, none of it shows up in review.
• So the work is context, not prompts. Give it the real shape of your data, your transactions, and your instance, and it does precise work. Leave those implicit, and it's confidently wrong in ways that compile.

What am I missing?

If you've run the AI FDE on your own Foundry work and seen a behavior that isn't here, or found a way to steer it that this misses, I want to hear it. We'll either fold it in or argue about it.