The autonomous codebase

Estimated reading time: 6 minutes

Key takeaways:

• Prompt-to-PR is solved, but maintaining what exists isn’t. New models barely move the needle; a big monorepo change still hurts.
• The next leap is a self-maintaining codebase: triggers and agent functions that fix issues before anyone opens a prompt window.
• None of it works without codebase-wide context. 

Five years into the AI-assisted coding experiment, I rarely find myself saying “wow” anymore. We, as an industry, have honed the prompt-to-code pipeline to just about the finest point imaginable. That’s not to say we haven’t made a huge leap – I recently used a first generation Retrieval-Augmented Generation (RAG) chat coding assistant for the first time in years, and it felt like I was trying to code by writing in the dirt with a rock. 

The progress has been so fast, and so massive, I’ve come to expect the world. However, when a new model drops these days, I can rarely detect a difference in the code. The harness wars just don’t feel that exciting anymore, and the fact that they’re all competing on new battlegrounds (cloud infrastructure, multi-agent orchestration, extensibility) makes it clear that we’ve pretty well nailed the prompt to PR (or issue to PR, or plan file to PR, pick your favorite jumping off point) problem.

That doesn’t mean the developers of the world can pack up and retire to a farm. I still find myself groaning in pain whenever I need to update something non-trivial in our Sourcegraph monorepo.

I talk to engineering leaders at large, enterprise companies every week that tell me the same story. I don’t know if it’s just a context problem anymore; if it’s context availability, or context window exhaustion, or low quality retrieval and wasted effort, or a simple mismatch between the coding agent paradigm and the sheer scale of these codebases. Maintaining existing, “brownfield” code remains very much unsolved. 

What’s more, as the quality of code generated by new models has begun to plateau (at pretty damn good code), I can confidently say that a new model drop isn’t going to solve this problem. 

It’s part context, part infrastructure, part interaction model. It requires a paradigm that looks absolutely nothing like “prompt to PR.”

The agents that revolutionize how we maintain large, existing codebases will look nothing like a text box

The simplest version of an autonomous agent is a cron job.

“Every Monday morning at 8am analyze our logs and o11y stack for anomalies and let me know what you find.”

“Every evening send me a recap of progress against our Q3 roadmap in Linear.”

As groundbreaking as a tool built in 1975 can be, these sorts of autonomous workflows have changed the way I work more than any coding agent harness has in the last couple of years. You can still vaguely see that same “prompt to PR” shape in these agents, but the jump they take from human initiated to self-driven clearly sets them apart. 

At a high level, I don’t want to be an engineering manager for my agents. I don’t want to be a proxy that has to tell my agent what to do when I get alerted about downtime or a new supply chain vulnerability or a customer complaint. The promised land is a self-maintaining codebase. 

The simplest primitives for this system are:

• A system of triggers: “8am on Monday,” a new commit landed in an upstream repo, a new Common Vulnerabilities and Exposures (CVE) report was published, a supply chain attack was reported, production logs showed high latency in our indexed search pod, memory ran out in a customer’s Sourcegraph instance, Sentry reported elevated error rates after commit c321e0e landed, and so on.
• A system of callable, composable agent “functions:” a Deep Search codebase-wide investigation, a notification to a human via Slack or email, a coding agent deployed to fix an issue and push a PR, a mechanism to generate batch changes across a codebase, and more.

This system would be autonomous, composable, and fully agentic. Yet, it is still more deterministic than what many thought leaders are proposing; it’s a simple, directed graph workflow, with purpose-built agents deployed to solve enterprise codebase problems. The system could be recursive, or even self-modifying, but that’s not required. The agent harnesses you choose determine how much rope you give it.

I should be clear that this is not a new concept. Every enterprise I talk to is thinking about agentic Software Development Life Cycle (SDLC) automation. Agent-to-Agent (A2A) was defined partly to enable this sort of workflow. Billions of GitHub Actions run per year, a large portion of which likely have a large language model (LLM) step in them! Yet, massive, unsolved problems like identity, authorization, and budget controls remain outstanding.

My belief is that many of these issues are our own creations, and are solvable at the harness level. We’ve spent four years generalizing harnesses in pursuit of prompt-to-PR perfection: an agent that can take any human instruction and execute against it!

In the coming years, inside of enterprises, we will move in the opposite direction, and see more narrowly scoped and narrowly authorized agents composed into trigger/function workflows that automate codebase maintenance work safely. 

That is the promise of the autonomous codebase.

Everything worth doing in a codebase starts with understanding

The latest trend in large enterprise agent rollouts is “enterprise knowledge bases.” Let me tell you, it’s a great time to be a context shovel seller. 

However, I want to be clear that this is a very, very positive development in the cycle. Thousands of enterprise dev teams have moved mountains and spent millions of dollars in token contracts to roll out coding agents to every corner of their engineering orgs, in many cases rewarding and even mandating tokenmaxxing.

The result is a tidal wave of absolutely terrible code that then needs to be reviewed, tested, fixed, instrumented, and ultimately trashed or deployed. Agents can do all of that, too (the Anthropic and Cursor sales reps say)! 

What they can’t do is tell you, while you’re writing the code or even before you merge, that the service or library you changed is used by another part of the organization in a different repo, on a different code host. Or that the blast radius of your agent’s work was completely underestimated.

New York • September 15 & 16, 2026

Don’t figure it out alone. Learn what works at LDX3 New York.

Explore

I can’t blame those sales reps though. Their products are revolutionary, and can turn any prompt into a PR. In the real world, they’re being asked to guess what number you have behind your back. Context, as they say (or in this case, retrieval), remains absolutely essential for agents to do good work.

Even the autonomous codebase system I describe above would fail without codebase-wide context. It may be beautiful in its simplicity, but deployed against a two-thousand-repo codebase, it simply wouldn’t be capable of doing much of anything right.

How can an agent investigate a CVE if it can’t clone and grep every single repo before it’s sandbox times out, before it goes into context window exhaustion psychosis, or before the LLM just decides “I’ve done enough, this should be good?” 

Everything worth doing in an enterprise codebase starts with universal code visibility and code understanding. Some things never change: context is king.