A useful version of self-driving software is already taking shape
Self-driving software describes a system that can observe problems in production, investigate them and propose changes to its own code. Automated bug fixing already covers parts of that process. A dependable loop also needs tests, release controls and evidence that the original problem stopped affecting people.
For a business running custom quoting, scheduling or operations software, that is a practical opportunity. A recurring failure can arrive with its likely cause and a proposed repair, instead of becoming another vague ticket waiting for someone to reproduce it.
Sentry, PostHog and GitHub are building different parts of this loop. Their tools can move work toward a pull request: a proposed code change that a team can inspect before merging. How far that proposal can travel safely depends on the systems around it.
What Sentry, PostHog and GitHub can do today
Sentry starts with the failure. Seer uses issue details, traces, logs, profiles and connected code to investigate errors and performance problems. It can propose a fix and create a pull request, or hand implementation to a supported coding agent. Repository integration and enabled features are prerequisites. Sentry also distinguishes its Seer Agent conversational feature, which is in open beta, from the broader Seer toolset. See the Seer documentation.
PostHog starts with signals about the product. Its self-driving research agents investigate connected sources such as error-tracking exceptions and GitHub issues, then produce reports with urgency and actionability assessments. The research workflow is in open beta. Its implementation workflow creates a branch, changes the code, runs local tests if configured and opens a PR for review. PostHog describes the person reviewing and merging that change; installing it does not hand over production deployment.
There is a useful extension for AI features: PostHog can turn LLM evaluation results and changes in cost, latency or errors into investigations. Its AI Observability documentation labels anomaly investigations alpha. These are capabilities to evaluate against your own incidents, rather than assume every finding is correct.
GitHub Copilot’s cloud agent can take a task, work in an isolated development environment, run tests and linters, and open a PR. It can then iterate on review feedback. GitHub explicitly calls for reviewing and testing generated changes before merging. That makes it a possible implementation layer in a larger system, with documented limitations and responsibilities.
Full-stack integration gives the agent a trail to follow
A customer says, “I clicked once and got two orders.” The browser shows a timeout. The API accepted the request. A background worker retried it. The order system now contains two records. Every tool may be reporting something accurate, while none has enough context to explain the whole failure.
Full-stack integration connects those observations. Carry a request identifier from the interface through the API and queued jobs. Associate it with the release version and the relevant order identifiers. Preserve retry history and the downstream response. Use access-controlled identifiers for correlation; avoid copying customer details into every log.
| Connection | Question it should answer |
|---|---|
| Support report to product session | What was the customer trying to finish? |
| Session to API and worker traces | Where did the request stall, retry or branch? |
| Trace to release and repository | Which deployed code handled it? |
| Proposed fix to regression test | Can we reproduce the failure and show the change prevents it? |
| Release to business records | Did customers complete the task, and are affected records accounted for? |
This is integration work you can start today. It does not require replacing every application or giving an agent every database. Our platform and cloud work connects release, monitoring and recovery; data integration establishes which system owns the records those checks depend on.
Follow one bug all the way through the business
Consider an illustrative wholesale business whose customer portal sometimes duplicates orders after a timeout. Here is a proposed workflow, not a claim that any one vendor supplies the entire sequence out of the box.
The support report and production traces become one investigation. The agent identifies a retry path that can create a second order, then prepares a failing test using synthetic order data. The test exercises both a retry after an uncertain response and two attempts arriving together.
A proposed patch makes repeat processing safe: a stable operation key and an atomic record of the accepted operation prevent two workers from independently creating the same order. The implementation must fit the downstream platform’s actual API and transaction behavior. Reviewers should see why the failure occurs, the changed code, the failing-then-passing test and any assumptions the agent could not verify.
After review, the delivery pipeline deploys the change to a limited population and checks the outcome. Are duplicate orders declining while legitimate orders still complete? Error counts alone are insufficient: swallowing an exception can make a dashboard look healthier while customers remain stuck.
Existing duplicates need a separate recovery plan. An operator reviews affected orders before canceling shipments, releasing inventory or adjusting invoices. Shipping a code fix does not reverse a warehouse action. Link the investigation, PR, deployment and recovery record so support can see what was actually resolved.
The interesting opportunities extend beyond crashes
Once those connections exist, the same approach could investigate quieter problems. These are designs to test, not established outcomes or promises about a particular product.
- A quote that customers keep abandoning. Combine a change in completion rate with relevant sessions and release history. The agent might find a broken validation rule and propose a test. A confusing price or weak offer still needs a business decision.
- An integration drifting out of sync. Detect that accepted requests are no longer reaching the dispatch system. Give the agent the connector’s schema, sanitized failed payloads and version history so it can propose a mapping repair.
- An AI feature getting expensive. Investigate repeated retrieval calls or retry loops, then propose a change tested against both cost and answer quality. A cheaper run that produces unusable answers has failed the evaluation.
Prioritize by consequences. One blocked dispatch workflow can deserve attention before thousands of harmless browser warnings. Give investigators the business definitions needed to make that distinction, and keep their priority judgments reviewable.
The next step is software that checks its own improvements
Our expectation is that routine maintenance will increasingly arrive as a proposed change with evidence already attached. The best systems will also return after deployment to check whether the intended outcome improved. That is a forecast about where the workflow is heading, not a claim that arbitrary business software can safely run unattended today.
We would expect autonomy to grow first around narrow, reversible work with strong tests and clear ownership. Cross-system incidents remain harder: a model may understand the code but lack the supplier’s status, the warehouse cutoff or the finance rule that explains what should happen next.
A sensible first build connects one recurring failure to its evidence, an isolated repair environment, review and a measurable production outcome. Keep an engineer responsible for the result. Expand only when accepted fixes, recovery time and operating cost justify it.
Bring us a recurring failure and the systems it crosses. We can map the path from bug report to verified fix.
Written by the dplyz team
Senior engineers who work inside client companies to take AI from pilot to production: agentic workflows, AI integration and the platform work around them.
