Backseat Software →

A historical perspective on the evolution of software by Mike Swanson:

What if your car worked like so many apps? You’re driving somewhere important…maybe running a little bit late. A few minutes into the drive, your car pulls over to the side of the road and asks:

“How are you enjoying your drive so far?”

Annoyed by the interruption, and even more behind schedule, you dismiss the prompt and merge back into traffic.

A minute later it does it again.

“Did you know I have a new feature? Tap here to learn more.” […]

I’ve started to think of this as backseat software: the slow shift from software as a tool you operate to software as a channel that operates on you.

It’s a long post but worth reading in its entirety.

Key points I want to remember:

  • When software collects data and sends updates, usage analytics (DAU, funnels, etc.) can become central to product decisions. The focus then shifts from helping users achieve goals to optimizing engagement metrics.
  • Metrics can be correct but still mislead you. For example, a feature seems unused because it was badly designed and buried in the UI, not because it isn’t valuable.
  • Testing can produce insights but also turns products into continuous experiments on users, where decisions favor what moves metrics fastest, not necessarily what aligns with product vision.

The paradox is that this approach is practiced at companies who believe that this is what they should be doing to be successful. But the visionaries who built enduring companies kept their focus on the users.

Steve Jobs:

You’ve got to start with the customer experience and work back toward the technology — not the other way around.

Jeff Bezos:

We start with the customer and work backwards.

So instead of backseat software, we should build frontseat software. Software that stays out of your way, helps you finish the job, and shuts up when it’s done.

via Daring Fireball

Engineering, Product, and Design Are Now Like Video Game Skills

Engineering, Product, and Design used to be separate skills, but in the age of AI agents, they are like video game skills. You can clear the early levels by maxing one, but you won’t progress if the other two are at zero.

It’s now normal to see product managers and designers writing code and implementing UI with agents in the loop.

Two examples from the SuperPlane team:

Aleksandar is a Product Manager. He spends most of his time curating the product not by writing tiny issues for engineers but by acting as a full-stack developer, writing code to build new features or tweak the existing ones. He’s also orchestrating agents to create issues based on product requirements, review pull requests, and generate new ideas.

Petar is a UI/UX Designer. He’s creating the UI/UX for the app and implementing behaviors that he wants to see in the app as a full-fledged frontend developer. Since picking up Cursor, he has not opened Figma.

The best thing about AI is that it makes leveling up universally available. It’s fun to see how people are using it to evolve and do more than they ever thought possible.

SuperPlane Is Open Source

This week we open-sourced SuperPlane, a DevOps control plane for running event-driven workflows across the tools you already use. You can think of it as ‘n8n/Zapier for DevOps’ that sits on top of Git, CI/CD, observability, infrastructure, and the rest of your production system.

Why does this matter? To evolve, DevOps needs to move on from one-off scripts, tribal knowledge, and untraceable workflows.

For years, the best automation tool at hand was the humble CI job. Pipelines are great at building and testing code, but they are not great at running workflows that span multiple tools and repositories, pause for human intervention, and run for hours or days.

What we need is a vendor-neutral interoperability layer for DevOps automation; a way for tools, humans, and agents to talk to each other, with domain-specific channels and components. This launch is the alpha release of that layer, starting with 40+ core components and integrations.

A few links if you want to kick the tires:

Ultimately, the goal is to make it safe to describe what you want in natural language and have the system execute it in a safe, auditable way. It’s a journey, and we’re committed to keeping it open and transparent.

You Need To Change The Whole Assembly Line

In the DevOps Paradox episode 2026 — The Year of Discovery, Viktor and Darin talk about how software work is changing, but the bottlenecks aren’t where people think.

A few quotes are basically a version of why we started SuperPlane. My comments below.

You cannot just give developers, here’s AI. Everything else stays the same… you need to change the whole assembly line.

Most organizations are currently applying AI to optimize the coding process. The constraint will simply move downstream: releases, verification, coordination, incident handling. If you don’t address the system, you get faster queues, not faster outcomes.

You have a platform that you can say, hey, give me a database, and you get that database. And that database is done based on your company’s best practices, rules, policies […] ask me questions that I need to answer and don’t ask anything more.

This is what engineers are actually asking for: outcomes, and systems that hide incidental complexity without hiding state.

People simply don’t want to… relinquish part of their power… [and] don’t want to introduce randomness in production.

This is the hard part. It’s not so much a capability problem as much it’s a trust problem. People will only use automation in production when it’s controllable, auditable, and fails in predictable ways.

To get there, I think we need a control plane that makes cross-tool operational workflows explicit and inspectable: what triggered, what ran, what it touched, and what evidence it produced. If you can’t explain a change, you can’t safely automate it.