Yeah, we allow importing projects so you can fix bugs you've encountered elsewhere, but we want to streamline the app building process and the UX used in v0/Bolt etc is already really well done. We want this app building to be more reliable though, it's easy to hit bugs that prevent progression.
We're also interested in using our API with MCP so that e.g. Cursor could be used to fix bugs you're seeing locally, and plan to explore that angle before long.
Yes, that's all true. Even so, vibe coding empowers anyone who can write clear instructions to build software, but the limits of the technology get hit pretty quickly by non-developers and they have little recourse. This blog post https://addyo.substack.com/p/the-70-problem-hard-truths-abou... is a great overview.
The tech will get better and better (I couldn't imagine we'd be doing this a year ago) but to be truly useful it has to reliably produce reasonably well engineered code, and effective debugging is a key piece of that.
I’m sure it will. My pessimistic take is that the worst case is that thousands of bozos create crappy little apps that only cause minimal harm. And people just endure it instead of pushing for better guard rails.
Best case is some high profile shit show caused by software made mostly or entirely by ai that hopefully is bad enough that legislators wake up and realize that in the modern world software is essential enough that you can’t let just anyone sell it or services based on it. Just like you can’t allow anybody design/build bridges or hardware or whatever.
But I’m sure thats wishful thinking. Hacks and buggy software causing consumers harm is just accepted and software industry folk all hope to be billionaires so nobody cares.
Thanks, yeah we're really thankful to StackBlitz for open sourcing the early version of Bolt.new and to the Bolt.diy community for continuing to develop it.
We don't have a commercial offering yet and are planning to migrate off WebContainers for the upcoming full stack features -- WebContainers show their limits pretty quickly in a full stack context (e.g. CORS issues) and we need observability into the server side of the app for full stack debugging.
Regardless, our interests here are only lightly commercial. We're not really developing Nut to drive revenue but to help us develop the debugging API and push forward the SOTA for AI development as effectively as we can. That API is what we want to sell.
Yes, Nut is a fork of https://bolt.diy and like bolt.diy you can add your own API key and use it as much as you want (Nut is hosted though so you don't have to set anything else up).
The improvements we're making are under the hood. When you ask Nut to fix a bug it should do a much better job -- we record the app's behavior and analyze it so the AI has context for the changes it needs to make.
We've also added some UI to approve or reject the changes the AI makes. For now we're using this to gather feedback so we can improve Nut, but down the line we'll also refund the user any credits when they reject changes -- you shouldn't have to pay when the AI screws up, a big issue with these tools (and vibe coding in general).
Thanks! Unfortunately the chat links aren't shareable yet. We're planning on adding this within the next couple weeks along with the other full stack features (database integration and easy deployment).
Hmm, strange, it's loading alright for me but we've had a couple reports of rendering problems. If you have a chance to file an issue here https://github.com/replayio/nut.new/issues I'd appreciate it, thanks!
1. Rather than having to restore state to the point at the previous step, we can step backwards by replaying a separate process to the point before the step, and looking at the state there (this post talks about how that works: https://medium.com/replay-io/inspecting-runtimes-caeca007a4b...). Because everything is deterministic it doesn't matter if we step around 10 times and use 10 different processes to look at the state at those points.
2. We record the calls made by the browser, though it is the calls into the system libraries rather than the syscalls themselves (the syscall interfaces aren't stable/documented on mac or windows).
3. Maintaining ordering like this isn't normally necessary for ensuring that behavior is the same when replaying. In the case of memory locations, the access made by thread 2 to location B will behave the same regardless of accesses made by thread 1 to location A, because the values stored in locations A and B are independent from one another.
Thanks for the explanation! Do you ever run into performance issues with replaying from the start on each backward step or is this not really in issue in practice? I imagine for most websites and short replays it's probably fine, but for something like a game with a physics engine it sounds like it would be too expensive and you'd need snapshots or something. I guess that's a super small percentage of the market though.
For question 3 on the ordering, I was imagining the following kind of scenario: one thread maybe calls a system library function to read a cursor position and another calls a system library function to write a cursor position. So even though they're separate functions, they interact with the same state. Do you require users to manually call to the recorder library to give the recorder runtime extra info in this kind of scenario? Sorry if this is a dumb question, I haven't really done any programming at this level.
We definitely need to avoid replaying from the start every time we want to inspect the state at some point. This is kind of an internal detail, but we can avoid having to replay parts of the recording over and over again by using fork() to create new processes at points within the recording.
Ordering constraints between different library functions do crop up from time to time. In cases like this the recorder library uses ordered locks internally (basically emulating the synchronization which the system library has to do) to ensure that the calls execute in the expected order when replaying.
(Replay employee) Yeah, later in the post (https://medium.com/replay-io/effective-determinism-54cc91f56...) we mention needing mitigations to ensure that hashtable iteration is deterministic in cases where it affects how the browser interacts with the JS engine. There are others needed as well to ensure that the browser behaves the same across a large range of websites, my favorite is handling sites that sniff information about the system's math libraries by e.g. calling Math.sin() on specific values and testing the results --- the values when replaying need to be bitwise identical with what happened while recording.
Ah I shouldn't have stopped reading. Then as one of the rare browser replay experts (there's gotta be at least like... 7 of us right?) I can certify your project as the real deal.
