I think it's the amount of embedded videos. I appreciate them because it really illustrates what each feature is, but they lag the page. If I recall this can be solved with animated webp images which are more lightweight than full on <video/>s. Or maybe just not autoplaying them
because with vibe coding, one can easily generate thousand lines of code in a short period of time. If we do this in parallel, merging the changes, resolving merge conflicts will be a nightmare. Unless, the agents work on completely isolated modules, but that's rarely the case?
You could have them work in separate areas if it's in the same code base or just spread work across code bases. Not sure if that's a very efficient or enjoyable way to work but I'm assuming that's how you could scale it.
I might get this with ui/styling experimentation. But shouldn’t devs have an idea of what they’re building - the specific building blocks, logical, and data flows - before you prompt? I couldn’t imagine getting three different one shot attempts at an implementation and having to validate and read through each one.
Not everything will work the first time. You could try 3 approaches and immediately discard the ones that don't pass tests. (Which is likely to be 1-2 of them)
Let me guess - they vibe coded this anouncement page also?
I cannot be sure but there are clues ... (The fact that this page crashes after ten seconds on mobile chrome being the first one :))
Crashed Safari on my iPad multiple times. For what should be a static text page. Pretty bad look for a software development tool.
I think it's the amount of embedded videos. I appreciate them because it really illustrates what each feature is, but they lag the page. If I recall this can be solved with animated webp images which are more lightweight than full on <video/>s. Or maybe just not autoplaying them
I don't understand multi-agent vibe coding.
because with vibe coding, one can easily generate thousand lines of code in a short period of time. If we do this in parallel, merging the changes, resolving merge conflicts will be a nightmare. Unless, the agents work on completely isolated modules, but that's rarely the case?
separate projects, working on multiple projects at once, I find context switching is a lot easier than having multiple agents on 1 project
You could have them work in separate areas if it's in the same code base or just spread work across code bases. Not sure if that's a very efficient or enjoyable way to work but I'm assuming that's how you could scale it.
I read their pitch as trying out multiple agents to do the same task and then pick your favorite approach
I might get this with ui/styling experimentation. But shouldn’t devs have an idea of what they’re building - the specific building blocks, logical, and data flows - before you prompt? I couldn’t imagine getting three different one shot attempts at an implementation and having to validate and read through each one.
Not everything will work the first time. You could try 3 approaches and immediately discard the ones that don't pass tests. (Which is likely to be 1-2 of them)
This page transferred well over 200MB of video before I stopped it, just FYI.
Couldn't find the info quickly, is the stealth model cheetah they had a few weeks ago their new Composer 1 model? If not, who's was it?
Edit: yes it was: https://x.com/amanrsanger/status/1983581288755032320
[dupe] https://cursor.com/blog/2-0 (https://news.ycombinator.com/item?id=45748727)