Self-Driving Codebases

Hi friend!
​
Today I'm sharing a few notes on my experiments around self-driving codebases, a phrase often used by the Cursor team. If you find this interesting, share it with a friend or colleague!
​
Thanks for reading,
Robert

Notes: Self-Driving Codebases

The idea of a self-driving codebase might sound abstract. But with recent releases from Cursor, Claude Code, and similar tools, it is becoming more concrete.

Across the major coding harnesses, the same shift is happening: coding agents are moving from interactive assistants inside an IDE to programmable infrastructure that can be triggered and managed programmatically.

In its current form, a software release- and feedback cycle in a typical company might look roughly like this:

Production errors and explicit user feedback usually move through several handoffs: support triages the issue, a PM or planning process turns it into a ticket, a developer investigates and writes the fix, and the change then moves through the release process before reaching users.

A self-driving codebase, in contrast, might look something like this:

Instead of turning feedback and errors into a long handoff process, they can trigger a cloud agent that investigates the issue, proposes a fix, and pushes the result into the CI/CD pipeline, with or without human review.

That trigger can live outside the codebase, for example as part of an automation workflow, or it can become part of the product itself. The second version is what I am currently exploring:

In my side project Readbetter, a tool that converts newsletters into Kindle-ready EPUB files, a recurring failure mode is that Amazon rejects a generated file. The only signal is a vague email saying the file could not be processed.

Previously, that email started a lengthy manual process: tracing the affected account, locating and downloading the EPUB from the cache, running validation scripts, inspecting the issue, finding the relevant code path, fixing the bug, testing, and shipping a new release.
​
Now, the email triggers a cloud agent.

Email parsing is already a core part of Readbetter, so I extended that flow with a function that can call the Cursor SDK. The failure email is parsed, the relevant context is extracted, and a Cursor cloud agent is started with a pre-configured environment.

The agent receives the context and runs through the same steps I previously handled manually, inside a sandboxed cloud environment. It then proposes a fix by pushing to a feature branch and opening a PR.

That is the lite version of a self-driving codebase: a real production failure becomes a structured coding task automatically.
​
In my own experience, Cursor currently offers the smoothest developer experience for setting this up with very little overhead. You could build a similar loop with Claude Managed Agents, or with more configuration on top of other coding harnesses.

The broader direction is clear: AI is no longer just helping inside the coding loop; it is starting to close the loop between production signals and code changes.

Headlines & Links

• ​You can now also coordinate agents in VSCode with its own version of the "agents window".
  ​
• Codex is getting natively integrated into the ChatGPT mobile app:

OpenAI @OpenAI You've been asking for this one... Now in preview: Codex in the ChatGPT mobile app. Start new work, review outputs, steer execution, and approve next steps, all from the ChatGPT mobile app. Codex will keep running on your laptop, Mac mini, or devbox. 8:6 PM • May 14, 2026 2613 Retweets 21750 Likes Read 1616 replies

​

• ​Apple Silicon costs more than OpenRouter – not surprising: running an open source model locally will often be costlier compared to the cloud based if you fully price in the hardware and electricity
  ​
• ​Codex-maxxing - Jason from the Codex team wrote a post about how he uses Codex. What I found most interesting was the non-code related work, i.e. combining it w/ Slidev to create slidedecks, or leveraging computer-use to get an Amazon refund.