How we built ClearFactr's first end-user feature by prompting Claude Code inside IntelliJ — and why most of it already existed.
Last month we shipped Move Range. Select a block of cells, right-click, and relocate the whole thing — values, formulas, and optionally its row and column headers — somewhere else: lower on the same tab, over to another tab, or into a brand-new tab that's built to fit. The original cells clear out, a version checkpoint saves automatically, and the formulas inside the block keep pointing at each other exactly as they did before. It is the kind of small, sensible tool you stop noticing the day after it ships — which is the highest compliment you can pay an editing feature.
It is also the first end-user-facing feature in ClearFactr's history where the entire thing — the dialog the user sees, the input validation, the server-side orchestration, the tests — was written by prompting Claude Code inside IntelliJ. No one hand-typed the implementation. We described what we wanted, read what came back, corrected course, and shipped.
The milestone is real. But the more interesting story is why it went so smoothly — and it has little to do with the AI being clever.
Move Range sounds like a lot of moving pieces, and it is. To do it correctly you have to insert rows and columns to make room, or overwrite cleanly when asked. You have to create a new tab and size it to the block, carrying over column widths, number formats, and grouped header spans. You have to clear the source. You have to re-point every formula so the relationships between cells survive the relocation. And you have to checkpoint the whole thing so it can be undone.
Here is the thing: ClearFactr already knew how to do every one of those operations, independently. We have spent years building robust, well-exercised machinery for cut-and-paste, for inserting and removing rows and columns, for spinning up tabs, for copying structure, for re-pointing formulas when cells relocate, and for saving versions. None of that was new. None of it had to be invented for Move Range. Each capability had already paid for itself many times over, in features that shipped long before this one.
So what Move Range actually is, is thin. It is an orchestrator — a layer that calls capabilities we already had, in the right order, with the right inputs. The AI's job was not to invent spreadsheet mechanics from scratch. It was to wire together leverage that was already sitting inside the product, and to handle the small surface of things genuinely new to this feature: the dialog, the choices a user makes in it, and the bookkeeping of getting the selection from the grid to the server.
This is exactly the argument in Software Capital and the one we made in Build Assets, Not Liabilities. When you invest in discoverable, reusable components — the stacked gold bricks — each new thing you build stands on the ones before it. Duplicated solutions get factored into shared capability once, and then you draw on that capital again and again, at lower and lower marginal cost. Move Range cost a fraction of what building relocation, insertion, tab creation, and formula re-pointing from nothing would have. The feature was, in a real sense, mostly already there. We were not writing it so much as composing it.
And that is also why an AI could write it. A thin orchestrator over well-defined, well-named capabilities is a far more tractable thing to prompt into existence than a green-field engine. The accumulated software capital did not just make the feature cheap for us — it made it legible to the model. Good names, clear seams, and capabilities that did one thing well gave the AI a vocabulary to build in. The model was only as good as the bricks we handed it.
Prompting a feature into existence is less like dictation and more like pairing with a fast, literal-minded, slightly over-eager colleague. You describe the behavior you want. The AI proposes an implementation. You read the diff — and reading the diff is the real work — then you correct, narrow, or redirect, and go again. The whole feature came together in that loop, in hours of conversation rather than days of typing.
The most instructive moment was when the AI got it wrong in a revealing way. Faced with the central challenge — keeping the formulas inside the moved block correct after the move — it did the obvious thing. It wrote its own routine to translate those formulas, walking each one and find-and-replacing the old cell identifiers with the new ones. On simple examples it worked. Then it broke, quietly, the moment a moved formula also referenced something outside the block: the replacement only knew about the block's own cells, so it would confidently rewrite the wrong reference and leave the formula subtly corrupted.
The fix was not to teach the rewriter about the harder cases. The fix was to delete it. ClearFactr already translates formulas correctly when cells relocate — it has to, because that is what an ordinary paste does, and that machinery has years of edge cases baked into it. The right move was to stop the feature from doing the translation itself and let it lean on the capability that already existed. The feature got smaller and more correct in the same edit. We shipped less code than the AI first wrote, and it worked better for it.
That is the part worth sitting with. The model's instinct, like a junior engineer's, was to generate — to solve the problem in front of it by writing more. The leverage was in the restraint: knowing that the problem had already been solved elsewhere in the system, and that the most valuable thing we could do was connect to it rather than reinvent it. The software capital did not only tell us what to write. It told us what to delete.
Reuse gets you most of the way. It does not get you correctness for free — and in a modeling tool, correctness is the only thing that ultimately matters.
The hard part of moving a block is not the block. It is the references inside it. When cells in the middle of your selection refer to other cells in the same selection, those internal relationships have to travel with the block, intact, to a new address.
Picture a small block on a tab called Assumptions: a few input rows, and one cell among them that totals the inputs around it. Now move that block to a new tab. The total has to keep summing its own neighbors — the cells that just moved with it — and not the empty space it left behind. But when the source clears, those vacated cells read as zero. If the moved total is still, even for an instant, looking back at its old address, it computes a perfectly formatted, perfectly wrong zero. Nothing turns red. No error is raised. The model simply lies, and it lies in a font you trust.
We came to call this the “donut hole”: a block with a cell in its interior that depends on the rest of the block — the hole in the middle that has to survive the trip. It is the scenario most likely to break, precisely because that cell's references live entirely inside the thing that is moving, where a careless move can sever them and a clever-but-wrong move can silently mis-point them. So we built it as a deliberately nasty test: a donut-hole block moved across tabs, asserting not that the grid looks right afterward but that the interior cell computes the exact value it should on the far side of the move.
It does. We wrote that test as carefully as we wrote the feature, because “looks right in the grid” and “is right” are different claims, and only the second one is worth anything to someone making a decision on the number. The reused machinery gave us the feature. The test is what let us trust it.
It is tempting to read this as a story about AI writing code, and to argue about whether that is impressive or alarming. We think that framing misses the point. Our first AI-authored feature was not a triumph of raw generation. It was a payoff on capital. The accumulated, reusable substance of the product made a real feature small, safe to verify, and something we could build largely by conversation. The model was the lever; the capital was the fulcrum. Move the fulcrum and the same lever does almost nothing.
That is the quiet thesis underneath all of this, and it is the same one ClearFactr makes about your spreadsheets. Value compounds when work is captured as reusable, legible, governable components rather than re-solved from scratch each time. An organization that has built that base of software capital does not just ship faster — it gives every new collaborator, human or AI, a stronger foundation to stand on and a clearer vocabulary to build in. The leverage is never really the worker. It is what the worker gets to stand on. We spent years stacking the bricks. Move Range is what it looks like to start cashing them in — and it will not be the last.