Start with the irony. Excel has outlasted four decades of software built to unseat it, and it got its own start by unseating someone else. It did not invent the spreadsheet. Dan Bricklin and Bob Frankston did that with VisiCalc in 1979. Microsoft's first try, Multiplan, chased VisiCalc and lost to Lotus 1-2-3. Excel was the second try, begun in 1983 under the code name Odyssey, and it was built to take Lotus's market by staying compatible enough to pull Lotus's users across. It even copied Lotus's date bugs to make the migration painless. Ripping off a successful program was routine. It was also a slog: months or years of reverse-engineering by a room full of engineers. What changed lately is the price. You can now, up to a point, prompt for it. That shift made cloning cheap in some places and left it expensive in others, and the gap between those two conditions is the interesting part.
Two recent projects sit at opposite ends of that gap. One is Ammaar Reshi's port of Command & Conquer: Generals Zero Hour to the iPhone and iPad, built by pointing Claude Code at the problem and letting it grind. The other is Matthew Berman's, who told an agent to clone Excel outright and let it run for twelve days. The first took an afternoon and shipped. The second produced a clone its author called perfect, which turned out to mean the part of Excel you can see in a demo. Same category of task, different distances covered. The reason is not that one person had a better model. It is what each of them could check their work against.
The easy end: a port wearing a clone's clothes
The C&C story got told as a clone. However, that's not accurate: it was a port - not a clone. The distinction matters and it changes what it proves.
Three things were already true before Reshi started. EA had released the full Generals and Zero Hour source under GPL v3 in early 2025, so the actual engine code was on GitHub. A community project, GeneralsX, had already done the genuinely hard part: getting a DirectX 8, Windows-only, 2003 codebase to compile and render on non-Windows platforms at all. And the original still ran, so its behavior was sitting right there to compare against. Reshi forked GeneralsX and had Claude Code add the Apple layer: the iOS and iPadOS build, the file-system redirection (the engine expected a writable PC disk, an iOS app gets a locked, code-signed bundle, so saves and cache paths had to move), and touch controls for a game that only ever knew a mouse. When people checked the commit graph afterward, his fork came to about twenty commits on top of a two-thousand-commit base.
None of that diminishes the result. Zero Hour running natively on an iPhone with touch controls is a real thing that did not exist a week earlier, and the debugging was real work. But the starting position was the strongest one an agent can have. The source was the specification. A working reference build told you what "correct" looked like. The running original let you diff behavior directly. When the model got something wrong, the loop that caught it was cheap and fast: compile, run, look, compare, fix. Reshi burned through his entire Claude Max quota over two days doing exactly that. An afternoon is what a large, boring translation costs when nothing has to be guessed and everything can be checked.
The hard end: cloning the bugs
Now point the same kind of tool at Excel, with no source code to stand on. Someone already has, in public and at full ambition. Matthew Berman handed OpenAI's Codex a six-word goal, clone Excel, full feature parity, and let it run. The agent opened the real Excel on his machine, studied every feature it could find, and rebuilt them in its own window. It ran unsupervised for twelve days before he stopped it, and the result was genuinely impressive: adjustable columns, cell formatting, live formulas, sorting, a thing you could squint at and take for the original. Berman called it perfect.
But perfect is the wrong word here. What the demo shows is the core: type one plus two and get three, sort a column, format a cell. What twelve days does not surface is the rest of Excel, which is most of Excel: several hundred more functions, pivot tables, the macro language, charting, the order in which a sheet recalculates, and the file format that every existing spreadsheet is already written in. Full feature parity was the instruction in the prompt. It was not the thing on the screen. The clone reproduced the part you can see in a two-minute video, which is the part that was never the hard part.
The reason the rest does not come cheap is that a clone anyone can actually switch to has to read and write those existing files and compute the same answers, down to the cases where Excel is wrong on purpose. The famous one: Excel treats 1900 as a leap year, so it accepts February 29th, 1900, a day that never existed. Microsoft inherited that from Lotus 1-2-3 for file compatibility and has kept it ever since, because correcting it would shift every date serial in every workbook on earth. An Excel engineer once told Joel Spolsky it was the only way to import Lotus worksheets.
That bug is now a written requirement in the OOXML file-format standard behind .xlsx. A strictly correct, Gregorian implementation is the non-compliant one, and it will silently disagree with every real file and every other copy of Excel. So the specification you have to match is not "what a spreadsheet should do." It is "what Excel does," mistakes promoted to requirements included, and the leap year is only the mistake that happened to get written down. The rest of the behavior you would have to match lives nowhere but in the running binary.
That is why coverage is the expensive part, and it is worth being careful about what those twelve days actually proved, which is less than the headline. Berman's agent could check itself against the live app for anything it thought to try, which is how it nailed the core. The tail is everything nobody thought to try, and it is vast. Berman's own read was that with more time the agent might eventually get all of it. He might be right. Nobody has shown that the tail closes, and nobody has shown that it cannot; this is one anecdote, telling but not proof. What it does establish cleanly is the shape: the core is cheap and fast, and everything after it costs progressively more.
The axis is verification, not source code
The tempting way to describe the gap between those two projects is "one had the source and one didn't." That is close, but it points at the wrong variable.
Not having the source does not mean you have nothing to check against. Even cloning Excel from behavior, real Excel is sitting right there, and you can compare cell by cell for any input you can dream up. You have a reference to check against. What you lack is a complete and cheap one. The variable that actually orders these tasks is the completeness and cost of verification, not the presence of source. C&C is the good corner: the reference is the source itself, verification is close to total, and each iteration is a fast compile-and-diff. Excel is the bad corner: the reference is observable behavior over an input space you cannot exhaust, so verification is partial and every additional nine of coverage costs more than the last. Everything else people call "cloning" is a point on that one line.
This also explains why coding and math ran ahead of everything else these past two years, and there is nothing mysterious about it. Those are the domains where a machine can check its own work for free. Code compiles or it does not. A test passes or it does not. The whole reason the C&C port works in a loop at all is that the loop has a cheap, honest judge at every step. Take the judge away, or make it expensive, and the same model stalls. Reshi's note that Opus 4.8 could not finish the port until he switched models is a capability data point, but it sits on top of the more basic fact that the task was checkable in the first place. No amount of model quality rescues a task you cannot cheaply check.
So the real frontier of automatic cloning is the frontier of automatic verification. Progress looks like models getting better at two specific things: inferring hidden behavior from the outside, and building their own test harnesses to check a reproduction against a reference when nobody hands them one. As they get better at building their own reference from behavior, the line between the C&C corner and the Excel corner moves. It moves from the bottom up. The top of the space, where behavior cannot be observed at all, or where the thing of value was never reproducible logic, does not get crossed by better checking.
You clone the slice, not the app
All of that assumes the goal is to reproduce the whole thing. It almost never is, and that assumption is the one "cover all functions" smuggles in. The reason full parity is so expensive is that its specification is "everything Excel does," an unbounded set nobody wrote down. But the reason you opened Excel this morning was a budget, a tracker, a table with three formulas. That slice has a specification you could write on an index card, and you are the person who can write it.
Cutting the scope to what you use changes the problem from the last two sections. It takes the unbounded, undocumented surface that made verification hopeless and replaces it with a small, bounded set you know completely. You stop needing a reference you cannot build, because you become the reference. The handful of functions you actually use are checkable in an afternoon, and when you later need one more, you add it to the tool instead of reproducing the four hundred you will never touch. The artifact is not a frozen clone you have to finish. It is a small tool that grows when you hit a wall.
This is why feature parity is the wrong test, which I argued at more length in The End of Renting the Small Things. A personal Trello clone does not fail because it lacks enterprise administration. It fails only if the person using it needed enterprise administration, and most of the time nobody did. This is the shift that is actually underway, and it is the quiet one: not a whole application conjured from a sentence, but the useful slice of one, scoped to a single job and extended when the job changes.
Cloneable is not the same as displaceable
There is a last trap in the "software is a commodity now" reading, and Excel is the cleanest place to see it. Even a perfect clone of Excel would not dislodge Excel.
People have been trying to replace it for years. Bloomberg ran a whole feature on Excel as the AI-resistant core of a multi-trillion-dollar business, and the recurring finding is that the would-be replacements are copycats or add-ons that end up producing Excel-compatible files anyway. One Andreessen Horowitz partner's summary of the startups in the category is that they all sit on top of Excel rather than replacing it. The calculation engine is crackable. The value of Excel was never in the calculation engine. It is in the install base, the file format everyone already exchanges, the muscle memory of somewhere between 750 million and a billion users, and the trust that the number in the cell is the number. A clone inherits none of that on day one. Which is why the pressure on an incumbent like this never arrives as a clone. It arrives as erosion at the edges. The small workflows that were only ever Excel's because building the slice used to cost too much leave one at a time, and the monolith keeps everything a monolith is good at.
That generalizes. When reproduction gets cheap, the part that gets commoditized is the part that was checkable, which tends to be the part that was already the least defensible. What survives the price collapse is everything that resists cheap verification, plus everything whose worth was never in the code to begin with: the data, the distribution, the integrations, the accountability. A model can rebuild the artifact. It cannot rebuild the reasons people depend on the original.
So the "clone this and make sure you cover all functions" future is real, but it is a gradient, not a switch, and the gradient is verification. The prompt works exactly as well as your ability to check "all functions" cheaply and completely. Where that check is free, as with a source-available port and a running reference, one person ships in an afternoon. Where it is partial and unbounded, as with all of Excel, the same tools get you the core cheaply and charge more for every step after. The lever most people miss is that the scope is theirs to set. You can shrink what you are reproducing until it becomes checkable, and the slice you actually need usually already is. So the first question is never which model to use. It is what you are going to check the output against, how complete that check is, and what each check costs. That number predicts the outcome better than anything on the model's spec sheet.
Unlock the Future of Business with AI
Dive into our immersive workshops and equip your team with the tools and knowledge to lead in the AI era.