As a programmer I'd be happy with an API, so I can keep working in the environment I'm accustomed to. Programmers can get very picky when it comes to their ergonomics, so it would be wise to let them handle this part.
This, however, would be a significant obstacle to non-programmers. You might consider offering an in-game editor similar to Scratch or BYOB for people who want to dip into programming. It'd be a fun way for them to learn
> Adding to this: it's not just that the apprenticeship ladder is gone—it's that nobody wants to deal with juniors who spit out AI code they don't really understand.
I keep hearing this and find it utterly perplexing.
As a junior, desperate to prove that I could hang in this world, I'd comb over my PRs obsessively. I viewed each one as a showcase of my abilities. If a senior had ever pointed at a line of code and asked "what does this do?" If I'd ever answered "I don't know," I would've been mortified.
I don't want to shake my fist at a cloud, but I have to ask genuinely (not rhetorically): do these kids not have any shame at all? Are they not the slightest bit embarrassed to check in a pile of slop? I just want to understand.
> If I'd ever answered "I don't know," I would've been mortified.
I'm approaching 30 years of professional work and still feel this way. I've found some people are like this, and others aren't. Those who aren't tend to not progress as far.
It seems so obvious now, but it does make me thankful that my training drilled into my head to constantly ask "what is the problem I am trying to solve?". Communication in a team on what's going on (both in your head and the overall problem space) is just as important as the mechanical process of coding it.
I feel that's the bare minimum a junior should be asking. the "this is useful" or "this is slop" will come with experience, but you need to at least be able to explain what's going on.
the transition to mid and senior goes when you can start to quantify other aspects of the code. Like performance, how widespread a change affects the codebase at large, the input/outputs expected, and the overall correctness based on the language. Balancing those parameters and using it to accurately estimate a project scope is when you're really thinking like a senior.
I do think that there's a meaningful difference between writing code that was bad (which I definitely did and do) and writing code where I didn't know what each line did.
early on when I was doing iOS development I learned that "m34" was the magic trick to make flipping a view around have a nice perspective effect, and I didn't know what "m34" actually meant but I definitely knew what the effect of the line of code that mutated it was...
Googling on it now seems like a common experience for early iOS developers :)
Senior level. Still can't sometimes. Just the other day I looked over some code I wrote and realized what a pile of slop it was. I kept wondering "What was I thinking when I wrote this? And why couldn't I see how bad it is till now?" My impostor syndrome is triggered hard now.
I've done this too. The nice side-benefit of this approach is that it also serves as good documentation for other humans (including your future self) when trying to wrap their heads around what was done and why. In general I find it helpful to write docs that help both humans and agents to understand the structure and purpose of my codebase.
I guess we're in a minority but I'm in full agreement. Color passthrough really felt like a game-changer, and I've long wished for a more open, non-Meta alternative. Guess we'll be waiting a bit longer
> 2. Their subtitles are just the subbed version's subtitles which are drastically different from what the dubbed VAs are actually saying.
I get that you might not like it, but it sure beats the option you didn't list:
4. Has auto-generated subtitles for the dub that fail in dramatic and distracting ways, especially for proper nouns or any kind of show-specific invented terminology
Yeah I don't know if this is a skill issue on my part, the nature of my projects, the limits of Sonnet vs. Opus, or a combination of all of the above, but my experiences track with all of yours.
From the article:
> The default mode requires you to pay constant attention to it, tracking everything it does and actively approving changes and actions every few steps.
I've never seen a YOLO run that doesn't require me to pay constant attention to it. Within a few minutes, Claude will have written bizarre abstractions, dangerous delegations of responsibility, and overall the smelliest code you'll see outside of a coding bootcamp. And god help you if you have both client and server code within the same repo. In general Claude seems to think that it's fine to wreak havoc in existing code, for the purpose of solving whatever problem is immediately at hand.
Claude has been very helpful to me, but only with constant guidance. Believe me, I would very much like to YOLO my problems away without any form of supervision. But so far, the only useful info I've received is to 1) only use it for side projects/one-off tools, and 2) make sure to run it in a sandbox. It would be far more useful to get an explanation for how to craft a CLAUDE.md (or, more generally, get the right prompt) that results in successful YOLO runs.
When I first got started with CC, and hadn't given context management too much consideration, I also encountered problems with non-compliance of CLAUDE.md. If you wipe context, CLAUDE.md seems to get very high priority in the next response. All of this is to say that, in addition to the content of CLAUDE.md, context seems to play a role.
> If you use projects, Claude creates a separate memory for each project. This ensures that your product launch planning stays separate from client work, and confidential discussions remain separate from general operations.
If for some reason you want Claude's help making bath bombs, you can make a separate project in which memory is containerized. Alternatively, the bath bomb and bedsheet questions seem like good candidates for the Incognito Chat feature that the post also describes.
> All these LLM manufacturers lack ways to edit these memories either.
I'm not sure if you read through the linked post or not, but also there:
> Memory is fully optional, with granular user controls that help you manage what Claude remembers. (...) Claude uses a memory summary to capture all its memories in one place for you to view and edit. In your settings, you can see exactly what Claude remembers from your conversations, and update the summary at any time by chatting with Claude. Based on what you tell Claude to focus on or to ignore, Claude will adjust the memories it references.
So there you have it, I guess. You have a way to edit memories. Personally, I don't see myself bothering, since it's pretty easy and straightforward to switch to a different LLM service (use ChatGPT for creative stuff, Gemini for general information queries, Claude for programming etc.) but I could see use cases in certain professional contexts.
If you're getting into OpenSCAD I'd highly recommend getting Belfry ASAP.
https://github.com/BelfrySCAD/BOSL2/wiki
I wouldn't really consider using OpenSCAD without it
reply