The self-driving company

Most companies already run on software. Very few run on software that moves on its own. Someone still has to notice the problem, write the ticket, wait for a sprint, chase the review and check that the fix shipped.

AI agents change that. They can take a goal, read the codebase, make the change and test it. That raises a bigger question than developer productivity: what does a company look like when agents carry most of the work from intent to result?

Replit calls this the self-driving company, and the name fits. People choose the destination and stay accountable for the route. Agents do the driving, inside limits the company sets.

What "self-driving" means, borrowed from cars

The car industry already has a useful vocabulary. SAE's levels of driving automation run from Level 0, where the human does everything, to Level 5, where the car drives anywhere with no one at the wheel. The interesting levels sit in the middle. The car drives, and the system knows when to hand control back to a person.

Companies sit on a similar scale:

1. Level 0, manual. People do the work and coordinate it through meetings and tickets.
2. Level 1, assisted. Individuals use AI to draft, summarize and autocomplete. The workflow and the org chart stay the same.
3. Level 2, delegated. Engineers hand well-scoped tasks to coding agents and review the pull requests. Output goes up, but only for the people who can operate the agents.
4. Level 3, shared. Anyone close to a problem can put agents to work on it, on the real systems, with clear rules for when a human must approve.
5. Level 4, self-driving. Agents carry most work from goal to result. People set direction, judge quality and handle the exceptions agents flag.

Most teams we talk to are at Level 2. The jump to Level 3 is where a company starts to become self-driving, and it's mostly an organizational problem. Better models alone won't get you there. For the engineering side of that maturity curve, see The 5 stages of AI nativeness.

Why engineering-only agents stall

When only engineers can direct agents, every idea still queues behind them. A PM spots a confusing onboarding step and writes a ticket. A designer files a spacing fix. Sales needs a CSV export before a customer renews. Each request waits for an engineer to turn it into a prompt, run the agent and check the result.

The agents got faster. The handoffs didn't. The engineer becomes the bottleneck the agent was supposed to remove.

A self-driving company lets the person who understands the problem start the work. They describe the change in plain language, shape the plan with the agent and check the result themselves. Engineers stop acting as translators and start building the system that makes it safe to delegate.

The false choice between a caged agent and a loose one

Leaders who try to get there usually hit the same wall. They can lock agents down, with narrow access and little to show for it. Or they can hand out credentials and let people run agents from personal accounts and chat windows, where nobody decided what the agent can touch and nobody can see what it changed.

Neither works. The first never gets past Level 1. The second leaves production systems and customer data one bad prompt away from an incident.

A self-driving car doesn't solve this by removing the brakes. It drives inside lanes, shows the passenger where it's going, and hands control back when it should. A company needs the same things.

What a self-driving company needs

Lanes: isolated environments

Every agent task runs in its own sandbox with its own copy of the codebase. Not on someone's laptop, and never directly on production. If the agent gets something wrong, the mistake stays in the sandbox.

A plan everyone can read before any code

Before an agent writes code, the plan is visible to everyone involved. A designer can catch a missing empty state. An engineer can flag the service that shouldn't be touched. Fixing a plan takes minutes. Fixing a merged change takes a release.

Live previews for the people who asked

The person who requested the change should check it in a running preview of the real product, not a mockup or a screenshot. They know what "right" looks like better than anyone reading the diff.

Brakes: approval where it matters

Agents can act freely inside the sandbox. Anything that reaches production goes through a person with the authority to approve it. That means separating who can propose a change from who can merge it, and keeping the review rules engineering already trusts.

Work that starts where people already are

Requests shouldn't need a new tool to begin. A Slack thread, a Linear issue or a Jira ticket should be enough to start a task, with updates flowing back to the same place.

Control of your own models

Models improve every few months. A self-driving company should be able to bring its own models and subscriptions and switch between them without moving its codebase, permissions or history.

What changes for people

The self-driving company doesn't remove people from the work. It moves them up a level.

• PMs spend less time writing tickets and more time deciding what to build and checking whether it worked.
• Designers ship their own polish instead of filing it and waiting.
• Ops and support fix the internal tools and workflows they use every day.
• Sales can act on the request that would close the deal, then hand engineering a reviewed change.
• Engineers spend their time on architecture, test coverage, guardrails and review. That's the work that lets the company delegate more, safely.

Meetings change too. Teams spend less time debating a mockup and more time reviewing working software.

How to move up a level

You don't need a company-wide transformation to start. A practical path:

1. Pick one repo and one team. Choose a product area with a steady stream of small requests.
2. Make the codebase agent-ready. Reliable setup scripts, decent test coverage and written conventions make agents far more dependable.
3. Decide who proposes and who approves. Write it down before anyone outside engineering ships a change.
4. Start with small, visible changes. Copy, UI polish and internal tools are good first tasks for non-engineers.
5. Measure the handoffs. Track time from request to merged change, and how many merged changes started outside engineering.

Where LightSprint fits

LightSprint is built to get teams to Level 3. PMs, designers and ops describe changes in plain language on the team's real codebase and work on the plan together. Each change runs in an isolated sandbox with a live preview, and the pull request goes through the engineering approval controls the team already uses.

Builders propose changes and view previews but can't merge. Approvers, usually engineers or leads, review and merge. Tasks can start in Slack, Linear or Jira, and teams can bring their own models and subscriptions. Read more about how we handle sandboxes and permissions, or how a whole team runs agents together in a multiplayer software factory.

The destination is still yours

A self-driving car still needs someone to choose where it's going. So does a company. Agents can carry more of the work than ever, but deciding what's worth doing and owning the result stays with people.

The companies that let everyone direct agents, safely and on the real systems, will ship what their competitors are still writing tickets for.

Start for free