And I don't want to hear "it's alpha" and "it'll improve over time". The very foundation it is built on is a near zero understanding of the domain.
This is exactly the same as all the sudden Lightroom and Photoshop replacements.
I added one issue (allow to change default trace width) and we'll see how it goes. If they actually fix it, with maybe 30 another similar fixes it could be usable.
Put a usable product on the market from day one or don't bother. There's absolutely no proof you will deliver anything here. This is just slavery to an inferior promise in the name of progress.
I'm not patting this on the head and waiting and expecting it to grow up into a work dog.
Don't sloppy that copy!
i wish i could use the shell this way; some of my colleagues could pipe things in between /usr/bin utilities all day for things i'd need a script for
not to mention that there are only three contributors and #2 is claude, although that might be because they just committed a bunch of previously-untracked code at once, i don't care to check.
I feel like you're being snarky but, regardless, I'm curious to hear your reasoning for the first paragraph. being a monorepo helps us share code across 50 different apps without falling into a submodule/dependency hell.
also a monorepo like this is worse for human interaction, if you care. what if someone only wants to pull and work on sudoku? now they have to get everything else. issues and pull requests are also more annoying to varying degrees depending on use.
The UI frameworks already exist, there's 0 reason to share more things between them. That is, unless it has a slopped revolutionary(tm) UI framework #1000.
I’m all for recreating software, especially to be faster, cleaner, smaller, and more bespoke - but trying to one-shot a whole suite will never work. Building these foundational office-y tools requires an immense amount of testing and attention.
additionally, somewhere in the agent prompt i asked it to maximize app functionality without the user having to sign in. for most office/creative/engineering apps this should work very well in the long term (fingers crossed)
The reality of launching a good product with AI is that the coding is very fast, but the QC, the documentation, the refinement and user testing, isn't all that much faster, if you care about it being good.
This is a mountain of code, full of bugs and weirdness that users will be the first to find, because nobody else is looking at it.
My process for building with AI is "intense weekend of vibe coding" and then several times that time spent on refinement and testing that comes from actually using the software a lot. A couple of devs can't be responsible for every major application.
With AI, you can make anything you want, but you can't make everything.
This certainly checks that box!
[0] https://www.neowin.net/news/denmark-has-abandoned-plans-to-d...
I'm not the first to say that AI is enabling a fracturing of these projects, though. There's this, and also "ArtCraft" I think, which seem to be trying the exact same thing. I wonder if there is still a place in the AI era for separate projects to merge efforts and processes to accelerate the development of quality clones.
> Does this person have any experience building and releasing software that wasn't built and released for them by a robot?
I built https://github.com/heyputer/puter. What have you done? Because your GitHub is pretty empty: https://github.com/etchalon, and your company's website doesn't redirect to https. Doesn't inspire much confidence when you're not even doing the basic stuff right, does it?