I personally find it slower to read text without capitalization. It helps me visually chunk information from different sentences, in the same way that line breaks separate ideas into different paragraphs. Without it, it’s sort of like a wall of text that I have to read more carefully to parse (although a closer reading perhaps isn’t bad).
I agree, for at least some listed, though many people blow past the amount of money actually needed. Money starts as a proxy measure for attaining these things, but it eventually replaces them as the goal, per Goodhart's law.
For sure, I find many of the LLM-isms to be useful writing techniques and terms (although there's something uncanny-valley about the repetition and density of them).
But what I was more thinking about are truly unique jargon terms / phrases that get generated when deep in a problem. As an example of both of such a term and the phenomenon itself, Claude calls this "fluent compound coinage." They usually make sense in the original context, but get confusing when thrown around otherwise.
One danger in acclimating to this style of communication style is that we may accidentally use it in your own communication with other people. If the other person hasn't grokked the dialect, it can make things quite confusing (to say the least). For example, there is common jargon used by people and there is chat-session-specific jargon created by LLM agents, and I've seen the latter popping up in various meetings, unbeknownst to the speaker. Some people call it out, but others may simply disconnect from the discussion.
Yes, agreed. Beautiful keyboard, but when I heard "magic" I hoped to find a touch ID. That sensor so useful that even though I use a mechanical keyboard, I keep an apple magic keyboard off to the side of my desk just for the touch ID sensor.
What I'd love to have is a standalone touch ID sensor that I could attach anywhere -- mechanical keyboard, side of the monitor, under my desk, etc. I guess this is bottlenecked by Apple's IP on the device, so I've considered just hacking one together by deconstructing and extracting an Apple keyboard...
Yes, I had a related experience of reading a book and observing what I thought were claude-isms, only to realize it was written in 2019. Some of the common tells are actually good writing practices, but I guess they are best in smaller doses.
I agree this should be built-in. Many apps have their own "focus mode", but I wanted something that works uniformly across all apps. There is a full-screen mode in macOS, but it stretches the widow and context to full width, which doesn't pan out too well in some apps (lots of empty space or lines that are too long to read comfortably). So this preserves the window width but extends the height when focused, which works well for my daily drivers. The "fade" is somewhat unusual too, which means everything else is darkened close to black, which I find visually suppressing things and reduces distraction.
By the way, repo has an animated demo in case you want to see how it works.
Would be great, and it's technically possible to spotlight multiple windows in this setup. But I wonder about the mechanics of picking the right apps. One way is to use named sets, e.g. dev=(iTerm2, Safari), each with their own shortcut. Another is to to focus one window and then use Cmd+Tab as an picker to choose which app to add next. I guess it depends on whether the arrangement is changing or relatively stable.
Author here, I made this macOS tool "Zen Mode" to provide a global focus mode that works across apps. There are plenty of things approaching this (HazeOver, Stage Manager, built-in full-screen mode, etc.) but nothing quite like I imagined. The basic idea is to have a shortcut to bring the current window front and center and fade everything else to black like a spotlight, and when you're done, the window returns home, and the lights come back up. A simple solution with about 250 lines of Hammerspoon Lua, built with Fable, though with many iterations to get the UX right. Happy to answer any questions or hear any feedback.
Yes, and one of my favorite anecdotes like this: at one of the greatest jazz concert ever recorded, Charlie Parker played a cheap plastic saxophone because he hadn't brought his own.
This is great and echoes my experience. Although I would add a caveat that this mostly applies to solo work. Once you need to collaborate or operate on a team, many of limits of self-hosting return.
I believe slash commands are all loaded into the initial context and executed when invoked by the user. Skills on the other hand only load the name and description into initial context, and the agent (not user) determines when to invoke them, and only then is the whole skill loaded into context. So skills shift decision making to the agent and use progressive disclosure for context efficiency.
Thank you for publishing that paper, which I think greatly helped address this problem at the time, which you accurately describe. I guess things have to be taken in their historical context, and science is a community project which may not uniformly follow best practices, but work like this can help get everyone in line! It's unfortunate, and no fault of the authors, that the general public has run wild with referencing this work to reject fMRI as a experimental technique. There's plenty of different ways to criticize it today, for sure.
This study was really highlighting a statistical issue which would occur with any imaging technique with noise (which is unavoidable). If you measure enough things, you'll inevitably find some false positives. The solution is to use procedures such as Bonferroni and FDR to correct for the multiple tests, now a standard part of such imaging experiments. It's a valid critique, but it's worth highlighting that it's not specific to fMRI or evidence of shaky science unless you skip those steps (other separate factors may indicate shakiness though).
To a large extent, I think this could be solved by labs having more long-term permanent research staff (technicians, data analysts, scientists) and reducing the number of PhD students. Many students would gladly stay on in that position instead of leaving, so it increases job opportunities. It would also improve the quality of the science because the permanent staff would have more historical knowledge, in contrast to the current situation where students constantly rotate in and out with somewhat messy hand-offs. The students could also then focus more on scholarly work, planning and overseeing research execution with the team. The problem is that the incentives are aligned to allocate students to doing all lab tasks, not long term staff. I think we could change this through changes to the requirements and structure of science funding mechanisms however, since ultimately that's the source of the incentives.
One other feature with CLAUDE.md I’ve found useful is imports: prepending @ to a file name will force it to be imported into context. Otherwise, whether a file is read and loaded to context is dependent on tool use and planning by the agent (even with explicit instructions like “read file.txt”). Of course this means you have to be judicial with imports.
When asking customers how well they were helped by the customer support system (via CSAT score), I've found industry-standard AI support agents will generally perform worse than a well-trained human support team. AI agents are fine at handling some simple queries, e.g. basic product and order informatino, but support issues are often biased towards high complexity, because otherwise they could solve it in a more automated. I'm sure it depends on the industry, and whether the customer's issue is truly novel.
Taking a shot at this, one concrete definition might be that the business model is essentially white labeling, that is, the base LLM is rebranded, but task performance in the problem domain is not functionally improved in some measurable way. As a corollary, it means the user could receive the same value if they had gone straight to the base LLM provider.
I think this might be more narrow than most uses of the term “wrapper” though.
Yes, this feature might be a prime driver of user engagement and retention, and it could even emerge "naturally" if those criteria are included for optimization in RLHF. In the same way that the infinite scrolling feed works in social media, the deranged sycophant might be the addictive hook for chatbots.
I think you're both right, but you might be thinking of different tasks and libraries. If we're talking about solving a specific type of PDE, then in that scenario he's probably right that MATLAB will work better out of the box, but if we're talking about logistic regression on data from a messy CSV table, then python will work great and have better usability than MATLAB (IMO). He might also be thinking of versioning and packaging headaches in python, which are quite a pain the first time exposed to them coming from a walled garden environment.