Self-Driving Dreams Requires Open Roads

Linear published their vision for self-driving SaaS last week. It's a concrete example of what I wrote about in my last post: software that works autonomously on your behalf, not just assists you.

Their vision: software that doesn't just help you work, but works autonomously on your behalf. Customer requests automatically extracted from support tickets. Issues analyzed and assigned to the right team. Simple changes dispatched to coding agents. Documentation that keeps itself current.

This isn't aspirational. It's already happening. And what Linear is describing is actually Continuous AI applied to product development.

Breaking Down Self-Driving SaaS

Linear's examples map cleanly to Continuous AI workflows. Each one has a trigger, an agent that does work, and an outcome.

Support ticket → Linear issue

• Trigger: New support ticket arrives
• Agent: Extract customer request, analyze context, draft issue
• Outcome: Prioritized Linear issue

New issue → team assignment

• Trigger: Issue created
• Agent: Analyze past completion history, backlog, roadmap
• Outcome: Issue assigned to correct team and person

Simple issue → merged PR

• Trigger: Issue flagged as simple change
• Agent: Coding agent implements, tests, commits
• Outcome: Pull request ready for review

Requirements → updated docs

• Trigger: New requirements roll in
• Agent: Update specs, keep docs current
• Outcome: Documentation that never goes stale

This isn't one AI feature. It's a composed system of autonomous workflows, each building on the outputs of the previous one.

The Autonomy Levels

Linear explicitly uses the self-driving car metaphor with levels of autonomy. This maps directly to how teams actually adopt Continuous AI.

At low autonomy, the system suggests actions. Linear recommends which team to assign an issue to. You can use the suggestion or not. This is like autocomplete - helpful but supervised.

At moderate autonomy, the system takes the first pass and you correct what doesn't fit. Linear applies suggestions automatically under conditions you define. You review and adjust. This is like running agents in parallel while you orchestrate.

At full autonomy, you take your hands off entirely. The system drives from start to finish. You confirm you arrived at the right destination. This is event-driven workflows that run without human initiation.

They're right that you don't flip a switch to get there. Trust builds through repetition. Capabilities and culture both need to progress.

The Gap

Here's what Linear's blog doesn't address: they can't build all the workflows every team needs.

Your company has unique workflows. Your support system might be Zendesk, Intercom, or custom. Your deployment has bespoke steps. Your code review standards are specific to your team. Your documentation lives in Notion, Confluence, or GitHub. Your definition of "simple change" is different from everyone else's.

Linear can build 20 opinionated workflows. Your team needs 200 customized ones.

If only Linear can create workflows for Linear, then you're waiting on their roadmap. They prioritize what benefits the most customers. Your unique workflow that would unblock you tomorrow? Not on the list.

Why This Needs Developer-Buildable Workflows

Self-driving SaaS is the right vision. But it only works if developers can build their own workflows.

You need to define your own triggers. Not just "new Linear issue" but "Sentry error >100 occurrences" or "PostHog flag hits 80% rollout" or "customer Slack message mentions bug."

You need to compose your own chains. Not just Linear → GitHub, but Slack question → Notion search → drafted response → Linear issue → GitHub PR → Slack summary.

You need to connect your own tools. Not just blessed integrations, but any system via MCP servers.

You need to measure your own outcomes. Not Linear's opinionated metrics, but intervention rates and success rates that matter to your business.

Linear is building self-driving features into their product. That's valuable. But your competitive advantage lives in the workflows they'll never build.

What This Looks Like in Practice

At Continue, we're seeing teams build workflows that extend Linear's vision:

• PostHog insight triggers Linear issue with context from recent customer conversations
• Sentry error creates Linear issue, which triggers agent to investigate and file PR
• Linear issue completion triggers documentation update and changelog entry
• GitHub PR merge triggers Linear issue comment with deployment status

These workflows connect Linear to the rest of your stack. They're specific to how your team works. And they're not waiting on Linear's roadmap.

The Path Forward

Linear's self-driving vision is correct. Software should work autonomously on your behalf. But that vision requires an ecosystem where developers can build their own workflows.

The teams that will win are the ones building custom workflows today. Not waiting for vendors to ship them. Not renting someone else's opinionated automation. Building workflows that match how they actually work.

Self-driving SaaS isn't something you buy. It's something you build.

And once you start building, individual workflows quickly evolve into something more powerful. That's what I'll explore next.