Python for AI engineers: what you actually need

Python for AI engineers is a narrow, practical subset of the language: type hints and data classes, environments and packaging, async for calling models and APIs, testing with pytest, and vectorised work in NumPy and Pandas. You do not need metaclasses, descriptors or the whole standard library. You need to write code that someone else can install, read, test and run in production.

Python is the one skill that is core for every AI role, from applied scientist to platform engineer, which is why it sits at the start of the AI engineer roadmap. The question is not whether to learn it but which parts repay the effort.

How much Python do AI engineers need?

AI engineers need enough Python to turn an experiment into a small, dependable program: fluent with functions, classes, modules, exceptions, comprehensions, generators and context managers, and comfortable with the five areas below. That is less than a Python specialist knows and more than most tutorial graduates can do.

Why do type hints matter so much in AI code?

Type hints matter in AI code because the data is unusually loose: dictionaries from JSON, model outputs that may or may not follow the format you asked for, and configuration with dozens of fields. Types make the shape explicit, and a type checker finds the wrong-shape bug in seconds instead of forty minutes into a pipeline.

The habit to build is validating at the boundary. Parse untrusted input, such as a model's JSON reply or a row from a file, into a typed record once, and reject it there if a field is missing. Everything downstream can then trust the record. This is the difference between an LLM feature that fails with a clear error and one that passes None through four functions before crashing.

Use data classes for plain records and a validation library when the input comes from outside your program. Mark records as frozen when they should not change, so that a function cannot quietly alter a config another function depends on.

When should you use async in Python?

Use async in Python when the program spends most of its time waiting on the network, which describes most LLM applications. Calling a model for fifty documents one after another means waiting for fifty responses in a row; async lets those waits overlap. Async does not speed up CPU-heavy work such as tokenising a large corpus or training a model, because only one piece of Python code runs at a time on the event loop.

The example below is typical of the code an AI engineer writes: a typed record, a concurrency limit so the provider is not flooded, and a test.

import asyncio
from dataclasses import dataclass


@dataclass(frozen=True)
class Answer:
    question: str
    text: str


async def ask(question: str, limit: asyncio.Semaphore) -> Answer:
    async with limit:
        await asyncio.sleep(0.1)  # stands in for a network call to a model
        return Answer(question, f"answer to {question}")


async def ask_all(questions: list[str], max_parallel: int = 5) -> list[Answer]:
    limit = asyncio.Semaphore(max_parallel)
    return await asyncio.gather(*(ask(q, limit) for q in questions))


def test_ask_all_keeps_order() -> None:
    answers = asyncio.run(ask_all(["a", "b", "c"]))
    assert [a.question for a in answers] == ["a", "b", "c"]

Three details in that example are the ones interviewers probe. The semaphore caps how many calls run at once, because unlimited concurrency gets you rate-limited. asyncio.gather returns results in the order the tasks were passed in, not the order they finished. And a blocking call inside an async function, such as a synchronous HTTP request or time.sleep, freezes every other task until it returns.

What NumPy and Pandas skills do interviews expect?

Interviews expect you to work on whole arrays and columns instead of looping over rows. In NumPy that means understanding shapes, broadcasting, boolean masks and axis arguments well enough to write cosine similarity or a softmax without a for loop. In Pandas it means joins, group-bys, reshaping, datetime handling and a deliberate approach to missing values.

Know the failure modes as well as the functions:

• Silent broadcasting. Subtracting an array of shape (n,) from one of shape (n, 1) produces an (n, n) matrix, not an error. Check shapes when a result looks wrong.
• Row-by-row apply. Calling a Python function once per row is often orders of magnitude slower than the equivalent column operation.
• Join blow-up. Merging on a key that is not unique multiplies rows. Count rows before and after every merge.
• Unintended copies and views. Know whether an operation changed your data in place or returned a new object, and assign results explicitly.

The same thinking transfers directly to SQL, which is why the two are often tested together; see what SQL interviews test for AI and ML roles.

How do you test code that calls a model?

You test code that calls a model by separating the deterministic parts from the model call and testing them differently. Prompt construction, output parsing, retry logic, chunking and metric calculations are ordinary functions with ordinary unit tests. The model call itself is replaced with a stand-in that returns fixed replies, including malformed ones, so you can prove your code handles them.

Whether the model's answers are any good is a separate question that unit tests cannot settle. That needs a set of example cases and scoring, covered in how to evaluate an LLM application.

For data code, test with small hand-built tables where you can work out the right answer yourself: an empty input, a duplicate key, a missing value. Those three cases catch most pipeline bugs.

What Python can you skip for now?

You can skip most advanced language features until a real problem demands them. Metaclasses, descriptors, custom import hooks, C extensions and deep knowledge of the interpreter rarely appear in AI engineering work or interviews. Web frameworks beyond one API framework, desktop interfaces and scripting niches can also wait.

What you should not skip is the engineering around the language, because that is where service-company and college projects are usually weakest:

Where you go next depends on the role. An AI backend engineer leans hardest on the services stage; an ML engineer on array thinking. For the interview side, coding interviews for AI roles explains how the algorithm round and the practical round differ, and AI portfolio projects shows how to turn these habits into something a reviewer can see.

If you want to know which of these areas is your actual gap, the free readiness check scores you against the role you choose and orders what to study first.