loh

I recently began playing around with ZCode. Works pretty well. Super sketchy though if it is in fact silently uploading full git history of every user's projects. This is why we need not only open weight models, but open source harnesses as well. Luckily the project I'm trying ZCode on is already open source (Molecule.dev), and I'm already allowing full telemetry with my other agents/harnesses (e.g., Claude) for this particular project, so it's not a huge deal in my case, but it's obviously a huge deal for anything proprietary.

There is still a lot of work do be done surrounding the systems AI integrates for us, and as a sibling comment mentioned, AI's ability to use various abstractions is incredibly beneficial, as it results in fewer tokens (not reinventing the wheel) and can provide more consistent/predictable polished results. If you're building something trivial like a basic web page or a very simple one-off script, sure, abstractions would be overkill. But if you're building something that needs to scale and interface with many other systems and work perfectly on every available platform, we still need abstractions that AI can work with.

I don't think we've seen the end of the library/framework churn from the last few decades before AI, but I do think we will eventually settle on an "optimal approach" where the average developer no longer has to consider tool A versus tool B for basically every common use case. Future libraries and frameworks will be designed specifically for AI to "understand". Most LLM training data is based on the old way of building software, and while it is pretty good at it, I think we'll see major improvements (and counterintuitively, less AI slop) as the underlying abstractions and AI models adapt to the new paradigms and workflows enabled by AI.

I agree with you here, but to make it clear what I meant, I'll reiterate what I said in a sibling comment: I wasn't referring to the current state of Opus 5 (or even Fable 5.1) output. I was referring to possible future information density (vocabulary and sentence structure) that LLMs may evolve to use.

I wasn't referring to the current state of Opus 5 output. I was referring to possible future information density (vocabulary and sentence structure) that LLMs may evolve to use.

If this kind of "AI-speak" becomes ubiquitous and humans reading it becomes the norm (whether to guide AI or other reasons), I'd imagine future generations (of humans) who grow up with it will be able to understand and work with it much better than we do. Future humans' brains will probably be wired a bit differently, similar to multilingual speakers of today. We may even see "AI language" classes become a common part of school curriculums. Although, I think AI will probably advance enough that most people will never even need to communicate on "its level", but it's probably a good idea to keep humans in the loop either way, and in which case, understanding the more advanced "AI vocabulary" might be useful.

TL;DR: Revived my dead startup with AI and open sourced 99% of it.

For a bit of background here, I built Molecule.dev back in 2021 before AI was really a thing. It worked by allowing you to select the stack, libraries, and features you wanted, and then it would cherry pick a series of carefully crafted git commits to produce a fully functional app and API based on your selection. The idea was to provide polished code (using best practices at the time) that easily fit into common workflows of professional teams to help them quickly scale. It was probably too ambitious for the time, so after failing to find product-market fit fast enough, I very dangerously ran out of runway and had to scrap it.

Fast forward to early 2026... Opus 4.5 was out and after playing around with it a bit, it became clear that the original vision of decoupled, easily swappable stacks, features, and integrations was now possible. Long story short, I pointed Opus at Molecule v1's codebase and explained the design patterns, where I wanted to go with it, and have been grinding away at it nonstop ever since.

Turns out that v1's cherry-pickable architecture translates pretty well to code that weak LLMs can understand and work with. This makes it possible to very cheaply integrate/swap full-stack features and functionality common to almost every app, end-to-end, and the result is polished, predictable, and works immediately... so people no longer need to waste a bunch of time and tokens generating/testing/fixing semi-random unpolished code for core functionality. As you might expect, the AI generated code within Molecule's own packages isn't always the best, but I'm certain that we will solve that problem with more time and tokens, as the Molecule "bond" pattern helps enforce better code and architecture.

The goal here is to help people (tech savvy or not) build higher quality software faster and cheaper, allowing them to focus on solving real problems instead of dealing with the mundane work that makes the last 10% of building a real app such an unexpected pain. Hopefully it will help reduce the "AI slop" type apps by giving people more time and energy to build things that are more unique but still provide all of the common functionality we expect from polished software. Ideally, some years from now, no one (not even LLMs) will need to think about how some common core functionality should be implemented. We should be able to look back and say "problem solved".

There is still a lot to do (with some really cool/useful stuff planned for the future!) and it's definitely rough around the edges at the moment, but I figured I'd go ahead and share v2 as a proof of concept.

Actually quite good for a meme library! Unironically considering using some of this, or pulling some inspiration from it at least.

Also, I'm curious as to when the animated gradient text started being a popular thing. I started doing it back in 2021 or so. I think I was inspired by some of Apple's webpages at the time.

Not really, no, at least not with Claude. It seems to already understand the UE5 way of doing things, but there were a couple of edge cases for new features beyond its cutoff date where I had to refer Claude to the UE5 documentation. Once it read the documentation however, it understood and continued without issue. Also, for any compilation errors, I just copy and paste the error messages into Claude Code and it usually fixes it immediately.

Just for fun, I built a first person shooter game in UE5 from scratch using agentic coding. I've only spent a couple of months on it in my free time so far, and it isn't complete yet, but it's close enough that I could definitely release an early access version with another month or so of work. The most time consuming tasks have actually been tasks that agentic coding hasn't been able to help out with, like animations and mapping. The game is mostly written in C++ and sometimes the agent makes some bad decisions, but with a bit of extra guidance and being smart about my git commits so that I can revert and try again if necessary, I've always been able to make it work the way I want. I most definitely would not have been able to build this on my own in any reasonable amount of time.

FWIW it seems like it heavily depends on the agent + model you're using. I've had the most success with Claude Code (Sonnet), and only tried Opus 4.5 for more complex things. I've also tried Codex which didn't seem very good by comparison, plus a handful of other local models (Qwen3, GLM, Minimax, etc.) through OpenCode, Roo, and Cline that I'm able to run on my 128 GB M4 Max. The local ones can work for very simple agentic tasks, albeit quite slow.