KPMG's FDE: the bottleneck is now context, not code

When Justin Johnsen joined KPMG as a software engineer, every line of code was written by hand. He is now the firm’s forward deployed engineer and lead technical architect, and in his view the hardest part of the job no longer happens at the keyboard.

In a first-person piece for Business Insider, Johnsen says the bottleneck used to be writing code. Now it is gathering context and clarifying intent before development begins. Business Insider’s Japanese edition, drawing on an interview with him, records the same point.

If you work as an FDE or are aiming for the role, that shift changes how you are judged. On the client site, your value moves away from how fast you write code and towards how deeply you understand the problem, so that the brief you hand to AI leaves no ambiguity for it to guess at.

AI is only as good as the context you give it

Johnsen argues that AI is enormously capable but only as good as the context it receives. That sounds obvious; the consequences for FDEs are less so. When a model can write a module in minutes, a misread requirement turns into wrong code just as quickly.

Imagine a client asks you to “automate invoice reconciliation”. Hand that sentence as it stands to a coding agent and you will get code that runs but may solve the wrong problem: what discrepancy is acceptable, how foreign-currency invoices are handled, who approves the exceptions.

The answers live in the heads of the client’s accounting team, not in the repo.

That is why, when Johnsen defines an FDE, he stresses staying power: the FDE works directly with the client and stays with the problem. Business Insider Japan is more specific: the journey runs from understanding the business need to delivering a solution that actually works.

But don’t read this as “less technical”

The easiest mistake is to treat the AI-era FDE as a consultant with a laptop. KPMG US’s posting for a Technical Lead, Forward Deployed Engineering says the opposite: candidates need at least seven years of recent experience shipping production software systems end to end.

According to the posting, the hire will rapidly build and deploy end-to-end AI systems alongside a pod of “AI-native” full-stack engineers. The pod works in cycles of two to six weeks, taking feedback directly from users and stakeholders. Cycles that short only work when the person writing the spec also understands where the system will break.

Gathering context does not replace engineering skill; it is built on it. You only know to ask the right question about foreign-currency invoices if you already understand how they can break a reconciliation pipeline.

What does an intent spec look like?

Go back to the hypothetical invoice-reconciliation case. Instead of one sentence, the brief you give the agent might open with the business goal: reduce the number of invoices the accounting team matches by hand, not “match every invoice”.

The constraints section spells out what must be asked of the client first: who sets the threshold for automatic matching, and which day’s exchange rate applies to foreign-currency invoices. The edge-case section lists invoices paid in instalments and cancelled invoices, with a rule that they go to a queue for a human reviewer.

Last come the acceptance criteria: rerun a month of historical data and compare the results with what the accountants did by hand. Every line in that document is a question you have to put to the client, and that is precisely the work Johnsen calls the bottleneck.

It is also worth taking into an FDE interview. Walking through a spec like this, and pointing to the question that saved the project from building the wrong thing, is usually more persuasive than a list of frameworks.

Johnsen began his career writing every line of code himself. The seven-year bar for shipping production systems in KPMG’s posting shows that such experience is still the price of entry; what has changed is that it is now used to ask the right questions before the first line of code is written.