I immediately tried Circuits, because I have a lot of expertise here and realised it was expected: absolutely zero understanding of the product domain. It looks like an EDA package, it smells like an EDA package but an EDA package it ain't.
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 created schematic, pcb. Then exported Gerbers as zip and it passed and looks ok at jlcpcb. So it's usable.
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.
Why should I when there's KiCad on the market? Or even pay for Altium?
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.
I see no evidence that you're committed to it getting better over time. Tell me again in a year or two when something you've made has actually gotten usable. Until then, build your credibility by making something good, not just making a sloppy copy.
I want to see good, small, focused tools that are highly polished and (user) tested, and fit into a bigger ecosystem that can be mashed up and adapted on the fly to fit the task you have. Just porting existing mega-apps doesn’t seem appealing at all. They are still going to be as inflexible and overwhelming, and much rougher around the edges.
I think eventually the smaller focused tools will win the market by a wide margin. But for now, there is huge demand for open-source and free alternatives to mega apps. Especially for the education/non-profit sector.
> good, small, focused tools that are highly polished and (user) tested, and fit into a bigger ecosystem that can be mashed up and adapted on the fly to fit the task you have
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
shoving all of these vastly different applications into one monorepo does not bode well for them being seriously designed, maintained, and cared-about pieces of software. such is the nature of LLM development, i suppose.
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.
I might be missing something but inspecting a few of them the testing seems quite thin. I won’t do anything now without layers of controls for agent coding. Just for testing — near 100s for v8 coverage, property, mutation, fuzz, chaos, contract, bdd e2e, api and playwright exploratory mcp. Long term maintenance of all of this is going to need a ci/cd that puts all that through a ringer around the clock.
there are other ways to share code than a monorepo, namely independently versioned packages. you say dependency hell but if you're in control of everything you're in the best position to avoid that if you put thought into it. with a monorepo you could actually get worse results in some cases. say i change something in a graphics api for sudoku and suddenly the zoom clone doesn't work. yuck. i only buy the monorepo argument for systems of code that actually need to be deployed in sync, like server/client stuff or larger. iirc google has a massive monorepo for nearly all of their production code because basically all of it works together (server/client stuff, auth, etc)
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.
What's shared between the "Property Management" and "Photo Studio"?
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.
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)
This is the worst kind of slop. The kind where someone doesn't exhibit any concern for quality or user experience. I know that's so, because it's a gazillion unrelated apps that clone existing huge apps, built by a couple of people and Claude.
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.
I like the idea of replacing entrenched proprietary apps with familiar UIs, using AI.
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.
The arrogance required to think you can vibe code everything. I am all for LLM generated replacements for the rent-seeking garbage that permeates software, but this is not the answer. Tools developed by people who use them are the future. Instead, I guarantee this person has the same mindset as the Adobe management he’s trying to displace: create what looks like a useful tool with minimal effort and rely on scale to beat everyone else.
Are people not aware that every single one of these already had open source, self-hosted alternatives? Why do we need to add a pile of slop-code knockoffs? Why does it need to be one giant repo? Does this person have any experience building and releasing software that wasn't built and released for them by a robot?
> 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?
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.
Tall words for someone recommending KiCad.
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.
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!
https://github.com/morluto/rea
[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?