You Don’t Need to Build the Engine to Drive the Car
AI work is starting to separate model-building from the skills needed to navigate models through real business processes — much as driving separated from car repair.
A century ago, a driver often had to understand the engine. Today, the driver needs to understand the road. AI may be going through the same transition.
In the early automobile era, the line between driver and mechanic was surprisingly thin. Wealthy owners often employed chauffeur-mechanics. Owner-drivers were encouraged to carry tools, learn common faults and repair their cars when infrastructure failed them.
That was not because driving and mechanical engineering were naturally the same profession. It was because the technology and the service ecosystem around it were still immature.
Then the split happened.
Cars became more reliable. Repair shops professionalised. Roads, petrol stations and service networks expanded. Driving became its own skill: understanding traffic, choosing a route, reacting to conditions, following rules and reaching a destination safely.
AI may now be approaching the same separation.
When working in AI meant building the engine
For decades, serious AI work largely meant machine learning.
The educational path reflected that:
- linear algebra and statistics;
- regression and classification;
- gradient descent and optimisation;
- neural networks and backpropagation;
- model training and hyperparameter tuning;
- TensorFlow, PyTorch and the surrounding ML stack.
These skills remain essential for people who build, train, fine-tune and optimise models.
They are the engine specialists.
But foundation models have changed the point at which many companies enter the AI stack. An organisation can now start with a capable model available through an API rather than with a dataset and a training cluster.
The first question is no longer always:
How do we build the model?
Increasingly it is:
How do we get this model through a real business process and arrive at a useful outcome?
That is a different engineering problem.
The hard part moves from the engine to the road
Imagine an AI agent handling a customer request, validating a change, preparing a quotation or investigating an incident.
The model may already exist.
The difficult questions begin afterwards:
- What information is the agent allowed to see?
- Which tools and APIs may it use?
- Which business rules constrain its choices?
- What state must persist between steps?
- When must a human approve an action?
- How is output evaluated?
- What happens when the model is uncertain or wrong?
- Which actions are reversible?
- How do we reconstruct what happened later?
- How much latency and cost can the process tolerate?
Modern agent architectures increasingly treat models, tools, instructions, orchestration and guardrails as separate components. OpenAI’s agent guidance, for example, describes agents as systems in which the model manages workflow execution while tools connect it to external systems and guardrails constrain behaviour. Anthropic similarly distinguishes predefined workflows from agents that dynamically direct their own tool use.
None of this makes machine learning irrelevant.
It changes where expertise creates value.
A driver is not an inferior mechanic
The analogy can easily be misunderstood.
A modern driver knows less about rebuilding an engine than a mechanic does. But that does not make driving a trivial skill.
The driver operates in a different problem space.
A good driver understands the destination, the road, traffic, risk, rules, timing and the capabilities of the vehicle. They know when to slow down, when to change route and when the car needs a specialist rather than another attempt at driving.
The same distinction is emerging around AI.
An ML engineer may need deep knowledge of model architecture, training, inference and optimisation.
An AI engineer working with existing models may need deeper knowledge of APIs, context, RAG, tool use, evaluation, integration, observability and security.
An AI or process architect may need to understand something else again: where AI belongs in a workflow, what authority it should receive, where deterministic controls remain necessary, how humans intervene and what evidence is required before an action becomes acceptable.
These roles overlap. They do not collapse into one role.
The enterprise needs route knowledge
This distinction becomes particularly important in enterprise AI.
Suppose the task is to improve incident handling.
Training a better language model may not be the bottleneck.
The bottleneck may be deciding which incidents an agent can resolve, which systems it can query, whether it may execute a remediation step, how it validates the result, when it escalates and how the whole sequence is audited.
Or consider procurement.
The difficult part may not be generating text. It may be connecting policy, supplier data, approval thresholds, ERP actions, exceptions and human accountability into one controlled route.
In these situations, knowing how a transformer is trained is useful background.
Knowing how work actually moves through the organisation may be more important to the outcome.
That is why process knowledge, integration architecture, IAM, state management, governance and evaluation are becoming first-class AI skills.
We may be teaching the wrong abstraction
Machine learning education is not becoming obsolete.
Mechanics did not become obsolete when cars became easier to drive.
What disappeared was the assumption that every competent driver also had to be capable of repairing the engine.
AI education and hiring still sometimes carry that assumption. Roles focused mainly on using existing models in products and processes can still be described as if training models were the centre of the job.
For some positions, that is exactly right.
For others, it is like asking a logistics driver to explain combustion timing before discussing whether they can get a shipment across Europe reliably.
The better question is not whether everyone in AI needs machine-learning knowledge.
They do need enough to understand the capabilities and limits of the technology they are using.
The better question is how deep that knowledge must go for the job that actually needs to be done.
The emerging split
A useful way to think about the stack is:
ML Engineer → builds and improves the engine.
AI Engineer → connects the engine to tools, data and operational systems.
AI / Process Architect → chooses the route, defines the rules of the road and designs how AI reaches a business outcome.
The boundaries will remain fuzzy. Some people will work across all three layers. New technology may move them again.
But the direction matters.
As foundation models become infrastructure, competitive advantage moves upward. It comes increasingly from selecting the right model, giving it the right context and tools, putting it inside the right workflow, constraining it appropriately and measuring whether it actually produces value.
That is not merely “using AI”.
It is a distinct engineering discipline.
The Market Signal
A century ago, driving and automotive mechanics separated as the technology matured.
AI appears to be beginning a similar transition.
The people building the underlying models will remain essential. But a much larger group of professionals may work one layer above them: navigating models through organisations, processes and decisions.
For those people, the central question will not be:
Can you build the engine?
It will be:
Can you drive the technology through a complex organisation, choose the right route, stay within the rules — and actually reach the destination?
That is a different profession.
And we should probably start teaching and hiring for it as one.