The forward deployed engineer and the dilemma Brazil already knows

There's a role that became a craze in AI startups, and almost no one agrees on what it means. "Forward Deployed Engineer" (FDE) is the hot ticket at labs like OpenAI and Anthropic, at PE funds, and at AI-native startups. And, as Vinoo Ganesh, CEO of Kepler and former leader of the Project Frontline program at Palantir, well documented in an essay on Latent Space, the term has been stretched so far that it became synonymous with "person who does something that vaguely involves a client."

I want to bring this debate into our own backyard. Because, reading Ganesh's piece, my conviction only grew: the FDE isn't an imported trend we're going to copy badly. It's the formalization of a competency that senior Brazilian developers have already practiced for years, often without a name and without recognition. The problem is that the AI-native startup market here still stumbles exactly at the point that separates the real FDE from the consultant with a laptop.

What the FDE Really Is (and What It Isn't)

Ganesh separates things with a clarity I'd adopt in any scope discussion. Keeping the client happy is the solutions architect's job, and it's a legitimate job. The FDE exists for something else: solving a client's problem in order to extract the information that defines what gets built into the product. The sentence that closes the argument is harsh:

An FDE engagement that ends with a delighted account and nothing changed upstream failed at the one thing the role exists to do. You got the context and spent it locally.

>

-- Vinoo Ganesh, CEO of Kepler

This is where the fork he calls "the fork" comes in. Do the work without a platform underneath and you learn one company's model, deliver something shaped exactly for it, and lose everything when the contract ends. The next client starts from zero. That's consulting: it pays well, the people are excellent, and it doesn't compound. Put a platform under the same work and every company mapped makes the next deploy faster.

The difference, in his words, is between selling hours and building an asset. And the verdict is scathing: "my honest read of this gold rush is that most companies in it are building the former and describing the latter to the board."

Collecting Nouns and Verbs

The most applicable part of the essay, and the one I'd bring into any onboarding for a dev who's going to face clients, is the method: the FDE's job is to collect nouns and verbs.

Nouns are the things the business treats as real: a position, a trade, a counterparty. And here's an observation that anyone who has ever integrated a system knows in their bones: the same concept usually has at least four different names. Sales says customer, ops says client, finance records a billing entity, and engineering writes org_id. Every seam between these teams hides a translation that breaks the instant someone changes a definition.

Verbs are how the nouns move: how a trade gets recorded, what needs to be true before closing the books, who signs off on an exception at eleven at night, and what happens when that person is on vacation. Almost none of this is written down. It's culture, it lives in the heads of six people who've been there long enough to stop noticing it, and in a spreadsheet someone built four years ago that the entire team silently depends on.

The case that illustrates this is the best in the piece. A startup spent nearly a year trying to migrate a client from CSV to Parquet, and a data quality engineer kept blocking it every time, with reasons that kept changing. Arguments about storage reduction, compute, pipeline optimization: nothing moved the needle. An FDE went out there and simply watched her work. She'd pull the CSVs from S3 onto Windows, double-click, open them, and eyeball the rows by hand. That was her quality control. Parquet, at the time, had no native viewer, so the proposal took away the only tool she had and gave nothing back.

We built a Parquet viewer that night, she approved the migration two days later, and pipeline run time dropped from about seventeen hours to two.

She would never have said this in an interview. From her point of view, the reason was obvious and not worth mentioning. That's the kind of insight no discovery call captures, and the kind that determines whether the rest of the product gets used.

Why This Speaks to the Brazilian Developer

Here's where my position comes in. In Brazil, senior devs have always had to understand the business. The culture of the "software factory" (fábrica de software), of custom-built projects, of banks and retailers with processes that exist nowhere on paper, produced a generation of engineers who already collect nouns and verbs by instinct, sitting next to the user to figure out why the bank reconciliation screen has a field nobody can explain.

The difference the FDE model brings isn't competency. It's the structural discipline of turning that learning into a platform instead of a workaround. And this is exactly where the AI-native market here stumbles.

Ganesh tells a story that any of us would recognize. He hastily wrote a groovy script to hold a client together, called vinoo.groovy, an afternoon's work that was never supposed to survive the week. A year later, it was running at a client with almost a hundred thousand people, with his name stuck to it. The team started calling it vinoo.groovy. The lesson:

Every shortcut you ship becomes something you now maintain. The discipline is knowing which fixes belong to the platform and which ones you deliberately throw away the moment they've served their purpose.

I don't know a single Brazilian engineer without a vinoo.groovy on their conscience. The cultural issue is that, in a poorly structured AI-native startup, nobody deliberately decides what dies. The FDE solves the client at hand, the founder celebrates the closed account, and the compounding never happens because the structure never asks for the signal back.

The Detail Almost Everyone Gets Wrong: the Reporting Line

The most concrete and replicable point in the piece, for anyone building a team, is where the FDE reports. At Kepler, the function sits inside product, not sales. And that's not an administrative detail:

Point the function at sales and the incentive becomes closing the account in front of you, which is real work and someone at the company should do it. It isn't this one.

Pointed at product, every deploy is forced to produce something the next deploy can reuse. It's an org design decision, and it precedes the clients. Ganesh set it up this way on day one, before there were clients to justify it, because the alternative is discovering in month fourteen that your engineers optimized for the wrong thing.

There's also a technical gain that interested me as an architectural argument: Kepler treats provenance as a correctness requirement, and that's what makes field work compound. A system that improvises on top of a bad encoding never tells you the encoding was bad. Theirs doesn't improvise: when they misunderstand how a fund defines something, that shows up as a failure, not as a plausible answer. The engineer who got it wrong finds out from the system, not from the client in a meeting six weeks later. It's system design in service of learning, not just delivery.

The Honest Counterargument

I need to face the "isn't this just reinventing consulting?" that, as Ganesh himself admits, dominates the comments on any video about FDE. And the honest answer is: when there's no platform underneath, it really is consulting, just with a fancier badge. The term became HR marketing in many places, to the point that there's now a "forward deployed equity researcher" job posting. The criticism is fair against most implementations.

My defense is of the model done well, not of the label. And it's a conditional defense: it only holds if there's a product to receive the signal from the field. Without that, hiring FDEs in Brazil will just rebrand the old systems analyst who puts out client fires, and the founder will swear to the board that they're building a scalable asset while actually selling hours.

What remains open, for those building here, are two practical questions. The first: does your startup have a platform mature enough to absorb what the field brings back, or will the FDE just become a firefighter? The second, more uncomfortable one: can your technical culture handle a senior engineer sitting next to the user instead of closing tickets? If the answer to both isn't yes, the problem was never the lack of the title. It was the lack of the structure that makes it different from consulting, and no new title fixes that.