[jameslk]

At least for me, I have felt like the chat history in an agent is often times just as important and potentially even more important than the source code it generates. The code is merely the compiled result of my explanations of intent and goals. That is, the business logic and domain expertise is trapped in my brain, which isn't very scalable.

Versioning and tracking the true source code, my thoughts, or even the thoughts of other agents and their findings, seems like a logical next step. A hosted central place for it and the infrastructure required to store the immense data created by constantly churning agents that arrive at a certain result seems like the challenge many seem to be missing here.

I wish you the best of luck with your startup.

[vidarh]

I'm building an "improvement agent" that kinda embraces that. It starts out by running exploration across a codebase or set of documents and extract possible goals, and a vision from that. It then starts producing improvement plans (tickets, effectively). If it gets things wrong, I nudge it in the right direction, and it gets incorporated into revisions of the documents via a review stage. It's an experiment for now, but it is both doing semi-self-directed implementation and helping me identify where my thoughts haven't been crystallised enough by seeing where it fails to understand what I want.

I'm not just running it on code, but on my daily journal, and it produces actionable plans for building infrastructure to help me plan and execute better as a result.

[grey-area]

Natural language is in fact a terrible way to express goals, it is imprecise, contradictory, subjective, full of redundancies and constantly changing. So possibly the worst format to record business rules and logic.

This lesson has been learned over and over (see AppleScript) but it seems people need to keep learning it.

We use simple programming languages composed of logic and maths not just to talk to the machine but to codify our thoughts within a strict internally consistent and deterministic system.

So in no sense are the vague imprecise instructions fed to LLMs the true source code.

[vineyardmike]

Before LLMs (and still now) a human will often write a doc explaining the desired UX and user journeys that a product needs to support. That doc gets provided to engineers to build.

I agree - at least with the thesis - that the more we "encode" the fuzzy ideas (as translated by an engineer) into the codebase the better. This isn't the same thing as an "English compiler". It'd be closer to the git commit messages, understanding why a change was happening, and what product decisions and compromises were being designed against.

[grey-area]

I think I’d rather have the why in English and the how in code, i.e. keep both, keeping just the English instructions is nowhere near enough to fully specify what was done and why. These things evolve as they are produced and English is too fuzzy.