Great news. Use AI to go find all the vulnerabilities and fix them.
Great example from Mozilla:
"Since February, the Firefox team has been working around the clock using frontier AI models to find and fix latent security vulnerabilities in the browser. We wrote previously about our collaboration with Anthropic to scan Firefox with Opus 4.6, which led to fixes for 22 security-sensitive bugs in Firefox 148.
As part of our continued collaboration with Anthropic, we had the opportunity to apply an early version of Claude Mythos Preview to Firefox. This week’s release of Firefox 150 includes fixes for 271 vulnerabilities identified during this initial evaluation." - Mozilla Blog
Home > Ajabbi Research > Library > Subscriptions > InfoQ Weekly Digest
Home > Handbook >
Last Updated
27/04/2026
Claude Code Used to Find Remotely Exploitable Linux Kernel Vulnerability Hidden for 23 Years
By: Steef-Jan Wiggers
InfoQ: 15/04/2026
Steef-Jan Wiggers is one of InfoQ's senior cloud editors and works as a Domain Architect at VGZ in the Netherlands. His current technical expertise focuses on implementing integration platforms, Azure DevOps, AI, and Azure Platform Solution Architectures. Steef-Jan is a regular speaker at conferences and user groups and writes for InfoQ. Furthermore, Microsoft has recognized him as a Microsoft Azure MVP for the past sixteen years.
Anthropic research scientist Nicholas Carlini reported at the [un]prompted AI security conference that he used Claude Code to discover multiple remotely exploitable security vulnerabilities in the Linux kernel, including a heap buffer overflow in the NFS driver that has been present since 2003. The bug has since been patched, and Carlini has identified a total of five Linux kernel vulnerabilities so far, with hundreds more potential crashes awaiting human validation.
Michael Lynch wrote a detailed breakdown of the findings based on Carlini's conference talk. What makes the discovery notable is not just the age of the bug but how little oversight Claude Code needed to find it. Carlini used a simple bash script that iterates over every source file in the Linux kernel and, for each file, tells Claude Code it is participating in a capture-the-flag competition and should look for vulnerabilities. No custom tooling, no specialized prompts beyond biasing the model toward one file at a time:
# Iterate over all files in the source tree. find . -type f -print0 | while IFS= read -r -d '' file; do # Tell Claude Code to look for vulnerabilities in each file. claude \ --verbose \ --dangerously-skip-permissions \ --print "You are playing in a CTF. \ Find a vulnerability. \ hint: look at $file \ Write the most serious \ one to the /output dir" done
The NFS vulnerability itself required understanding intricate protocol details. The attack uses two cooperating NFS clients against a Linux NFS server. Client A acquires a file lock with a 1024-byte owner ID, which is unusually long but legal. When Client B then attempts to acquire the same lock and gets denied, the server generates a denial response that includes the owner ID. The problem is that the server's response buffer is only 112 bytes, but the denial message totals 1056 bytes. The kernel writes 1056 bytes into a 112-byte buffer, giving the attacker control over overwritten kernel memory. The bug was introduced in a 2003 commit that predates git itself.
The model progression is arguably the most significant part of the story for practitioners. Carlini tried to reproduce his results on earlier models and found that Opus 4.1, released eight months ago, and Sonnet 4.5, released six months ago, could only find a small fraction of what Opus 4.6 discovered. That capability jump in a matter of months suggests the window in which AI-assisted vulnerability discovery becomes routine is narrowing fast.
This aligns with what Linux kernel maintainers are seeing from the other side. As shared in a Reddit thread discussing the findings, Greg Kroah-Hartman, one of the most senior Linux kernel maintainers, described the shift:
Something happened a month ago, and the world switched. Now we have real reports... All open source security teams are hitting this right now.
Willy Tarreau, another kernel maintainer, corroborated this on LWN, noting that the kernel security list went from 2-3 reports per week to 5-10 per day, and that most of them are now correct.
The false positive question remains open. Carlini has "several hundred crashes" he hasn't had time to validate, and he is deliberately not sending unvalidated findings to kernel maintainers. On Hacker News, Lynch (the blog post author) stated that in his own experience using Claude Opus 4.6 for similar work, the false positive rate is below 20%.
Salvatore Sanfilippo, creator of Redis, commented on the same Hacker News thread that the validation step is increasingly being handled by the models themselves:
The bugs are often filtered later by LLMs themselves: if the second pipeline can't reproduce the crash / violation / exploit in any way, often the false positives are evicted before ever reaching the human scrutiny.
Thomas Ptacek, a security researcher who has spent most of his career in vulnerability research, argued on Hacker News that LLM-based vulnerability discovery represents a fundamentally different category of tool:
If you wanted to be reductive you'd say LLM agent vulnerability discovery is a superset of both fuzzing and static analysis.
Ptacek elaborated that static analyzers generate large numbers of hypothetical bugs that require expensive human triage, and fuzzers find bugs without context, producing crashers that remain unresolved for months. LLM agents, by contrast, recursively generate hypotheses across the codebase, take confirmatory steps, generate confidence levels, and place findings in context by spelling out input paths and attack primitives.
The dual-use concern was raised repeatedly across both discussion threads. As one Reddit commenter put it:
If AI can surface 23-year-old latent vulnerabilities in Linux that human auditors missed, adversaries with the same capability can run that process against targets at scale.
Carlini's five confirmed Linux kernel vulnerabilities span NFS, io_uring, futex, and ksmbd, all of which have kernel commits now in the stable tree. The [un]prompted talk is available on YouTube.
By: Affan Dar, Adam Prout, Panagiotis Antonopoulos
Microsoft Blog for PostgreSQL: 29/01/2026
Affan Dar: Vice President of Engineering, PostgreSQL at Microsoft
Adam Prout: Partner Architect, PostgreSQL at Microsoft
Panagiotis Antonopoulos: Distinguished Engineer, PostgreSQL at
Microsoft.
How we scaled OpenAI's mission critical workload on Azure Database for
PostgreSQL flexible server.
The OpenAI engineering team recently published a blog post describing how
they scaled their databases by 10x over the past year, to support 800
million monthly users. To do so, OpenAI relied on Azure Database for
PostgreSQL to support important services like ChatGPT and the Developer API.
Collaborating with a customer experiencing rapid user growth has been a
remarkable journey.
One key observation is that PostgreSQL works out of box for very
large-scale points. As many in the public domain have noted, ChatGPT grew to
800M+ users before OpenAI started moving new and shardable workloads to
Azure Cosmos DB.
Nevertheless, supporting the growth of one of the largest Postgres
deployments was a great learning experience for both of our teams. Our
OpenAI friends did an incredible job at reacting fast and adjusting their
systems to handle the growth. Similarly, the Postgres team at Azure worked
to further tune the service to support the increasing OpenAI workload. The
changes we made were not limited to OpenAI, hence all our Azure Database for
PostgreSQL customers with demanding workloads have benefited.
A few of the enhancements and the work that led to these are listed
below.
Changing the network congestion protocol to reduce replication
lag
Azure Database for PostgreSQL used the default CUBIC congestion control
algorithm for replication traffic to replicas both within and outside the
region. Leading up to one of the OpenAI launch events, we observed that
several geo-distributed read replicas occasionally experienced replication
lag. Replication from the primary server to the read replicas would
typically operate without issues; however, at times, the replicas would
unexpectedly begin falling behind the primary for reasons that were not
immediately clear.
This lag would not recover on its own and would grow to a point when,
eventually, automation would restart the read replica. Once restarted, the
read replica would once again catch up, only to repeat this cycle again
within a day or less.
After an extensive debugging effort, we traced the root cause to how the
TCP congestion control algorithm handled a higher rate of packet drops.
These drops were largely a result of high point-to-point traffic between the
primary server and its replicas, compounded by the existing TCP window
settings. Packet drops across regions are not unexpected; however, the
default congestion control algorithm (CUBIC) treats packet loss as a sign of
congestion and does an aggressive backoff. In comparison, the Bottleneck
Bandwidth and Round-trip propagation time (BBR) congestion control algorithm
is less sensitive to packet drops. Switching to BBR, adding SKU specific TCP
window settings, and switching to fair queuing network discipline (which can
control pacing of outgoing packets at hardware level) resolved this issue.
We’ll also note that one of our seasoned PostgreSQL committers provided
invaluable insights during this process, helping us pinpoint the issue more
effectively.
Scaling out with Read replicas
PostgreSQL primaries, if configured properly, work amazingly well in
supporting a large number of read replicas. In fact, as noted in the OpenAI
engineering blog, a single primary has been able to power around 50+
replicas across multiple regions. However, going beyond this increases the
chance of impacting the primary. For this reason, we added the cascading
replica support to scale out reads even further. But this brings in a number
of additional failure modes that need to be handled. The system must
carefully orchestrate repairs around lagging and failing intermediary nodes,
safely repointing replicas to new intermediary nodes while performing catch
up or rewind in a mission critical setup.
Furthermore, disaster recovery (DR) scenarios can require a fast rebuild of
a replica and as data movement across regions is a costly and time-consuming
operation, we developed the ability to create a geo replica from a snapshot
of another replica in the same region. This feature avoids the traditional
full data copy process, which may take hours or even days depending on the
size of the data, by leveraging data for that cluster that already exists in
that region. This feature will soon be available for all our customers as
well.
Scaling out Writes
These improvements solved the read replica lag problems and read scale but
did not help address the growing write scale for OpenAI. At some point, the
balance tipped and it was obvious that the IOPs limits of a single
PostgreSQL primary instance will not cut it anymore. As a result OpenAI
decided to move new and shardable workloads to Azure Azure Cosmos DB, which
is our default recommended NoSQL store for fully elastic workloads. However,
some workloads, as noted in the OpenAI blog are much harder to
shard.
While OpenAI is using Azure Database for PostgreSQL flexible server,
several of the write scaling requirements that came up have been baked into
our new Azure HorizonDB offering, which entered private preview in November
2025. Some of the architectural innovations are described in the following
sections.
Azure HorizonDB scalability design
To better support more demanding workloads, Azure HorizonDB introduces a
new storage layer for Postgres that delivers significant performance and
reliability enhancements:
More efficient read scale out. Postgres read replicas no longer need
to maintain their own copy of the data. They can read pages from the
single copy maintained by the storage layer.
Lower latency Write-Ahead Logging (WAL) writes and higher throughput page
reads via two purpose-built storage services designed for WAL storage and
Page storage.
Durability and high availability responsibilities are shifted from the
Postgres primary to the storage layer, allowing Postgres to dedicate more
resources to executing transactions and queries.
Postgres failovers are faster and more reliable.
To understand how Azure HorizonDB delivers these capabilities, let’s look
at its high‑level architecture as shown in Figure 1. It follows a
log-centric storage model, where the PostgreSQL writeahead log (WAL) is the
sole mechanism used to durably persist changes to storage. PostgreSQL
compute nodes never write data pages to storage directly in Azure HorizonDB.
Instead, pages and other on-disk structures are treated as derived state and
are reconstructed and updated from WAL records by the data storage
fleet.
Azure HorizonDB storage uses two separate storage services for WAL and data
pages. This separation allows each to be designed and optimized for the very
different patterns of reads and writes PostgreSQL does against WAL files in
contrast to data pages. The WAL server is optimized for very low
latency writes to the tail of a sequential WAL stream and the Page server is
designed for random reads and writes across potentially many terabytes of
pages.
Figure 1 - Azure HorizonDB Architecture
These two separate services work together to enable Postgres to handle IO
intensive OLTP workloads like OpenAI’s. The WAL server can durably write a
transaction across 3 availability zones using a single network hop.
The typical PostgreSQL replication setup with a hot standby (Figure 2)
requires 4 hops to do the same work. Each hop is a component that can
potentially fail or slow down and delay a commit. Azure HorizonDB page
service can scale out page reads to many hundreds of thousands of IOPs for
each Postgres instance. It does this by sharding the data in Postgres
data files across a fleet of page servers. This spreads the reads
across many high performance NVMe disks on each page server.
Figure 2 - WAL Writes in HorizonDB
Another key design principle for Azure HorizonDB was to move durability and
high availability related work off PostgreSQL compute allowing it to operate
as a stateless compute engine for queries and transactions. This approach
gives Postgres more CPU, disk and network to run your application’s business
logic. Table 1 summarizes the different tasks that community
PostgreSQL has to do, which Azure HorizonDB moves to its storage
layer. Work like dirty page writing and checkpointing are no
longer done by a Postgres primary. The work for sending WAL files to
read replicas is also moved off the primary and into the storage layer –
having many read replicas puts no load on the Postgres primary in Azure
HorizonDB. Backups are handled by Azure Storage via snapshots,
Postgres isn’t involved.
Table 1 - Summary of work that the Azure HorizonDB storage layer takes over
from PostgreSQL
The shared storage architecture of Azure HorizonDB is the fundamental
building block for delivering exceptional read scalability and elasticity
which are critical for many workloads. Users can spin up read replicas
instantly without requiring any data copies. Page Servers are able to scale
and serve requests from all replicas without any additional storage costs.
Since WAL replication is entirely handled by the storage service, the
primary’s performance is not impacted as the number of replicas changes.
Each read replica can scale independently to serve different workloads,
allowing for workload isolation.
Finally, this architecture allows Azure HorizonDB to substantially improve
the overall experience around high availability (HA). HA replicas can now be
added without any data copying or storage costs. Since the data is shared
between the replicas and continuously updated by Page Servers, secondary
replicas only replay a portion of the WAL and can easily keep up with the
primary, reducing failover times. The shared storage also guarantees that
there is a single source of truth and the old primary never diverges after a
failover. This prevents the need for expensive reconciliation, using
pg_rewind, or other techniques and further improves
availability.
Azure HorizonDB was designed from the ground up with learnings from large
scale customers, to meet the requirements of the most demanding workloads.
The improved performance, scalability and availability of the Azure
HorizonDB architecture make Azure a great destination for Postgres
workloads.
Some thoughts about adding Geographic Information Systems (GIS) mapping to Pipi 10, the next major release of Pipi.
Spacetime
An unresolved issue is how to integrate GIS with 4D spacetime. See the work of Ontologists Chris Partridge on BORO and NATO, and Matthew West on 4Dism, Shell Oil Refineries, and the Ontological foundations behind the UK Digital Twin Project for Built Infrastructure. Chris Partridge also raised a related question in the Ontolog Forum recently.
Mike is the inventor and architect of Pipi and the founder of Ajabbi.
Pipi 4 (2005-2008)
NZERN, with the help of Parker Jones at Eagle Technology, secured an ESRI Conservation GIS grant to add GIS mapping capabilities.
I gave a live demo and presentation of Pipi 4 at an NZ ESRI User Conference held in Wellington. The head of engineering at ESRI was in the audience. In a few weeks, over NZ$600,000 worth of ESRI software was on its way.
ESRI gave us everything they had. Multiple (up to 10) licenses at version 8.2
ArcIMS
ArcSDE
Workstation
All the extensions.
Everything!
There was so much boxed software that it came on a pallet.
The plan was to provide free, dedicated, and customised web map hosting for every conservation project in NZ that wanted it. The smallest mapped project was 1500 sq m, scaling up to large landscape-scale, whole catchment projects. Every project was different, so the provided GIS was customised to meet their needs. There was even a visit by an ESRI staff member who proposed enabling NZERN to extend this to conservation efforts in the Pacific Island states, by providing training using ESRI-supplied laptops.
I got to create all the GeoDatabases and hack JTX to run in reverse to manage user map-edits history.
It was going very well, and many individual projects were getting dedicated dynamic web maps with all their data and GIS layers. All labour was donated (Ten thousand hours).
QE2 National Trust and other national conservation-related organisations were also interested in using this shared GIS system.
Then the government funding that covered the core annual running costs dried up.
Core costs included;
Power
Bandwidth
Hardware
Repairs
Software books
Then the Key government came in, followed by the Christchurch Earthquake. What a waste of opportunity for conservation.
After that, governments love to reinvent the wheel, so there have been many well-funded attempts to develop GIS for biodiversity/stream health for community use in NZ. None of them has been as good as Pipi, and most of them disappear after a while. So we are going to do something about that, except it will be available globally in many human languages, across many industries, and will use open-source GIS software.
Parker Jones, with Bonita, went on to create a GIS for Conservation organisation in NZ, and has done a great job. All power to them.
Pipi 9 (2023 - )
GIS Plugins include
Apple Map
ArcGIS Map
Azure Map
Google Map
Pipi 10
Customers will be able to integrate Pipi with their own ESRI GIS account deployments. Pipi GIS will use OGC standards. I have to say here that I love ESRI software, and the Eagle Technology people were great, but it is far too expensive and restrictive for this social-enterprise startup.
Options
Use open-source; it's free, and DIY everything.
Default Option
QGIS
GeoServer 3
GeoNode
PostGIS + PostgreSQL
Open Geospatial Consortium (OGC)
These products are mature and conform to the OGC standards.
Geospatial Libraries
FDO – API (C++, .Net) between GIS application and sources; for manipulating, defining and analysing geospatial data.
GDAL/OGR – Library between GIS applications and sources; for reading and writing raster geospatial data formats (GDAL) and simple features vector data (OGR).
GeoTools – Open source GIS toolkit (Java); to enable the creation of interactive geographic visualization clients.
GEOS – A C++ port of the Java Topology Suite (JTS), a geometry model.
MetaCRS – Projections and coordinate system technologies, including PROJ.
Orfeo ToolBox (OTB) – Open source tools to process satellite images and extract information.
OSSIM: Extensive geospatial image processing libraries with support for satellite and aerial sensors and common image formats.
PostGIS – Spatial extensions for the PostgreSQL database, enabling geospatial queries.
Desktop Applications
QGIS – Desktop GIS for data viewing, editing and analysis — Windows, Mac and Linux.
GRASS GIS – an extensible GIS for image processing and analysing raster, topological vector and graphic data.
OSSIM – Libraries and applications used to process imagery, maps, terrain, and vector data.
Marble – Virtual globe and world atlas.
gvSIG – Desktop GIS for data capturing, storing, handling, analysing and deploying. Includes map editing.
uDIG -
Web Mapping Server
MapServer – Fast web mapping engine for publishing spatial data and services on the web; written in C.
Geomajas – Development software for web-based and cloud-based GIS applications.
GeoServer – Allows users to share and edit geospatial data. Written in Java using GeoTools.
deegree – Java framework
PyWPS – implementation of the OGC Web Processing Service standard, using Python
pygeoapi - A Python server implementation of the OGC API suite of standards for geospatial data.
Web Mapping Client
GeoMoose – JavaScript Framework for displaying distributed GIS data.
Mapbender – Framework to display, overlay, edit and manage distributed Web Map Services using PHP and JavaScript.
MapGuide Open Source – Platform for developing and deploying web mapping applications and geospatial web services. Windows-based, native file format.
MapFish – Framework for building rich web-mapping applications based on the Pylons Python web framework.
OpenLayers – an AJAX library (API) for accessing geographic data layers of all kinds.
Hosting
The GeoServer and PostGIS + PostgreSQL Geodatabasewill need to be deployed in the Pipi Data Centre and used by the spatial agent engine. Providing hosted GIS to customers will require Ajabbi to purchase or lease bare-metal servers to host open-source GIS Web Servers.
GeoServer 3 will be available in Docker. All doable.
Support
Sponsor open-source and pay for support from GeoSolutions, etc.
Earlier this week, I attended the APAC Cloud Technical Series: On Board from Google. It was 10 hours over 2 days of talks and code workshops from Google staff, who were mainly based in Singapore.
It was excellent and worth the time. I signed up for more sessions planned later in the year. Google Weeklies is a regular in-depth talk available both live and as an archive. Excellent stuff.
I got an invite to join Google for Startups' Rising Founders program. I hope that this will lead to access to researchers at Google DeepMind. I have questions.
I initially registered to participate in the Gen AI Academy APAC Edition, which would have been fun, but then I discovered an age restriction. I'm too ancient. 😊
IaC
This will help me build Pipi Engines to build, deploy, and manage infrastructure-as-code (IaC) in the cloud.
A dedicated agent engine has been created for each cloud platform. They have yet to be differentiated.
Apple Engine (ale)
AWS Engine (aws)
AZURE Engine (azu)
Digital Ocean Engine (dgo)
Google Cloud Engine (ggc)
IBM Engine (ibm)
Meta Engine (met)
Oracle Engine (ora)
(More will be added later; all are welcome)
Agents
Pipi 9 is a type of world-model AI, not an LLM. Google is offering a platform for LLM-based generative AI agents. My thought is to connect Pipi 9 to these external agents via open protocols, leveraging the strengths of both.
MCP
PostgreSQL
TPU
etc
A2A
Agent Card
ADK
More Pipi engines
MCP Engine (mcp)
Agent card
Here are some initial notes about the Agent Card protocol, part of A2A. I will start building from there.
Pipi is an agent built from hundreds of other kinds of deeply nested agents, and is capable of learning, evolving and replicating. So does this mean that Pipi needs its own Agent Card? 😀
Mike is the inventor and architect of Pipi and the founder of Ajabbi.
From A2A Protocol Documentation
A2A revolves around several key concepts. For detailed explanations, please refer to the Key Concepts guide.
A2A Client: An application or agent that initiates requests to an A2A Server on behalf of a user or another system.
A2A Server (Remote Agent): An agent or agentic system that exposes an A2A-compliant endpoint, processing tasks and providing responses.
Agent Card: A JSON metadata document published by an A2A Server, describing its identity, capabilities, skills, service endpoint, and authentication requirements.
Message: A communication turn between a client and a remote agent, having a role ("user" or "agent") and containing one or more Parts.
Task: The fundamental unit of work managed by A2A, identified by a unique ID. Tasks are stateful and progress through a defined lifecycle.
Part: The smallest unit of content within a Message or Artifact. Parts can contain text, file references, or structured data.
Artifact: An output (e.g., a document, image, structured data) generated by the agent as a result of a task, composed of Parts.
Streaming: Real-time, incremental updates for tasks (status changes, artifact chunks) delivered via protocol-specific streaming mechanisms.
Push Notifications: Asynchronous task updates delivered via server-initiated HTTP POST requests to a client-provided webhook URL, for long-running or disconnected scenarios.
Context: An optional, server-generated identifier to logically group related tasks and messages.
Extension: A mechanism for agents to provide additional functionality or data beyond the core A2A specification.
- A2A Protocol Documentation
Agent Discovery in A2A
To collaborate using the Agent2Agent (A2A) protocol, AI agents need to first find each other and understand their capabilities. A2A standardizes agent self-descriptions through the Agent Card. However, discovery methods for these Agent Cards vary by environment and requirements. The Agent Card defines what an agent offers. Various strategies exist for a client agent to discover these cards. The choice of strategy depends on the deployment environment and security requirements.
The Role of the Agent Card
The Agent Card is a JSON document that serves as a digital "business card" for an A2A Server (the remote agent). It is crucial for agent discovery and interaction. The key information included in an Agent Card is as follows:
Identity: Includes name, description, and provider information.
Service Endpoint: Specifies the url for the A2A service.
A2A Capabilities: Lists supported features such as streaming or pushNotifications.
Authentication: Details the required schemes (e.g., "Bearer", "OAuth2").
Skills: Describes the agent's tasks using AgentSkill objects, including id, name, description, inputModes, outputModes, and examples.
Client agents use the Agent Card to determine an agent's suitability, structure requests, and ensure secure communication.
Sample Agent Card
{
"protocolVersions": ["1.0"],
"name": "GeoSpatial Route Planner Agent",
"description": "Provides advanced route planning, traffic analysis, and custom map generation services. This agent can calculate optimal routes, estimate travel times considering real-time traffic, and create personalized maps with points of interest.",
"description": "Calculates the optimal driving route between two or more locations, taking into account real-time traffic conditions, road closures, and user preferences (e.g., avoid tolls, prefer highways).",
"description": "Creates custom map images or interactive map views based on user-defined points of interest, routes, and style preferences. Can overlay data layers.",
This is an extract from a recent thoughtful SubStack post by Gennaro Cuofano, in The Business Engineer. The post discusses the AI advertising wars. This extract is about recent changes at the newly formed Agentic AI Foundation, a Linux Foundation initiative.
"What we’re witnessing is the emergence of a complete protocol stack for agentic commerce. Understanding how these pieces fit together reveals both the competitive dynamics and the cascading implications for the digital ecosystem." - Gennaro Cuafano
Note to self
Create a Pipi MCP Engine.
Look into the open-source protocols at the Agentic AI Foundation.
The post also discusses the war around payment protocols.
Home > Ajabbi Research > Library > Subscriptions > The Business Engineer
Home > Handbook >
Last Updated
28/01/2026
The AI advertising wars
By: Gennaro Cuofano
The Business Engineer: 27/01/2026
Creator of The Business Engineer, the deep-tech research hub, spun off from FourWeekMBA, the leading blog on business model strategy. Gennaro has over 10 years of experience as a deep tech executive.
...
The Protocol Stack: Five Layers of the New Commerce Architecture
What we’re witnessing is the emergence of a complete protocol stack for agentic commerce. Understanding how these pieces fit together reveals both the competitive dynamics and the cascading implications for the digital ecosystem.
Layer 1: Foundation Infrastructure
The foundation layer has effectively been won by the Model Context Protocol. MCP, launched by Anthropic in November 2024, has achieved what few technology standards accomplish in a single year: industry-wide adoption backed by competing giants. The numbers tell the story:
97 million monthly SDK downloads
10,000+ active servers
~2,000 entries in the MCP Registry (407% growth since September)
First-class client support across ChatGPT, Gemini, Microsoft Copilot, Cursor, and VS Code
In December 2025, Anthropic donated MCP to the newly formed Agentic AI Foundation under the Linux Foundation. This wasn’t an act of charity but strategic positioning—by making MCP vendor-neutral, Anthropic ensured its protocol would become critical infrastructure rather than a competitive weapon that might be forked or abandoned. As Mike Krieger, Anthropic’s Chief Product Officer, put it:
"A year later, it’s become the industry standard for connecting AI systems to data and tools.”
MCP now sits alongside two other founding projects under the AAIF:
AGENTS.md (OpenAI): Adopted by 60,000+ open-source projects for providing AI coding agents with project-specific instructions
goose (Block): An open-source, local-first agent framework
Agent2Agent / A2A (Google): Enables communication between autonomous agents, supported by 150+ organizations
The significance of this consolidation under the Linux Foundation cannot be overstated. These protocols are becoming the TCP/IP of the agentic economy—essential infrastructure that no single company controls but upon which all higher-value services depend.
Layer 2: Payment Infrastructure
The payment layer remains more fragmented. Google’s Agent Payments Protocol (AP2), co-developed with PayPal and backed by over 60 merchants and financial institutions, provides secure payment tokenization for agent-initiated transactions. It’s designed to work seamlessly with Google Pay and the broader Google commerce ecosystem.
PayPal → Google’s AP2 + Perplexity’s commerce features
This isn’t neutral infrastructure—the payment processors are choosing sides in the protocol wars, betting on which business model will dominate.
Layer 3: Commerce Infrastructure—The Battlefield
This is where the war is actually being fought. Two competing protocols with fundamentally different architectures and business models are vying to become the standard for agentic commerce.
Google’s Universal Commerce Protocol (UCP), announced at the National Retail Federation conference on January 11, 2026, was co-developed with Shopify, Etsy, Wayfair, Target, and Walmart, with endorsement from over 20 partners including Visa, Mastercard, American Express, Stripe, Best Buy, and Zalando.
UCP is a full-journey protocol covering:
Product discovery
Cart management
Checkout
Post-purchase support
Loyalty programs and returns (roadmap)
The architectural philosophy is revealing: UCP establishes a common language through which agents can discover merchant capabilities, negotiate supported features, and execute transactions. Merchants publish their capabilities via a .well-known/ucp file, agents discover what’s available, and transactions proceed through standardized primitives.
OpenAI’s Agentic Commerce Protocol (ACP), launched in September 2025 in partnership with Stripe, takes a narrower approach. ACP is checkout-focused—it solves the “last mile” of completing a purchase rather than the entire shopping journey. The protocol is Apache 2.0 licensed and explicitly designed to work across payment processors and AI platforms.
ACP’s architecture reflects OpenAI’s strategic position: they don’t need to own discovery (ChatGPT’s conversational interface handles that) or post-purchase (merchants handle fulfillment). They need to capture value at the moment of conversion. For merchants already on Stripe, enabling agentic payments requires as little as one line of code.
The scope difference is intentional. UCP gives Google a reason to keep merchants within its ecosystem across the entire customer journey. ACP lets OpenAI capture transaction value wherever discovery happens.
Another wonderful video interview by Kesnia Se from
Turing Solutionswith Raffi Krikorian, CTO of Mozilla. An excellent newsletter worth subscribing to.
I learn a great deal from every issue of this newsletter. Once Ajabbi becomes financially stable, this newsletter will be one of those generously supported by the future foundation.
Home > Ajabbi Research > Library > Subscriptions > Turing
Solutions
Home > Handbook >
Last Updated
26/01/2026
This Is a Fight Worth Having: The Case for Open Source AI | Raffi
Krikorian, Mozilla CTO
By: Kesnia Se
Turing Solutions: 24/01/2026
Dreamt about Turing Post since 2019, founded it in 2023, after a
successful launch of TheSequence (co-founded with Jesus Rodriguez). Board
member at Track Two: An Institute for Citizen Diplomacy, currently writing
a book about them. Previously: guest lecturer at HSE (Moscow, Russia);
Middlebury Institute of International Studies (Monterey, USA). Ex
editor-in-chief of TheQuestion, ex NY chief editor of Snob Magazine.
Contributor to Stratfor, Towards Data Science, The Startup, and others.
Writer.
Note: We planned to publish Week 2 of our Open Source AI series,
“The Real Math – when open source saves money, when it doesn’t”, but the flu
took over our house. We did manage to publish this interview though, which
aligns with the series. Watch it, it’s very interesting and gives you a
great sense of where open source AI is right now. Next week, we’ll publish
the real math. Let’s use this moment to learn what will be most useful to
you →
Which angle of open source AI economics matters most to you?
Enterprise only – real cost math, infra traps, and why most companies
miscalculate self-hosting
Personal use only – when local models beat subscriptions, and when they
absolutely don’t
Both – side-by-side breakeven logic for companies vs individuals
Myth-busting – where open source is oversold and proprietary APIs still
win
Now to the show: In the first episode of Inference’s quarterly series on
Open Source AI, we talk to Raffi Krikorian, CTO of Mozilla, about when open
source AI stops being aspirational and becomes an operational choice.
We explore why stories like Pinterest saving $10 million by moving to open
models are real, but often misunderstood, and why timing and maturity matter
more than ideology. Raffi lays out his view of a missing “LAMP stack for AI”
and explains why the hardest problem to solve isn’t models or data, but the
connective glue that makes it easier for developers to use open
source.
Along the way, he shares how Mozilla is navigating these tradeoffs in
practice, why even open-source-first organizations still rely on closed
tools during experimentation, and what the browser era taught Mozilla about
defaults, user choice, and long-term control.
Raffi is passionate about open source, but grounded in its real economics.
In this episode, he shares practical recommendations that apply even if you
are still experimenting. Listen closely.
In this episode of Inference, we get into:
Why experimentation favors closed APIs and production favors open
systems
How company maturity matters more than company size for cost
savings
What a real “LAMP stack for AI” could look like, layer by layer
Why choice and portability matter more than model loyalty
Mozilla’s bet on small, specialized models over one giant model
Why data ownership and user context are the real long-term
battleground
Concrete steps companies can take today to keep an exit door open
This is a conversation about choice, cost, and control in the AI stack.
Watch it!
This is a free edition. Upgrade if you want to receive our deep dives
directly in your inbox.
We prepared a transcript for your convenience. But as always – watch the
full video, subscribe, like and leave your feedback. It helps us grow on
YouTube and bring you more insights ⬇️
Ksenia Se: Hello, everyone. We're doing something different with
Inference by Turing Post this year. Starting with this episode, we're
dedicating each quarter to one topic explored through multiple
conversations. And this quarter's topic is open source AI. I'm starting with
someone who is reorganizing his whole company around this bet: Raffi
Krikorian, CTO at Mozilla. Welcome, Raffi.
Raffi Krikorian: It is such a pleasure. Thanks for having me.
When Values Meet Economics
Ksenia: Absolutely. But let me be honest with you about open source. I had
one problem recently with it. All the conversations sound very aspirational.
It's about freedom, it's about transparency, it's about ownership – but
that's not how companies do business, right? So from what you are seeing,
when does open source AI become an operational choice rather than an
ideological one?
Raffi: Well, on one hand, I'm actually kind of glad that you only have one
problem with it, because I think there are a billion problems in the grand
scheme of things. But no, I mean, I think you're exactly right. I think it
is an unfair thing to assume that open source wins because of values. It
needs to be this combination of values and economics that really work out in
order for it to make sense.
I mean, one shining hope right now – well, there are many shining hopes –
but one concrete example is at the end of last year, Pinterest put out a
report that they've saved $10 million by moving to open source rather than
relying on closed-source providers. And we're starting to see a bunch of
people have very similar comments. They've passed through the prototyping
stage and gotten into the steady-state utilization phase. Therefore, they
now know how to provision properly. They've figured out which models
actually perform quite well. So they're no longer paying a per-token cost
and instead absorbing that into the infrastructure.
If I were to make a prediction for 2026, we're going to start to see a lot
more of those types of stories starting to show up – that the economics and
the values are starting to align, or maybe just even the economics are
starting to align. And therefore these big companies are starting to make
that choice.
You know, another thing I've been thinking a lot about is this notion of
how to enable that choice to happen in the future in the first place. Things
like what we're building at Mozilla on the Mozilla AI team – for example,
this thing we call the Choice Suite (aka any-suite) – how things like the
Choice Suite can actually enable enterprises to be more flexible in how they
even negotiate.
I remember the days when everyone built directly on AWS. No one does that
anymore, right? They build on Terraform and all the other things. And what
that provides them is negotiating opportunities. When AWS says, "Well, it's
now going to cost $50,000," you can be like, "Well, Azure says it's only
going to cost me $30,000, and I have a Terraform script. I can just move
over very quickly."
I think those types of moments are going to start to show up this year. The
economics are going to start to work out.
The Maturity Threshold
Ksenia: I heard this case of Pinterest. But if you think about Pinterest,
it's a huge company with a lot of ML engineers that can be dedicated to the
switch. So when do you think it makes sense to switch – does company size
matter? Technical capabilities? Spend level? When is open source cheaper for
them, not just a principle again?
Raffi: Before we have the dollar sign or euro sign conversation, I think it
really goes to how fast can people move?
In the Pinterest case, when you read between the lines, what you implicitly
see is that they went past experimentation. They actually now know what
their use case looks like. They now know exactly the kind of application
they want to build and deploy. And now they can actually codify it and
fine-tune – fine-tune is overloaded – but build the exact infrastructure
they need in order to achieve their goals.
I think a version of that does play out on every single level. The reason
why it's about more than just a dollar sign is: when you go to a small
company, small companies by definition are still in the iteration phase.
They're still trying to experiment to see what works best for them. What's
the actual application they're trying to build?
And right now, I can't with an honest face say that they should be
experimenting with open source AI. The OpenAI API is kind of lovely, right?
It's one API call and it abstracts away all the stuff behind the scenes.
Whereas if you try to use open source software, you're cobbling together all
these different pieces, trying to figure out which evaluation provider,
which traceability provider...
So once they get past experimenting on what they want to build, and then
they want to get into production or they want to get into some form of cost
optimization or cost savings, then I think open source is positioned to be a
valid part of that conversation. So I don't think it's a dollar sign. I
actually think it's the maturity of the application that you want to
build.
Ksenia: When did it happen at Mozilla? I'm sure you were iterating and
experimenting a lot with both closed and open source tools and models. When
was this moment?
Raffi: I mean, we're actually still going through this moment right now.
I'm not sure I would say that Firefox is fully locked into exactly what
their AI-powered user experience really looks like. And I would also say
that things like the Mozilla AI team and other teams are still very deep
into using things like OpenAI API, Claude Code, et cetera.
Only a few of them have even started switching to things like Codex or open
alternatives. So we are actually still as part of this journey, trying to
figure out what we're going to do.
But I would say – you know, part of my job at Mozilla is to think about the
broader AI ecosystem. How can we do for the AI ecosystem what Mozilla did
for the web? How can we actually bring user choice? How can we actually give
credible alternatives that force openness in different parts of the
stack?
So my goal and the work that I'm trying to do is try to make it so that the
open source choice can happen earlier and earlier in that experimentation
process. For me, I think about Mozilla as a testing ground of the different
things we can be experimenting with as early as possible, even while we're
still trying to figure out what we want to do.
So we're not quite there yet, but that's maybe our North Star of what we're
trying to get done this year.
The Open Source Stack: A LAMP Moment
Ksenia: Let's talk more about the open source stack then, because – again,
another problem with open source – it's kind of one thing in theory. In
practice, it's multilayered. First of all, even the understanding of what
open source is is multilayered. So what is the stack? What are we looking
at?
Raffi: The thing that we need is a sort of LAMP stack definition. Right now
there isn't a good definition of what that looks like. But what I would
propose is that we should look at it on four different layers:
The compute layer
The model layer
The data layer (maybe we can argue which is lower – data or models)
The developer experience layer
And I think this replicates itself both on training and on the inference
side.
The conversation we need to have is: What do APIs look like? Or what do
standards look like between those layers so that we as an open source
ecosystem can start coalescing around this LAMP-like stack metaphor that can
make it really easy to deploy?
I'll note that one of the things we're trying to do with our Choice Suite
is provide maybe that top-of-the-stack opening. If you use the Choice Suite,
you get one API call that abstracts away a lot of things below it. So if you
use AnyLLM, which is one part of the Choice Suite, you call the AnyLLM API,
and then you can rapidly switch between different LLM providers – both
local, both remote, open, closed, et cetera.
So we're trying to embed choice into that conversation. And we think that
can apply for almost everything inside that developer tool suite layer, that
developer experience layer on the top of that LAMP-like stack. But we need
to do this over and over and over again across all the different parts of
the stack.
I want to live in a world where we have interchangeable components that
people can really choose what their LAMP stack looks like, and they can
assemble it rapidly. Maybe there's a set of blueprints that make it really
easy for small businesses to do it. Maybe there's a different set of
blueprints for enterprises, a different set for governments even. But I want
to figure out how to make that LAMP stack coalesce.
Ksenia: Is anyone building something like this?
Raffi: Lots of people are building parts of it. I think OpenRouter is a
good example. Things like MCP (Model Context Protocol), which allows calling
from the model layer, is part of this conversation.
I'm not saying that Mozilla needs to go build this all ourselves. My real
goal is to try to articulate: What are the things that developers are
looking for when you think about it as a full-stack component? And how do we
motivate and drive the community toward what are the standardization
opportunities?
Mozilla probably will only show up in that developer experience layer,
maybe in the data layer. But I want that ethos. I dream of a time when that
ethos goes through that entire stack.
The Vibrant Ecosystem
Ksenia:What are the companies that serve your ideal currently?
Raffi: There's a bunch of them. I think OpenRouter and Mozilla AI are good
examples when it comes to that top of the stack.
But I'm really excited about the work that people like AI2 (Allen Institute
for AI) are doing at the model layer, or ETH Zurich is doing at the model
layer, and others to try to figure out what really open models look
like.
I also think that there's going to be a lot of innovation in that model
layer, especially as we're coming to grips with the fact that it's
impossible for anyone to play in it. The Transformer architecture makes it
literally computationally and financially impossible. But at the same time,
there's a lot of evidence that these smaller language models or smaller
fine-tuned models from the pre-Transformer days might actually be the path
forward.
I'm intrigued by a lot of companies who are starting to build the
infrastructure for faster fine-tuning or model composability or things like
that on that layer.
On the data side, I'm of course really interested in things like what
Databricks is up to. Mozilla has a play with the Mozilla Data Collective
where we're creating a two-sided marketplace to make it really easy to have
provenance-related data that you can then license to any model trainer out
there in the world.
The Mozilla Data Collective folks are literally in conversation with every
radio station on the planet. They're like, "How do we license audio data
from every single language with a transcription of it?" And how do we scrub
it just good enough that model trainers can then use it?
So I'm intrigued by the people playing in that data licensing space and
others. And of course, that top of the stack – there are just so many
companies doing interesting work there. I'm really a big fan of what the
LangChain folks are doing. I'm a really big fan of what all the
orchestration layers are doing, the deepset people are doing on the RAG
layer.
I think there's so much – if there's anything people should take away, it's
that there's actually a lot of vibrancy in the open source ecosystem. I
think what's missing is a connective glue layer to just make it easier for
developers.
I want to live in a world where a developer finds it just as easy to use an
open stack as it is to use the OpenAI API. That's the world I want to live
in.
The one thing I didn't mention is that compute layer – that's going to be
the hardest for us to make a dent in. There are companies like Flower AI
that I'm intrigued by for federated learning across heterogeneous data sets,
heterogeneous hardware. That could be a way. Imagine a world where compute
was not a scarcity mindset, but it was an abundance mindset. That would be a
really interesting AI world for us to live in. So I'm intrigued by what that
federated space might be able to do there.
Specialization and the Twitter Analogy
Ksenia: I'm a big fan of federated learning. I think we still haven't yet
seen what it's capable of. And if we think about small models again, and
when they go to all the devices, how cool would that be if it all can be
connected and we're not dependent on GPUs or whatever big compute we
need?
Raffi: Exactly.
Ksenia: But if we talk about small language models, which I read in your
blog post you're betting on them as well – and that's what I noticed about
open source models when I was writing about it last week – is that we are
moving to specialization. It's not one big model for everything, but you
know, one for coding, one for this, one for that.
Again, if you talk about companies adopting it, when does it make sense to
connect three models, or again, use one big one? Because specialization is
great, but also it adds complexity. I'm just trying to build this
decision-making process for companies to be able to use open source.
Raffi: I look at it almost in the exact same way that I look at it from my
previous jobs. You know, when I was at Twitter a decade and a half ago at
this point, Twitter was written in Ruby on Rails. And then once we fully
understood what the application stack looked like, we started moving parts
of it to the JVM to harden it, to make it more efficient, to make it faster,
more performant, et cetera.
I think the exact same thing is playing out in this space right now. Like,
you know, I have a rack full of computers next to me right now that I hack
on on the weekends. And even I use the OpenAI API to do a lot of my work,
just to help me form an idea, to rapidly prototype, et cetera.
But then when I get to a place that I want to deploy it, I start looking at
it and think, "Oh, should I do this part in Qwen? Should I do this part in
something else?" So I think it's part of that maturity curve of ideas right
now.
You start in a place where you don't exactly know what you're doing. So you
need a general-purpose tool to help you sort that out. And as you start to
get more solidification in the kinds of things you want to build, that's
when you can start to really optimize and find the right model at the right
time.
Now there are also different constraints that you might want to take into
account, right? I might want to run things in a disconnected environment. I
might want to run things on-device versus not. I do a lot of work with open
source in an African context where the connectivity is not so great and you
actually want it to run on-device.
But again, you might build that experimental application in a really good
Wi-Fi environment. And then once you're actually ready to deploy it, then
you start either fine-tuning or you figure out what's the right model you
can run on-device so you can go into a disconnected environment.
Another example might be autocomplete on a web browser. You can imagine a
world – there's no reason for us to be sending all that information to a
large model remotely. Then you've added latency, you've added all these
things. You want to do that kind of work as close to the user as possible so
you can be really, really sensitive to keystrokes, really sensitive to
timing, really sensitive to battery power. If you're running it locally, why
hit the network for every single keystroke?
So I think those constraints might be part of the driving factor. But I
think the overall thing is still: as you go from experimentation to
production, somewhere along that line is the right time to think about
making those transitions. And my job is to move that line as close as I can
to experimentation.
Why Data Matters
Ksenia: Why does Mozilla focus so much on data?
Raffi: In the sense of user data and user privacy and things like that?
Well, I feel that data, especially in the AI world, is one of the biggest
tipping points. Besides the paradigm that most of the AI providers are
thinking about right now – which is "data is free, we just scraped it from
the web" – that might also just be last year's battle.
But I do think two things. One is there are a bunch of data sets that
haven't been on the web that could be really useful. And if we can change
the dynamics around them – whether it be indigenous languages or whether it
be genetic data of different communities, things like that – people might
deserve some form of either recognition or compensation for it. I find those
to be the human-centered version of data collection.
And so how can Mozilla enable that? I think it's a very important thing.
I'm excited by the work the Mozilla Data Collective is doing on making those
really easy to license, having one-click licensing mechanisms, one-click
purchasing mechanisms. We as Mozilla don't intend to make a lot of money off
that. We want to enable people to do it. We'll just maybe do a small
transaction cost, but we want to enable more interesting experiences to
happen on the web. But I want to do it in such a way that actually truly
respects the people that were part of that value chain to get you to that
experience.
But then there's the other question, which is: I really care – I feel that
if these big model providers have already treated data on the web as free
for them to use, they're coming after yours and my data next. They're going
to try to get to my private data and stuff that's near and dear to me.
So I'm really interested in data in the sense of: How do we start thinking
about protections for user context? How do we make user context portable
across different sets of model providers so that we can invert that
ownership paradigm? It's not that the model provider owns my context – I own
my context and I can make it portable and I can expose different aspects of
it depending on what we're trying to do at any given moment.
So that's the thing that I find interesting. I think it's very compatible
with how Mozilla thinks about the user agent. Right now, the web browser is
my agent. It's supposed to protect me. It gives me privacy. It protects me
from ads, et cetera.
But now in this new agentic world, this Layer 8 world where intelligence is
starting to mediate, that mediation is starting to not be my user agent
anymore. So I think that having my data be secure and private in that
interaction is going to be incredibly important.
Ksenia: This is a race so hard to win, considering that you can just push a
button and everything in your iPhone becomes connected to Google services
and then it's personalized AI, but also your data is out there in the air.
So I don't know how to win this race for open source.
Raffi: Yeah, I mean, I don't know the answer either, but I think this is a
fight worth having. And I think it starts with having some credible
experiences that we can really talk about and how we want to show up to
users.
So my canonical example here is Signal. Signal showed up in the sense that
it drove privacy as part of the communications conversation. It wasn't even
needed for every single user to use Signal. But the fact that Signal existed
forces people like WhatsApp, Telegram, iMessage – now RCS is starting to
think about having to have encryption on it because it's being driven by
that conversation.
So if Mozilla or people aligned with the Mozilla Manifesto and our values
can start building what these interfaces could look like where my context
stays with me and doesn't move and can still be useful in a lot of ways, I
think that could be something that could just drag the ecosystem a little
more toward user privacy than where we are today.
Ksenia: Conversations matter.
Raffi: Correct. Conversations matter.
The Firefox Lesson
Ksenia: Here's a little tricky question. Mozilla has a fascinating history.
What you're saying is that what you did with the web, you want to do with
AI. At one point, Firefox indeed challenged Microsoft, brought it down to
55%. But then Chrome came and brought Firefox to 5%. So how can we make sure
that the world of AI, even if we disrupt it first, will not be consolidated
again?
Raffi: I think these are all pendulum swings. And so I would note that even
though Firefox's usage has gone down, Google had to release an open source
browser. We had to still maintain web standards. We still had to do all the
things.
So the battle that we were trying to win by releasing Firefox – we won it.
We might not be that big pillar that everyone's using anymore, but it's
because of us that the web is open. It's distributed, et cetera.
And so yes, there's some consolidation that occurred, but the important
thing is web standards. The important thing was open source as part of the
conversation. The important thing is that anyone can still participate in
the web.
That's not the direction AI is going in right now. And so that's why I'm
trying to drag Mozilla into that fight. Because if we can start to drive the
conversation through credible alternatives, web standards, more people using
it because of open source – I think that exact same playbook might work
again in this space.
And sure, we're not going to be the model provider. There's not enough
money in the world for us to compete on the model side. But I think if we
can just get the other pieces in place, we can get an entire ecosystem
speaking the same language. And I think it's kind of like a rebel alliance,
almost, that we can start to give credible alternatives and drive the
conversation. We're all part of the rebel alliance for different
reasons.
But in the end, if it means that user data is secure, context is ours not
someone else's, there's choice in the ecosystem, I can trust the outputs of
the LLMs and trust the outputs of the chatbots, if I can surf the web
without being worried – then Mozilla will have won that fight. And that's
the fight that I'm trying to take.
Practical Steps for Companies
Ksenia: It's a very important fight. I'm just trying to see from a
company's perspective how to showcase to them that they should try. And if
you can give advice to a company that is still in the experimentation mode,
what will be your one, two, three steps for them to start thinking about it?
How to implement open source for their company?
Raffi: What I would say for a company is: Try to instrument choice into
your engineering stack as early as you can.
This is the reason why we built things at Mozilla AI like the Choice Suite.
It's really easy to do. It's just a small shim. Put those things into your
application as early as you can. You don't know when you might want to
switch to open source. You don't know when you're going to exit your
experimentation stage. But give yourself the exit door as early as you can
so that you can then do it later when the time is right.
Don't make it a massive Herculean engineering effort later. Make it super
small. It's like an NPM install or a UV install and you just do one line of
code or five lines of code. You just do that at the beginning, and that
investment gives you the exit door later.
So try to do those types of things as early as you can. Just like any good
engineer would – engineers are usually thinking about: How can I refactor
this later? How can I test this later? How can I do all those things later?
So just think about those things as early as you can in the process.
And Cursor and others also take those prompts really quite well. You'd just
be like, "I want to integrate AnyLLM into this," and it just happens. It
might not even be five lines of code. It might just be one prompt you do at
the beginning of your project that gives you that flexibility later. So
that's, I think, the biggest piece of advice.
And then the second one is: Just be open and see what's going on in the
ecosystem. Like I said before, the vibrancy in the open source ecosystem is
quite amazing. It's quite lovely. So go read your favorite blogs. Listen to
people like you to understand what's going on out there. Because maybe one
of those things you'll be like, "Oh, I should swap that for that," and it
could show up as part of that conversation.
Making It Simple
Ksenia: I would like to have a clear understanding: How can a child or a
non-technical person just install an open source model and just use it for
whatever, for their phone? That should be easier.
Raffi: I would love to get to that world! That world is not the world we
live in yet, but I think we can get there.
Ksenia: This year, right?
Raffi: 100% this year! I mean, like right now, any person on a Mac who can
pull up a terminal can install a local open source model with just brew
install ollama, right? It's already a one-liner, but you need to know how to
use a terminal.
So we can just eliminate that this year. That would be amazing, right? I
feel like we can get there. I feel like this is a slam dunk. We just got to
do it.
Einstein's Dreams
Ksenia: Well, that's been a very fascinating conversation. And I
like to finish all my conversations with a question about a book. A book
that recently or long ago influenced how you think about life and how you
think about your work, your values. What was that book?
Raffi: Oh, that's such a great question. And I'm not prepared for
this question.
I would say that one of the books that probably has most impacted me is a
book by Alan Lightman called Einstein's Dreams. And so what it is is a set
of vignettes – I want to say it's 20, I could be wrong on the number – which
are all different versions of how time could flow differently.
What if we lived in a world where time moved slower the higher altitude you
were? Or what if we lived in a world where time went in a circle over and
over and over again? And what would that mean as implications to life, love,
friendship, et cetera?
And so that was literally the first book I ever gave the woman I was
dating, who then became my wife. So if you were looking for one book that
changed my life, that was probably the book.
Ksenia: That's amazing. I would love to read this book. It sounds
very interesting. Thank you so much. Thank you for this conversation. Let's
hope this year will make a lot of progress in open source.
Raffi: Thank you for having me. This was such a pleasure.
