DEV Community: Neil Chaudhuri

Python Is Not the Language of AI

Neil Chaudhuri — Tue, 30 Sep 2025 14:45:16 +0000

MIT recently reported that a staggering 95% of enterprise AI deployments fail.
That is really bad! The primary reasons are strategic rather than technical like the absence of a data strategy and no clear business objectives beyond "We need to use more AI or we will fall behind!" In all things, AI or otherwise, whatever you do downstream from terrible leadership is pretty much doomed to fail.

However, even the most thoughtful strategy will fail without a very particular technical understanding:

Python has always been and will likely always be the language of machine learning (ML), but it is not the language of AI. The failure to understand the difference is hurting AI adoption. Succeeding with AI is a function of context not computation.

A little history

Imagine you work at Netflix in 2010. You have a hypothesis: People are more likely to watch content, and therefore ads that will make your manager happy, that takes place in the city where they grew up. For example, someone who grew up in Scranton, Pennsylvania, is more likely to watch The Office than they would otherwise.

At that time and still to this day, Python was the best choice to test your hypothesis. With its dynamic typing and intuitive syntax, the Python language makes it very easy for data scientists, who are not programmers and understandably have no interest in the ceremony of traditional software engineering, to experiment quickly. With that
growing popularity came the blossoming of a prolific ecosystem. Libraries we take for granted today like Pandas, NumPy, Scikit-learn, spaCy, GLiNER, and countless others emerged with Deep Learning staples like PyTorch and TensorFlow arriving later. Machine learning pipelines using tools like dbt, Dagster, Airflow, and Great Expectations became ubiquitous. Bombshell tooling like Jupyter Notebooks and powerful IDEs entered the villa. It is easy to see why the Python ecosystem has been so dominant for so long for running experiments and solving many popular use cases like spam detection, sentiment analysis, fraud detection, loan default prediction, and image classification. There are powerful data science alternatives like R and Julia, but they just don't have the juice.

When ChatGPT came along in 2022, Python appeared poised to become more powerful than you can possibly imagine. With Python the clear choice for NLP and Deep Learning, AI companies use Python to train Large Language Models (LLMs). If you want to fine tune an existing model to train it for your use case, you use Python tools like Unsloth. Naturally, Python also led the way in AI orchestration. As Retrieval Augmented Generation (RAG) became all the rage, LangChain and LlamaIndex inherited the Python pipeline tradition and made it easier to ground LLMs on your own structured and unstructured data. To take things even further, because Python has dominated ML for so long and there have always been so many outstanding ML models, and now AI models, on Hugging Face, core Hugging Face libraries like Transformers are Python libraries. Other approaches like Deep Java Library and Spring AI are technically possible to work with Hugging Face, but the process is never very straightforward.

The result was predictable. You can see the surge in Python popularity in various Python language rankings like the August 2025 TIOBE Index, which not only puts Python at #1 but also jumping 8.1% after the last ranking!

However, as AI adoption explodes, organizations are butting against the limits of Python for building mission-critical, production software for real users. Python doesn't readily deliver what enterprise AI needs to thrive.

In the Real World, ML ≠ AI

It's a vast oversimplification, but machine learning is computation. And to be fair, it's true you need very advanced computations to build LLMs in the first place. But once you have LLMs in place doing real work, generating value from them for your business is not about computation at all.

It's about context.

The key to success with AI is to provide the best context to the best suited LLM(s) so they can pattern match their way to the best result.

For you individually, if you are using an LLM to find a job, context means using Model Context Protocol (MCP) clients like Goose to integrate the job description on a company website and other relevant pages about company strategy and values with the PDF resume on your laptop. That context helps LLMs offer suggestions on what to emphasize in your work history to maximize your chances for an interview. That doesn't require any code from you, Python or otherwise. It's simply knowing which context matters and making it available to AI.

Similarly for a business, context means gleaning the most relevant information across the enterprise—in databases, Notion, Jira, Slack, GitHub, Salesforce, Dropbox, Confluence, SharePoint, Google Workspace, Office 365, and all the other typical black holes of organizational memory in big companies—to your problem and providing that to an LLM. This likely requires some code, but it's just API calls to the data and the LLM(s), which software engineers have been doing forever, rather than calculating root mean squared error.

Put simply, AI is a context integration challenge not a number crunching challenge.

Python Limitations

I have a deep appreciation for Python. In fact, it's the language I recommend to people who want to get into programming for the first time for all the same reasons it's so popular with data scientists.

But there are several reasons why Python never really caught on to solve integration challenges at scale in enterprises:

Lack of type safety, which Pydantic AI, BAML, and other modern AI libraries try to address because it's so important to ground LLMs in structure
Poor performance of Python at scale, which FastAPI and other modern libraries address in limited scope
Lack of mature middleware options like Kafka integration
Lack of mature tooling around security, observability, and resiliency

There is an old cliché in software engineering: Use the right tool for the job. The qualities that make Python dominant for ML are irrelevant, even counterproductive, to what you need for AI.

Python is fine, but it's not the right tool for the job.

Better Choices for AI

If AI is an integration challenge rather than an ML challenge, AI success demands technologies built to solve integration challenges. There are lots of languages whose features, runtimes, and ecosystems
make them far better options than Python:

JVM languages like Java, which has dominated the enterprise for decades, and Kotlin, which is a modern alternative interoperable with Java and currently my favorite language
.NET languages like C#, which also dominates the enterprise, and F#
TypeScript, which has emerged very quickly as a popular integration option with libraries like Prisma and tRPC
Go, built for speed and integrates well with middleware
Rust, really built for speed with a devoted, growing community willing to tackle the tough learning curve
Elixir, niche language but purpose built for scalable, fault tolerant distributed systems

Your choice depends on all the usual considerations like available talent and skills, deployment constraints, available SDKs, and so on. The key point is you are not limited to Python for AI because of its legacy in ML. You can even do better. You will find higher-level agent frameworks that rival and arguably beat LangChain and LlamaIndex like Koog (Kotlin) and Embabel (Kotlin and Java) on the JVM, Mastra in TypeScript, and Semantic Kernel in C#, Java, and yes, Python. The great thing about these frameworks is they affirm the lessons we have learned about mature software engineering at scale over the last few decades by espousing concepts like type safety, testing, security, Domain-Driven Design, observability, and disaster recovery. While completely unnecessary for data science experiments, these concepts are all crucial for serious software deployed at scale, AI or otherwise.

Succeeding with AI begins with sound business strategy and data strategy. After that, your technical implementation is a matter of integrating context not performing computations. Solve the right problem with the right solution to maximize your chances for success with AI.

Why Types and Tests are Both Essential in Programming

Neil Chaudhuri — Sun, 05 Mar 2023 15:53:11 +0000

90% of Tech Twitter is the same arguments over and over again:

Are engineers being laid off simply not good enough? (No. Layoffs are all but random and serve, along with stock buybacks using all the cash on hand tech companies have, to impress The Street and inflate stock price.)
Does preference for remote work mean you're lazy? (No. What matters is if your customers are happy and your business is profitable, and your business should enable you to contribute in the easiest way possible for you and your family.)
Is HTML a programming language? (Who cares? Stop gatekeeping.)
Is Tailwind CSS a productivity boost or the spawn of Satan? (This is stupid. Mind your business. Use what you like and let others do the same.)
Should you have more unit tests or integration tests? (Shoot me.)
Must you love programming to excel? (No. Don't believe me? Then believe Sarah Drasner, who is smarter than both of us.)

Another common debate, and one that is more interesting, is whether you should invest in types or tests. It raises some key questions about what makes each valuable, but unfortunately the debate gets lost in the haze of programming language preferences, developer experiences, and other tangential concerns. Still, the answer matters because it's central to improving our process so we can build as efficiently and with the highest quality as possible.

It turns out you need types and tests because each solves completely different problems that are both important to you as a developer.

Types automate API integrity at development time

The key components of an API call—whether it's a Java method, a REST endpoint, or a Python function—are the input parameters and the output. There are infinite ways a consumer can interact with your API, but we don't want that.

Consider an API call that takes first name, last name, and an amount of money parameters with no types:

(firstName, lastName, amount) => {...}

Each parameter has literally infinite possible values, so our API forces consumers to be very careful. For example, it's very easy to mix up the firstName and lastName strings.

True story: There is a political fundraising apparatus that has switched my first and last names, so every email starts off "Chaudhuri, we need your help!" when they really mean "Neil, we need your help!" It's like my high school coach is yelling at me to donate.

Even worse, they could mix up one of the string values with the number in the amount. In fact, it's very easy to put garbage of any type into each parameter, and relatively speaking almost all of it is bad. Of course you can paper over the problem in a number of ways:

Intuitive parameter names like I did above
Logical order for parameters
Comments or other documentation
Default values or optionality for parameters (if your programming language has those features)

These things are good as a general matter, but they don't solve the problem.

We can improve the situation considerably by adding types:

(firstName: string, lastName: string, amount: number) => {...}

Now we have ensured firstName and lastName can only be strings and amount can only be a number. But I know. We can still switch firstName and lastName. We can put a negative number in for amount. Each parameter still has literally infinite possible values, but we have shrunk the universe of valid inputs immeasurably. Don't let perfect be the enemy of good. This is progress!

We can tighten up our types further to do even better:

(firstName: FirstName, lastName: LastName, amount: Currency) => {...}

How you do this depends on the features of your programming language. Maybe it has a built-in type already for currency. Or you can define a type with a custom implementation or as simply as a type alias. Regardless of how you get there, look how far we've come. No confusing name with amount. No mixing up names. No improper values for the amount. The tigher our type constraints, the more we make life easier for consumers by narrowing the field of possible values for each parameter. Yes, there are still infinite possible permutations of parameters, but at least it's not "infinite infinite."

Types constrain our API to limit the universe of possible inputs, and best of all, they work at development time. If API consumers make a mistake by supplying a value outside the type boundary, they are going to hear about it: from the IDE, type checker, compiler, code generator. We all know the faster you find something wrong the easier it is to fix, and nothing works faster than types to all but guarantee the integrity of our APIs. This is the beauty of automating API integrity rather than wasting time as human compilers and static analyzers who inevitably get it wrong. You also get a form of documentation that helps you understand the API just by looking at it.

As for outputs, constraints on return types are also valuable because as we compose functions, the return value from one call becomes the input to another. Programs are essentially data pipelines of composed functions, so types guarantee the integrity of the entire call chain, which is pretty amazing.
If you maximize the power of types of the values going in and coming out of your API calls, and you then compose them so they fit together like Legos, you have made enormous strides in maximizing the quality of your code without writing a single test.

But that isn't quite enough.

Tests verify your API behavior at runtime

We've used types to limit the universe of values our API consumers can apply, but how do we know we have done the right thing with them to satisfy our API contract and return what consumers asked for?

Or more simply, does our code work? This is where tests come in.

As entire books have been written about testing and you likely already know much about it, I won't spend a lot of time on it here. What matters for this discussion is that while types define APIs in development, tests act at runtime to verify your API behavior with the parameters whose types have
already been guaranteed. Types and tests are complementary. You need both.

So why the controversy?

While it's been around for as long as static and dynamically typed languages have coexisted, in my experience the Types vs. Tests debate blew up fairly recently in the JavaScript community, where more experienced developers in particular were already comfortable acting as human compilers and static analyzers and viewed the emergence of TypeScript with skepticism. After all, types add more verbosity (to varying degrees given your programming language's talent for type inference), and developers hate extra keystrokes. Add to that more work like tsconfig.json for TypeScript or adding hints or the typing library in Python and you have a recipe for tension.

But at the core of the debate is one key question: "Tests can do everything types can do, so why bother with all the ceremony?"

My view: Nah not really.

Sure you can fake type safety with tests by enforcing invariants like ensuring amount, a number in the second example above, is nonnegative. That isn't actual type safety though. It's just moving type enforcement from the interface to the implementation, which has disastrous consequences. Like all tests, "type tests" depend on your discipline. You may not write any at all because of deadlines, or you may write bad ones that don't add value.

Some might say types demand discipline too. If your types are loose, you don't reap the benefits. That depends on how strongly typed the language is and how effective you are at maximizing the power of its type system. But intentionally widening types is more sabotage than lack of discipline.

You've also shifted type guarantees right, from development time to runtime, and delayed feedback as a result. This makes you slower.

You know what else makes you slower? You've chosen a manual process over automation. You've sacrificed tooling support and implicit documentation for the chance to waste time doing extra work types do more reliably and cheaply. That's particularly weird since one of the primary objections to types is extra work.

In the end, substituting types with tests in your code is like substituting Chris Hemsworth with his brother Liam in the cast of your movie. You could do worse but look at how much you've lost in the process. Use types to automate API integrity and tests to verify API behavior together to build the most reliable and maintainable code in the shortest amount of time.