Earlier this month, I got a new title.
AI Forward Deployed Engineer.
For anyone wondering what I did to get the job, spoiler alert: it was a complete surprise to me.
I was essentially volun-told.
Once the surprise wore off, I started figuring out what I had actually signed up for. I never planned my career around becoming an AI FDE, and most people I talk to ask the same question:
What does that even mean at IBM?
After a few conversations and a lot of reading, I had a second reaction.
I was born for this shit.
The way we explain it to clients comes down to six words: from working demo to working business.
At IBM, an AI FDE works inside the client’s environment with the systems and data the business actually uses.
The goal is to take one important AI use case out of demo mode and put it into production, where people use it and the client can keep it running.
IBM saw what I had been building, trusted me to do it for clients and made it my day job.
Grateful is an understatement. It’s an honor.
Six and a half years of enterprise pre-sales at IBM, then this line changed.
What happens after the demo?
I know how convincing a good demo can be, especially when the data has already been cleaned and the person who built it is running the call.
Then the demo ends, everybody goes back to work and somebody has to make it real.
The same system now has to connect to whatever the client already runs, usually with uglier data than anyone wants to admit. Security has questions. The users are busy, and somebody still needs to own it when it breaks.
The pilot ran on a clean extract with the vendor on the call.
Production runs on a Tuesday at 4 p.m., on data nobody cleaned, with nobody from the vendor in the room.
MIT Project NANDA put a number on that gap in 2025.
Its preliminary report estimated that only about 5% of task-specific enterprise GenAI tools reached successful implementation with a sustained productivity or P&L impact.
You can read the full report here:
The GenAI Divide: State of AI in Business 2025
Production has to survive real data, real workflows and real users.
Here’s what that can look like
This example is made up, but the problems in it show up all the time.
Say an insurance team pilots an AI claims-routing assistant. It reads a clean batch of claims, sends each one to the right queue and recommends the next step. In the demo, it looks great.
Then the team tries it on real claims. One field means something different in another system, and an important note is buried in free text. Compliance asks how anybody will audit the decision.
Worse, the tool adds clicks to a process the claims team already hates.
At that point, the model is not even the main problem anymore.
That mess is the job.
The FDE sits with the people who run the systems and the people expected to use the result.
When something breaks, we follow it into the source system or the workflow and fix what is actually in the way. Then we test again with the people who will own it.
This is hands-on work.
We have to understand the tech and the room
The work changes with the client. You could spend one day tracing a broken integration and the next testing model output with someone who knows the process better than you ever will.
Sometimes the technical problem is obvious. Other times everything passes testing and the users still will not touch it.
You have to understand both situations well enough to ask whether the team is solving the right problem.
I have watched highly technical teams spend months building something nobody needed.
An FDE needs the credibility to build and the judgment to ask an uncomfortable question before the team wastes three months.
This job requires technical depth and good judgment.
How I ended up here
I did not come into this from a traditional engineering role.
I spent the last six and a half years in enterprise technical pre-sales at IBM. I gave more demos than I can count, built proofs of concept and helped close more than $25 million in business.
Most days, I was translating what the client needed into what the technology could actually do. When the work moved into production, I would bring in our Client Engineering team.
Many of those engineers are my teammates now.
My strongest lane is the engagement side. I spend a lot of time finding the problem beneath the request, getting the right people in the room and making sure what we build actually gets used.
The building side is something I have sharpened outside of work through my own projects. Now that part is becoming much bigger in my day job.
I did not walk in as the best software engineer in the room, and I will not pretend otherwise.
My advantage is that I can translate between the people building the system and the people who own the business problem.
There is not one resume that qualifies you for this work, and I will write a separate piece about becoming an AI FDE.
If you hate unclear requirements and technical systems that refuse to cooperate, this job will wear you out.
I happen to love that part.
The part I get to stay for
For years, my role often ended right when things got interesting.
I could prove the technology and help a client see the path. Then I would bring in the engineers who could take it into production.
Now I get to stay for the hard part.
I get to see what happens when the clean demo meets the client’s actual environment. I get to work through what breaks and find out whether the thing we built makes anyone’s job better.
People keep asking me what this new title means. The honest answer is that I am still learning the full shape of it.
What I know already is that it puts me closer to the work I have wanted to do for years.
The Army taught me that nobody carries a mission alone. I am already learning the same thing here.
An FDE is only as strong as the pod around them.
That pod deserves more than a quick explanation at the end of this article, so I am giving it the next one.
Volun-told or not, I would have chosen this.
Know somebody who keeps asking what the hell an AI FDE is?
Send them this.
Next up: What Is an FDE Pod, and why would this work fall apart if one person tried to carry it?
Disclosure: I work at IBM as an AI Forward Deployed Engineer. I write here in my personal capacity, and the views are my own. This is my interpretation of the role, not an official IBM publication. The example above is fictional and contains no client-confidential information.