386 karma · joined December 11, 2020
When computing was niche, you really only got into if you had a real interest in it (I assume - I wasn't around back then). That's changed, but it doesn't mean that that category doesn't exist anymore. If anything, it's probably way larger in absolute terms, if a smaller proportion of people who work on software in general.
You can learn how to use it, or you can put it down if you think it doesn't bring you any benefit.
Note: I, myself, am guilty of forking projects, adding some simple feature I need with an LLM quickly because I don’t want to take the time to understand the codebase, and using it personally. I don’t attempt to upstream changes like this and waste maintainers’ time until I actually take the time myself to understand the project, the issue, and the solution.
Yeah, it turned out that almost all mainstream tracks nowadays have post-processing on vocals (the extent varying between genres and styles).
I say this as someone who would definitely be far less productive without Google, LSP, or Claude Code.
Microsoft is very far from being at risk of failing, but if it did happen, I think it's very likely that the government keeps it alive. How much of a national security risk is it if every Windows (including Windows Server) system stopped getting patches?
Now, once you have that, to actually make edits, you have to record a macro to apply at each point or just manually do the edit yourself, no? I don't pretend LLMs are perfect, but I certainly think using one is a much better experience for this kind of refactoring than those two options.
In my rules I tell it that try catches are completely banned unless I explicitly ask for one (an okay tradeoff, since usually my error boundaries are pretty wide and I know where I want them). I know the context length is getting too long when it starts ignore that.
If Texas wants to block content from entities that have nothing to do with Texas, they can build their own great firewall.
I agree that for most tasks a pre-defined workflow with task specific LLM calls sprinkled in is a much better fit.
However, I really like agents with tool use for personal use (both programming and otherwise). In that case, the agent is either sandboxed or I approve any tools with the potential to do damage.
For the example of the Supabase MCP, it still seems pretty useful when limited to a test environment or read-only access to prod - it's a dev tool. Since it's a dev tool, the user needs to actually know what its doing. If they have no clue but are still running it on prod data, they have no business touching it or frankly any other dev tool. I class this as the same ignorance that leads people to storing passwords in plaintext.
So, I blame the developer for trying to use an MCP server 1) when they have no idea wtf it does and 2) in an environment that can affect real users who aren't aware of the incompetence of the dev whose service they're using. Likewise, in TFA, I blame the dev, not the tool. Unfortunately, no matter how you do it, lowering the barrier of entry for development while still providing access to ample footguns will always result in cases like this.
I can't think of how a private, but still public-access, park survives without a rich benefactor eating the losses, even today.
There are plenty of ways to sandbox things for a particular use case.
LLMs are still incredibly useful under these constraints.