I still like the idea of source code as documentation and unit tests as documentation. While revising code written by an LLM to make it easier for humans to understand is now a controversial practice, I believe it's worthwhile in a lot of case.

> Markdown is becoming source code, not documentation

> That Markdown should be checked in to /src

I've made a similar argument last June, although I made the point with a sample project rather than manifesto style

https://github.com/TZubiri/keyboard-transpositions-checker

> A Proof of Concept for LLM as source code. I am of the position that the "code" is now target code and not source code. My strongest source for this claim is Stallman's classical definition of Source Code which is the "preferred way to modify the program".

> Upload the conversation with ChatGPT as source code

Although this was pre-agents/markdown, the main way to generate code was just with user-interface conversations with the LLM.

And my position differs in which I argue against uploading the target code, just the source code. Which is an issue if the LLM is not deterministic, but it's workable.

That said I apparently did foreshadow solutions to these issues

> Since we are using a consumer interface, and not an api, (first we have no guarantees that the code will not be used for training, so there's no IP protection, but also), we don't have much reproducibility, robust publishing should use API access and publish exact model with revision as well as seed (and even then we are not guaranteed reproducibility.

I think in general we'll end up rewinding so much, the sloppers are recursing and building a ton of harnessing tools that will need to be trashed because they made a fundamental mistake at the very first steps. Those of us who are a bit more careful will probably only get back to agentic engineering once the slopper activity dies down, it's pretty much career suicide at this point to get into it. Anyone who is barely careful is just waiting it out.

Let’s keep the Codex session JSONL there too, why the hell not. And the debug build logs, since they’re easily greppable text useful for diagnosing recurring problems. And logs/reports from every test run - a ton of useful info there, lets you track regressions over time; would be a shame to throw it away. We could also store screenshots of every app run to have a LLM-compatible historical record of how each component changed visually. And the token provider billing documents, since we’re gonna have a lot of those once we’ll start maintaining all that.

So

1. he's describing a manual version of Spec-Kit / OpenSpec / BMAD?

2. Thinks Markdown is... somehow different from normal text or other markup languages?

3. Doesn't seem to understand that LLMs are not deterministic?

This sounds a lot like a low tech version of Delta from Zed. All your agent transcripts live in the same place as code.

src/md doesn’t seem all that different from docs. Maybe it changes how people search the filesystem, though?

If you split code up into multiple packages, moving the docs closer to the code might make sense. The docs for package foo could be in packages/foo/docs.