Don't overthink it! `git bug bug` is fine - it's easy to type and becomes muscle memory quickly. Love the project, my first impression is "why hasn't this existed the entire time?" which usually means you're on to something.

Mines pretty much inverted - my colleagues and I noticed almost zero difference between the quality of code in Opus vs Fable. Occasionally I'll switch to Fable for an arduous debugging task but that's about it.

I'm very interested in this but I am confused on what Pi provides you if you are building the harness? What does Pi get you that writing from scratch doesn't?

Any good starting points or tutorials you recommend?

Pi is just a nice base and it has defined extension protocols and such. You might as well start there, it's just easier and going from nothing to working to adding whatever functionality is like 2 minutes.

Yes they are, in the form of lobbying to remove subsidies and adding tax penalties to EV/solar purchases.

I never said I believed it was going to save us.

Weird, I'm still using my M1 Pro and it feels just as fast as it always has. MacOS feels almost identical to me as it did 5 years ago, too, except the ugly icon change.

Tahoe slows it down, but Seqouia is still strong.

same... mine works great...

Disagree, I want to go to the party hosted by $10 rag guy

I'm curious how that works - are you actually hand writing specs with RFC level detail yourself completely or is it more of an LLM assisted effort? It seems like writing a comprehensive spec manually would almost be as much (if not more) work than the implementation.

I'm writing the specs by hand.

The LLM solely helps with research and retaining the normative document layout (RFC 7322).

Since the spec grounds the underlying implementation I have to fully understand it, writing the spec manually prevents infecting the spec with the typical LLM specification slop.

When writing the specs, the goal is to systematically keep the right balance between scope and depth:

- Scope takes the most effort because it's the only thing preventing the model from escaping an intended boundary, that includes things like stable constraints/interfaces/data models

- Depth is something where I can tolerate "non-normative" interpretations by the LLM. Unless I need a stable implementation, I can decide how much I manually invest into depth vs. letting the model figure the "good enough" solution.

Since the scope/boundaries are explicitly set, the internals are pretty encapsulated and the model comparing an implementation with the spec can identify the "non-normative" pieces and communicate those to me. Then I can decide between "good enough" or to refine these non-normative implementations and make them normative.

From my various experiments the spec vs. code ratio is roughly 1/8.

I have tried prompting it out and providing strong guidelines in my AGENTS.md against it, but I still get _way_ too many useless "explain the code" style comments no matter how much I try. I usually have to do something like "Look at all commits in the past X days and remove (DO NOT TRIM) all comments that are not truly exceptional"

Normally when I can't get claude to follow a prompt I try a lint hook, but it's tough to lint something that subjective.

I find well described but concise acceptance criteria does a good job of anchoring the llm to the correct output. Also have them take screenshots of any UI work and respond to the ticket with them as proof.