We do something similar at work, called metadev. It sits above all repos and git submodules othe repos in, and works with multiple changes with multiple sessions with worktrees, and stores long term knowledge in /learnings. Our trick has been to put domain specific prompts in the submodules, and developer process in metadev. Because of the way Claude hierarchically includes context, the top repo is not polluted with too much domain specifics.

Two husbands without kids, working in tech, have a huge amount of cash, time capacity and ideation opportunity. I felt these added up to a huge advantage for getting quality shit done and taking risks. Fair play.

It makes you download it but then a button appears saying join in browser. I have tons of zoom binary copies

I have a pretty good one here https://observablehq.com/@tomlarkworthy/robocoop-2 and I have a port of opencode in-progress

I use regex to force an XML schema and then use a normal XML parser to decode.

XML is better for code, and for code parts in particular I enforce a cdata[[ part so there LLM is pretty free to do anything without escaping.

OpenAI API lets you do regex structured output and it's much better than JSON for code.

Could you share some samples / pointers on how you do this?

Yeah, this upsert_cell tool does it

https://observablehq.com/@tomlarkworthy/forking-agent#upsert...

format: { type: "grammar", syntax: "regex", definition: cellsRegex },

Where cellRegex is

cellsRegex = { const CELL_OPEN = String.raw`<cell>\s`;

  const INPUTS_BLOCK = String.raw`<inputs>.*<\/inputs>\s*`;

  const CODE_BLOCK = String.raw`<code><!\[CDATA\[[\s\S]*\]\]>\s*<\/code>\s*`;

  const CELL_CLOSE = String.raw`<\/cell>`;

  return "^(" + CELL_OPEN + INPUTS_BLOCK + CODE_BLOCK + CELL_CLOSE + ")*$";

}

And the extraction logic is here https://observablehq.com/@tomlarkworthy/robocoop-2#process

function process(content) { const doc = domParser.parseFromString( "<response>" + content + "</response>", "text/xml" ); const cells = [...doc.querySelectorAll("cell")]; return cells.map((cell) => { const inputsContent = cell.querySelector("inputs")?.textContent || ""; return { inputs: inputsContent.length > 0 ? inputsContent.split(",").map((s) => s.trim()) : [], code: (cell.querySelector("code")?.textContent || "").trim() }; }); }

BTW that agent is under development and not actually that good at programming. Its parent https://observablehq.com/@tomlarkworthy/robocoop-2 is actually very good at notebook programming

Parquet/iceberg

We fixed this at work by instructing it to maximize coverage with minimal tests, which is closer to our coding style.

also after you have a to-and-fro to course correct it on a task, run this self-reflection prompt

https://gist.github.com/a-c-m/f4cead5ca125d2eaad073dfd71efbc...

That will moves stuff that required manually clarifying back into the claude.md (or a useful subset you pick). It does a much better job of authoring claude.md than I do.

?

Its like GET <namespace>/object, PUT <namespace>/object. To me its the most obvious mapping of HTTP to immutable object key value storage you could imagine.

It is bad that the control plane responses can be malformed XML (e.g keys are not escaped right if you put XML control characters in object paths) but that can be forgiven as an oversight.

Its not perfect but I don't think its a strange API at all.

That may be what S3 is like, but what the S3 API is is this: https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/s3

My browser prints that out to 413 pages with a naive print preview. You can squeeze it to 350 pretty reasonably with a bit of scaling before it starts getting to awfully small type on the page.

Yes, there's a simple API with simple capabilities struggling to get out there, but pointing that out is merely the first step on the thousand-mile journey of determining what, exactly, that is. "Everybody uses 10% of Microsoft Word, the problem is, they all use a different 10%", basically. If you sat down with even 5 relevant stakeholders and tried to define that "simple API" you'd be shocked what you discover and how badly Hyrum's Law will bite you even at that scale.

> That may be what S3 is like, but what the S3 API is is this: https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/s3

> My browser prints that out to 413 pages with a naive print preview. You can squeeze it to 350 pretty reasonably with a bit of scaling before it starts getting to awfully small type on the page.

idk why you link to Go SDK docs when you can link to the actual API reference documentation: https://docs.aws.amazon.com/AmazonS3/latest/API/API_Operatio... and its PDF version: https://docs.aws.amazon.com/pdfs/AmazonS3/latest/API/s3-api.... (just 3874 pages)

It's better to link to a leading S3 compatible API docs page. You get a better measure of the essential complexity

https://developers.cloudflare.com/r2/api/s3/api/

It's not that much, most of weirder S3 APIs are optional, orthogonal APIs, which is good design.

Because it had the best "on one HTML page" representation I found in the couple of languages I looked at.

That page crashes Safari for me on iOS.

It gets complex with ACLs for permissions, lifecycle controls, header controls and a bunch of other features that are needed on S3 scale but not at smaller provider scale.

And many S3-compatible alternatives (probably most but the big ones like Ceph) don't implement all of the features.

For example for lifecycles backblaze have completely different JSON syntax

Last I checked the user guide to the API was 3500 pages.

3500 pages to describe upload and download, basically. That is pretty strange in my book.

Even download and upload get tricky if you consider stuff like serving buckets like static sites, or stuff like siged upload URLs.

Now with the trivial part off the table, let's consder storage classes, security and ACLs, lifecycle management, events, etc.

Everything uses poorly documented, sometimes inconsistent HTTP headers that read like afterthoughts/tech debt. An S3 standard implementation has to have amazon branding all over it (x-amz) which is gross.

I suspect they learned a lot over the years and the API shows the scars. In their defense, they did go first.

I mean… it’s straight up an Amazon product, not like it’s an IETF standard or something.

!!!

I’ve seen a lot of bad takes and this is one of them.

Listing keys is weird (is it V1 or V2)?

The authentication relies on an obtuse and idiosyncratic signature algorithm.

And S3 in practice responds with malformed XML, as you point out.

Protocol-wise, I have trouble liking it over WebDAV. And that's depressing.

HTTP isn't really a great back plane for object storage.

Etag and cache control headers?