Ramp's Leo Mehr on Scoping and AI in Engineering

There is a role in enterprise software that doesn't have a clean name yet, which tells you something about where the industry is in thinking about it. Forward Deployed Engineering — FDE, in the shorthand — is what happens when a software company plants engineers directly inside the sales and customer success process. Their job, concretely, is to take what enterprise customers say they need, figure out what they actually need, and build it fast enough to close deals. They live at the intersection of product, engineering, and sales, which means they're accountable to all three and fully owned by none.

Leo Mehr is a director of engineering at Ramp, the corporate finance platform, and he runs its FDE organization. At a recent AI Engineer conference, he laid out two principles that he says have guided the function: always be scoping, and scale with tokens. The first is older than software. The second is very much of this moment. Together, they describe what it looks like when a pragmatic engineering team tries to absorb the AI wave without getting swept away by it.

Worth taking both seriously — starting with what's genuinely useful and where the real tensions lie.

The case for skepticism first

Mehr's opening story is instructive in the way that good embarrassing stories usually are. A large enterprise customer needed a mobile reimbursement feature. The mobile team was unavailable. Two engineers on the FDE team taught themselves iOS and Android development, ground out the feature on both platforms, and went back to the customer ready to ship. The customer's response: they mandate iOS devices for all employees. Android was never going to be used.

"It was a big lesson for us to remember the importance of scoping," Mehr said. "Even some of the most basic assumptions — like which mobile platform you build on — it's super important to validate them."

This is the kind of story that gets better with time because it's so avoidable in retrospect. A single question — "Does your company standardize on a mobile platform?" — asked before a single line of code was written would have saved weeks of work. Nobody asked it. Everyone assumed.

Mehr's response to this pattern is what he calls "always be scoping" — a deliberate practice of gathering context before committing to a solution. Not just technical context, but organizational context. Who's using the integration? Has anyone explored a manual workaround? Is the urgency coming from the customer or from a sales rep under end-of-quarter pressure? Does the request benefit one customer or a dozen?

That last question matters more than it might seem. An FDE team that builds a feature for a single customer once is doing customization. One that builds a feature for ten customers who all have the same underlying problem is doing product development. The distinction determines whether the work compounds or just accumulates.

None of this is revolutionary, which is partly the point. Mehr isn't claiming to have invented requirements-gathering. He's arguing that the FDE context — the urgency, the sales pressure, the customer relationship — makes it especially easy to skip. The default reflex, as he puts it, is to say yes and start coding. The trained reflex is to pause.

Whether "always be scoping" constitutes a principle or just good engineering practice is, honestly, a fair question. Every software methodology of the last fifty years has had some version of this lesson embedded in it. Agile, waterfall, XP — they've all tried to solve the problem of building the wrong thing with great efficiency. The FDE version has a particular texture because it's navigating active sales pressure and real customer relationships rather than abstract backlogs, but the underlying discipline is familiar.

What Mehr adds that's worth noting: scope isn't just about the current request. A well-scoped request is one that's been examined against the full pipeline — other prospects, other customers, other use cases — before a single line of code gets written. That's a slightly different framing than "understand the requirements." It's treating individual customer requests as signals about what the product should do for everyone.

Where AI actually fits in

The second half of Mehr's framework is where the 2024 context arrives, and where things get interesting.

An FDE team's work follows a rough pipeline: receive a customer request, scope it, write a technical specification, implement the feature, deliver it. Mehr's argument is that each stage of that pipeline is a candidate for automation by AI agents — software systems that can carry out multi-step tasks given appropriate instructions and context.

He's not claiming this is done. He's claiming it's the right direction, and he has one concrete example of it working.

Ramp's FDE team receives customer requests through an internal Slack channel. Account managers and sales reps post when they've hit a blocker for a large prospect. The quality of those requests varies wildly — some are detailed and actionable, others are a sentence long. Before, an engineer would read each one, do back-and-forth with the submitter, and eventually produce a usable specification. That process took hours or days.

Ramp built an AI agent — surfaced through Notion, the document and workflow tool — to handle the intake step. In its first version, the agent simply read the incoming request and asked clarifying questions. That alone compressed response time from hours to seconds. Mehr said the team iterated on it, and the current version conducts multiple rounds of questioning with the submitter before deciding it has enough information to generate a specification. Mehr estimated the tool has saved roughly 20% of the time his team would otherwise spend on request scoping.

That's a real, measurable result from a narrow, well-defined intervention. It's worth distinguishing from some of the AI deployment stories floating around the industry, which tend to be either vague about what was automated or careful not to mention what was left for humans.

Here's what the Ramp system actually does: it runs the intake conversation — asking the questions a human engineer would ask — so that by the time an engineer looks at a request, the basic context has already been gathered. The system uses past requests and existing help documentation as reference material to ground its questions. Engineers then review the generated specification, catch errors, apply judgment, and decide what to build.

The system cannot decide whether a request is worth building. It cannot weigh one customer's need against another's. It cannot recognize when a sales rep's urgency is manufactured. Those are the parts that, at least for now, require a person.

Mehr was candid about what remains unsolved. The middle of the pipeline — turning a well-scoped specification into a production-ready feature — is what he called "gnarly and unformed." Getting AI systems the right context is hard. The product knowledge an experienced engineer carries in their head — the edge cases, the architectural constraints, the history of previous decisions — doesn't live neatly in a document. "Imagine all the knowledge that a product manager has in their head about their product," Mehr said. "How do you get that into an agent?"

He doesn't have a complete answer. He's honest about that.

The failure mode he's warning against

Mehr closes with a warning that's sharper than it first sounds. An AI system that accepts requests and generates output without scoping discipline, he argued, becomes what he called a "token-maxing slop cannon" — a phrase that earns translation. "Token-maxing" refers to an AI system that generates the maximum possible output in response to each input, optimizing for volume rather than accuracy or usefulness. The more tokens (units of text) it produces, the more confidently wrong it can be, at scale, without anyone catching it. Slop at speed.

The point is that automation amplifies whatever discipline you bring to it. A well-scoped request fed into an AI pipeline produces a useful result faster. A poorly-scoped request fed into the same pipeline produces a useless result faster. The scoping practice and the automation practice aren't competing approaches — if you skip one, the other makes your situation worse.

"If you are amazing at scoping but don't invest in building out this agent factory," Mehr said, "your competitors who do are going to overtake you and outcompete." Companies that automate their engineering intake and delivery pipelines will process more requests, close more enterprise deals, and ship faster than those that don't — regardless of how good their individual engineers are.

That's a competitive argument with teeth, and it's the part of Mehr's talk that will have the longest shelf life. Not because it's complicated, but because it's true and most organizations haven't acted on it yet.

The agents handle the queue; someone still has to decide what the queue is for.

Mehr's framework, at its core, is a claim about where human judgment remains irreplaceable — and where it's being wasted. Reading intake requests and asking clarifying questions is valuable work, but it's not the work that requires an experienced engineer's judgment. Deciding whether to build an SAP integration at all, weighing it against ten other requests, and betting on what the market actually needs — that's the work that compounds.

The question every FDE team, and arguably every engineering organization, now faces is whether they can make that distinction clearly enough to act on it.

By Bob Reynolds, Senior Technology Correspondent, BuzzRAG