Meta released Muse Wonder and Muse Wonder Full on October 12. Wonder is available through its API and Muse Code; Wonder Full is available to Muse Code subscribers. Another company is asking people building software and agents to reconsider what its models can do. Meta's announcement.

Another release to evaluate. Another set of assumptions to revisit. It feels as though every day brings something that might change what is worth working on.

The question I keep coming back to is how to work under these conditions. How do you think clearly, make a plan, and stay with something long enough to finish it when the next model release could remove the reason you started?

You can spend months building a capability that becomes a standard feature overnight. You can invest in learning a complicated workflow just as someone makes most of its steps unnecessary. A decision can be reasonable when you make it and expensive by the time you finish executing it.

Photoshop makes this feel concrete. Earlier this month, ArtCraft's creator described using language models to help recreate seven Adobe applications in Rust, covering image editing, illustration, video, photography, motion graphics, page layout, and PDFs. These are attempts to rebuild categories of software that have taken enormous amounts of work to develop. The creator's account.

There is a considerable distance between an ambitious recreation and a dependable professional replacement. PhotoCraft's own assessment describes an alpha product with serious remaining gaps, including the reliability of exchanging Photoshop files. Anyone whose work depends on those details has good reason to care about them. PhotoCraft's assessment.

Still, I find the attempt significant. The cost of attempting something this large appears to be changing. A competitor does not have to reproduce every feature to become useful to someone whose needs are narrower.

Adobe is changing the experience from inside too. Its AI Assisted Editor beta lets people describe edits in natural language within desktop Photoshop, alongside the existing Pro Editor. The software remains, but the knowledge required to accomplish some tasks through it is shifting. Adobe's documentation.

Taken together, these developments make me less comfortable assuming that the difficulty of building something will protect its value. There is also a difference between making useful software and being able to charge for it. A feature can become more widely used while the price anyone will pay for it falls.

In July, I wrote about orchestration I had spent months building, some of which had just become a model setting. Task decomposition and subagent coordination were moving into the model. That was useful to me as a builder, and uncomfortable for the same reason.

There is a particular frustration in seeing something you worked hard to learn become easy for everyone else. The effort happened. The advantage may still disappear.

That makes the investment question harder. Can you commit serious time and money when you cannot know how long the advantage will last?

I think you can, but the reason for committing deserves more scrutiny. A project that helps a business do something valuable today can justify itself before the technology changes again. A project that only works financially if today's limitations persist for several years is asking for a much larger act of faith.

Before committing, I would want to know what happens if the underlying models get substantially better. Does the product become more useful? Does it become easier for someone else to reproduce? Does the customer still need it at all? Often all three answers contain some truth.

Waiting has a cost too. A better model might make the implementation easier in three months, but it cannot retroactively give me three months of feedback from people using the thing. I could spend that time learning what matters to them, or waiting for a more convenient moment to begin. The uncertainty exists in both choices.

I can have a long commitment to a problem while making much shorter commitments to a particular implementation. The plan needs to make its vulnerable assumptions explicit. If six months of work depends on a model being unable to do something, that limitation deserves to be tested whenever a relevant release arrives.

For example, before spending six months building an elaborate document system, I might spend two weeks running one recurring task with the people who need it. That should produce evidence about usefulness, failure, and willingness to pay. The next commitment can be larger because I know more.

I might learn that the hard part is getting the right information into the system, or checking answers people will act on. Those needs could survive several model releases. I would still want evidence of that, rather than declaring customer relationships or domain knowledge permanently safe from change.

The temporary version can have value too. If it saves enough work while it exists, replacing it later does not make the original decision a mistake. But the calculation has to include checking outputs, maintaining the system, and moving people to whatever comes next. Cheap code can still create expensive obligations.

Execution requires some restraint for the same reason. A new model should earn a place in the workflow by doing something better on the tasks that matter. A release announcement gives me a reason to investigate; it does not automatically justify a migration.

I would keep examples of difficult tasks and failed outputs, and use them to judge whether a new model changes the project. Sometimes it will remove weeks of work. Sometimes the improvement will be too small to repay the time spent switching.

This is where the daily pace becomes a problem of attention. There is always another tool to try, and evaluating tools can consume the time that was meant for using them. Staying informed needs a boundary, or the plan gets reconsidered so often that nothing is allowed to become useful.

Some work also needs uninterrupted time. Understanding a customer's situation, developing judgment, and earning trust require repeated contact with reality. Faster implementation can give us more opportunities to do that work, if we spend the saved time on it.

I still want to make long commitments. I want to work on things that take more than a release cycle to understand. What I am less willing to do is assume that a long commitment requires the same tools, the same process, or even the same product throughout.

When the next release arrives, I hope I can get past the question of how much of my work it has made obsolete. Which part can I stop doing now, and what does that let me attempt?