What FDEs need to deliver AI in legacy environments and across different agent systems, while meeting production requirements
Over the last two years, FDEs have been the de facto solution for getting AI into the enterprise. The typical company will be looking for people who are comfortable with the AI tools themselves (Claude Code, Cursor, Codex, GitHub Copilot, etc.). In the big organization, though, the actual problems you’re trying to solve are often very little to do with the tools.
This is precisely why I think the current FDE model is fundamentally flawed. We have around 2,000 FDEs at Altimetrik, so our perspective is based on first-hand experience. Gartner has forecast that 80% of engineers will need to upskill by 2027. For FDEs, the hardest skill to find is an understanding of the enterprise. In our work, we see two distinct gaps. To fix both of these, we need FDES to work in a completely different way.
The first gap is in the systems that the engineer inherits. The AI coding tools work best with modern, well-documented code, and most of the enterprise code that you’re going to come across isn’t like that. An FDE in banking or manufacturing could be looking at a legacy ERP, a COBOL mainframe from the 70s, and a SQL Server 2003 database on some very old infrastructure. The agent can generate code for any of that. In a billing workflow that has an old database, a whole raft of custom apps, and some new cloud services, the real decision you have to make is whether you go the route of modernizing the app, whether you go the route of fixing the data layer, or whether you go the route of putting a safer interface in front of the legacy system. That decision is going to be dictated by the dependencies and the security controls that the tools simply can’t see. That decision is going to be the one that ultimately determines whether anything gets to production.
Research supports this. In a randomized trial of experienced developers working in well-known, mature codebases, they actually took 19% longer using the AI tools (despite thinking they would be faster). Stack Overflow’s 2026 survey found that 48% of developers will trust AI output if they can easily verify it, but only 6.6% will trust it for critical decisions. It’s much harder to verify AI output in legacy systems, so brownfield projects show this issue first.
The second gap is newer and sits above the code. Each of the major platforms (Snowflake, Databricks, Zendesk, Workday, ServiceNow, Salesforce) has its own agents and its own orchestration layers. If you’re using five of them, you end up with five agent runtimes and five different permission models. Someone has to decide which agent can act on a customer record and what happens when two agents disagree. DORA’s 2025 research found that AI increases both speed of delivery and instability. When that instability spans multiple vendor control planes, it becomes part of the architecture, and no single team can see the whole picture.
These two gaps lead to a very straightforward question for 2027: can one engineer really be the master of legacy modernization, several vendor agent systems, and all the AI tools on top? I don’t think so. A delivery model based on finding such a person will keep running into problems.
This is as much a leadership issue as it is an engineering one. The leadership team needs to know who is accountable when an agent acts across multiple systems, and whether there is any mechanism to stop or reverse that action. If every new use case requires an engineer to go and re-build the architecture, the permissions and the governance from the ground up, then you’re going to end up with a collection of disparate projects rather than a genuine AI delivery capability.
So rather than go looking for a better generalist, we’ve changed the operating model for the role. The FDE now has a clear definition of what they are responsible for, the architecture they work within, the agents that do the specialist work, and the controls that determine what actually gets into production.
ALTi AIOS™, our reference architecture for making AI production-ready across both legacy and modern systems, solves the control plane problem. It adds a governed layer on top of the vendor runtimes so that agent identity, policy as code, and audit all work the same regardless of the platform the agent is running on. Security is our starting point, as that’s the first thing that breaks when agents cross system boundaries. It also informs the brownfield decisions we discussed earlier, which would otherwise be up to an FDE to make on their own.
Our AI-Engineering PDLC provides the agents. For each project, we have a dedicated agent for each platform (Databricks, Snowflake, AWS, etc.) to do the QA, architecture, and infrastructure work that the team would have previously done manually. Each agent is given the project’s risk level, and its output is validated before anything else in the process, depending on that level. The FDE manages 10-20 agents, sets the goals, reviews the outcomes, and has sufficient domain knowledge to spot mistakes. The engineer and the client team remain ultimately accountable. Every change can be traced back to the original requirement.
The technology to do all of that is already available, so it’s really more about fear than technical capability. The fear is generally that agents will cause issues in production. That’s a legitimate concern, and the model is designed to address it. Guardrails, governance, risk-based release gates, and people in control are all baked into the architecture from day one rather than being bolted on after the fact.
Waiting has an implicit cost too. Every quarter in a typical company, you’ll see more platforms adding their own agents, each with their own runtime and their own permission model that someone will have to deal with at some point. A company that waits until 2027 is going to face a more difficult version of gap two than one that starts now. 2027 is only about 10 weeks away, so the best time to start was yesterday.
Start with a brownfield workflow that is important to your business. Work out which systems and agents are involved, who can take action, how the output is checked, and who is ultimately accountable if things go wrong. If all of those answers are currently reliant on one engineer knowing all the answers, then that’s the workflow you should look at in terms of updating your operating model first.
Have a look at the ALTi AIOS™ to see how we can help you close both gaps in your organization, starting with that workflow.
Explore how AI leadership can drive shared prosperity through competitive economies, business transformation, workforce development, and trusted AI adoption.
Most organizations can tell you what CVEs they found last quarter. Few can tell you which packages will become a problem next month or which AI skills are running in production without a certified identity. This piece is about closing that gap.
Learn how to govern Agentic AI with human oversight, delegated authority, runtime controls, and accountability to enable secure, responsible enterprise AI.
