Harnessification of software

Your customers can build what you sell. Their agents can use it without opening it. Now software can take care of the work itself.

We’re in the early days of the harnessification of software.

A harness is the system that gives an AI model a way to get work done. It provides access to tools and the context needed to use them. The agent can take action, check what happened, and try again when something goes wrong.

This is already changing how software gets built and how people use it. The bigger opportunity is software that keeps working after the customer has moved on. It can recognize when something needs attention and handle work that previously required a person to initiate every step.

For anyone building a software business, this raises a fundamental question.

What will customers pay for when they can increasingly build the features themselves and let agents handle the work?

Software is becoming something software makes

In February 2026, OpenAI described an experiment in which a small engineering team built an internal product without writing code by hand. Codex generated everything needed to run it, including tests and infrastructure. In five months, the repository reached roughly a million lines of code and 1,500 merged pull requests.

The engineers’ most consequential work was designing the environment in which Codex operated. They added checks in response to mistakes and improved documentation when the system lacked context. Each problem became an opportunity to make future attempts more reliable.

Mitchell Hashimoto had described a similar approach earlier that month. He called it harness engineering. Every recurring failure becomes an opportunity to improve the system around the model so it handles that situation better next time.

Here’s what that looks like in practice. You ask a coding agent to fix a checkout bug. A proposed change means little until someone checks whether the checkout works. The harness lets the agent edit the code and run the tests, then use any failures to guide another attempt. That feedback loop makes the same model more capable of finishing the job.

Tools such as Lovable, Replit, and v0 are bringing a version of this experience to people who don’t write software professionally. A founder can prototype an idea before hiring a team. An employee can create an internal tool that would never have made it onto the engineering roadmap. Vercel’s v0 API even allows other software to request a generated application.

The ability to create software is itself becoming a software feature, and that has consequences for the business of selling applications. A customer who once had to subscribe to a specialized tool may be able to make a version suited to their particular workflow. Sometimes that will be enough.

A working prototype can still be a long way from a dependable business system. Someone must keep it running when integrations break or access changes. The security and maintenance work doesn’t disappear because the first version was easy to generate.

Yet the barrier to creating a credible alternative has moved. If a product’s value consists mostly of a few screens that move information from one place to another, the company selling it needs a stronger reason to exist.

Your next competitor might be your own customer.

Software is becoming something other software uses

Consider the software customers already own. A sales manager asks an agent for a briefing on an important account. The agent retrieves the latest support issues and checks what changed in the deal. It can prepare the next action in the CRM without asking the manager to click through each screen.

The CRM remains the source of the account history, and the support system retains the customer conversation. What changes is who operates them.

In April 2026, Salesforce announced Headless 360, making more of its capabilities available through APIs, MCP, and command-line tools. Those are ways for software to work with other software. An authorized agent can use parts of Salesforce directly instead of navigating its website like a person.

That is a remarkable move by a company whose product has long been associated with people working inside an application. Salesforce is preparing for customers to receive value from its software while spending less time directly using its interface. Other major software businesses may end up in the same position.

An agent might choose which service to call based on the job someone wants done. That creates a new kind of distribution power for whoever operates the agent. Ben Thompson has explored how the agent could become the place where demand gets gathered and directed.

But choosing a service is only part of the work. The record must remain correct after the agent updates it. Payments still need to settle, and merchants remain responsible for fulfilling orders.

The company that controls those capabilities may become more valuable as agents use them more often.

This is why the SaaS story is more complicated than the disappearance of applications. An agent can reduce the number of times someone opens a product while increasing how often that product’s underlying services get used.

A software company can lose screen time and gain usage at the same time.

Software is starting to take care of work

The third change may have the greatest potential to reshape the product itself. Most software waits for someone to do something. We open the dashboard, notice the problem, and decide what happens next. A harness makes another relationship possible. The system can check on a job, recognize when something needs attention, and take an authorized action without a new prompt each time.

Linear’s Loops, introduced in July 2026, are an early example. A team can tell Linear Agent to perform a recurring job or respond when an event occurs. It might investigate an incoming bug report and create follow-up work. People can inspect the instructions and see what happened during each run.

Recurring automation is a useful step, though it doesn’t yet amount to taking responsibility for a result. Imagine the difference for a website owner. Today an analytics tool can show that checkout conversion dropped. Someone has to notice the chart and figure out what happened. A more capable product could detect the drop on its own and investigate whether a recent site change caused it. If the evidence is strong enough, the product could prepare a fix and request approval before making it live. Then it would check the result.

That product would carry a responsibility over time, knowing what to watch and when to involve a person. A market analyst could follow competitors between meetings, while a finance system handles routine reconciliation. In each case, the job continues beyond a single request.

The smallest useful unit of software may be shifting from a feature to a responsibility.

A feature gives someone a capability. Responsibility comes with an expectation that the work will be taken care of, even when nobody is actively using the product. That requires the system to recognize when to act again and when to ask for help.

For a software founder, that is a different kind of product promise. The customer is no longer just paying for the ability to perform a task. They’re starting to pay for the confidence that the task will be handled.

Reliability decides how much work we can delegate

Delivering that future reliably remains difficult. A 2026 study of production agents found that 68 percent ran no more than ten steps before human intervention. Nearly three quarters of the systems studied relied primarily on people to evaluate their results. Reliability remained the main engineering challenge.

That matches an important lesson from using agents in real workflows. A system can produce an answer that looks finished while leaving someone else with the work of checking it.

Suppose two agents handle the same support issue. The first responds quickly but requires someone to review almost every resolution. Its competitor takes longer, yet catches mistakes before they reach the customer. That slower system may cost more per attempt and much less per resolved case.

A founder needs to understand that difference. The useful number is cost per verified result, including the human review and recovery work required to deliver it.

This changes what good product engineering looks like. A recurring mistake should lead to a better check. When the answer depends on a record that might be outdated, the system needs a way to verify the source. And when it can’t safely proceed, handing the work to a person is part of doing the job well.

Over time, the harness can preserve the lessons that matter. It can retain useful history and improve its methods, provided there’s a way to test whether those changes actually help.

A flashy demonstration tells you what software might do once. The more valuable evidence is what it handles correctly month after month.

Autonomy becomes valuable when people can trust the result without having to redo the work.

The SaaSpocalypse missed the deeper question

In February 2026, new tools from Anthropic helped trigger a sharp selloff in software stocks. Investors worried that agents would replace work that customers had previously needed specialized applications to perform. The episode became known as the SaaSpocalypse.

Months later, software stocks had recovered much of their losses, although performance varied across companies. Neither the selloff nor the rebound tells us exactly how the businesses will change.

The more useful question is what customers will still need to buy when software becomes easier to generate and agents can operate many existing tools.

Some products are exposed because their value is concentrated in functionality that customers can reproduce. Others hold authoritative records that a business depends on. Those records have to remain consistent, regardless of which agent or person makes the next change. Software that carries out financial transactions has a different kind of value again, because being able to request a payment doesn’t mean being able to settle one.

Then there are products that can take responsibility for a recurring job. If they perform it reliably, customers may prefer to keep paying rather than assemble and supervise their own agents.

The business models will reflect what each product delivers. An interface where people collaborate may still be priced per seat, while a payments service charges for transactions. Products that finish measurable work can experiment with charging for completed results, as Intercom has done with its Fin support agent. The right pricing model depends on what the customer receives and what it costs to deliver.

An attractive interface may face more competition, while a trusted record system could become essential infrastructure for agents. Products that reliably handle an entire job may create new categories altogether. Founders need to understand which part of their business customers truly depend on.

An agent’s permission isn’t unlimited

The companies operating those underlying services retain an important form of control. Even if a customer authorizes an agent to act on their behalf, the services involved have to permit that access. A bank can restrict automated account operations. An online store can decide which outside agents are allowed to transact with it. Some companies are already limiting access because of security concerns or commercial agreements.

The right to act becomes a product problem of its own. Shopify’s Universal Commerce Protocol is one attempt to solve part of it. Merchants can describe what shopping capabilities their systems offer so an agent knows how to interact with them. Stripe has developed tools that let an agent complete an authorized payment without being given unrestricted use of someone’s card.

Those systems make delegation practical by defining what an agent is allowed to do. They also preserve the responsibilities of the merchant and payment provider.

A great agent can still fail when it lacks legitimate access to the system needed to finish the job. Conversely, a service that handles important records or transactions may become more valuable precisely because so many agents need to use it.

As a result, the next generation of software will depend on more than capable models. It needs trustworthy ways to perform actions in the real world.

What I would do if I were building a software business

I’ve spent most of my working life building software. Much of the work used to begin with deciding which features customers needed and making those features easier to use.

I’d start somewhere different today by identifying the recurring job customers care most about. Then I’d look closely at what happens before and after they use the product. What forces them to open it? Which decisions require their judgment? When the work goes wrong, who notices and who fixes it?

That exercise reveals opportunities a feature roadmap often misses. The customer may already be telling you they want someone to handle the work, even if they describe the problem as needing a better dashboard.

Next, I’d test how replaceable the product has become. Give a capable coding agent the job of recreating one valuable workflow. Measure how far it gets, and pay attention to what breaks when you try to use the result for real work. That tells you more than debating whether vibe coding will kill SaaS.

I’d also try to accomplish the customer’s job through an outside agent using the services they already have. Success would expose the need for a stronger reason to buy my product. Failure might reveal the exact capability worth building.

Then I’d decide how much responsibility to take on. Start with something bounded. For example, a website product could promise to detect checkout failures, investigate the likely cause, and prepare a verified recommendation. It might earn permission to make limited changes later, after demonstrating that it can identify problems accurately.

A useful responsibility should be easy to describe.

When this happens, my software will do this, and the customer will know it worked because of this evidence.

If that sentence is impossible to finish, the product may be promising more autonomy than it can deliver.

Finally, I’d measure the cost of the entire job. Count the review time and failed attempts alongside the model usage. Track what the customer had to do after the agent said it was finished. Improving that number may be more valuable than adding another capability to the interface.

None of this means every product needs to become autonomous. A design tool can be valuable because people love making things inside it. Games and creative software offer experiences users want to participate in. Even operational software will need interfaces for oversight and difficult judgment calls.

But if the product exists mainly to help someone complete repetitive work, it’s worth asking how much of that work the product can eventually carry itself.

What software becomes

I suspect we’re going to create far more software than we have today, including applications built for one company or even one problem. Agents will also become more frequent users of existing products, sometimes increasing demand for underlying capabilities even as people open the interface less often.

The most consequential products will go further. They’ll remain attentive to a job and maintain enough context to recognize when the next action is needed. Their usefulness will depend on whether they can show what happened and earn permission to handle more of the work.

The opportunity for founders is larger than making software easier to build. It’s to rethink what a customer should have to do after buying it.

What valuable work can your software be trusted to take care of, and how will the customer know it did?

We’re in the early days of the harnessification of software. The businesses that matter will be the ones that keep earning the right to do more of the work.