Top
Best
New

Posted by wilhelmklopp 5 days ago

Towards Self-Driving Codebases(blog.detail.dev)
121 points | 99 commentspage 2
jakeinspace 5 days ago|
Kind of feels like we're in a similar place with AI programming as we are with self driving vehicles. Good enough for the typical case, maybe even better than most humans, but bad when dealing with novel situations or situations which require a really cohesive model of the system (code, business requirements, physical world, whatever).
kreneskyp 5 days ago||
My answer to this is adding an engineering assurance module to my specification and verification toolkit. Every project has a different definition of success and quality. My goal is to provide a consistent way to define, analyze, and report quality metrics tailored to each project.

https://github.com/agent-ix/engineering-assurance https://github.com/agent-ix/quoin

vb-8448 5 days ago||
> Global memory

I don't get why we need global memory for code? Aren't code comments (even if invented for humans) the ideal place where to put "memories"?

rrr_oh_man 5 days ago||
LLMs also do not have anything like memory, by design. Everything bolted on that smells like memory or is being called memory is a crutch, at best. Not being pedantic, I just think this aspect is lost on a lot of people.
Terr_ 5 days ago|||
Also, when we humans are tricked into perceiving a remote mind, we automatically assume it has a memory like us, or at least like large animals.

In other words, there's a story-document between a SherlockHolmesBot and UserPlaceholder that's growing like a crystal formation. Some software sees "Sherlock Homes Says" and then "performs" the dialogue at us, and we then assume Sherlock Holmes exists with a mind and memory, rather than being a facet of a text-story.

alansaber 5 days ago|||
Exactly, this is why we see such minimalistic memory systems being used. Information retrieval is bad, but improving information availability by pre-computing information retrieval is not the obvious fix people think it is.
drob 5 days ago|||
Sometimes, but I think there are a few problems with this:

1. Some context doesn't have an obvious place to write it in the code. If you're explaining why a tricky function is implemented a certain way, you can leave the explanation above the function or within the function. If you're explaining something more general, there might not be a natural place to put it.

2. Relatedly, some context doesn't have an obvious location to read in the code. E.g. you can comment on a schema that a table is intended to be append-only, but an agent could easily miss this comment if it doesn't gather context all the way down to the raw schema. Any research process has unknown unknowns. There may not be a canonical place to look.

3. Adding comments for every single human intent might be a bit noisy. E.g., if a code reviewer flags something that I know isn't a bug, I want the system to learn from this, and I want that knowledge to take effect outside of just code review, but I might not want every single code review thread to yield a codebase comment.

vb-8448 5 days ago||
1: There are corner cases, no doubt, but the main source of information should remain near the code.

2 & 3: How to be sure that the agent will pick the "append only hint" from the memory? Especially when it starts growing and cannot be part of the context?

lubujackson 5 days ago||
I think the bigger need is for outside concerns, like: what is the infrastructure like? How much volume does this feature handle? How should changes to live code be rolled out to prevent running processes from failing?

In addition to all the product details that aren't in the codebase or docs, like "keep this logical path because it is used by our one big client."

Mostly what I think is needed is a richer worldview available to the LLM so it understands not just the code but can understand the product and its real world usage and constraints.

vb-8448 5 days ago||
But how you are going to link the "keep this logical path ..." with the code? You cannot feed all the memory to the agent because of the context rot, and you are not sure the agent will always pick it when needed.
6thbit 5 days ago||
The things in the 'what should be self-driving' section are the exact things i give to juniors so they can build their mental model of the codebase.

Now, I agree it'd be fantastic to have that automated, but how do we then share that context with the humans that will drive the non-self-driving actions?

tonymet 5 days ago||
I'm hoping the "blogging about doing" format will fade away, now that doing is cheaper than blogging. It used to be that the doing part was expensive, and risky. Now you can just do 5 things and throw away 4. So I'd rather see the finished product than talk about it.
sroerick 5 days ago||
This article hints at it, but I think the blocker is environment.

How can you self drive an app on windows? There's no clear UI framework, design pattern, nothing which can bullet proof your app.

I bet you'd have better luck on Plan 9.

Remove the choice. Make frameworks which have limited options which are usable by default.

TimVasil 5 days ago|
Spot on about environment.

I recently built a calculator to try to quantify the gains an org could expect as they become more "AI-native." I tried to account for a bunch of things including env, which I call "AI roadway," but I'm definitely missing codebase readiness (thank you, author), and also bottleneck analysis. Even without those considerations, though, gains are usually modest. It's hard to get to 2x.

Tool is here if useful: https://timvasil.com/ai-native

ody2 5 days ago||
I have integrated AI into my application. The source code is embedded into the binary. When someone questions the numbers in my app it can debug itself. If it truly finds a bug in itself it will tell the user and open a ticket. Soon we are going to let the application fix itself.
jorl17 5 days ago|
How do you protect intellectual property? Or is this a case of the value being somewhere else, such as in your backend? If so, how does the agent debug frontend and backend? I presume it stops at frontend
jaksa 5 days ago||
Not sure about you, but I've been writing real world software using agents for a while now. https://github.com/jaksa76/microfactory
owebmaster 5 days ago|
Is this the "real world software" or a tool that creates "real world software"?
writeslowly 5 days ago||
I suspect that if you're not careful with agent memory it creates a danger of agent-driven cargo-cult behavior. I've watched this in my own ad-hoc agent loops where it starts with something basic, like the first agent tried to run some gigantic dependency inspection command and OOMed the local JVM and eventually recorded a workaround (to enable it to run gigantic dependency inspection commands...), and by time I get a few more agents into the loop, agents have written entire paragraphs about testing and validating local dev environment memory configurations that are mostly irrelevant to whatever is being worked on.

In general I've seen other issues like this where small errors and irrelevant comments in the codebase spin out into larger problems that consume annoying amounts of time/tokens. Maybe Anthropic and OpenAI don't notice this because they're in an "infinite monkeys with typewriters" scenario, but it's noticeable to me when the agent in my CLI has been spinning for 15 minutes contemplating irrelevant details

memjay 5 days ago|
This happens way too often in my experience and I tried a lot of things. If the agent has access to an existing codebase it will always try to stay as close to it as possible. It doesn’t diverge from the initial direction the project/code went into, even if it’s already clear that this direction goes nowhere. Somehow agents aren’t able to detach themselves from existing code to come up with completely new solutions.

Sometimes I feel like it would be best to only give the agent access to clear API boundaries (say public interfaces to certain modules) and let it work out a new system from scratch given the expected inputs and outputs. Then plug this independent solution into the system. Of course it can still overfit these interfaces but it’s less than having access to the entire codebase.

Thinking about it, maybe it’s possible to let one agent extract those interfaces, then use them as grounding for a new session.

One less nice way of achieving the same is to tell the agent once in a while that it should think completely from scratch (from first principles). But this relies heavily on instruction following in the reasoning part, which sometimes works and sometimes fails.

billybones 5 days ago|
Super exciting, and absolute killers on the customer testimonial page.
More comments...