New Frame of Reference for Development: From Additive to Subtractive

I just completed a massive software port in 5 days, for less than $200 in AI costs, using 3+ coding agents (Codex Sol 6.1 High). A project I had previously dismissed because it would have required months of work from a small team of experienced engineers.

I've been using AI in my development work since the tools first became available, but this was my first experience running a well-defined, multi-agent task over such a long period (context window, caching and model efficiency weren't making that realistic to me until recently). Most of my AI coding tasks take minutes to a couple of hours. I even often struggle to find enough meaningful work to queue up overnight.

This time was different.

The project involved porting an existing application to a radically different platform and architecture. I had designed the new architecture, separating the reusable C++ core behind a local API from the UI, rendering, and platform-specific systems. The core was already exposed and used via an API, but the original UI/UX weren't available.

The challenge wasn't just reproducing the graphics. It was preserving years of nuanced controller logic while replacing the underlying APIs, threading, memory management, rendering, and even the input system.

I started cautiously, assigning one agent some particularly painful rendering challenges. After a few iterations figuring out how to validate the work, optimize compile/test cycles, and parallelize the tasks, the results were good enough that I decided to hand over the entire plan. Including an almost absurdly comprehensive test suite, the kind I could never have economically justified having engineers write.

Five days later, I have a nearly complete port, written in my coding style, following my architecture, with extensive C++ tests and an additional Python validation suite. The agents worked 24/7 through the weekend, occasionally texting me architectural questions when they encountered decisions my original design hadn't anticipated.

What stands out is the attention to detail. Porting is tedious work. Endless cycles of compiling, testing, verifying visuals, checking controls, tracking down subtle behavioral differences, and doing it all over again. Even with the original source code, I doubt a team of three engineers could have accomplished the same amount of work and test coverage even with more time.

Is it perfect? No. There are a few things I'll want to clean up before calling it done. But the complex, nuanced behavior of the original implementation has been preserved and extensively tested.

What's interesting to me isn't so much the technical accomplishment itself. It's that a project whose business value couldn't justify its development cost suddenly became economically trivial to undertake.

And that fundamentally changes how I think about product development.

The question is increasingly less about what I can afford to build, how long it will take, or how many engineers I need. It's about what I should build, and how I can use this newfound capacity to create something truly exceptional. But not in the traditional backlog or roadmap sense. We can now afford to iterate faster than ever, build too much, strip away what doesn't work, and keep refining.

It's almost as if we've shifted from an additive model of development to a subtractive one. Instead of carefully assembling something piece by piece, we can start with a massive block of possibilities and sculpt away everything that doesn't belong until the real idea emerges.

And I find that both exciting and a little scary, because it means I can no longer hide behind technical costs, staffing, or timelines to justify my product decisions.

Originally published on LinkedIn.