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.

Yeah, I looked all over for a comparison and couldn't find anything in the repo, on their social media, etc. I saw some other comments here that said it's supposed to be "15.8 fp16 ops compared to 14.7 fp32 ops" but that isn't really enough to go on. Maybe when I have the time I'll install their TestFlight app and do some comparisons myself.

I had a good chuckle at "squishy machines". That's a really interesting way to think about it. It makes me wonder if, some day, we will be able to build "squishy machines" of our own, capable of outperforming silicon while using a tiny fraction of the energy.

Thanks for this. Just a few minutes ago I pulled up an old project using `ts-node` with ESM and tried to run it on a new machine, had some issues and remembered reading your comment here earlier. I switched to `tsx` and in less than a minute everything was working beautifully. I'll probably migrate all my TS projects to `tsx`.

For years I had the same gut issues described by others here, seemingly caused by a combination of factors. I'll share what helped me solve the problem.

The most effective thing for me seemed to be hitting the gym hard, lifting heavy and sweating a lot.

Alongside that, I went through a lot of trial and error with the foods my body would tolerate. I started with a low histamine/low FODMAP approach, various fasting methods, bone broths (collagen), probiotics (sauerkraut, kefir), etc., and slowly introduced various foods on top of that while noting what made me feel good or bad and basing my diet around that. Everyone is different so what worked for me diet-wise may not work for you.

Lastly, for my particular case, I think liver-boosting supplements like milk thistle and NAC helped significantly (and probably some others for any vitamin/mineral deficiencies, especially D3+K2). I suspect the root cause of my problems was toxic mold plus stress/trauma.

This is why, on almost every website I visit where I know I'll be opening multiple links (which would normally require hitting the back button to view them all), I just open every link in a new tab and then close the tab when finished.

I suspect many people use HN (and similar) this way.

It's always a fun time when I occasionally use the browser/website "as intended" and hit the back button, but the scroll position has been completely lost so it takes a bit to find the exact place I was looking originally.

Give Molecule.dev a look. (I'm the creator. Lots of open source improvements in the future, but for now, it is what it is.)

Very cool! I'm definitely going to try this out.

Whoa, I might have to try the mouse -> usbc adapter just for fun! I had no idea that was a thing.

A neural net was my first guess as to how this would work but was pleasantly surprised at the actual technique used, which makes a lot of sense. The animated gif does a great job of explaining it on its own.

It sort of reminds me of a video game UI for an RPG or something. Game UIs usually do a great job of organizing and simplifying complex hierarchical information and making it quick and intuitive to find what you need. A lot of the web tech I've built over the years has been inspired by well designed games.

> Writing glue code and boilerplate is a waste

> Why not use a framework?

These 2 sections highlight exactly the problems I've been trying to solve with Molecule.dev. I agree with the author that software development has somewhat stagnated, and I believe something like Molecule.dev is the future. It isn't perfect and there's still a lot of work to be done, but I'm certain it's headed in the right direction. The codebase is currently in the process of being repackaged (it'll be an MIT licensed monorepo) so that developers can more easily play with it, and so that it can be more easily integrated into existing systems, as starter apps are not a frequent enough problem to build a scalable business from. This repackaging is taking longer than normal because all the investors I've spoken to apparently don't see the value in it (yet), so I've been looking for contract work to stay afloat. (Know anyone?)

> Testing and Correctness

> I want simpler testing

I built something else in early 2020 to address this exact problem as well, TestFront.io. I haven't touched it in a while (so don't sign up) but I may return to it eventually. It's open source. I've tried many testing tools/frameworks and none of them quite do what TestFront.io does. There is a pretty similar tool which someone turned into a very successful business (actually can't remember the name of it now), so there's definitely some value in it, but from what I saw when trying it, it's still not quite up to par with TestFront's granularity and ease-of-use. I'd like to return to TestFront some day, but for now there are bigger fish to fry.

It's down for me at the moment.

Before I officially had an MVP, I posted about something I was working on here: https://news.ycombinator.com/item?id=29815771

Made my first sale from it, but I'm still looking for PMF and will need to pivot a bit. There's obviously value here, but I think the specific problem it solves is too infrequent to create a sustainable business from, and developers are a rightfully picky bunch.

I'm like 90% sure I was spit on by this woman during a week long business trip in 2018. I ignored it and kept walking. Figured she just didn't like the cut of my jib or something, but I guess it makes sense that it'd be a regular occurrence and I feel slightly less bad about it now.

Sometimes web tech is the best tool for the job. Sometimes native is the best tool for the job. Sometimes it's a mix of both. Again, it depends on the requirements and the resources you have at your disposal.

Also, I think part of the reason you often see lower quality web apps (including the underlying tech) is because the barrier to entry is much lower than with native. If we improve the tooling around web tech, the average person can produce higher quality web apps. As it is now, I agree native generally comes with a better experience, but I see no reason why it can't be eventually matched on the web.

I was just thinking about this exact topic less than an hour ago.

We seem to be slowly reaching a consensus on various best practices and tools, and it's obvious which ones are winners and will be here to stay for the foreseeable future, despite the inevitable churn. There will always be discussion (and disagreements) on how to make things better, and when I was less experienced, I (ironically) used to be way more opinionated on the best approaches, but over time, after witnessing the evolution over the years, it always comes down to one core tenet: choose the best tool for the job. Even this isn't purely objective, as it can vary depending on your individual circumstances, time constraints, and the people (and their skillsets) available to do the work.

I've always imagined a future where almost anyone can quickly assemble high quality applications (both software and hardware) to meet almost any human need. We're seeing this trend with all of the low-code/no-code tools popping up, but to take it up a notch, it will probably require some standardization of tooling and practices. I think this is the next phase of our technological evolution and would be a great solution to the author's request for "more better web apps".

I was (and still am) genuinely looking for work and to help companies build their products. My thought process was that if they're looking to hire an engineer, they're looking for someone to build their app, and I was offering a way to do that for them, faster.

My main problem is that I didn't know how to find the exact type of person I'm looking for, so I cast a much wider net than I should have. I was told by an experienced salesperson that I should aim for ~100 emails per week, and then send followup emails to those same email addresses a couple days later, even if they don't respond to the first one, meaning I contacted ~400 people over the course of June. Part of the advice I received was that contacting the wrong person is okay, as they might forward me to the right person.

By the way, Apollo.io is a YC backed company, which was a huge part of my thought process. "YC? Based out of SF? Okay this must be how people do things these days." So against my better judgment, I gave it a shot.

It was definitely the wrong approach, but as someone with zero experience or knowledge of sales and cold outreach, there's no way I could have known that without trying first, especially with experienced salespeople telling me it's just what people do.

The link is supposed to be https://www.molecule.dev/typescript-react-postgres-saas-star.... I forgot that HN looks for the canonical link tag. Can @dang or someone please delete this?

I'm curious. What do you (and the GP) have against Brave and its "crypto wallet"? I use Brave myself, but have never bothered with the wallet. Last I checked, you could earn BAT from watching ads provided by Brave, which is why I never personally bothered with it. (I really don't like ads.) Is that your reasoning as well? Or is there another reason?

Check out Molecule.dev.

It has basically everything you're requesting - both front-end and back-end, image uploads, authentication (and OAuth login via Twitter, Google, etc.), user plans/subscriptions, Stripe integration, cross-platform support with Apple Pay and Google Pay, push notifications, emails, documentation, unit tests, etc. And after some minor setup, it's immediately ready for you to publish to app stores if you wish to do so, with thorough step-by-step instructions on how to set it all up.

I should also note that it isn't a framework, so you're not locked into learning some specific way of doing things. It assembles full-stack codebases using tools and libraries most developers are already familiar with, so you'll have full control over everything. It is designed for teams, startups, and indie devs to quickly build and scale.

You'd still need to implement custom functionality like voting and reposting yourself, however.

Disclaimer: I'm the creator of Molecule.dev.