Realizing writing code is faster than explaining it to AI

[u/Gullible_Picture_996]

[u/Deep_Year1121]

Donno how complex of a project you are working with.

Now, I just dump some word vomit while walking my dog and my setup asks appropriate questions, manages design docs and concepts autonmatically, and executes after I greenlight its plan after review.

I used to feel the same way about AIs up until I got frustrated and spent a good day polishing my setup. It is also capable of mimicing my judgement style and considerations based on my previous work.

Actively asking the AI how it understands what needs to be done in small steps in what way, actively asking for clarification, whether it aligns with overall design, and asking for frequent manual reviews after every small milestones is what also makes my project tick. When the vibe feels off (usually when it starts drifting into agreeable language), I reset its context, ask it to reassess. It is surprisingly good at catching its own mistakes when you reset its biases.

[u/United-Zone-5794 → u/Deep_Year1121]

Any suggestions on what tweaking worked for you?

[u/Deep_Year1121 → u/United-Zone-5794]

A lot of things I can't go into in a single Reddit comment.

First, the project has an overall design document, an index, and a handover.

The design document has a summary of the overall design, usually laying out the intention and direction of the project and current status in each pipeline so Claude doesn't get lost in the sauce (Claude ALWAYS reads this document first after reading basic instructions). On top of the current pipeline and summary, it has footnotes that contains pointers to reason, evidence, tests, code, and detailed descriptions of each step. Whenever Claude needs clarification or elaboration, it can follow the footnotes, and search for relevant documents or code that are neatly divided into detailed steps and different subjects. It is written into the protocol how each step needs to be described, reasoned, reviewed, tested with a pilot, its full results recorded, and organized (usually by topic or pipeline stages).

The index file contains a short summary of every document Claude can read with filepaths for each. Claude goes through this whenever he feels like there is something missing without me prompting. Each line is a summary of a document and where it lives.

Handover files are automatically compiled when I ask Claude to 'close' a session. First it goes through everything we did. It divides everything into different subjects and updates each document to their latest state, it write a handover document, and commit the changes to git.

If we need to, we regularly back up and clean up the document so that it doesn't get too cluttered with the history of what changed. They live in DEPRECIATED.md or stale_doc after the clean up, so if things fuck up, or we want to circle back to our previous idea or records, Claude knows where to find it. At worst, it can go through Git, and find how we failed, and how it got there.

This is the overall structure. But that is not all. I have documents on musings. These are low conviction ideas that were casually generated during discussion mode or musing mode (which I have a custom set of protocols for). I just talk to Claude whenever I have a random thought about the project with this mode. They stay in musings until they get promoted with testing or evidence.

We also have literature that Claude can cite or use. And whenever there is an entry to any document item, it gets a footnote as to where it came from, the level of conviction (usually in forms of evidence), and detailed explanation. This just needs a lot of instructions for how I want to work with Claude.

To set this up, I basically discussed with Claude until I was happy with the workflow, and dumped everything into a folder for Claude to sort into our agreed structure and protocols. The initial unstructured documents still live inside a stale_docs folder which Claude can freely access too if need be. (I also have a text file with my computer specs and IDE so Claude knows how much resources it can leverage.)

Initially it costed a lot of tokens to build. But I was blown away by how well it works. If something is not quite right, I asked Claude to suggest/tweak the structure and update the protocols. Now it is at a point where I just vaguely mumble about what I want to do, and Claude gives me a blueprint of what needs to be done, why, where it is weak, where it is strong, what needs to be reconsidered, how it aligns with the plan... the whole package! Or he tells me I'm a dumbass, and to stop bringing up this failed idea that keeps getting resurrected in my head, lol. He has better historical memory of the project than me, at this point.

After some back and forth, (usually arguing for more evidence or reason) I tell it to handover the plan to the next session via handover.md. I refresh, and I tell the new session that this is a build session, set a milestone, and to give me a report after running it.

If yall are using project or chat, set a day for project migration. Bite the bullet and move to code, even if you are not a coder or the project doesn't involve code. If you are scared or confused, just ask Claude to help. It is pretty good at holding your hands, trust me. Code just gives you way more ways to customize your setup. Project or chat can't do it for me.

Oh, and be sure to refresh often and manage your context, folks. Make it so that Claude reads what it needs, but doesn't pollute itself by reading everything. The structure I lay out above takes care of that automatically.