So the issue really isn't "social media", it's the blackbox personalized algorithmic feed.
So that is what we should be addressing.
Things like -> no personalized algorithmic feed for minors. The ability to disable algorithmic feed and revert to historical feed from contacts. Giving the user control over suggestions and feed via the requirement that it should be possible to switch to a "third party algorithm provider" or self-host, while still being able to have full access to the contents and social features of the platform.
> So the issue really isn't "social media", it's the blackbox personalized algorithmic feed.
> So that is what we should be addressing.
That is what the bill addresses. It bans providing an "addictive feature" to users under 16. It says it does not prohibit letting under 16 users use the service as long as it does not provide addictive features on those accounts.
It says addictive features are autoplay and addictive feeds.
Most of the bill is then defining what those mean. There's plenty to argue over in that, but the core is just what you've said is what we should do.
I use Claude Code, primarily writing web applications and JavaScript. I'll have it use various frameworks. It's built apps for me using React, Ember, Astro, etc. I don't restrict myself to frameworks I'm particularly familiar with, since it's easy for the AI to teach me the basics whenever I would like to dig in.
As for specific practices, these are my main ones:
- I have a gotchas-log.md file that acts as a log of gotchas likely to trip up future runs. I have the AI write to this occasionally when things go haywire in the same way multiple times. And I have it read it as part of its iterative reviews, described below.
- I have a good-code-guidelines.md file where I write my preferences for code. I have the AI read this as part of iterative reviews, described below.
- I have a plan-and-execute.md file that prompts the LLM to make a plan, and then to review and iterate on that plan repeatedly (while reading gotchas-log.md and
good-code-guidelines.md) until its reviews stop finding issues. I tag this file to implement almost every non-trivial change.
- I have other various helper prompts. For example, I can simply tag @make-a-git-commit.md and it tells the LLM to make a commit and write the message the way I like it. I have @simplify.md, which I can tag to have the LLM explain whatever it just did to me using simple language that makes it easier for me to understand, and using concentric circles of explanation that go from broad to specific so I'll repeatedly encounter important topics; this makes it much more bearable for me to read its responses.
- Occasionally, whenever a particular system of my codebase starts to get hairy, I spawn a Claude Code session to read through and trace all the relevant code paths, then write a short guide to that system in a markdown file that lives in the codebase. IT's useful for me to read and also useful to tag for future prompts to get the LLM up to speed quickly. Only challenge here is that these guides go stale and require updating, so it's important to prompt the AI to write them at the appropriate level (not to specific) that prevents them from being overly brittle and getting out of date with every little change. They're mostly high-level guides.
I could imagine (in a commercial organization) a case for something like: "we're obviously going to be relying more and more on AI, so if bad code comes out of it, instead of just shaming the engineer, let's study together what happened -- what was the chat context, the model, the system prompt, etc... ? What seemed to cause the issue? What processes or systems could we put in place to improve it? Etc... -- and then use the learnings to improve AI use throughout the whole org."
Saying "the language of LLMs", while technically correct, is not exactly precise. It should really be the language of "AI agents", or "chatbots". OG LLMs would just mimic the style of its context based off of (pre)training from text on the Internet.
The kind of quirks you see came from crowd-sourced human-in-the-loop fine-tuning, with not very good work conditions or level of qualification (so resulting in "what non-writers thought good writing looked like", before people had developed the flair to detect these patterns) as well as feedback loops during agentic reinforcement learning and RLVR.
Claude is all we have at $work, if you don’t count MS Copilot (and you shouldn’t count MS Copilot).
Imagine being “incentivized” to aggressively use a tool for your job, and that tool produces thousands of lines of text in Olde English which you need. You’d be griping too, methinks.
I think you are referring to GitHub Copilot, which is fine (even though their context windows are artificially truncated and their dev tooling leaves a lot to be desired). I was making fun of the Copilot that’s shipped with MS stack. “Hey summarize my Teams meetings and try not to fuck that up too badly” - that one.
Anthropic has done their utmost to put Claude front and centre for professionals in multiple industries. This includes extremely tedious marketing campaigns. I'm sure they can handle a few negative comments from people they've snared, by hook or by crook.
That's why you first ask the LLM: "tell me how you would do this, and ask me any clarifications and questions you may have, and share any other thoughts you may have. Don't implement yet."
The LLM will look through the codebase, think, and tell you what it would do and if there's any design decisions you would have to make, as well as other things you probably need to be aware of. Then you go through the LLM's output and address all those decisions point by point, asking the LLM more questions if something isn't clear or requires more investigation or you're unsure what to do. And end with "address what I wrote, and share any other thoughts or questions or things to clarify you might still have, don't implement yet"
And you do this back and forth until all the design decisions have been addressed and you feel confident of what the code and architecture will look like, and only then say "ok, implement"
That way you get a lot of the benefits of writing it by hand (being forced to think through what the best design would be and how it would integrate with existing code, and increasing understanding of how existing code works) but it's still much faster. The tool I personally use is Cursor in auto mode.
P.S. actually before even that you first ask the LLM "what is the current state of X in the codebase" and then you ask follow-up questions until you have a good understanding of all the details that are relevant to you. And then you can start having the design/implementation conversation in the same chat context, since having the above information in context is useful.
P.P.S. and you can also ask a bridge question like "can XYZ be cleanly added with how things are currently structured?" or "what would it take to add XYZ to the project?"
Sure, but I'm only able to do that because I'm intimately aware of everything in the code base. The more I do this where the LLM ends up writing the code (even based on my decisions), the less good critique I'll be able to give in the future.
Is that the experience you had? What if you ask it questions about the codebase?
I find AI agents really great for codebase exploration and understanding how it works. In some ways even moreso than from manual implementation since it's easier to get a global picture.
You can also ask it questions like "are there recurring patterns of how X is done in the codebase?" to which it might answer sometime like "there are actually three competing patterns" and tell you what they are and the exact files, and then you can choose to refactor them if you want.
I do often use the /qa skill regardless though. I always hated QA because it was so monotonous and it required a level of organization and creativity i never had (i mean im the developer so if I thought of edge cases id have solved for them)
I like that /qa covers and documents every edge case that it tested and I can nudge it about other ones
I think the reason is that no one (who has the correct leverage / area of ownership / authority) cares.
Big companies have processes for deciding what gets done and which features are prioritized, and if the people in that loop aren't power users of those features, and they don't have the kind of metrics or analysis framework that would indicate that those features are important, they won't be prioritized.
I don't think there's some kind of conspiracy to make search worse... I think it's just that nobody cares enough, and with time the features break as everything else around them is changed
So that is what we should be addressing.
Things like -> no personalized algorithmic feed for minors. The ability to disable algorithmic feed and revert to historical feed from contacts. Giving the user control over suggestions and feed via the requirement that it should be possible to switch to a "third party algorithm provider" or self-host, while still being able to have full access to the contents and social features of the platform.
reply