It constantly takes whatever is currently visible in your editor to feed its context. If you get a nonsense/hallucinated suggestion, you can accept it, get it to read the error message from LSP diagnostics, undo, and then it'll correct itself next time. Or if you need to make changes in 5 places, and the next 4 changes are easy to guess after seeing the first one, it'll guess the next 4 for you.

I still use standard IDE features extensively. The intelligent autocomplete is just another tool to reduce typing when the next change is easy to guess.

Oh, and I turn it off when I'm writing prose or need to actually think deeply. Then it really does hurt more then help.

(Worth noting: I currently work primarily in Go, which is a language that's ridiculously verbose and has lots of repetitive patterns. YMMV for more expressive languages.)

> To avoid this, you will probably need to intentionally write in a very different style than you usually do (or to have AIs rewrite all your prose for you, but, ugh, that’s not a world I look forward to living in).

I agree. The amount of vague and cliche'd AI writing I read on the daily is already exhausting enough.

It would be interesting if you could train a model to sprinkle random red herrings throughout your text in a minimally disruptive way. But I fear you might have to stretch the definition of "minimally disruptive" to make it robust against detection.

Comments URL: https://news.ycombinator.com/item?id=47929361

Points: 3

# Comments: 1

I've developed an intuitive understanding of this, but I had to experiment just now to describe the behavior precisely. And my intuition is still wrong sometimes (like if the app has windows on multiple monitors, it's hard to predict the z-order).

> if I Slack open in Firefox in workspace 1 and Outlook open in Firefox in workspace 2, there is no way to switch between Slack and Outlook

My local maximum is to never use workspaces – just cmd+tab, cmd+`, and sometimes cmd+h to reduce screen clutter.

Yes, banks should (and sometimes do) double- and triple-check with you before allowing large transfers/withdrawals, but scammers know how to coach their victims past this. Speaking from experience.

(I also don't fully agree this is Google's responsibility, and I am not happy about this development. But there are legitimate points in favor of outsourcing the question of "will this software do nefarious things" to some kind of trusted signing authority.)

Laws are interpreted by people trained to fill in the blanks[1] with a best guess of the legislative body's intent. And the intent here seems pretty clear: to regulate computing devices that let end users easily install software from a centralized catalog.

[1] which we all do subconsciously in day-to-day speech, because all language is ultimately subjective

Some designers say that refresh buttons shouldn't exist because the interface should always reflect the current state of reality. They're right, but until the day we get 100% bug-free bidirectional sync with perfect conflict resolution that instantly polls the network whenever it reconnects, refresh buttons are a necessary evil.

Type-safe Rust code is free from certain classes of errors. But that goes out the window the moment you parse input from the outside, because Rust types can enforce invariants (i.e. internal consistency), but input has no invariants. Rust doesn't ban you from crashing the program if you see input that violates an invariant. I don't know of any mainstream language that forbids crashing the program. (Maybe something like Ada? Not sure.)

I don't understand why you bemoan that Rust hasn't solved this problem, because it seems nigh unsolvable.

If chalk emits sequences that aren't supported by your terminal, then that's a deficiency in chalk, not the programs that wanted to produce colored output. It's easier to fix chalk than to fix 50,000 separate would-be dependents of chalk.

Of course, small libraries get a bad rap because they're often maintained by tons of different people, especially in less centralized ecosystems like npm. That's usually a fair assessment. But a single author will sometimes maintain 5, 10, or 20 different popular libraries, and adding another library of theirs won't really increase your social attack surface.

So you're right about "pull[ing] in universes [of package maintainers]". I just don't think complexity or number of packages are the metrics we should be optimizing. They are correlates, though.

(And more complex code can certainly contain more vulnerabilities, but that can be dealt with in the traditional ways. Complexity begets simplicity, yadda yadda; complexity that only begets complexity should obviously be eliminated)

(or: just solicit feedback in a space frequented by designers, and harness the power of being wrong on the internet ;)