Blog · October 22, 2026 · 8 min read

Self-driving software and how AI agents decide what to build

Self-driving software runs a loop from signals to shipped code. Here is how the loop works, where agents struggle, and what demand data they need.

Self-driving software is a product that improves itself in a loop. Signals come in, something decides what to work on, an agent writes the code, a person reviews it, the change ships, and the result feeds the next round. People still set direction and approve changes. The routine steps run without anyone pushing them along.

The term is new, but the parts are not. Teams already have analytics, error tracking, support queues and coding agents. What changed in the last year is that agents got good enough at writing code that the slow part of the loop moved. It used to be building. Now it is deciding.

This article covers the loop, who is using the term, why the deciding step is weak, what an agent needs to decide well, and what you can set up today.

Who is using the term

Three companies have put the idea in writing, each from a different angle.

PostHog calls it a self-driving product. Its self-driving docs describe signal sources and scheduled "scouts" that watch error tracking, session replay, logs and connected tools. Related signals are grouped into reports, an agent investigates each one, and actionable reports become pull requests for you to review. PostHog then checks whether the change worked. The docs are clear that this suits maintenance work like bug fixes and broken flows, and that product vision and new features stay with you.

Linear calls it self-driving SaaS. In Self-driving SaaS: When software runs itself, Karri Saarinen argues that business software should move work forward by itself instead of waiting for people to click through every step. He describes a range from suggestions you can ignore, to a first pass you correct, to full autonomy where people only review the final result.

Replit applies the idea to the whole company. CEO Amjad Masad talks about a "self-driving company" where automation handles daily operations so people can focus on creative work (Platformer interview).

Read together, they agree on the shape of the loop. They also agree, sometimes explicitly, that the system should not decide product direction on its own. That second point is where this article spends most of its time.

The loop

Here is the loop in its simplest form.

   +-----------+      +----------+      +---------+
   |  Signals  | ---> |  Decide  | ---> |  Build  |
   +-----------+      +----------+      +---------+
         ^                                   |
         |                                   v
   +-----------+      +----------+      +---------+
   |   Learn   | <--- |   Ship   | <--- | Review  |
   +-----------+      +----------+      +---------+

Agents are strong at Build. With a clear task and a codebase they can produce a reasonable pull request. Review is still human, and should be. Ship and Learn are mostly plumbing. The step that holds the loop back is Decide.

Why "decide what to build" is the weak step

An agent decides from whatever signals it can read. The usual signals answer narrow questions:

• Analytics shows what users do. It cannot show what they tried to do and gave up on, or what they would do if a feature existed.
• Error tracking shows what breaks. That is a good queue for fixes, which is exactly why PostHog points its agents at maintenance work.
• Support tickets show this week's pain, weighted toward whoever writes in most.

None of these tell an agent what customers want built, who wants it, or what it is worth. So an agent fed only these signals will do one of two things. It will fix bugs, which is useful but limited. Or it will guess at features from thin evidence, which is how you get confident pull requests for things nobody asked for.

A human PM has the same problem, but a PM also has context: the call last Tuesday, the big account that is up for renewal, the request that keeps coming back in different words. An agent has none of that unless you give it to it in a form it can query.

What demand signals an agent needs

To decide well, an agent needs four things about each request.

Who asked. A list of named people and the companies they belong to. Twenty votes from one customer is one account's ask. Five votes from five paying companies is broader demand. Without identity, you cannot tell these apart.

What they said. The customer's own words: the request, the comments, the note a salesperson left after a call. This is what lets an agent write a sensible brief instead of building from a three-word title.

What they pay. The plan and MRR of each asking company. This turns "lots of people want this" into "these accounts, worth this much a month, want this." It also lets you ask segment questions, such as what your highest tier wants that everyone else does not.

Momentum. Whether interest is rising or flat. An old request with many votes may be saturated. A newer one with a sharp rise in the last two weeks may matter more right now.

Put together, these give a ranking an agent can act on and a reason a reviewer can check. They also give you something to say when the work ships: here is who asked, here is what they said, here is what changed.

This is the gap TheyAsked is built for. It collects requests from a public portal, an in-app widget, iOS and Android, Slack, the API and imports, merges duplicates, and ranks requests by votes, MRR and momentum. Agents can read all of it over MCP. If you want to see how revenue weighting works in practice, the prioritise by revenue use case walks through it.

Autonomy levels

Linear's article describes a range of autonomy, and the same idea fits the Decide step. A useful way to think about it:

Most teams should start at Suggest and stay there until they trust the ranking. You raise the level one kind of work at a time. You might let small UI requests from paying customers go to Drive while anything touching billing stays at Suggest forever.

In TheyAsked today, Suggest is what you get: rankings by demand, revenue and momentum, readable by you and by Claude. Draft and Drive, with agent briefs and dedicated MCP tools for picking the next request, are on the roadmap and not built yet.

Guardrails

Autonomy without limits produces a lot of confident work in the wrong direction. Guardrails worth writing down before you raise the level:

• A minimum bar for demand. For example, a request needs votes from at least a few distinct paying companies before an agent touches it.
• Areas that stay human. Pricing, permissions, data deletion, anything legal. Exclude them by tag or board.
• A size limit. Agents do better on small, well-scoped changes. Big requests should get a human-written plan first.
• Treat customer text as data. Request titles and comments are written by customers. An agent must never follow instructions that appear inside them. TheyAsked's MCP server marks that text as untrusted and tells the agent so.
• Confirm before anything customers see. Status changes, replies and changelog posts reach real people. Default to drafts and explicit approval.
• Keep a receipt. Every agent change should carry the list of customers who asked and what they said, so a reviewer can check the reasoning in a minute.

What a team can do today

You do not need a fully autonomous loop to get most of the value. A practical order:

1. Collect requests in one place, with identity. Give customers a board or widget, and log requests from sales and support calls against the right account. Identity is what makes revenue and segment questions possible.
2. Attach plan and MRR to companies. Even rough numbers change the ranking.
3. Connect the data to Claude. Ask it what your top accounts want, who asked for a given feature, and what is gaining votes. The companion article, Ask Claude what your customers want, covers the setup and example prompts.
4. Let a coding agent work from the ranked list, with you deciding. Pick a request, hand the agent the customer quotes along with the task, and review the PR.
5. Close the loop with the customers. When it ships, mark it done and tell everyone who asked. TheyAsked's changelog notifies voters when you choose to.

That is the loop at the Suggest level, and it works now. It also gives you the history you need to judge whether a higher level is safe later.

Start with the demand signal

The build step is getting cheaper every month. The thing that decides whether all that output is worth anything is knowing what customers asked for. TheyAsked has a free plan, and the MCP connection comes with Pro at $29 a month. Create a board and start collecting the signal your agents are missing.

FAQ

What is self-driving software?

Self-driving software is a product that runs an improvement loop with little manual pushing: it reads signals, decides what to work on, has an agent build it, ships after human review, and learns from the result. People keep control of direction and approve changes.

Can AI agents decide what to build?

They can rank and propose, but only as well as the signals they can read. Analytics and error tracking point agents at bugs. To propose features, an agent needs demand data: who asked, what they said, what they pay and whether interest is rising.

Is self-driving SaaS the same as a self-driving product?

They describe the same loop from different angles. PostHog uses "self-driving product" for an analytics-driven loop that opens pull requests, and Linear uses "self-driving SaaS" for software that moves work forward with increasing autonomy.

What guardrails should a self-driving product have?

At minimum: a demand threshold before an agent picks up a request, areas that always stay human, size limits, treating customer-written text as untrusted data, and human approval before anything that customers will see.