So, Greenspun's Tenth Rule seems to have come full circle: now, "Any sufficiently complicated Coalton program contains an ad hoc, slow implementation of half of OCaml." ;)
I've left out "informally specified, bug-ridden" because I guess that's not the case for Coalton, but kept "slow" for when Coalton is used on a slower CL implementation.
There's also Armstrong's Corollary: "All sufficiently complicated distributed systems contain ad hoc, informally-specified, bug-ridden, slow implementation of half of Erlang".
Sure. It's just an old I7 8700 (non-k), 64gb ram. Running proxmox. But recently I put an AMD R9700 AI Pro, in there which is a 32gb inference focused card, think of it as a 32gb version of a 9070xt.
All the inference happens on that card, so the CPU/RAM is there for the other containers.
I'll eventually swap the motherboard and CPU for something better, so I can fit 1 or 3 more of those cards.
Why not NVIDIA? 32gb on team green means spending crazy money. And I can get 4 R9700s for the cost of one 32gb 5090.
> The main difference between my workflow and the authors, is that I have the LLM "write" the design/plan/open questions/debug/etc. into markdown files, for almost every step.
>
> This is mostly helpful because it "anchors" decisions into timestamped files, rather than just loose back-and-forth specs in the context window.
Would you please expand on this? Do you make the LLM append their responses to a Markdown file, prefixed by their timestamps, basically preserving the whole context in a file? Or do you make the LLM update some reference files in order to keep a "condensed" context? Thank you.
Not the GP, but I currently use a hierarchy of artifacts: requirements doc -> design docs (overall and per-component) -> code+tests. All artifacts are version controlled.
Each level in the hierarchy is empirically ~5X smaller than the level below. This, plus sharding the design docs by component, helps Claude navigate the project and make consistent decision across sessions.
My workflow for adding a feature goes something like this:
1. I iterate with Claude on updating the requirements doc to capture the desired final state of the system from the user's perspective.
2. Once that's done, a different instance of Claude reads the requirements and the design docs and updates the latter to address all the requirements listed in the former. This is done interactively with me in the loop to guide and to resolve ambiguity.
3. Once the technical design is agreed, Claude writes a test plan, usually almost entirely autonomously. The test plan is part of each design doc and is updated as the design evolves.
3a. (Optionally) another Claude instance reviews the design for soundness, completeness, consistency with itself and with the requirements. I review the findings and tell it what to fix and what to ignore.
4. Claude brings unit tests in line with what the test plan says, adding/updating/removing tests but not touching code under test.
4a. (Optionally) the tests are reviewed by another instance of Claude for bugs and inconsistencies with the test plan or the style guide.
5. Claude implements the feature.
5a. (Optionally) another instance reviews the implementation.
For complex changes, I'm quite disciplined to have each step carried out in a different session so that all communinications are done via checked-in artifacts and not through context. For simple changes, I often don't bother and/or skip the reviews.
From time to time, I run standalone garbage collection and consistency checks, where I get Claude to look for dead code, low-value tests, stale parts of the design, duplication, requirements-design-tests-code drift etc. I find it particularly valuable to look for opportunities to make things simpler or even just smaller (fewer tokens/less work to maintain).
Occasionally, I find that I need to instruct Claude to write a benchmark and use it with a profiler to opimise something. I check these in but generally don't bother documenting them. In my case they tend to be one-off things and not part of some regression test suite. Maybe I should just abandon them & re-create if they're ever needed again.
I also have a (very short) coding style guide. It only includes things that Claude consistently gets wrong or does in ways that are not to my liking.
Thanks for sharing. Would you mind expanding on a few points?
> 2. sell what makes customers feel good buying
What did you have in mind? What would make a purchase feel good or bad for a customer?
> 3. Never compete, focus on service with a novel niche product. Stupid people by their nature destroy everything around them regardless of long term benefit.
I'm not sure how the second sentence connects to the first - could you clarify what you mean there?
> 9. Stay quiet (especially online in a sea of cons), and only talk about the distant past when people try to goad you into telling them how you make revenue
You mean staying quiet about the specifics of your current products and strategy, as opposed to sharing general advice like here, right?
> Never let technical staff talk with the customers, or vendors.
Difficult to put a thesis on a road sign, but in general people make mistakes when building a business:
i. desperately grasping at low hanging fruit in a fragmented market. Where people burn enormous amounts of cash to bid down their own sectors perceived value.
ii. trying to innovate their way out of a bad business plan, instead of studying the market for what folks actually wanted.
iii. cognitive offloading, and premature labor cost-minimization using LLM isomorphic plagiarism to poison public discourse
I've left out "informally specified, bug-ridden" because I guess that's not the case for Coalton, but kept "slow" for when Coalton is used on a slower CL implementation.
reply