7 Python Topics You Still Need To Understand (Even If AI Writes The Code)

AI writes most of the code now. I still think you need to understand what’s happening under it, and that comes down to seven Python topics. Not exotic ones. The boring stuff that shows up in every real pipeline.

Exception handling and logging

Things break. APIs time out, files are missing, a column that used to be an integer suddenly isn’t. You need to catch that, and you need to log it somewhere, a file, a database, CloudWatch, whatever you’re using.

Without this, a pipeline just fails silently at 3am and you find out from an angry Slack message the next morning.

And it’s not just about catching the error, it’s about catching the right error.

Wrapping an entire script in one giant try/except that swallows everything is a common shortcut, and it’s a bad one, because now the pipeline looks “fine” while it’s quietly skipping half the data. That’s worse than no error handling at all, because now you trust a number that’s wrong.

Catch specific exceptions, log what actually happened, and let the things you didn’t expect actually blow up so you notice them.

Datetime

Timestamps are everywhere, and they cause more bugs than people expect. Timezones, daylight saving, string formats that look identical but parse completely differently.

I’ve seen a pipeline break because one system logged UTC and another logged local time, and nobody noticed until a report was off by an hour.

Get comfortable with datetime early, it saves you a debugging session later.

The annoying part is that these bugs almost never show up in testing. Everything works fine for months, and then daylight saving flips or a partner system switches formats, and suddenly a join that used to match perfectly is off by an hour and nobody can figure out why.

Store everything in UTC internally and only convert to local time at the very last step, right before it’s shown to a human. That one habit alone prevents most of these headaches.

JSON and JSON validation

Every API you touch speaks JSON. You send it, you receive it, and a lot of the data lying around in data lakes is JSON too.

The part people skip is validation. You get a payload, you assume the structure is what you expect, and then one day a field is missing and your whole job crashes downstream.

Tools like Pydantic will validate the shape of your JSON before it causes damage further down the pipeline.

Think about it this way, an upstream team changes an API without telling you, a field that used to always be there is suddenly optional, and your pipeline has no idea until it explodes three transformations later.

Validating at the point where data enters your system means you find out immediately, with a clear error, instead of hunting through five steps of transformations trying to figure out where a null crept in.

Unit testing

Whenever you write a transformation, you need to know if it actually does what you think it does. That’s unit testing.

The cool thing is, AI is genuinely good at writing these for you now, give it your function and it’ll spit out reasonable test cases in seconds. But you still need to understand what a good test actually checks, otherwise you’re just approving whatever the AI wrote without knowing if it’s testing the right thing.

I’ll be honest, this is the one that gets skipped the most, even by people who know better. It feels like it slows you down when you’re trying to ship something. But the one time a transformation silently drops rows on an edge case nobody thought of, a test would’ve caught it before it ever touched production.

It’s cheaper to write the test now than to explain to your manager why last week’s numbers were wrong.

Pandas

The big one. You need to work with dataframes, understand how to merge them, how to pivot them, how to group and aggregate.

I still see people trying to loop through rows manually instead of using vectorized operations, and it’s painfully slow on anything beyond a few thousand rows.

Pandas is one of those libraries where learning it properly once saves you from writing bad code for years.

Actually nowadays a lot of people also use DuckDB in python instead for quick transformations. Take the dataframe, write it into a duckdb database. DuckDB is basically just an imported library (If you don’t add a storage location then everything happens in memory.), do the transformation with SQL and then export the data again.

The requests library

Sending a request to an API sounds trivial until you’re doing it in production. Retries, timeouts, rate limits, handling a 429 response gracefully instead of just crashing.

The requests library is simple to start with, but there’s a real difference between a script that works once on your laptop and one that survives an API having a bad day.

That difference is basically invisible until the day it matters. Your script works perfectly in every test you run, and then it goes into production, the API has a rough afternoon, and your job either crashes completely or hammers the API with retries and gets you rate limited or blocked.

Adding exponential backoff and proper timeout handling takes maybe ten extra lines of code. It’s a small investment that separates a script from an actual production job.

Working with databases

Even a simple database setup, tables, SQL, and especially bulk loading. This is the one people underestimate the most.

Inserting rows one at a time works fine for a demo and falls apart completely once you’re loading real volumes of data. Bulk loading, whether that’s a COPY command in Postgres or a bulk insert method, is often the difference between a job that finishes in seconds and one that times out.

A pipeline that works great on a sample of a thousand rows can go live on the real dataset and just never finish, and by then it’s too late to fix it quietly. Nobody tells you this in school, but the way you load data matters just as much as the SQL you write to query it afterward.

Why this still matters in the AI era

I know the argument, AI writes the code, so why learn the fundamentals.

Here’s the thing: when the AI-generated code breaks, and it will, you’re the one who has to read it, understand it, and fix it. You can’t debug what you don’t understand.

These seven topics are what let you actually own the code AI hands you, instead of just hoping it works.

In my Python for Data Engineers course, we’re covering all seven of these hands-on. It is available in my Free Labs Bundle until end of August.

In the bundle you’ll also find a Databricks course, Kestra for orchestration, DuckDB, Docker fundamentals, and more! Get the bundle here.

Which of these seven do you think most people skip first?

***

Ready to become a Data Engineer? Then join my Learn Data Engineering Academy today!

Looking for free hands-on projects and tutorials? Then check out my Free Labs.

More Data Engineering content on: YouTube | LinkedIn | Spotify