What AI Skills Do Engineers Need Now?

Every engineering leader in financial services is now asking some version of the same question.

Engineers have always needed to learn new languages, frameworks and platforms. AI is different in scale and consequence: AI-assisted coding tools are appearing inside everyday development workflows, models are being embedded directly into trading, settlement and reconciliation pipelines, and regulators are increasingly interested in how those systems are built, tested and governed.

Strong traditional software engineering skill remains essential. But it is no longer sufficient on its own.

Before an organisation can train, assess or hire effectively, it needs a clear picture of which AI skills its engineers actually need — and which ones can wait.

Why engineering skill requirements are changing

AI is entering financial services engineering teams from three directions at once.

First, AI-assisted coding tools are changing how software gets written day to day, from autocomplete-style suggestions to tools that can generate entire functions or test suites.

Second, models are being embedded directly into operational systems — flagging anomalies in trade reconciliation, supporting pricing decisions, or monitoring settlement flows.

Third, data pipelines feeding these systems now carry new requirements around volume, quality and monitoring that traditional ETL practices were not originally designed for.

Each of these changes what "good engineering" looks like. An engineer who writes clean, well-tested code but has no understanding of how a model behaves, or why its output might drift over time, is now operating with an incomplete skill set — not because their core engineering ability is lacking, but because the systems they are building have new failure modes.

This is a genuine skills gap, not a marketing narrative. Financial services firms are increasingly expected — by regulators, auditors and their own risk functions — to demonstrate that the people building AI-enabled systems understand what they are building.

How engineering teams traditionally built technical capability

Engineering teams have long-established methods for building technical capability, and most of them remain valuable.

Structured onboarding introduces new starters to internal systems, coding standards and architecture. Certifications validate competence in specific languages, platforms or cloud environments. Mentorship and pairing transfer tacit knowledge that is hard to document. Code review culture catches errors and spreads good practice across a team.

These approaches work well for stable, well-understood technical domains where the underlying concepts change slowly and correctness can be clearly defined.

AI-related skills sit less comfortably within this model. Model behaviour is often probabilistic rather than deterministic, meaning traditional testing and review practices need adaptation. Tooling changes quickly, so certifications can go stale within a year. And some of the most important skills — recognising when a model's output should not be trusted, for example — are harder to teach through code review alone.

Traditional training approaches remain the foundation. They are just no longer the whole answer.

Where AI changes what engineers need to learn

Across financial services engineering teams, the AI-related skills gap tends to fall into four categories.

AI-assisted development. This covers the practical skill of working effectively with AI coding assistants — knowing when their suggestions are reliable, how to review AI-generated code with the same rigour as human-written code, and how to avoid over-reliance on tools that can confidently produce incorrect output. Every engineer using these tools needs this skill, regardless of seniority.

Model and system literacy. This is the ability to understand, at a working level, how a model or AI system behaves: what its inputs and outputs mean, what a confidence score does and does not tell you, how performance can degrade over time (model drift), and what monitoring is needed once a system is live. This does not require the mathematical depth of a data scientist, but it does require more than treating a model as a black-box API.

Data and pipeline engineering for AI. AI systems are only as reliable as the data feeding them. Engineers need practices suited to AI workloads specifically — validating data quality at scale, designing pipelines that can detect and flag anomalies before they reach a model, and building in the traceability needed to explain why a model produced a particular output.

Risk and compliance awareness. Engineers working on regulated systems need enough understanding of relevant governance expectations — model documentation, explainability requirements, escalation paths for uncertain outputs — to build systems that pass internal and external review, without needing to become compliance specialists themselves.

Not every engineer needs equal depth in all four areas. A generalist engineer integrating a third-party AI tool needs solid baseline literacy across all four categories. A specialist AI/ML engineer building or training models in-house needs significantly greater depth in model literacy and data engineering specifically. The distinction matters: treating every engineer as though they need specialist-level ML skill wastes training investment and slows delivery.

Practical considerations for building these skills

Organisations building an engineering AI skills framework face several practical decisions.

The first is prioritisation. Not all four skill categories need to be built at once, and not all engineers need the same depth. A sensible starting point is baseline literacy across all four categories for every engineer touching AI-enabled systems, with deeper specialist training reserved for those working directly on model development or high-risk integrations.

The second is role-based skill depth. Job families should map to skill depth explicitly — a platform engineer integrating a vendor tool has different needs from a data engineer building the pipeline feeding a proprietary model.

The third is pace of change. Because AI tooling and practice evolve quickly, a skills framework should be treated as a living document, reviewed on a regular cycle rather than set once and left.

The fourth is governance integration. Risk and compliance awareness should not be bolted on as a separate module — it works best when embedded alongside technical training, so engineers learn governance expectations in the context of the systems they are actually building.

Example

A London-based clearing operations technology team introduces an AI-assisted reconciliation tool to flag mismatches between trade records ahead of settlement through the LCH.

The platform engineer integrating the tool needs more than knowledge of how to call its API. They need to understand how the model was trained, what its confidence scores mean, how to monitor for drift once it is live, and what documentation the risk and compliance officer will need to complete internal review before go-live.

Because the engineering team had been trained across all four skill categories — not just tool integration — they identified a data quality issue feeding the model, documented its limitations for the compliance review, and set up ongoing monitoring before go-live, avoiding a delayed or blocked rollout.

FAQs

• Do all engineers need to become AI or machine learning specialists?

  No. Every engineer working with AI-enabled systems needs baseline literacy across AI-assisted development, model behaviour, data pipelines and risk awareness. Deeper specialist skill in building or training models is only needed by dedicated AI/ML engineers, not the wider engineering population.

• How is this different from general AI literacy training given to the wider workforce?

  General workforce AI literacy focuses on awareness — what AI is, where it is used and basic risks. Engineers need additional technical depth, including how models behave, how to build and monitor data pipelines suited to AI workloads, and how to integrate systems responsibly within a regulated environment.

• How often should an engineering AI skills framework be updated?

  Because AI tooling and practice change quickly, the framework should be reviewed regularly, for example every six to twelve months, rather than treated as a fixed curriculum set once and left unchanged.