The elephant in the room?

​@itsmatt You’re not wrong about the shift—but you’re probably overcorrecting on what it means.

What you’re feeling is real: tools like Claude Code and Microsoft Copilot collapse a lot of “glue work” into fast, disposable code. That absolutely eats into the kind of ad-hoc, one-off workflows where FME used to shine. If your mental model of FME is “a faster way to script transformations,” then yes—AI agents are now competing directly with it.

But here’s the part that doesn’t hold up: the idea that this makes FME obsolete or that you’re heading toward irrelevance.

Where your argument is right

• Speed of prototyping has flipped
  AI agents are brutally efficient at “just do it” tasks. Writing Python + pandas + some spatial libs is often faster than assembling a workspace from scratch.
• Barrier to entry is collapsing
  Junior or non-technical users can now automate things that used to require an FME specialist. That will reduce demand for certain kinds of FME work.
• Cognitive shift
  You’re no longer rewarded for solving every small problem manually. That’s a real psychological loss if you used to enjoy that craftsmanship.

Where it breaks down

FME was never only just about speed—it was about reliability, transparency, and operationalization.

AI-generated scripts:

• drift over time
• lack clear lineage
• are hard to audit for now
• break silently in production for now

FME (especially with Flow) gives you:

• visual lineage (huge in enterprise + GIS contexts)
• repeatability and scheduling
• data governance compatibility
• team readability (not everyone reads Python well, even now)

AI is amazing at creating solutions. FME is still very strong at running them safely at scale.

The real shift (this is the important part)

You’re not being replaced—you’re being pushed up the stack.

The old role:

“Build the workflow”

The new role:

“Decide what should exist, validate it, and make it production-safe”

AI can generate 80% of a pipeline. But:

• Who ensures it handles edge cases?
• Who integrates it into existing systems?
• Who owns failures at 3 AM?

That’s still a human with experience—someone like you.

Why FME feels slow now

Because you’re comparing:

• AI → instant, disposable output
  vs
• FME → structured, production-ready workflows

That’s not a fair comparison. It’s like comparing a sketch to a building.

The real risk (and it’s not what you think)

The danger isn’t “FME dies.”

It’s:

You stay in “tool operator mode” while the world moves to “system designer with AI leverage.”

If you only define yourself as “the FME person,” then yes—that niche shrinks.

If you redefine yourself as:

• data workflow architect
• automation strategist
• AI-augmented problem solver

then you’re in a stronger position than most devs, because you already understand data pipelines deeply.

What would actually make us safer (practically)

• Lean into Python—not instead of FME, but alongside it
• Treat AI as your default builder, FME as your production layer
• Get comfortable reviewing and validating AI-generated code (this becomes a core skill)
• Think in systems, not tools

About your “FME agent” idea

You’re absolutely right:

An AI that can operate FME directly would be powerful.

That’s likely where things go:

• AI generating workspaces
• AI debugging them
• AI iterating inside tools like FME Flow

If that happens, FME doesn’t disappear—it becomes a backend execution engine.

Bottom line

You’re not imagining the disruption—but you’re aiming your fear at the wrong target.

AI didn’t just make coding easier.
It made building anything easier.

That doesn’t eliminate experienced people—it raises the bar for what “valuable” work looks like.

If you adapt, your 15 years of experience becomes more valuable, not less.

If you don’t, then yeah—it starts to feel like the walls are closing in.

P.S: I would not claim that these are my two cents! 

Happy FME:-) ing

SRG

​@itsmatt Thanks for putting into writing what I think is on a lot of people’s minds these days. 

I don’t think “FME is the new Cobol” just yet ;-) But I hear your arguments and we’ve had internal discussions in the same vein. It’s an interesting challenge, in particular when presenting FME to potential clients with more technical expertise than budget.

While you can definitely replace some workspaces with vibe-coded software, you’ll still face some very real challenges down the road. And for now I believe the longer the road, the bigger the challenges. Some of my own lessons learned include:

• There’s a real lack of predicitability in how AI handles edge cases (unless you’ve specifically planned for them) and no knowledge about the business aspects which a human developer would often take for granted
• As there is no collective memory of existing processes, AI tends to re-invent the wheel each time, sometimes with subtle and non-trivial changes in behavior. Just something as simple as establishing a parametrized database connection can be deceptively tricky and might be implemented in hundreds of ways. Which one will your AI coding agent use today?
• For getting predictable results and avoiding too much of a mess, you still need the mindset and some experience as a software developer, unless the task is trivial. Blindly trusting the output of AI is a recipe for problems than can be very difficult to resolve. A software developer might know a lot about coding, but do they also have deep domain knowledge about your GIS business workflows? FME empowers those with domain knowledge.
• FME is more than Form, and re-implementing the functionality of Flow using vibe-coded software, for it to run other vibe-coded software components, would still be a massive undertaking with a lot of risk. Yes, there are solutions like Airflow out there, but the barrier of entry is substantial, even with AI as support. Speaking of support, Safe is really in a league of its own.
• Quality testing is critical and time-consuming, and cannot be fully solved using AI-generated unit tests alone.

This is not to say that AI-generated coding does not solve real problems, but for the time being we are a long way away from saying it can fully replace established platforms like FME other than for relatively simple and isolated tasks. And, honestly, acquiring FME for only such use-cases is probably overkill anyway.

Regarding having proper AI skills to author and reason about workspaces, I believe that is something Safe is actively working on, and that would absolutely be a killer feature. I sincerely hope Safe can close this gap as soon as possible.

What I see in the meantime, is that the co-existence of established software like FME and custom scripts is increasingly important. To stave off the vibe coders, I believe FME could quickly gain a lot by improved integration with external workflows, in particular in the Flow ecosystem, already ideal for orchestration. There’s some really simple stuff that could be done to meaningfully improve how the FME platform co-exists with custom scripts, e.g. everything related to the SystemCaller:

In my opinion this is low-hanging fruit that would help proponents of vibe-coding to not see FME as competition, but as complementary.

My colleagues are slowly discovering these tools as well and can do a lot more themselves with AI, soon they wont need an FME guy to automate stuff

I think this is the scary bit tbh.  As they say, you don’t know what you don’t know. I look forward to finding more excel spreadsheets with latitude and longitudes that have been converted from British National Grid via an unknown transformation online. And that’s assuming they’ve got the x & y the right way round in the first place!

I don’t actually have any experience of using AI in FME as the environment i’m currently working in doesn’t have access to AI assist but I’ve been very disappointed with all the questions FME related I’ve asked other AI systems so far.  

How much of the work that you are talking about is spatial? 

• ​@itsmatt , I am quite happy that it will be easier to build pipelines and software, with population getting older, we need more productivity (at a reasonable environmental cost). Of course we will need to adapt. I just followed two software architecture courses and maybe we will end up working in bakeries but that’s life. 
  To complement on ​@david_r   points, my non AI 2 cents on our transition : 
  - If it is easier to build, there will be more pipelines, it does not necessarily mean that less people will be needed.
  - FME abstraction is quite good at forcing us to think modularly, not reinventing the wheel, etc... so we will still be needed to clarify domain experts needs (even without FME). 
  About FME as a platform, the vertical integration, readability etc... help but it is clear that rough times are coming. The speed*trust is still good for a production data process.
  For how long? No clue.
  
    

One of FME's biggest strengths that I don't think AI or coding agents can truly replace is the ability to visually see and understand your entire workflow as you build it. When you're working with complex data transformations, being able to see every connection, every transformer, and every data flow laid out in front of you is invaluable. While some code-based tools do offer pipeline visualization, they rarely match the granular, step-by-step transparency FME provides inside each transformation. With code, understanding what is truly happening within each element still requires developer-level expertise, which creates a significant gap for subject matter experts. And when something breaks in a complex pipeline, troubleshooting becomes exponentially harder without that visibility.

This is especially critical in industries where data accuracy and process integrity matter, like GIS, engineering, utilities, and logistics. A subject matter expert using FME can visually trace exactly where data is coming from, how it is being transformed, and where it is going. That level of transparency is not something you can easily replicate with code, especially AI-generated code that even the developer may not fully understand. Code-based solutions also constantly rely on external libraries, and frequent updates can break your entire pipeline. With FME, updates can occasionally introduce issues, but they are minimal compared to code-based solutions. And if a library becomes deprecated, you may need to rebuild your entire pipeline from the ground up if it was core to your solution.

AI and coding agents are great tools, and they will change how we work, but they do not replace the domain expertise and visual problem-solving that FME specialists bring. Companies also tend to underestimate the real costs of going the full-code route, including:

• Backend infrastructure setup and maintenance
• Developers needed to recreate legacy processes
• Managing integrations across existing and new systems

My longer-term concern is around critical thinking. The more we hand off complex problem-solving to AI, the more we risk losing the experienced human judgment that good data solutions depend on. AI is only as good as the people training it, and if those people stop developing deep expertise, the quality of what AI produces will suffer too.

Context matters enormously in this field. Humans naturally bring external knowledge into their decision-making, things like organizational history, business rules, and real-world constraints that are rarely fully documented. An experienced FME specialist doesn't just build a workflow, they make judgment calls based on years of accumulated knowledge that AI simply doesn't have. AI only knows what you explicitly tell it, and in complex data environments, what you leave out is often just as important as what you include. That gap is where things can quietly go wrong, and in ways that are hard to detect until it's too late.

FME is a platform built around making complex data workflows understandable, auditable, and maintainable. That is what makes it so special.

Matt, thank you for sharing this. There’s a lot of good stuff here but I don’t see any elephants! 😄

Your post is exactly the kind of post that gets us excited. With AI, everything is changing.

You’re absolutely right about programming. It has changed forever. I’ve even “written” code recently, although my assistant actually did it. And to be honest, I don’t always review it. The ground is shifting under all of us, and we all feel it.

We talked about this at Safe during our last all-hands meeting.  We looked at the arc from assembly code to writing every line yourself, to “vibe coding,” to a world where you simply specify outcomes and trust the system.

This isn’t just about coding. It’s happening to every role. I can’t remember the last time I created something entirely from scratch, including this response.

Where you’re spot on is this. AI has completely reset expectations around speed and effort. Once you’ve experienced an agent “just doing it,” anything slower feels slow and broken. That’s real, and we need to respond to it.

Where I think the picture is incomplete is the conclusion that the answer is moving away from FME toward raw coding in python with AI. I sense your frustration as to me it is clear what you really want is to be able to build workspaces for FME using AI.

AI is commoditizing coding. It doesn’t eliminate the need for problem solving, it amplifies it. When I used to code, the hard part was figuring out what to do. The coding was the mechanical part.  Enough time and effort and I could get it working.  Now, with AI knowing what to do is enough. AI can handle the rest.

With AI the value shifts to:

• orchestration
• reliability
• governance
• and most importantly, data

Today you can’t talk about AI without talking about data. And data is messy. It’s fragmented, secured, on-prem, in the cloud, behind APIs, and in formats no LLM has ever seen or can deal with. Some of it you can’t move. Some of it you aren’t allowed to expose. And yet AI wants all of it.

We’ve often described FME as a data pipe or nervous system connecting data to applications.
Now the most important applications are AI.

For me when you say you mainly use FME when it’s going into Flow, that’s actually a really important signal. It tells me that you're already gravitating toward orchestration. 

Here is what I think about what happens next:

• AI commoditizes the creation of FME workspaces
• Agents generate and refine them
• AI driven workflows run on an engine that can reach all your data, wherever it lives
• And that engine runs on-prem or in any cloud

We are actively working on what you described, a “coding agent that can speak FME.” You express intent, and FME artifacts are generated, ready to run or refine.

After all the engine is the product.

Everything else, Form, Flow, even AI, is about:

• generating “code” for the engine
• or exposing the engine through new services like Data Virtualization, and MCP

There is of course no rule that says that code has to be written by a human.

On MCP, we see a huge opportunity. FME is uniquely positioned to act as an MCP server, both on-prem and in the cloud, with the same stack. That means you can expose the right data to AI while keeping sensitive data secure.

I’ll also say this candidly:

FME as we know it today will change. It has to. This is a platform shift.

There will be winners and losers in this AI transition. The winners will be those who fully embrace AI. There is no halfway.

At Safe, we are all-in. Not as an add-on, but as a fundamental shift in how everything is built. Next week is our innovation week. Development stops and everyone focuses on building. AI will be front and center.

Please keep sharing posts like this. Fears, experiments, what’s working and what isn’t. This is exactly the conversation we need and enjoy as a community.

I believe what we’ll discover over the next few years, especially with MCP and agent-driven workflows, is that FME doesn’t disappear in the AI era.

It becomes one of the key ways AI connects to the entire world of data.

Do I feel uncomfortable at times? Absolutely.

But I also feel energized.

This is an incredible time.

I can’t wait to continue the conversation and see everyone in London.  Keep the discussion going. 

Thanks for kicking off this discussion ​@itsmatt! ​@donatsafe shared some more thoughts in this recent blog post: https://fme.safe.com/blog/2026/05/are-ai-coding-agents-replacing-tools-like-fme-lets-talk-about-it/

So I totally agree with these points around why platforms like FME still matter in enterprise environments:

• reliability

• auditability

• maintainability

• visual lineage

• governance

• scheduling/orchestration

• production safety

• debugging visibility

• team readability

• handling edge cases

Those things are massively important and they don’t just disappear because AI can suddenly write code really fast.

Where I somewhat disagree though is around the whole “AI generates 80% and humans validate the rest” thing. I think that really depends on what kind of 80% we’re talking about.

If AI is helping validate ideas, generate testers, SQL, regex, recommendations, troubleshoot stuff, suggest approaches etc then honestly that’s awesome. Human prompt -> inspect -> test -> refine. Massive productivity boost there.

But when it comes to really large complex production workflows, I’m not fully convinced that “AI builds it and humans inspect it” is always the better path.

Think about it this way... reviewing and understanding someone else’s huge workspace already takes a considerable amount of time. Understanding why it was done a certain way, testing assumptions, tracing logic, validating outputs etc. Sometimes for more complex stuff it’s actually more constructive and faster to build it the way you know how because you understand the intent and design decisions as you go.

And I still think even as AI improves, it’ll continue to struggle on the genuinely hard/complex tasks for quite a while. Humans are still better at making judgement calls, understanding context, spotting weird edge cases, and using AI almost like a sounding board to speed up problem solving. Could that eventually change? Maybe. But we’re definitely not there yet.

So for me the ideal world is still humans in the loop as the masters/chiefs, leveraging AI where it makes sense, staying in control, and producing robust deterministic processes that can actually be audited, understood, maintained, and trusted by organisations.

The other thing I worry about a bit is accidentally heading backwards.

Right now it’s great creating little mini tools and scripts with AI. But imagine a future where organisations end up with thousands of disconnected AI-generated scripts and automations, created by people who have long since left, all doing slightly different things with no consistency, governance, ownership, or visibility.

That starts looking a lot like the old data-silo world again... except now it’s AI scripting silos.

It actually reminds me a bit of the old “one system that can do it all” promise years ago. Big enterprise platforms came in replacing separate CRM systems, asset systems, mapping systems etc with the idea everything would live in one perfect ecosystem... and then over time a lot of organisations slowly drifted back toward specialised systems connected together because that reality worked better in practice.

In my mind AI feels a little bit like that right now.

We already have a really good structure:
FME acting as robust middleware, securely and safely connecting systems together, orchestrating processes, handling governance, visibility, reliability etc.

To me AI feels more like an extension and enhancement to that already great thing, rather than a replacement for the entire structure underneath it.

That’s my 2 cents at the moment anyway 😄

By the way, great idea having this kind of focus group/discussion!! Really interesting reading everyone’s thoughts on this because I think a lot of people are quietly thinking the same things right now.