Torras.ai

I have been working with a customer on a new software project. We spent time discussing the problem, understanding the workflow, and designing what the final system should do.

At moments, I wondered whether we were moving too slowly. In technology, it is easy to feel that every week spent thinking is a week lost. Someone else may launch first. The market may move. The opportunity may disappear.

Then something unexpected happened.

By the time we were ready to build, the tools had changed. I could work with Codex using GPT-5.6 Sol, connect it to Chrome, let it operate desktop applications through Computer Use, and give it access to more of the environment where the real work happens. Tasks that would previously have required custom integrations, extensive interface code, and many manual steps became much more direct.

We had started later. But suddenly, it looked possible that we would finish sooner.

That sounds contradictory. It is also a good description of the technological moment we are living through.

Why the second spaceship arrives first

Imagine that humanity wants to reach a distant planet.

We could launch a spaceship today using the best propulsion system currently available. It would immediately begin the journey and gain a valuable head start.

But suppose we wait ten years. During that time, propulsion technology improves dramatically. We launch a second spaceship that travels much faster than the first. It overtakes the original ship somewhere between Earth and the destination, then reaches the planet years earlier.

The first spaceship left first. The second one arrived first.

This is not only a science-fiction thought experiment. It has been studied as the wait calculation, also described as the incentive trap of progress. The question is whether it is better to launch with the technology available now or wait for a faster technology that may reduce the total time to the destination.

A later study extended the calculation to relativistic travel and applied it to potential interstellar missions. Its central question was the same: could a spacecraft launched later overtake an earlier mission and arrive first?

The basic logic can be expressed simply:

A later launch wins when the time saved by the better technology is greater than the time spent waiting for it.

This is the AI wait calculation.

Software now has propulsion technology

For much of software history, starting earlier usually created a durable advantage. Even if tools improved during the project, the team that already understood the problem, wrote the code, and reached the market had accumulated something difficult to overtake.

That assumption is becoming less reliable.

AI is not merely making existing programming tasks slightly faster. It is changing which parts of a project need to be programmed at all. A capable coding agent can inspect a repository, understand conventions, edit several files, run tests, diagnose failures, and verify the result. The Chrome connection lets it work with websites and signed-in browser context. Computer Use extends that reach to graphical applications when command-line tools and structured integrations are not enough.

Each of these capabilities changes the economics of implementation.

An integration that once required an API, an authentication flow, a synchronization process, error handling, and a custom interface may now begin as an agent operating the existing application. A feature that once required weeks of coding may become a well-specified task completed and tested in days. A prototype that would have been too expensive to justify may become cheap enough to build simply to learn from it.

The new spaceship is not just faster. It may need less infrastructure to reach the same destination.

Thinking was part of the journey

There is an important distinction between starting the project and starting the implementation.

The conversations with my customer were not passive waiting. We were identifying the real destination. We were deciding which problems mattered, which steps could be automated, where human judgment should remain, and what a useful result would look like.

That knowledge did not become obsolete when the technology changed. It became more valuable because the new tools could act on it more quickly.

If we had started coding immediately, we might have built assumptions into the architecture before understanding the workflow. We might also have created custom machinery for problems that newer AI tools can now handle directly. The early start would have produced more code, but not necessarily an earlier outcome.

This leads to a principle I increasingly believe is appropriate for AI projects:

Start learning early. Commit late.

Begin customer discovery, process mapping, data preparation, risk analysis, and success measurement as early as possible. Those activities clarify the destination and usually retain their value.

Be more careful with large, rigid, technology-dependent commitments. When the underlying capabilities are advancing quickly, an architecture designed too early can become the slow spaceship that a simpler system later overtakes.

The first spaceship is not always pointless

There is a tempting but dangerous interpretation of the wait calculation: never build anything because a better tool will always appear later.

That is the incentive trap.

If we follow that logic forever, no spaceship ever leaves Earth. There will always be another model, another framework, and another capability on the horizon.

Early systems can also create value even when they are eventually overtaken. A prototype may reveal a hidden requirement. A manual workflow may generate training examples. A limited release may establish trust with users. An imperfect integration may expose the real operational bottleneck.

In that sense, the first spaceship can send valuable information back to Earth.

The mistake is not launching early. The mistake is treating every early launch as the final vehicle.

During periods of rapid change, early versions should be designed as probes: small, reversible, and built to produce knowledge. They should help us decide what deserves a larger commitment. The generation ship comes later.

A practical wait calculation for AI projects

We cannot predict the exact pace of AI development, but we can ask better questions before committing to a build:

• Is the destination clear? If the customer problem is still vague, better technology will not rescue the project.
• How quickly is the enabling technology improving? Waiting matters more when a missing capability is visibly becoming cheaper, more reliable, or easier to integrate.
• What can we learn now? Interviews, prototypes, experiments, and data collection can create progress without locking us into an architecture.
• How reversible is the decision? A small prototype is easy to replace. A large custom platform, migration, or multiyear contract is not.
• Are we measuring effort or arrival? Starting development earlier may increase the amount of work completed while delaying the moment the customer receives the desired outcome.

The final question is the most important. Software teams naturally measure activity: requirements written, tickets closed, integrations completed, and lines of code shipped. Customers care about arrival.

Did the workflow become faster? Did errors decline? Did revenue increase? Did people stop performing work that a system could handle? Did the company gain a capability it did not have before?

A later project that reaches those outcomes first is the faster project.

Competing with a ship that has not launched yet

The uncomfortable reality is that every AI product is now competing partly with future technology.

A team may spend a year building a specialized feature, only to see a general-purpose model acquire the same capability. A carefully engineered interface may become unnecessary when an agent can operate the original application. A complex integration layer may lose its value when tools can securely move across systems on the user’s behalf.

This does not mean software companies should stop building. It means they should build where value is most durable: proprietary context, customer relationships, trusted workflows, distribution, domain knowledge, evaluation systems, and a precise understanding of the outcome.

The implementation should be modular enough to replace its engine when a faster one becomes available.

In my customer project, starting later did not mean doing nothing. It meant that when we finally launched, we had a clearer destination and a much faster ship.

That is the opportunity created by the AI wait calculation. The objective is not to wait as long as possible, and it is not to build as early as possible.

It is to recognize the moment when waiting stops reducing the journey and begins delaying it.

Start learning early. Keep early experiments small. Preserve what is durable. Delay the irreversible decisions. Then, when the technology is capable enough and the destination is clear, launch.

In a world of accelerating technology, the first mover is not always the first to arrive.