Earlier quoted context omitted.
4. Hallucinate the satisfied customer.
5. Hallucinate receiving money from hallucinated customers
The money in AI generally comes from hallucinating VCs, not customers.
Copilot for Docs
41–50 of 56 posts
Re: Copilot for Docs
#42I switched to Cursor (VSCode fork) a couple of months ago. It does this already and I haven’t looked back since. Especially as the copilot extension (along with all my others) work out of the box. It has full knowledge of your entire codebase rather than being limited to currently open files (I assume embeddings with RAG) and will index documentation (or any other URL). I find it especially useful for things like Swi…
copilot recently added feature to "ask your codebase"
Re: Copilot for Docs
#43Ok, so why do we need stackoverflow anymore?
If you're only using stackoverflow to have someone read the docs to you, then I feel you're missing the point. There is so much between the lines, and the LLM isn't 100% there yet.
Re: Copilot for Docs
#44Hate how they announce this product by shitting on the hard work of docs teams.
I get that docs are uneven in quality but there’s also been what I think is a renewed focus on quality & interactive examples. There’s some truly fantastic OSS documentation out there.
The tone of this just didn’t sit right with me.
Re: Copilot for Docs
#45Love how the AI hype went from "it's going to write code for you!" to "oh okay, maybe just boring boilerplate" to "it's basically a glorified search" (and it probably won't be great at that, either).
Re: Copilot for Docs
#46Love how the AI hype went from "it's going to write code for you!" to "oh okay, maybe just boring boilerplate" to "it's basically a glorified search" (and it probably won't be great at that, either).
Lot's of people (including me) use co-pilot and chat gpt to save several hours a week, likely > 1 hour a day. It's under hyped.
Re: Copilot for Docs
#47Love how 3/4 reactions are engineers from GitHub rather than customers.
They are engineering tools... if your internal engineers are loving your engineering tools, you are onto something.
Re: Copilot for Docs
#48Love how the AI hype went from "it's going to write code for you!" to "oh okay, maybe just boring boilerplate" to "it's basically a glorified search" (and it probably won't be great at that, either).
[deleted]
Re: Copilot for Docs
#49This is a great use of AI
Re: Copilot for Docs
#50Earlier quoted context omitted.
> I'm so used to links not being underlined Here’s a user stylesheet I’ve been using for 2½ years (when color-mix() landed behind a pref in Firefox Nightly!): :any-link { text-decoration: underline color-mix(in srgb, currentcolor 30%, transparent) !important; } :any-link:is(:hover, :active, :focus) { text-decoration: underline !important; } This means links get a semitransparent underline normally, and full-opacity o…
This is a really nice technique, thanks for sharing. Question: why would you prefer the latter technique on public sites, vs what's in your user stylesheet?
The user stylesheet version is deliberately blunt, done in two rules to forcibly override whatever the author may have done, to both the normal and the interacting experience.
If you control the site’s styles, it’s better to keep specificity as low as reasonable (which I decided meant one pseudoclass—you could reduce it to zero by shifting the `:where(` to the start, but I decided not to for some reason), and only change what you need to change (which is the text-decoration-color—notably, not the entire text-decoration—on links that aren’t being interacted with.
Why? Because as well as being shorter and more conceptually elegant (and frankly, I place likely-disproportionate value on it being just one declaration, pride probably factoring in), it makes it easier to override when you want to. Suppose, for example, you want to not get underlines because you’re making it look like a button (for better or for worse): you can write `.button { text-decoration: none; }`, just like you would have done previously, and it’ll work fine. Against the user stylesheet approach, even stripped of its !importants, you’d still get an underline on hover until you increased specificity (e.g. `.button.button`, and I’m assuming this is coming after the :any-link:is(…) rule, or else you’ll want `.button.button.button`) or reduced its specificity (which I grant :is → :where can do).