Not mine, but I found this to be really interesting as a language created by one person for their own use.
Also really interesting are the author's blog with articles on language design (for example his thoughts on exceptions, and how he added them to his language, then decided against them), and the change log for the language, showing its evolution.
my biggest code smell is debugging. Trying to step through the code is slow because of how much the debugger has to keep track off and it's a lot of step into / jumps until you get to the piece you actually care about. Then you also see stuff like "if langchain_v2: <branch> elif langchain_v3: <branch> else ...." ... breaking changes are ok! I feel like at this point they're hopelessly spaghettied and need a more opinionated approach to clean up a lot of the mess.
Since others are asking: My current goto is pydantic ai and it's been doing pretty well for my use cases.
It (and most other systems) abstract the wrong concepts when you want to create an agent. They promote what was likely never a great strategy but even parsimoniously what are strategies that were good ideas months or a year back.
For example how langchain or whatever else handles subagents and deep research is laughable even today.
So whats the recommendation? Just use pydantic and code everything up yourself. Maybe strands I dont know.
Which specific strategies do you think are outdated, and what would you recommend instead? This sounds more like a criticism of older versions of LangChain than its current APIs. The post also uses deepagents, a separate package in the same ecosystem. Is there something in the current implementation of either that you’re referring to?
> This sounds more like a criticism of older versions of LangChain than its current APIs
Oh no worries, I'm always happy when library / sdk makers are constantly changing their APIs in-between versions. Why would I not want to spend time updating my code to return to baseline functionality when I could have just built something using the 4-year stable underlying chat completions API instead...?
Creating deep research multiagent systems without explicitly handing it a file system is a terrible idea. The only successful way we have found to reliably hand off context in multiagent systems is using a file system. Langchain even today doesnt make that default or even encourage it.
It's just that the choice of object is weird.
"Pacing our progress" or "pacing development" is more usual. "Pacing the frontier" I guess is a shorthand for "Pacing [the development of] frontier [models]"
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.
Also really interesting are the author's blog with articles on language design (for example his thoughts on exceptions, and how he added them to his language, then decided against them), and the change log for the language, showing its evolution.
https://tibleiz.net/
https://tibleiz.net/copper/changes.html
reply