I speak English, I don't even know how to create one on my keyboard - is it a mac thing? I literally never saw one until chatgpt started to generate them
Not sure if it was Mac or phone, and I'm not sure if it was strictly emdash or one of the other seemingingly hundreds of different length dashes, but there was a time at least that -- would be rewritten to it. Also macs have this really really annoying habit of changing the dash when copying and pasting (but not always) so the nunver of times copying a bash command errors because it wasn't a dash, or I've copied a command to WhatsApp and the recipient got an error is enough to make me hate these clever dashes forever
I disagree with the naysayers. The README was scannable and sectioned so I could read what I wanted. But some things I wish were clearer, and I’m not sure they would be if you wrote it by hand.
Don’t waste your time rewriting it by hand just because keyboard warriors are up in arms on HN.
The material feedback here reflects the questions who might be from someone who’s been running local LLMs, so ask the LLM to update it with that in mind.
Another poster pointed out it’s not clear what the quantization is. There’s that one paragraph but it’s confusing. What I want to know right away is: are you running the unquantized model or is it quantized? If so, how much? Use terms like Q3 or Q4 or 4-bit or 8-bit. Explain why it’s not practical to quantize less. How much precision loss do you think there is at the quantization selected? What if I had 128GB RAM and wanted to have better precision and not higher token speed—would it be a good idea to choose 4-bit instead of 3-bit for some of these layers?
If you’re using the pi.dev harness, I found this tool to be quite good as a compaction alternative: https://pi.dev/packages/pi-blackhole — it keeps a memory so every prior conversation piece is recallable, not lost.
Try running your rule files through an LLM for optimization. 60k-80k tokens is massive.
Funnily enough, most anti-slop skills I found are both way too verbose and miss some common slop constructs.
I also reduced many rules from “When doing X, don’t do Y, but do Z.” Instead, the rule is “When doing X, do Z.” Fewer tokens and often works better.
I had one critical rule I was maintaining about searching the codebase using a structural index/graph and not grep. Every time the agent missed it, I asked it how to improve the rules. Eventually, I asked the AI to review that rule file and it rewrote it to be 30% smaller, but, crucially, structured to be more understandable by the LLM.
Another helpful thing was to ask AI to review my rules for things it can load on-demand when it works in that area.
AI cannot tell you why it did something. If you ask it why it didn't do X even though your prompt said so, it can come up with some plausible sounding explanation, which might even be correct, but there's a fundamental impedance mismatch between giving you the most plausible sounding answer and actually grounding that in knowledge of how it generated that answer.
TBF having a 60k personal style guide is also a bad idea, people get borderline AI-psychosed about how their special prompts are really steering the AI when in reality there is no way to evaluate this stuff. You invariably end up trying to define your style in terms of what it is and it isn't, it's like trying to define "red". "follow the style of my 5 most recent PRs" works pretty well.
Fascinating! I am glad you’re getting good results with that. Maintaining abstractions is critical and it’s very frustrating when the LLM ignores them.
I think that the gallup poll is flawed because it does not explain what daylight saving versus standard time is. I just spoke to an educated grad student, who thought that we were in standard time right now. Because the sun is out later during daylight saving time, the name is somewhat counter-intuitive. Also, because it’s on for most of the year, DST feels “standard.”
I've definitely talked to people that though daylight savings time is the time used in the winter, since that's when there are the fewest daylight hours and you need to "save" them or something.
Given how many times in my life I've internally groaned at yet another corporate email or website that references "EST" during the summer, I'm convinced no one is paying attention.
And that, if we do actually implement year-round daylight saving time, everyone will still call it EST.
I've heard both the "saving" has something to do with farming in the summer and candles in the winter, so either one could be daylight savings time. So I haven't been able to keep them straight and use "summer time" and "winter time" instead.
It’s rational to feel much safer in the Java packages ecosystem, where pinned versions are the default and the norm, and packages cannot run any install-time scripts.
And that’s exactly why semantic versioning provides only an illusion of stability. This is also why ecosystems that don’t pin their versions such as floating versions that are the default in JavaScript ecosystems are so much more vulnerable from a security and a regression standpoint.
Delaying non-security updates has the benefit of not wasting a team’s time when something regresses and is fixed in a quick follow up patch. Having to report issues upstream is not free.
Don't store any secrets in your repo. Don't store them in env vars.
Strong long passphrase on your SSH keys, stop using unencrypted SSH keys. Everything in a keychain.
The practice of storing secrets in a .gitignore'd .env.local.json or whatever is a really bad idea and I can't believe that it has become a normalized, acceptable practice in the industry.
Also it looks like English might not be the author’s first language—might not lead to the best training corpus.
reply