Theories
Stay up-to-date on our team's latest theses and research
Stay up-to-date on our team's latest theses and research
Python is the language of AI. By all conventional measures, it shouldn't be.
Python is slow. Thousands of times slower than C, it loses benchmarks to languages that died decades ago.
Python is unsafe. With no compiler to catch your mistakes, your code’s flaws are exposed when it breaks in use.
Python is unserious. It was a Christmas hobby project, named after a comedy troupe, with its philosophy encoded in an Easter egg.
By every metric that mattered in 1995, Python should be a footnote. And yet, it runs the AI revolution. The vast majority of ML research is published in Python, PyTorch dominates deep learning, The entire stack from training to inference to agents is Python.
The worst language won and its flaws are the reason why.
Flow state in Python is simply writing the logic you wish to implement and realizing it just works. Often lauded as the most literate of the languages, thinking in Python is thinking about your problem, instead of syntax gymnastics or interface simulacra. This cognitive transparency enables a direct interaction with the items at work, despite post-hoc typing and linting.
Notebooks and REPL’s do exist in other languages but truly shine in Python: should your model incorporate feature X? A few lines to load the data, a one-shot attempt at a data-transformation, and running a few cells quickly illuminate the credibility of the feature. Python keeps this feedback loop tight because you can write code on the same terms you’re thinking in, operating at the same level of abstraction as the problem you’re trying to solve.
Contrast this with typed languages: you start and end by thinking about your types. What's the shape of this object? What interface does it implement? The compiler demands answers to questions you don't care about yet. You're making promises about code you haven't written, which accrues friction. Each type signature is a tax on changing your mind. You can't try the dumb thing to see if it works because the dumb thing doesn't typecheck, and this encumbrance aggregates in the feedback loop you’re trying to keep fast.
You chose Python because you'd rather be wrong fast than right slow.
Eric S. Raymond contrasted a “bazaar” model of public, rapid release, and co-developed software, with the “cathedral” of private, slow, forethought – but refined. We recognize Python as an exemplar of the bazaar, but does that really explain its success?
Python’s bazaar can be seen via PEPs, PyPI, and the broad base of developers; however, Python’s scientific stack looks more like a cathedral. NumPy, SciPy, Pandas, and Scikit-learn are all sprawling attempts to broaden the applicability of Python, but they’re managed with slow API evolution, smaller contributor groups, and a deep focus on stability of behavior.
Instructive is the tale of who contributed to the scientific libraries: domain experts who happened to code, not programmers who happened to care about science. They chose Python because it let them think about their problems, not about programming. Shared values meant specific conventions: arrays as the universal data structure, broadcasting semantics, the DataFrame as canonical tabular format. Design choices that compound. The stack coheres because each layer was built by people who used the layers below.
This diverges from the other popular language for AI: Typescript.
At the 2025 Python Language Summit, Guido van Rossum argued that Python's early imperfection was a feature, not a bug. The code was simple enough that newcomers could understand it. The lack of optimization meant everything was obvious. Early contributors didn't just use Python; they developed a stake in it. These gaps served as invitations, and Python became their baby too.
Deep learning applied this philosophy at a higher level of abstraction: building neural networks is an empirical science where the architectures most frequently emerge from experimentation, not only first principles. How many layers? What activation function? What learning rate? Theory gives you intuitions, but running the thing tells you if it works.
By 2012, when AlexNet won ImageNet, Python already owned scientific computing. The researchers who built TensorFlow and PyTorch were already Python users. The numerical stack already existed. Transformers, GPT, the entire LLM revolution, arrived into a world where Python was the default. Python spent two decades becoming the language that fits how researchers think. When the revolution came, Python was ready because it was born ready. The same qualities that attracted scientists in 1995 attracted AI researchers in 2012 and agent developers today. We shouldn’t see this recurrence as coincidence; we should interpret it as the inevitable conclusion of intention.
Agent development extends the same logic. If deep learning is empirical, agent development is doubly so. You're experimenting with prompts, tool choices, reasoning chains — work that is reminiscent of hyperparameter or architecture searches. This is why many people have observed that building agents are well-suited to computational notebooks: rapidly updating a tiny fragment of the code, seeing how it outputs, and trying again.
Notebooks are perhaps the ultimate demonstration of Python’s beautiful flaws. While REPLs and notebooks exist for other languages, notebooks have really gone mainstream in Python – and more specifically in this intersection of Python and Science.
In a world that was already more literal, the wave of AI development has pushed more developers into a hyper literal programming environment — natural language. The logic layer and the business layer can more than ever look similar, and there’s opportunity in minimizing that delta.
.png)
Humans and agents need to write, run, debug, and observe code. Both reason via natural language (for now), but can drop into syntax if needed. If you’re building systems meant to be used by both, it’s unsurprising that Python would be the language of choice — in one medium, you can define tools, run them, and interrogate what happened.
This is why we’re hosting a conference on Python for AI. Plenty of AI events are happening, but almost none speak to the people building AI products – Python developers trying to get AI systems to actually work in production. Python is an incredible language for both real systems and the rapid experimentation that AI requires.
Join us for a day at the bazaar.
Today’s security giants have all become data platforms: from the traditional SIEMs (Security Information and Event Management) like Splunk, to CSPMs (Cloud Security Posture Management) like Wiz, to network security companies like Palo Alto Networks and endpoint security companies like Crowdstrike.
They are deeply entrenched with enterprises, and seem nearly impossible to rip out.
But they were designed for human analysts, and often don’t do that job particularly well: many enterprises complain about paying millions to store security data they can barely use.
Meanwhile, cybersecurity is in an escalating arms race of autonomy. Attackers are using AI agents to infiltrate systems at an unthinkable scale and pace. To counter, defenders are replacing slow, manual workflows with AI agents to triage alerts, hunt threats, and close vulnerabilities before they’re exploited.
Operating at agentic scale will push security data infrastructure to its breaking point. But these platforms aren’t easy to change. They are large, complex, mission-critical systems.
So what will happen to these data giants? Their moats are strong for now, but we think AI security agents will be a trojan horse for a dramatic platform shift.
Security teams already struggle with their data platforms today. Data volumes and costs are ballooning; enterprises often see their security data volumes grow 30-40% yearly. And making use of that data is hard: analysts write queries across multiple complex systems and languages, wait minutes to hours for them to run, then wrangle results in spreadsheets. It’s hard to figure out what’s already happened, let alone develop proactive detections and defenses.
We already see this being transformed by AI. Security agents (like Theory portfolio companies Dropzone in security operations and Maze in vulnerability management) will have superhuman knowledge of every platform in their domain. They’ll know every query language and schema quirk. They can wrangle data like the best analyst, and reason about attack patterns like an expert security researcher.
The result? Simple natural-language search and analysis; smarter, context-informed behavioral detections; and a rapid shift from a small number of human-led analyses to a massive amount of queries executed by AI agents.
If you were building an AI security agent that queries massive volumes of data 24/7, should you sit on top of the existing data stack or build your own?
There are strong arguments on both sides:
Sitting on top of the existing stack (sometimes called a federated or overlay model) is compelling because it’s easy. Customers don’t need to worry about a migration. They can keep using their existing tools and analysts don’t need retraining. AI systems will be able to deliver value practically from day one.
An objection to this model is often cost. If a company already spends millions on their core security data platforms, can they justify spending millions more on agents just to make that data useful? It can be a tough pitch for a CISO to make to their CFO, though AI’s ability to improve security posture and automate labor is undeniable.
Building your own integrated/consolidated stack is the best way to make AI systems work well. It’s easier for agents to make use of data with clean, consistent, and normalized schemas. You don’t need to worry about maintaining a suite of connectors and integrations. You can drive better cost and performance on a cheap, modern database like ClickHouse. And you can build more intelligent systems, like deciding how to ingest, transform, and retain data based on downstream AI agent needs.
But this approach comes with massive switching costs. For most enterprises, a security data migration is slow, expensive, and risky. For some, it is practically impossible due to regulatory requirements or legacy/on-prem infrastructure. Despite the benefits of an integrated platform, the prospect of a long, costly migration to realize them can be insurmountable.
Despite the benefits of an integrated data stack for AI, high switching costs means the security data giants are safe for now. But the way they could be unseated is clear.
AI-native entrants can enter as an overlay, integrating with existing data platforms and running analysis on top. It’s more work for the startup: they have to handle messy legacy data sources, maintain integrations, and demonstrate hard ROI (e.g. from time/labor savings). But it lets them provide value to customers instantly with minimal implementation risk.
These AI products will abstract away underlying platforms as agents take over most data interactions. When their contract for an underlying data platform is up, customers will wonder if they really need the expensive legacy infrastructure, when the AI system on top of it can provide a cheaper, more performant option using raw logs, commodity storage, and open-source databases.
This path will break the stranglehold of today’s security giants, and shift value from the data layer to the AI layer over time. It creates a generational opportunity to build massive, foundational new security companies that will rival today’s behemoths.
If you have thoughts on the evolution of security data platforms, I’d love to hear from you: at@theoryvc.com.
.png)