A mid-sized European telecom just posted a vacancy for an AI and ML Engineer. The job description lists many current enterprise AI requirements, but the business objective is unclear. The role asks for the full lifecycle: experimentation, production, MLOps, CI/CD for models, Kafka pipelines, streaming inference, LLM integrations, RAG, agentic workflows with LangChain or LlamaIndex, governance, bias mitigation, and — my favorite — "partner with stakeholders to translate business problems into AI/ML solutions." That requirement suggests the company has not yet defined specific AI use cases. The posting emphasizes AI capability broadly rather than naming concrete products, metrics, or deployment targets.
That makes parts of the role easier to automate, especially boilerplate implementation tasks.
What the job actually is
Stripped of the buzzword density, this is a role focused on converting broad AI ambitions into operational systems. The company sits on operational data — network telemetry, call detail records, OSS fault tickets, CRM churn signals, trouble tickets from field technicians — and wants someone to turn it all into "intelligent systems" that save headcount or prevent outages.
The job breaks down into three main areas visible in the posting:
- Classical ML on tabular data. Churn prediction, demand forecasting, network anomaly detection, ticket routing. This is where the "deploy ML models across business systems" part lives.
- LLM plumbing. Internal support bots, document-grounded Q&A over telecom contracts and runbooks, RAG pipelines hooked into whatever document store they licensed.
- MLOps / Platform engineering. Wrangling Kubernetes, writing Dockerfiles, setting up model registries, CI/CD pipelines, and monitoring for drift.
Now let's look at what an agentic coding and orchestration system does to each of those areas.
Bucket 1: Classical ML tasks can be partly scaffolded by coding agents
The "deploy ML models across business systems" line sounds like hard, grueling, domain-expert work. Some parts are routine, especially when the task is standard tabular prediction. Telecom churn and anomaly detection have many public examples, but production versions depend heavily on local data and business definitions. The actual workflow here is: ingest the data, handle the missing values, encode the categoricals, spin up a gradient-boosted tree or a basic LSTM, evaluate, serialize, and wrap in an API.
A coding agent can generate a first version of this pipeline from a clear schema and task definition. You feed the agent the schema — here are the columns from the CRM, here are the OSS fault events, here is the churn label — and it writes the training pipeline, the feature engineering logic, the API wrapper, and the Docker configuration. For baseline tabular models, telecom-specific knowledge may be less important than clean labels, stable features, and deployment constraints. It knows tabular ML, which is the same whether the rows represent phone customers or shipping containers.
The experimentation phase, the model selection, the hyperparameter tuning — all of that is automated by tools that already exist, and the code to invoke them is generated by the agent. The hardest part of this area was always getting the data into a clean shape, and that job belongs to the Data Engineers the posting mentions. The ML Engineer's job here is to write the glue code between the clean data and the model registry. Much of this glue code can be generated, but it still needs review, testing, and integration with existing systems.
Bucket 2: LLM integration work is often configuration-heavy
The JD calls for "LLM integrations, RAG systems, embedding workflows, and agentic AI automation using frameworks such as LangChain, LlamaIndex, or CrewAI."
Much of basic RAG implementation is configuration and prompt design, though evaluation, permissions, latency, and data freshness can be difficult. A basic RAG prototype involves choosing embeddings, chunking documents, indexing them, and writing retrieval logic. You wrap it in a chain that calls an LLM with a system prompt that says "you are a helpful telecom support assistant." You expose it via API.
A coding agent can be faster at generating boilerplate for this stack than a human starting from documentation, because the agent can draw on common LangChain and LlamaIndex patterns during code generation. The agent writes the retriever, configures the chunking strategy, sets up the evaluation harness, and even drafts the guardrails the posting asks for ("bias mitigation, explainability, transparency"). Some guardrails are implemented as additional model checks, but others involve policy rules, access control, logging, evaluation datasets, and human review. You build the AI, then you build the AI that watches the AI, then you build the AI that watches the watcher. This is one common pattern in agentic AI systems, and many layers contain boilerplate that an agent can generate quickly.
The "prompt libraries" the posting mentions maintaining? Prompt libraries are stored as text, but their value depends on test coverage, versioning, and behavior across real cases. An agent writes them, versions them, A/B tests them against the evaluation datasets, and tunes them while the human engineer is still reading the onboarding documentation.
Bucket 3: Many MLOps tasks already rely on automation
The job asks for "CI/CD for models, versioning, deployment automation, monitoring for model drift." This is the part where the argument is straightforward here, because the entire MLOps industry exists to automate MLOps.
A coding agent can scaffold Kubernetes and Kafka configuration, but a human usually still validates security, networking, scaling, and operational fit. You need a human to type "set up a Kubernetes deployment and a Kafka consumer" into a coding agent that has access to your cloud credentials. The monitoring, the drift detection, the alerting — many monitoring and drift-detection components are available off the shelf, though integration and ownership remain nontrivial, and, again, the agent writes much of the code around them.
The incident-response requirement is underspecified. When an LLM-based system breaks, the incident response is: "the API call failed, we'll retry, or we'll swap the model provider in the config." LLM failures are often hard to debug causally, but teams can still inspect prompts, retrieved context, logs, evaluations, and provider behavior. You adjust the prompt or you may change prompts, retrieval, fallback logic, or provider configuration after reviewing the failure mode.
Where it breaks
There are still parts of the role that are difficult to automate.
Stakeholder discovery is much harder to automate than code generation. The posting says "partner with stakeholders to translate business problems into AI/ML solutions with clear success metrics." That is the line that keeps a human in the seat. The business may not have translated broad goals into measurable ML problems, and the process of extracting a real, falsifiable, measurable problem from a stakeholder who wants "a predictive analytics dashboard" is a social exercise that no agent can perform.
The agent can build the dashboard. The agent cannot sit in a room with a network operations manager who is worried about his headcount and gently steer the conversation toward "actually, what you want is a classifier that flags cell sites likely to fail in the next 48 hours so your technicians can pre-empt them." That translation — human ambition to ML spec — is the real job, and the JD half-admits it by burying it at the bottom after all the technical bullets.
The data quality is the other catch. The posting mentions working with Data Engineers to "define scalable data pipelines and feature engineering logic." Translated: the data is a mess, the schemas are inconsistent, the OSS and CRM systems don't talk to each other, and someone has to figure out whether a "fault" in one system means the same thing as a "fault" in another. An agent can write the ETL, but someone has to decide what the canonical definitions are. Those definitions usually require agreement among domain owners, data teams, and product stakeholders.
Accountability is another reason the role persists. When the churn model is wrong and a high-value customer leaves, or when the LLM support bot tells a customer to do something stupid, someone has to be accountable. The company is not ready to say "our AI system made a bad call" in the post-mortem. They want to say "our AI and ML Engineer is looking into it." The job posting is, in part, also a way to assign operational accountability to a named role.
The verdict
A large share of implementation work in this role is automatable today, and that share will likely grow. Classical ML, basic LLM integration, and standard MLOps all contain repeatable patterns that agents can scaffold. The stakeholder wrangling is the only durable part, and that part isn't really "AI engineering" — it overlaps strongly with technical product management.
The company may be hiring someone to automate parts of the workflow that future hires would otherwise perform. The funny part is that the person who takes this job will, if they're good at it, build exactly the agentic pipelines that reduce the need for parts of their own role. The posting shows how the role may shift from writing individual systems to supervising automated delivery pipelines.
A more realistic version of the role would be to build and govern agents that handle repeatable engineering tasks. Then apply again next year as the "AI and ML Engineer" who manages the fleet of agents that replaced you. The job title may remain, but the work would move toward orchestration, validation, and accountability.
