Python Beyond the Hype today: AI, Backends, Data, and the Reality of Building Systems That Last

[0:00]Kunjan: Welcome back to the Python stack podcast. This is episode three, and today we are still talking about Python, but we are taking a slightly different route. We are not doing a beginner introduction. We are not doing a simple list of Python features. We are not doing the usual argument about whether Python is fast enough, whether the GIL is gone, or whether AI will make developers irrelevant.

[0:45]Kunjan: Today we are talking about Python beyond the hype. Because today, Python does not need hype to prove that it matters. It already matters. It matters in AI labs, startups, banks, universities, logistics companies, hospitals, media platforms, developer tools, cloud automation, cybersecurity teams, and data organizations. Python has moved far beyond the question of whether it is useful.

[1:35]Kunjan: The better question is this: if Python is now so useful that companies quietly build important systems with it, how do we stop treating those systems like temporary scripts?

[2:10]Kunjan: Because that is where Python becomes interesting. It starts as a convenience. It becomes a workflow. Then it becomes a dependency. Then it becomes infrastructure. And sometimes, by the time a company realizes Python is carrying real business weight, the original code was written by someone who thought they were just solving a small problem for Friday afternoon.

[3:00]Kunjan: So this episode is about the grown-up version of Python. The version where readability still matters, speed still matters, simplicity still matters, but now we also care about deployability, observability, testing, security, dependency risk, runtime upgrades, AI evaluation, data quality, and long-term ownership.

[3:30]Kunjan: To help us unpack that, I am joined by Elena Kovacs, principal software engineer and Python systems architect at HelioStack Technologies. Elena has worked on Python backends, AI platforms, data pipelines, automation systems, and developer infrastructure. Elena, welcome.

[3:58]Elena Kovacs: Thanks for having me. I like the framing because Python conversations often swing between two extremes. One side says Python is easy and can do everything. The other side says Python is slow and messy and should be replaced. Both sides miss the practical truth.

[4:35]Kunjan: What is the practical truth?

[4:40]Elena Kovacs: The practical truth is that Python is one of the best languages in the world for turning ideas into working systems, but it does not automatically turn working systems into reliable systems. That second step is engineering. Python helps you start. It does not remove the need to finish properly.

[5:25]Kunjan: That is a good distinction. Python helps you start, but it does not finish the job for you.

[5:34]Elena Kovacs: Exactly. Python is generous. It lets a data scientist automate a workflow. It lets a backend engineer expose an API quickly. It lets an infrastructure engineer script cloud tasks. It lets a product team prototype an AI feature. But because it is so generous, it also lets weak engineering habits survive for too long.

[6:20]Kunjan: So the danger is not that Python is bad. The danger is that Python makes the first version feel complete.

[6:30]Elena Kovacs: Yes. Python can make the first version feel deceptively finished. The code runs. The demo works. The data loads. The model responds. The API returns JSON. But production asks harsher questions. What happens when the data is malformed? What happens when the model times out? What happens when a dependency changes? What happens when five teams rely on this script? What happens when the original author leaves?

[7:00]Kunjan: Let us talk about Python’s identity today. People call it a beginner language, an AI language, a data language, a scripting language, a backend language. What is it really?

[7:18]Elena Kovacs: It is all of those, but the best description is probably bridge language. Python bridges disciplines. It connects research and production. It connects data and applications. It connects cloud infrastructure and business logic. It connects AI models and user-facing products. It connects people who might not otherwise work in the same technical layer.

[8:05]Kunjan: Bridge language is interesting because it explains why Python keeps staying relevant.

[8:12]Elena Kovacs: Yes. Python survives because it is useful at boundaries. Whenever one system needs to talk to another system, Python is often there. Whenever a team needs to glue together an API, a database, a model, a file format, and a dashboard, Python is often there. Whenever a company needs to move from experimentation to automation, Python is often there.

[9:00]Kunjan: That also means Python code often sits in places that are hard to classify.

[9:08]Elena Kovacs: Exactly. Is it backend? Is it data engineering? Is it machine learning? Is it platform tooling? Is it DevOps? Is it analytics? Sometimes the answer is yes. That is powerful, but it also creates ownership problems. If nobody knows what category the system belongs to, nobody knows who should maintain it.

[10:00]Kunjan: So one of the first production lessons is ownership.

[10:06]Elena Kovacs: Ownership is huge. Every important Python system needs an owner. Not necessarily one person forever, but a team, a process, a place in the architecture. If a script affects customers, money, compliance, reports, deployments, billing, security, or model behavior, it is not just a script anymore. It is part of the system.

[11:00]Kunjan: That sounds simple, but it is probably where many companies fail.

[11:06]Elena Kovacs: They fail because the first version works. And when something works, people avoid touching it. Then the little working thing becomes important, and suddenly nobody wants to refactor it because it is too risky. That is how temporary Python becomes permanent Python.

[11:30]Kunjan: Now let us talk about the runtime. Python 3.14 is a major release. Free-threaded Python is officially supported, Python 3.13 introduced experimental free-threaded CPython and an experimental JIT, and the runtime direction feels more ambitious than it did years ago. How should teams interpret this?

[12:00]Elena Kovacs: They should interpret it as a serious signal that CPython is evolving. For a long time, people talked about Python as if the runtime was fixed forever: readable, productive, but limited. Now the story is changing. Free-threading, JIT work, multiple interpreters, better error messages, and language improvements show that Python is not standing still.

[12:50]Kunjan: But you would probably warn teams not to overreact.

[12:56]Elena Kovacs: Definitely. Free-threaded Python is important, but it is not a magic upgrade button. It changes what is possible. It does not automatically make every existing application faster. If your application is waiting on a database, free-threading may not help much. If your bottleneck is network latency, it may not help much. If your hot path already runs inside optimized native libraries, the result may be different from what you expect.

[13:55]Kunjan: So teams still need profiling.

[14:00]Elena Kovacs: Always. The first rule of performance is to measure. The second rule is to measure the real workload, not a toy benchmark that flatters your favorite conclusion. A production team should test Python upgrades against real traffic patterns, real data volumes, real dependencies, and real deployment environments.

[14:55]Kunjan: What would a responsible Python 3.14 adoption plan look like?

[15:05]Elena Kovacs: Start with inventory. Which Python versions are running in production, CI, notebooks, containers, local developer machines, serverless functions, workers, and scheduled jobs? Then check library compatibility. Then run tests. Then run staging workloads. Then compare latency, throughput, memory usage, error rates, startup time, and operational behavior. Upgrade like an engineer, not like a fan.

[16:05]Kunjan: Upgrade like an engineer, not like a fan. That is good.

[16:12]Elena Kovacs: It matters. New features are exciting, but production systems need evidence. If free-threaded Python helps your workload, great. If the JIT helps your workload, great. If neither changes your actual bottleneck, that is also useful information. The point is not to win an argument online. The point is to build better systems.

[17:30]Kunjan: Let us be honest about where Python shines and where it does not. Where is Python genuinely excellent?

[17:45]Elena Kovacs: Python is excellent at orchestration, automation, data workflows, AI and machine learning, API development, internal tools, scripting, testing tools, infrastructure glue, command-line tools, and systems where developer speed matters. It is also excellent when the heavy work is delegated to optimized libraries, databases, cloud systems, or specialized services.

[18:40]Kunjan: And where should teams be careful?

[18:45]Elena Kovacs: Be careful with CPU-heavy pure Python loops, extremely low-latency systems, memory-heavy workloads, high-concurrency services with blocking libraries, and systems where startup time or deployment size is critical. Python can still be used in many of those places, but you need architecture. You might use multiprocessing, native extensions, vectorized libraries, Rust modules, queues, or separate services.

[19:50]Kunjan: So the mature answer is not Python for everything.

[19:56]Elena Kovacs: Correct. The mature answer is Python where Python creates leverage. Sometimes Python should be the main application language. Sometimes it should be the orchestration layer. Sometimes it should be the experimentation environment. Sometimes the hot path should be elsewhere. Good teams do not turn language choice into identity.

[20:55]Kunjan: That is hard because teams like having one stack.

[21:00]Elena Kovacs: One stack can reduce cognitive load, but one stack should not become one hammer. Python can be your default without being your only tool. A Python team can still use SQL well, use Rust for a performance-critical extension, use Java or Go for a certain service, use C++ behind a machine learning library, or use cloud-native tools where they fit.

[22:00]Kunjan: So the question is not whether Python can do something. The question is whether Python is the right place for that thing.

[22:08]Elena Kovacs: Exactly. Python can do a lot. That does not mean every job belongs inside one Python process.

[22:30]Kunjan: Let us move to modern tooling. A lot has changed in Python project setup. Teams are using pyproject.toml, lockfiles, uv, Ruff, type checkers, and cleaner workflows. What is the big picture?

[22:55]Elena Kovacs: The big picture is that Python tooling is becoming faster and more consolidated. For years, Python project setup could feel fragmented. You had one tool for environments, one for dependency locking, one for packaging, one for formatting, one for linting, one for imports, one for upgrades, and every team had a different recipe. Modern tools are reducing that friction.

[23:55]Kunjan: Where does uv fit?

[24:00]Elena Kovacs: uv is part of the new wave of Python tooling focused on speed and simplicity. It can manage projects, dependencies, environments, lockfiles, Python versions, and command execution. The important thing is not only that it is fast. It is that fast tooling changes developer behavior. People run tools more often when they are not painful.

[24:55]Kunjan: That is true. Slow tooling creates avoidance.

[25:00]Elena Kovacs: Exactly. If dependency installation is slow, developers avoid rebuilding environments. If linting is slow, they wait for CI. If tests are awkward, they skip them locally. If onboarding takes two days, the team accepts tribal knowledge as normal. Good tooling makes good behavior cheap.

[25:55]Kunjan: And Ruff?

[26:00]Elena Kovacs: Ruff matters because it gives Python teams a fast linter and formatter in one ecosystem. It can replace a lot of older tool combinations for many projects. That means fewer moving parts, faster feedback, and less debate about style. The less time a team spends arguing about formatting, the more time it can spend arguing about architecture, which is usually the better argument.

[27:00]Kunjan: So what should every serious Python repository have?

[27:08]Elena Kovacs: A clear pyproject.toml. A reproducible dependency workflow. A lockfile strategy. A formatter. A linter. A test command. A type-checking decision, even if the decision is gradual typing. A local development guide. A CI pipeline that runs the same checks developers run locally. And a clear answer to how the application is started, configured, tested, built, and deployed.

[28:00]Kunjan: Now Python backends. We have Django, FastAPI, Flask, async frameworks, workers, queues, and plenty of patterns. What does good backend Python look like today?

[28:20]Elena Kovacs: Good backend Python starts with choosing the right abstraction level. Django is strong when you need a full product framework: ORM, admin, migrations, auth patterns, security defaults, and a mature ecosystem. FastAPI is strong for typed APIs, OpenAPI generation, service boundaries, and async-friendly API work. Flask is still useful for lightweight services where flexibility matters.

[29:25]Kunjan: So it is not Django versus FastAPI as a religious war.

[29:30]Elena Kovacs: No. That argument wastes time. The question is product shape. Are you building an admin-heavy business application? Django may be the pragmatic answer. Are you building an internal model-serving API? FastAPI may feel natural. Are you building a small webhook receiver? Flask or another minimal setup may be enough. Choose for the system, not for social media.

[30:30]Kunjan: What mistakes do Python backend teams repeat?

[30:38]Elena Kovacs: They put business logic directly in route handlers. They do database calls everywhere. They do not define transaction boundaries. They forget timeouts. They retry non-idempotent operations. They mix configuration with logic. They use global state casually. They do not separate domain logic from IO. And they treat background jobs as an afterthought.

[31:45]Kunjan: Background jobs are a big one.

[31:50]Elena Kovacs: Huge. A background job is not a trash bin for slow work. It is part of the system. It needs retries, idempotency, visibility, dead-letter handling, timeout rules, concurrency limits, and monitoring. If a job fails silently for three days, that is not a background job. That is a hidden incident.

[32:50]Kunjan: What about async Python?

[32:55]Elena Kovacs: Async is useful, but only when the workload matches it. If you are waiting on many network calls, database calls, storage operations, or APIs, async can help. But async does not make CPU-heavy Python code faster. And async mixed with blocking libraries can create a service that looks modern but behaves badly under load.

[33:45]Kunjan: So async is not a badge of seriousness.

[33:50]Elena Kovacs: Exactly. Seriousness is knowing your concurrency model. Threads, async, processes, workers, queues, and external services all exist for different reasons. Use the one that matches the bottleneck.

[34:00]Kunjan: Let us move to AI. Python is everywhere in AI right now. LLM apps, RAG systems, agents, evaluation frameworks, model serving, data preparation. What are teams getting right and wrong?

[34:25]Elena Kovacs: Teams are getting the speed of experimentation right. Python is fantastic for trying ideas. You can call a model API, load documents, build embeddings, query a vector database, test prompts, and create a demo quickly. That is real value. The mistake is treating the demo as if it proves the production system.

[35:20]Kunjan: The demo proves possibility, not reliability.

[35:25]Elena Kovacs: Exactly. AI demos often show the best path. Production is mostly about the worst paths. What happens when the model gives a malformed answer? What happens when retrieval returns weak context? What happens when the user asks something adversarial? What happens when the model provider is slow? What happens when cost doubles? What happens when a prompt change quietly reduces quality?

[36:30]Kunjan: So AI Python systems need a different kind of testing.

[36:36]Elena Kovacs: They need traditional tests and evaluation. Unit tests still matter. Integration tests still matter. But you also need golden datasets, regression examples, output checks, quality metrics, safety checks, latency budgets, cost budgets, and human review loops where needed. You need to know whether the system is still useful, not only whether the code still runs.

[37:40]Kunjan: What about RAG systems?

[37:45]Elena Kovacs: RAG systems are often treated like a simple recipe: chunk documents, embed them, retrieve chunks, send to model. But production RAG is full of decisions. Chunking strategy matters. Metadata matters. Freshness matters. Permissions matter. Retrieval quality matters. Ranking matters. Evaluation matters. Observability matters. If the answer is wrong, you need to know whether retrieval failed, generation failed, permissions failed, or the source data was bad.

[38:55]Kunjan: That is a lot deeper than a tutorial.

[39:00]Elena Kovacs: Tutorials are useful for learning concepts. They are not architecture. A production AI system is a software system with probabilistic parts. The Python code around the model needs to be even more disciplined because the model itself is less predictable than ordinary code.

[40:00]Kunjan: Now data engineering and notebooks. Python dominates notebooks, but notebooks are controversial in production. What is the balanced view?

[40:15]Elena Kovacs: The balanced view is that notebooks are excellent for thinking and poor as invisible production systems. They are great for exploration, visualization, analysis, teaching, and communicating results. But notebooks can hide state. Cells can run out of order. Outputs can become stale. Secrets can leak into cells. Dependencies can be unclear. That is fine for exploration, but risky for repeatable operations.

[41:20]Kunjan: So when does notebook code need to graduate?

[41:25]Elena Kovacs: When other people rely on it. When it feeds a dashboard. When it affects a model. When it changes customer data. When it informs financial decisions. When it runs on a schedule. When it has to be repeated. At that point, extract the logic into modules, add tests, validate inputs, version dependencies, and make execution reproducible.

[42:30]Kunjan: What does good Python data engineering look like?

[42:35]Elena Kovacs: Good data engineering has contracts. It knows what data is expected, where it comes from, who owns it, how freshness is measured, what happens when data is missing, and how failures are reported. Python can orchestrate that beautifully, but only if the pipeline is treated as software.

[43:35]Kunjan: What does bad data engineering look like?

[43:40]Elena Kovacs: A folder of scripts with unclear names, no tests, no owner, hardcoded paths, copied credentials, silent failures, and output tables nobody understands. It may work for a while, but eventually somebody will ask why a number changed, and nobody will know.

[44:35]Kunjan: So Python makes pipelines easy to create, but not automatically easy to trust.

[44:42]Elena Kovacs: Exactly. Trust requires repeatability, visibility, validation, and ownership.

[45:00]Kunjan: Let us talk testing and observability. Python is dynamic, expressive, and flexible. How does that change the testing strategy?

[45:15]Elena Kovacs: It means tests are not optional ceremony. In Python, many mistakes show up at runtime. Type hints help, but they do not remove the need for tests. A serious Python codebase should test business rules, validation, permissions, serialization, database behavior, API contracts, background jobs, configuration, and failure paths.

[46:15]Kunjan: Failure paths matter a lot.

[46:20]Elena Kovacs: They matter because production is where failure paths become normal paths. Databases slow down. APIs time out. Tokens expire. Users send bad input. Queues grow. Files are missing. Models return strange outputs. If tests only prove the happy path, they are not protecting the system.

[47:15]Kunjan: And observability?

[47:20]Elena Kovacs: Observability is how you keep a system understandable after deployment. You need structured logs, metrics, traces, error reporting, health checks, and dashboards. Logs should include context: request ID, operation, route, user or tenant context where safe, duration, result, and error type. Metrics should show rate, errors, duration, saturation, queue depth, memory, CPU, and dependency latency.

[48:30]Kunjan: What is a common mistake?

[48:35]Elena Kovacs: Logging too much but explaining too little. A thousand unstructured log lines are not observability. They are noise. Good observability lets you answer questions quickly: what changed, who was affected, which dependency failed, how long did it last, did retries help, did the queue recover, did the model degrade, did costs spike?

[49:45]Kunjan: So the goal is not more data. It is better questions.

[49:50]Elena Kovacs: Exactly. Observability is question design. You design signals so future engineers can understand the system under pressure.

[50:30]Kunjan: Let us close with security, dependencies, and AI-generated code. Python has a huge ecosystem. What should teams be careful about?

[50:45]Elena Kovacs: Dependencies are a trust boundary. Every package you install can bring code, transitive dependencies, build behavior, licenses, vulnerabilities, and maintenance risk. That does not mean avoid packages. Python’s ecosystem is a strength. But serious teams review dependencies instead of installing casually.

[51:40]Kunjan: What should dependency review include?

[51:45]Elena Kovacs: Is the package maintained? Is it necessary? How many transitive dependencies does it bring? Does it run install scripts? What license does it use? Is it central to the architecture or just a helper? Is there a standard library solution? Is the package pinned or locked? How will we update it?

[52:45]Kunjan: And AI-generated Python code?

[52:50]Elena Kovacs: Useful, but untrusted. AI can help write boilerplate, tests, scripts, refactors, API clients, and documentation. But it can also invent APIs, use outdated patterns, mishandle async, swallow exceptions, skip validation, leak secrets, or create tests that only test mocks. The developer must still own the code.

[53:40]Kunjan: What should reviewers ask?

[53:45]Elena Kovacs: Can the author explain it? Does it validate inputs? Does it handle timeouts? Does it fail safely? Does it leak data? Does it retry correctly? Is it observable? Is it tested with meaningful cases? Does it follow the team’s architecture? Is the dependency actually needed?

[54:25]Kunjan: Final question. What is Python beyond the hype today?

[54:32]Elena Kovacs: Python beyond the hype is practical power. It is not perfect, and it is not magic. But it is one of the best tools we have for connecting ideas to systems. The teams that win with Python are the teams that respect both sides of it: the speed that makes it loved, and the discipline that makes it last.

[54:52]Kunjan: Elena Kovacs, thanks for joining us.

[54:55]Elena Kovacs: Thanks for having me.

[54:58]Kunjan: For everyone listening, the takeaway is simple: Python can get you to the first working version quickly. But the real craft is turning that first version into something people can trust.

[55:00]Kunjan: End.