Only if you think opening Cursor.app counts as “using an AI tool”. Most reasonable people wouldn’t expect an AI-enabled text editor to hack their machine right away -- it should have the common decency to wait until you type something into the AI agent panel, then hack you!
Ideally, they’ll be able to look back through the logs and find the original analysis from when the bug was submitted, figure out why it was incorrectly filtered, and use that to improve their automation.
The general idea of a few layers of automated triage by increasingly powerful LLMs, before finally escalating to a human engineer, seems like a reasonable way to handle a deluge of submissions. It just has to be implemented well and continuously calibrated.
It's really ridiculous how little discussion there was about places like Gibraltar and Northern Ireland before the Brexit vote.
Looks like NI voted ~55% remain and Gibraltar ~95% remain, but too bad, England voted ~53% leave, so screw all you little overseas territories with actual land borders who are most directly impacted.
Honestly? I don't really mind, and I even quite like it!
The thing is, "load-bearing" is a useful phrase when discussing architecture. What would you rather have it say, that has all the same nuances in as few words?
It's kind of like those sports metaphors that often get used in management-speak, like sending some important email "at close of play". Sure, they can sound a bit weird, but they're often useful -- they capture common concepts in a clear and pithy way.
Jargon isn't always just for obfuscation, good jargon exists because we needed a short word for the complicated thing that frequently comes up.
Usefulness aside, I quite like that Claude Code and other LLMs have their own weird way of speaking. Back in the day we always imagined robots and computers would talk like HAL or Spock; turns out that they talk more like Troi instead. Is that so bad? It reminds you that you're talking to an LLM, and as long as you're not lazy, it spurs you to rephrase things in your own words.
Your reconstruction is so close, I'm a little surprised you didn't stick with the original controls! Even though the BBC had a rather weird layout for all the non-alphanumeric keys.
It's been a very long time since I played Thrust, and I've played plenty of WASD games in the meantime, but it still felt really strange to control it that way rather than the classic BBC Z/X/*/? for left/right/up/down.
Pretty sure it was return to fire, space for shield/tractor; and maybe * for thrust? Edit to add: ah, no, shift to thrust. Works very well on modern keyboards too.
"Compiling" is vague here; for TS I think you need to distinguish bundling from type-checking.
If you're talking about bundling the entire app, 120 seconds down to 10 seconds is a great saving, but other bundlers can do it much faster already. Most people don't bother using TSC to bundle their code. I can understand why Microsoft might insist on using it, but it's not typical.
For type-checking the entire app, I would see that as akin to running all the unit tests. 120 -> 10 seconds is excellent, but not something that should be a constant bottleneck in your development workflow.
I can definitely see that 10x improvement being crucial on large teams (and/or LLM swarms) where the speed of the CI queue becomes a bottleneck.
Typescript's compiler is much slower than Rust's, but it's plenty fast enough for most people and you almost never see complains about it because it mostly doesn't matter
But you have to compile Rust code to run it. You can run TypeScript code without type-checking it. That’s a massive difference in the development workflow.
The new TSC, supposedly 10x faster, will be very pleasant to have but not as much of a game-changer as you might expect. A 10x faster Rust compiler would be incredible.
Even if you could understand human cognition to the level required to say, confidently, that it’s done one word at a time, it’s likely not!
I think they’re not talking about cognition, but about output: regardless of what may be happening inside your brain, ultimately one word at a time comes out of your mouth, right? And you can’t then unsay it.
When you put it in those terms, LLMs are in exactly the same boat.
Yep, this is my experience too. I think of it more as a very, very smart and fast intern -- you can tell it’s going places, and in many ways is already way better than you, but it still needs an experienced hand to steer it.
My rule of thumb is, any special processes you put in place for AIs are either sensible for humans as well, or they’re not worthwhile. Good CLIs, auto-summarization of long command outputs, Markdown docs and workflows -- those are all useful for people too!
To guard against mistakes and abuse, you use sandboxing and scoped permissions, not micromanagement.
One thing I’d like to figure out is a good pair-programming workflow for AI agents. You can tell a high-level model to go and do something, and that works; you can use a low-level model as an IDE assistant, and that works; but they’re separate workflows. What would be really useful is a way to kind of hand the keyboard back and forth with the high-end model and build something together. But safely, not in full-on YOLO mode on my own machine. This is one specific area where humans and LLMs differ -- it’s so much faster than me that I can’t just grab the keyboard back from it if it goes off the rails.
You can use it if you want, but the browser doesn’t help you at all. It can’t automatically turn a form into a matrix URI, and it can’t do anything useful with relative matrix URIs.
The main advantage of branding is that it’s a zero-cost abstraction -- the boilerplate vanishes at runtime. Just using a string instead of a containing object can give you a lighter-weight runtime.
Sounds like this is a golden oldie bug on Windows/DOS, which I assume is now patched by default. If so it’s Cursor’s problem.