A $200M Bet on AI That Works for the Machine: doubleAI Launches Code Execution Model Maxwell

Lede

October 19, Tel Aviv. The man who took Mobileye from an Israeli lab to Nasdaq and then sold it to Intel for $15.3 billion has announced that AI is getting a new boss to work for. Amnon Shashua's new company, doubleAI, announced two things on the same day: a $200 million Series A financing round, and a brand-new model category — Code Execution Models (CEMs) — with the first model, Maxwell, opening early access at heymaxwell.ai.

The most striking line in the official press release comes from Shashua himself: "CEMs, and Maxwell in particular, are agents on behalf of the hardware as opposed to code agents that are on behalf of the human user. In other words, they are the first AI that works for the machine, not the programmer."

For the past two years, coding agents have competed on "writing code for people"; doubleAI is betting on the other half of the battlefield — what happens after code starts running. If this read is right, the second half of AI programming won't live in the editor. It will live at runtime. This piece lays out the facts, the logic, and the skepticism, all at once.

The facts: who, what, and whose money

doubleAI is registered as AA-I Technologies Ltd., headquartered in Tel Aviv. Founder Amnon Shashua is a legend in Israeli tech: a computer science professor at Hebrew University, co-founder and former CEO of Mobileye, which he led all the way to a Nasdaq listing and ultimately a $15.3 billion acquisition by Intel — the largest tech acquisition in Israeli history at the time. This year he stepped down as Mobileye CEO, and earlier left AI21 Labs, the foundation-model company he co-founded, to go all-in on doubleAI. One detail says a lot about his style: Shashua is among the rare few who reached the top in both academia (computer vision, formal methods) and industry (Mobileye's EyeQ chips) — and CEM sits exactly at the intersection of those two résumés, demanding both AI expertise and the ability to land proofs on silicon.

The team is about 40 people, mostly PhDs spanning computer science, mathematics, physics, and biology, according to Israeli outlet CTech. The press release describes "a team of elite Ph.D. researchers" and states the mission bluntly: "building AI that out-reasons experts." Forty people against $200 million — $5 million per head — is the classic frontier-lab playbook: no headcount sprawl, just density.

The $200 million Series A was co-led by Lightspeed Ventures and Bessemer Venture Partners, with a heavyweight follow-on list: NVIDIA, Dell Technologies Capital, Greenfield, Pitango, and BRM. CTech puts the post-money valuation above $1 billion — doubleAI was born a unicorn. The investor mix is worth savoring: NVIDIA and Dell, the kings of compute and servers respectively, aren't buying financial returns here. They're buying an option on a variable that could change the "compute utilization" business itself. If CEMs can multiply the effective output of existing hardware several-fold, the biggest winners are precisely the people who sell hardware — the same chips, but magically more "available compute." The strategic intent of this round was written into the LP list from day one.

So what exactly is a CEM? Per the official release, it puts intelligence somewhere it has never been before: "between code and silicon." Unlike coding agents, which take human instructions and produce source code, a CEM takes three inputs — the running program itself, the hardware it runs on, and the data flowing through it — and produces "instructions meant directly, and only, for the machine." The source code written by humans and coding agents stays exactly as it was; Maxwell continuously inspects the binary underneath as the program runs, rewriting it to fit the exact hardware, data, and live workload it encounters. In the release's words: "Maxwell watches code as it runs, rewrites the binary under the code, and fits it to exactly what the machine is doing."

The whole play rests on one hard constraint: every rewrite must be formally proven correct. The release states it without hedging: "Maxwell formally and mathematically proves that every optimization it unlocks leaves the program's behavior unchanged." Note the strength of that claim — not "passes tests," not "probably fine," but mathematical proof. This is the most technically substantial and hardest-to-dismiss plank in the entire narrative, and we'll unpack it separately below.

On early access itself, public detail is thin: heymaxwell.ai is live, but selection criteria, supported languages and runtimes, and whether an API is offered are all undisclosed. For working developers, the only move right now is to join the waitlist — and wait for the first admitted users to publish real evaluations. Until then, every technical judgment in this piece rests on the text of the official release, and that needs to be said up front.

Why now? Three conditions just aligned. First, model reasoning finally reached the level of "understanding program semantics" — without LLM-grade code comprehension, binary rewriting is blind mutation. Second, the formal-verification toolchain (SMT solvers, proof assistants like Lean) matured to the point of being callable as engineering infrastructure; doubleAI claims "breakthroughs" in verification, and Shashua's academic background lends that claim extra credibility. Third, compute got expensive enough that "saving compute" became a big business in its own right. When GPU hours sell by the dollar and data centers have waiting lists, any technology that doubles the utilization of existing hardware deserves $200 million. Missing any one of these three, CEM stays a paper concept.

doubleAI's self-reported performance numbers are aggressive: in NVIDIA's open-source cuGraph library, over 55% of algorithms run 2x or faster; pandas runs 38x faster on the PDS-H query benchmark; AI inference kernels run 4.5x faster; the company's own LTX-2.5 world model generates video 2x faster. Both CPU and GPU are supported — the release pointedly says "either CPU or GPU," clearly not wanting to be dismissed as yet another CUDA-only GPU optimizer. The business model is equally novel: charge based on "the compute cost saved for the customer." Not a software license, not a per-token API, but a cut of verifiable compute savings — save $100, we take a share. It's pricing that monetizes technical outcomes directly. Ambitious, and full of pitfalls.

The curiosities are worth noting too. Maxwell broke a nearly 50-year-old chess record — checkmating in 63 moves (the old record was 60) — offered as a playful proof of the model's reasoning ability; the company's internal agents also made a new discovery in graph theory, shipped with a Lean formal-verification file — a clear signal to academia: we do real proofs, not just engineering. Separately, via a dailyaibrief citation of the WSJ, roughly half of the $200 million will go toward buying 1,000 NVIDIA B300 chips. That's secondhand and unconfirmed by the company, but it carries its own absurd humor: a company that charges for "saving you compute" first needs to burn $100 million buying compute.

Analysis 1: coding agents handle the "writing," CEMs handle the "running" — the second half is at runtime

Spread out the last two years of the AI coding wave and you'll see it only solved half the problem. Cursor, Claude Code, and Codex answer "how to write code faster," and their work ends at git commit. But the real cost of software isn't in the writing — it's in the running: always-on services in data centers, data pipelines re-run every night, training and inference jobs that burn tens of thousands of GPU hours. Writing the code is just the beginning; the machine executes it as written, and one inefficient loop can quietly burn the price of a car over three years. Code authors are desensitized to the cost of "running" — the cloud bill arrives monthly, inefficiency gets averaged out, and nobody can say exactly which line is burning money.

Traditionally, "running fast" belonged to compilers, JITs, performance engineers, and SREs — highly specialized, highly manual work. A senior performance engineer spending three weeks shaving 20% off a service's P99 latency is the kind of war story worth a blog post. doubleAI's insight is that runtime is exactly where static code can't keep up. The release puts the logic well: "Up until now, software has been static. Humans and AI agents write code, and that code is then carried out by the machine, exactly as written. But the environments it runs in are dynamic." Hardware, data, and usage shift constantly; the best version of a program can change by the hour, and static code can't keep up — that, structurally, is why hardware sits underutilized.

Put differently: the last two years of AI solved the efficiency of producing code, while the efficiency of executing code sat untouched. What a compiler can do at compile time is limited because it can't see runtime data distributions; human performance engineers can see them, but human effort doesn't scale to every line of code. CEMs aim at precisely this gap: an optimizer that never sleeps, stares only at live load, and can mathematically prove every change it makes.

There's a macro angle worth spelling out. The release opens with: "The promise of CEMs is in multiplying available hardware, through their ability to unlock a vast share of compute that sits idle today." It's an open secret in the data-center industry that vast compute sits underutilized year-round — redundancy reserved for peaks, stalls from data skew, conservatively written code. The old answers were "buy more cards" or "move to pricier cloud," both additive. CEMs are multiplicative: no new hardware, just more work out of old hardware. When compute becomes "one of the world's scarcest resources" (the release's own phrase), multiplication beats addition — which is also the deeper reason NVIDIA was willing to co-invest: CEMs won't reduce GPU demand; they'll make every GPU worth more.

So a CEM isn't a coding agent's competitor — it's its second-half partner: coding agents write for you, CEMs run for the machine. One works for you, one works for the machine. It sounds like marketing, but it describes a real transfer of labor — the first time AI's optimization target switches from "human-readable text" to "human-unreadable binary." The definition of programming is being stretched: from "writing correct code" to "making code run faster and faster in the real world."

Analysis 2: formal verification is the admission ticket, not a bonus

Why hasn't anyone done this before? The answer isn't AI capability — it's trust. Rewriting code at runtime gets zero human review; conventional AI models make mistakes; and one bad binary rewrite can take down a live service or miscalculate a trade — a completely asymmetric cost model. The most important sentence in doubleAI's release isn't a performance number, it's this: "Until now, AI has never been trusted inside running software: changes made while code runs get no human review, and conventional AI models can make mistakes."

Formal verification is the admission ticket. For readers unfamiliar: ordinary testing is spot-checking; formal verification is mathematical proof — not "probably correct" but a rigorous proof that the rewritten program behaves identically to the original. It's an extremely high bar, and an extremely clever positioning move: it turns "AI rewriting code" — something everyone does but nobody dares ship to production — into a provable, auditable, accountable engineering act. Without that proof, a CEM is just a more dangerous superoptimizing compiler; with it, a CEM can claim to be "the first AI that lives inside running code."

Shashua's background matters here. Mobileye's EyeQ chips are automotive-grade; every line of critical code in autonomous driving goes through formal verification — he has actually used this methodology at production scale, not just cited papers. That's the credibility behind writing "formally proven correct" into a press release: verification isn't an outsourced gimmick, it's the founder's home turf.

Of course, the boundaries of the proof deserve interrogation — and must be interrogated. Formal verification guarantees semantic equivalence: the rewritten program does the same thing in the mathematical sense. It does not guarantee timing (what about real-time deadlines?), side channels (could the rewritten instruction sequence leak timing information?), or numerical stability under extreme inputs (floating-point reassociation is a classic trap). More importantly: who generates the proof of "the model's rewrite," with which solver, and has it been fully checked? The release says nothing. Real behavior in early access remains to be seen. But the direction is right: when AI starts touching production binaries, "provably correct" should be the minimum bar, not a bonus. doubleAI at least drew the line in the right place.

Analysis 3: not a compiler replacement — AI-ified PGO

Hearing "rewriting binaries at runtime," many engineers' first reaction is: isn't that just JIT? Isn't that just profile-guided optimization (PGO)? The analogy is half right, and the wrong half is the interesting one.

The right half: JIT and PGO do collect runtime profiles and optimize accordingly — the philosophy overlaps: "watch how it actually runs, then decide how to optimize." The wrong half: they work by "applying preset rules as local transforms." Inlining, loop unrolling, branch prediction, vectorization — decades of compiler-engineer experience encoded as heuristic rules, with the optimization space capped by the rules' ceiling. PGO can tell you "this branch goes true 90% of the time," but it will never discover that "this graph traversal should use a completely different algorithm under the current data distribution."

A CEM does something else: it hands the full performance-engineering loop — observe, hypothesize, verify, rewrite — to the model. That self-reported "55% of algorithms 2x faster" in cuGraph, if true, hints at algorithm-level rewrites rather than instruction-level tuning — because instruction-level tweaks rarely squeeze a stable 2x out of a mature open-source library. The 4.5x on AI inference kernels is even more intriguing: inference kernels are among the most brutally optimized code on earth (hand-written CUDA, Triton tuning taken to the extreme). If Maxwell can still find 4.5x there, what it found likely exceeds human tuning intuition. All of this, of course, rests on "if the self-reported numbers are true" — skepticism gets its own section next.

So the sharper positioning is: CEMs are AI-ified, always-on PGO. They don't replace compilers; they stand on compilers' shoulders — compilers solve "fast and correct," CEMs bet on "faster the longer it runs." One easily missed line in the release: "Every proven, faster version becomes the starting point for the next, so programs keep getting faster for as long as they run." That's a compounding model: optimization isn't a one-time deliverable but a process that accumulates with runtime. Traditional PGO takes one profile and goes stale; a CEM's profile is alive, drifting with the data distribution. That's the real ambition behind "between code and silicon" — software morphing from static artifact into living thing.

Analysis 4: the skepticism — all numbers are self-reported; "pay for saved compute" has three hurdles

Cool down. Every performance number in the release — 38x, 4.5x, 2x, 55% — comes from doubleAI itself. No independent reproduction, no published benchmark methodology, no open reproducible test harness. pandas at 38x sounds stunning, but PDS-H is a query benchmark; data-pipeline speedups depend heavily on data distribution, query patterns, and the baseline version: which pandas release was compared, with how much parallelism? Change the workload and the number could look entirely different. "55% of algorithms 2x or faster" in cuGraph is similarly short on controls: what compiler flags was the baseline built with — official release or debug build? Which algorithms are the 55%, and what about the other 45%? All undisclosed in the early-access phase.

This isn't to say the numbers are inflated; it's to say that at the early-access stage, their marketing weight far exceeds their engineering weight. A startup launching a new category needs narrative momentum on day one, not peer review. The convincing evidence will have to wait for two things: independent third-party reproductions, and real invoices from paying customers. Until then, every number should be read as a "ceiling demo," not typical performance.

The bigger question mark hangs over the business model. "Pay for the compute you saved" sounds beautiful and has three hurdles in practice. First, who decides how much was saved? It needs a metering system both sides accept: how is the baseline set? If traffic growth drives compute up, does that count as "not saved"? Without agreement, every invoice is a dispute. Second, are savings durable or diminishing? If Maxwell eats all the available headroom in year one, why would the customer keep paying in year two — the renewal logic of this business is naturally diminishing, unless the workload keeps changing (fortunately, in reality workloads do keep changing — the most defensible plank in the CEM narrative). Third, security and compliance: letting an outside company's AI live inside your production binaries, continuously rewriting machine instructions — what level of audit does that mean for finance, healthcare, or government customers? Does data ever leave the customer environment? Who hosts the proof artifacts? The release says nothing, yet these are the top three items on any enterprise procurement checklist.

There's also an irony worth savoring: per the secondhand report, doubleAI plans to spend half the round on 1,000 B300s. Even if the report is wrong, it points at a structural tension — training and running CEMs is itself extremely compute-hungry. Saving compute with compute only pencils out if the input-output ratio works: spending $1 of compute on the optimizer must save the customer $10 to make sense. The company hasn't mentioned that number at all.

NVIDIA and Dell writing real checks shows the industry buys the direction; buying the direction is not buying the numbers. Stay excited, stay skeptical — the right posture for reading any AI startup press release.

What it means for vibe coders: slow code gets "eaten," and the "compute tax" gets a price tag

For people who write code with AI every day, the psychological shock of CEMs may exceed the technical one. Vibe coding's implicit assumption has been: ugly code is fine as long as it runs; performance is a later problem — and "later" usually means "never." CEMs drag "later" into "now": the O(n²) loop you vibed out could get rewritten and eaten by Maxwell on day one of deployment, emerging as O(n log n) machine instructions. You might never even know it happened — just as you never notice how much optimizing your compiler already does for you.

Will this let programmers abandon performance awareness entirely? Quite the opposite — it may birth a new cost concept: the compute tax. Inefficient code used to cost invisibly, averaged into the cloud bill, with nobody able to name which line was burning money. Services like CEMs put a precise price on waste: "your code was going to burn $100; after my optimization it burns $30; I take $20." When waste gets an exact price, code authors see for the first time what each line actually costs. One of vibe coding's biggest criticisms is "AI-generated code runs but isn't elegant" — the compute tax translates "not elegant" into money. That may, in turn, educate a generation of AI programmers to be more cost-sensitive — not because they learned hand-written assembly, but because the bill finally speaks.

The deeper impact is on debugging and mental models — the most underestimated part. When the binary running in production no longer maps one-to-one onto your source, "reproducing the bug" gets weird: the culprit might be an interaction between one of Maxwell's rewrites and a specific data distribution, and your source will never reproduce it in test — because the test environment's data distribution differs, Maxwell would never have made that rewrite there. The classic "works on my machine" upgrades to "works on the unoptimized build." Observability tooling has to catch up: every binary rewrite needs a version, a proof, and a rollback, or on-call engineers will lose their minds. doubleAI's release says nothing about this layer, but it's the mandatory road from early access to production — and a new opportunity for observability vendors.

There's a subtler shift too: semantic clarity becomes more important than execution efficiency. If runtime AI owns "fast," humans (and coding agents) should own expressing "what I want" unambiguously — clean interfaces, explicit invariants, complete tests. Ambiguous code is code the AI won't dare touch (it can't construct the proof); clearly written code is code the AI can freely optimize. Tomorrow's code aesthetics may bifurcate: the human-read parts optimized for readability, the machine-run parts handed to CEMs, and the contracts connecting them — types, assertions, tests — becoming more important than ever.

Finally, what this means for indie developers — the layer VibeFix readers should care about most. Performance optimization has historically been a big-company privilege: only teams that could afford dedicated performance engineers and profiling infrastructure got to play the "shave 20% off P99" game. Indie developers and small teams settled for "it runs," because human time cost more than machine time. If CEMs actually work, that privilege gets democratized — your app gets faster overnight while nobody watches, and your cloud bill shrinks by morning. Vibe coding solved "one person can ship a product"; CEMs might solve "one person's product can run as lean as big tech's." The caveat is pricing: "a cut of savings" is win-win for large customers, but for a side project burning a few hundred dollars a month, the savings base may be too small to cover the service cost at all. doubleAI hasn't published early-access pricing — small teams should keep watching that line.

Three practical suggestions for vibe coders. First, keep writing with AI, but start reading profiles: not hand-written assembly — just build the habit of glancing at a flame graph before each deploy and knowing where the hotspots are. Five minutes is enough. When "runtime AI" optimizes for you, you'll at least understand what you're paying it for. Second, write complete tests: CEM formal verification guarantees "the rewrite is equivalent," but it can't guarantee "your original semantics were right" — tests are the only anchor of semantics, and the faster AI writes code, the less you can skimp on them. Third, don't rush into early access: let the dust settle, wait for independent evaluations and the first paying customers' invoices, then decide whether to hand your production binaries to a 40-person startup.

Transparency notes

Core facts in this article come from doubleAI's official BusinessWire press release dated October 19, 2026 (read in full), including: the CEM category definition and "between code and silicon" framing, Maxwell's early access at heymaxwell.ai, the formal-verification claims, the $200M Series A and investor list (co-led by Lightspeed and Bessemer; NVIDIA, Dell Technologies Capital, Greenfield, Pitango, BRM participating), and the self-reported performance figures (55% of cuGraph algorithms 2x+, pandas PDS-H 38x, AI inference kernels 4.5x, LTX-2.5 video generation 2x, CPU/GPU support). The following are secondhand and labeled as such in the text: the above-$1B valuation and ~40-person mostly-PhD team, from CTech's October 19 report; the "half the round for 1,000 NVIDIA B300s" via dailyaibrief citing the WSJ, unconfirmed by the company; SiliconANGLE's October 19 coverage as cross-reference. Background on Shashua stepping down as Mobileye CEO, leaving AI21, and Intel's $15.3B Mobileye acquisition comes from public career records. All performance figures and the 63-move chess record are vendor-reported and unverified by independent third parties as of publication. Billing rules, metering methodology, and data-security terms for "pay for saved compute" have not been disclosed. The analysis section reflects the author's views and is not investment advice.