Fine-tuning an LLM to create long-form podcast timestamps. Apparently even the best LLMs with long context are incredibly bad with this so I'm curating data and creating a service out of it.
Great write up and clarification of some of the errors the authors made. The only thing I'm missing is the evaluation of structured generation on longer, complex JSON. In my experience this does tend to fall off depending on the model and the strictness of the imposed JSON structure.
Wow, I did not expect to see such negativity in this thread. Most of them read to me like the "Dropbox is just an FTP"-narrative. Yes, you and your pride can do most of these things in 0.3ms and better, but so will 1 million more people now.
You can do most of the things the author showed with your craftfully set-up IDE and magic tricks, but that's not the point. I don't want to spend a lifetime setting up these things only to break when moving to another language.
Also, where the tab-completion shines for me in Cursor is exactly the edge case where it knows when _not_ to change things. In the camel casing example, if one of them were already camel cased, it would know not to touch it.
For the chat and editing, I've gotten a pretty good sense as to when I can expect the model to give me a correct completion (all required info in context or something relatively generic). For everything else I will just sit down and do it myself, because I can always _choose_ to do so. Just use it for when it suits you and don't for when it doesn't. That's it.
There's just so many cases where Cursor has been an incredible help and productivity boost. I suspect that the complainers either haven't used it at all or dismissed it too quickly.
> You can do most of the things the author showed with your craftfully set-up IDE and magic tricks, but that's not the point.
Wrong you can do most of the things the author showed with a fresh install of vim/emacs or by logging in to a fresh install of vscode/intellij - In other words no lifetime was spent on this, I like having as bare an experience as possible so I can use the same setup on any computer.
> I don't want to spend a lifetime setting up these things only to break when moving to another language.
Editor configs don't break across languages?
> For the chat and editing, I've gotten a pretty good sense as to when I can expect the model to give me a correct completion (all required info in context or something relatively generic). For everything else I will just sit down and do it myself, because I can always _choose_ to do so. Just use it for when it suits you and don't for when it doesn't. That's it.
A lot of people don't have this level of wisdom or the skills to pick and continue without AI. Would I be wrong for assuming you've been programming for at least 10 years? I don't think AI is bad for a senior who has already earned their scars, but for a junior/no skill developer it stunts their growth simply because the do expect the model to give them a correct completion, and the thought/action of doing it without an AI is painful (because they lack the requisite skills) so they avoid it.
> Wrong you can do most of the things the author showed with a fresh install of vim/emacs or by logging in to a fresh install of vscode/intellij - In other words no lifetime was spent on this, I like having as bare an experience as possible so I can use the same setup on any computer.
Sure, though, for example, I haven't a clue for the shortcut for wrapping an expression in a try/catch block. With Cursor I just press tab and it often also adds a useful print or other useful expression inside the catch block. It comes down to requiring less discoverability.
> A lot of people don't have this level of wisdom or the skills to pick and continue without AI.
I have been coding for some time, but I think you underestimate people's BS detector. People are well aware that language models hallucinate. Most of the time you'll figure it out soon enough (compiler/run time) and adapt accordingly. I have learned much of my coding through reading public repositories/code which were also not always up to standards. You figure this out by banging your head once or twice.
It's pretty clear that the utility of tools like Cursor depends on a lot of variables such as:
- the type of project you are working on (what are you writing)
- who are you writing for: is this meant to be bulletproof corporate code, a personal project, a throwaway prototype, etc
- the experience level of the developer
If your use case plays to the strength of the tool/technology, then obviously you will have a better experience than others trying to see if it can do things that it is not really capable of.
A17 Pro huh, that's a first for putting a pro chip in a non pro iPad, isn't it? I guess it's, as they advertise, to handle Apple Intelligence although I don't understand why they are doubling down on this _now_ while nothing from the newly announced AI stuff is available as of today...
The A17 Pro (originally in the iPhone 15 Pro; now also in the iPad Mini) and A18 Pro (currently only in the iPhone 16 Pro) are the only chips Apple has produced with a "Pro" suffix.
Apple used to use the X suffix for bigger versions of their phone processors that went into iPads (starting with the A5X); that went away when the M-series was introduced.
And the "Pro" suffix itself doesn't seem to denote anything in particular-- there was never a non-Pro A17, and the "A17 Pro" going into the iPad Mini is itself a cut-down version of the chip that went into the iPhone 15 Pro (it has one GPU core disabled).
I'm guessing the delays to Apple Intelligence came late in the process and it was supposed to release with the new iPhones? And then they just left hardware plans as-is when the software got delayed.
