Neat example of the strengths and weaknesses of vibe coding… But if anyone here is looking for a solid browser-based parametric CAD solution, [onshape](https://www.onshape.com) is the best there is. It’s missing a few tools that more complex alternatives have but if all you need is something easy to learn so you can make things to 3d print it’s a good choice
Onshape is indeed fantastic for hobbyists and professionals alike.
Their licensing model is reminiscent of early Github days in that you can use all available modeling features free of charge, but must pay for a private repo. Otherwise, all user generated content is publicly available.
this is free and open source :) also runs directly in your browser / offline. onshore requires an account and internet connection because it streams to your browser
Nice UI. Pretty cool to see a CAD program in the browser, without even an annoying login to try screen. On the other hands it seems to be pretty choppy and I was visual artifacts about 5 seconds into the tutorial. I got the same artifacts in Zen and Chrome.
Sorry for the flood below. It's relevant but not very compact.
The compact answer is software complexity, intrinsically complex algorithms and geometric robustness. Data model may be difficult depending what you want to do. Robust import. Robust export domain to domain.
The last two are especially nasty if you are solo since there are no good specs here. There are _specs_ but what happens in practice is that each party has their own implementation that almost works, except in n. corner cases. Then you need to figure out is your software wrong, or is the input data wrong, and not rush to hasty conclusions. This will be time consuming.
Even though Claude's improved considerably in the past few months I'm super impressed what you achieved in a very little time.
You clearly know what you want and how to get there.
The key here is _you design parts_ for _your job_.
You _already_ know what the requirements are to do _your job_.
The HN critique is pointless noise honestly (sorry guys but that's how it usually is, queue 'Dropbox' critique). If you want to develop this further, design your robot with this, then find other people building robots, test can they use this and fix the parts that don't work for others, iterate.
What's your most important talent here? Not the software engineering bit. You are an industrial end user yourself. If you give me a room full of four mediocre software engineers and one person who understands the end user deeply, and a room with 1-2 kick-ass programmers 9/10 times the room with the domain expert wins. Now in this case you are the programmer and the end user. I'd say I would bet very high on good outcomes for this project if you can keep at it and can sustain empathy for end users (not all of them! just the ones you care about).
So rather than explain this as "CAD" explain it as "CAD for doing X" and I would hazard X in this case is robots.
I mean it's startups 101. You develop a tool to solve your own problem. Then you build your mvp and find your next users. You know how to build robots and what the problems are. I guarantee you 100% there are other people building robots, well capitalized, and they have exactly the same problems as you.
That said the problems to you may not be problems to others. Not all solution are universal. That's why understanding _the market_ needs with an mvp after you know how to solve your own problems is critical.
"I will solve your problem" and "this will exist in 10 years" are the two magic words to industrial adoption if you are not bullshitting and find someone to hustle those first magical beached users in.
If history of software business has taught us anything it's this: The _most important talent_ in developing complex software is not be a kick ass software engineer. It's to understand the end user. And in industrial workflows end user pain has an immediate and usually significant financial benefit to it which means if you actually can penetrate the market do plan for making this into a business. But not an open source one. Those end in tears usually. See Ondsel for example https://www.ondsel.com/blog/goodbye/. I don't know _why_ these things fail but I _guess_ there comes a point where you need to be well capitalized to make headway and capital does not seem to like open source. I'm not telling you what to do! I'm just giving a fair warning the Open Source route may be the more difficult one unless you land exactly right.
--
To answer you _technical_ question the 1st difficulty _is_ figuring out to whom the software is and what they do with it.
There is no "universal" CAD. _All_ of the applications are tailored for a more or less specific industrial design workflow. Mech eng is totally different than AEC which is totally different from circuit design.
The second hard part is understanding the software's position in the value chain. What are the inputs. What are the outputs.
Traditionally in CAD the final outputs have been
a) drawings
b) manufacturing robot control code (GCODE, CAM etc)
c) documentation (database, drawings, 3d models... whatever the documentation spec requires)
And in addition to this there are the software that sit "in between" where the input is a design file from previous modeling step or software, and output is another design file.
Why are these hard? Markets are surprisingly opaque unless you participate in them - there is no playbook to copy, you have to mostly discover it yourself.
Now what does this have to do with _the actual part of modeling_?! Well, the user requirements drive the outputs _which drive the requirements_ to your surface model and the enrich data landscape where it lives.
Based on what I'm reading your blog you might be grokking these things intuitively so it may sound I'm spewing trivialities but trust me, in the industrial scale of things - they are not - these are some hard learned facts :)
Ok, now you know for whom the software is and what the inputs and outputs are.
Now we get to the technical bits.
The thing that kills your velocity will be complexity creep unless you take care.
Since you are a software engineer you probably understand what good architecture is, so I don't have to spell it out, but in these types of programs good architecture gets thrown under a bus at some point as the software has basically evolved to an architectural dead end because the team did not anticipate some requirements that manifest only much later in the development plan. Then what happens is rather than refactor the entire codebase (which at this point is usually massive) the team starts to do "clever hacks" to implement the next feature.
Then those "hacks" pile up and you end up with legacy software like no other, like I would guess most of Autodesk's or Trimble's portfolio is composed of.
Why dont't they just fix things? Well, then the user space equivalent of Hyrum's law kicks in.
At this stage you are either default dead or have bunch of industrial projects humming on your software.
And industrial users _don't appreciate change_. They prefer 99/100 times a software whose bugs they understand and know how to circumvent to have the software perform reliably in _their_ design pipeline for the next decade at least (well, figuratively speaking - in any case you need to commit to _support_, _maintenance_ and _not changing critical things_).
One point of view to all software is that they are discovery tools for end user requirements.
The problem with CAD is that the entire stack is so complex that when you get to your mvp:s using the software successfully, it's already so complex you really don't know how to fix it anymore without writing it from scratch or breaking things.
I think the above makes clear why I'm quite bullish for you and hope you keep up with the project.
But the architecture will stab you in the back so many times unless you prefer the "gray goo" model of software architecture. There's no manual for this. Just keep at it. Why can't someone tell you just what the problems are? Because they are emergent. Because you are doing a creative thing and not just copypasting some boring-as-hell SaaS app that's Crud-with-sugar-on-top.
In general I agree with the overall software architectural sentiments you wrote about so looking good so far :).
P.S. Of course 3D modeling, good UX and all that stuff is really hard if you look at industrial baseline on what things are "easy" or "hard" for people, but that's the table stakes stuff which you need to also to cover.
This... what is this even doing? The camera controls are all fucked up. Why is mousewheel bound to rotate on the X axis? I can't actually select and move things. The container example is... is this supposed to be an object? Why is a cylinder floating above it? Why is shading all fucked up on the "twisted ribbon"? Etcetera etcetera.
Oh, it's vibe coded? And the author seems to have a bad case of Dunning-Kruger?
Interesting, that would be a big plus once it works.
I don't have a concrete use case, I just know that it's generally easier to "attach this cube to this face", than having to work out the formula to position it correctly, especially once you start working with weird angles, or wanting something to be tangent to a circle. That is how every professional CAD package I've ever used works.
Neat example of the strengths and weaknesses of vibe coding… But if anyone here is looking for a solid browser-based parametric CAD solution, [onshape](https://www.onshape.com) is the best there is. It’s missing a few tools that more complex alternatives have but if all you need is something easy to learn so you can make things to 3d print it’s a good choice
Onshape is indeed fantastic for hobbyists and professionals alike.
Their licensing model is reminiscent of early Github days in that you can use all available modeling features free of charge, but must pay for a private repo. Otherwise, all user generated content is publicly available.
> Their licensing model is reminiscent of early Github days
The licensing cost has a few more digits than GitHub ever did.
And you are locked in.
You are not wrong, but they’re much more generous than anyone else in the professional CAD space.
Yeah, it's pretty good but still crazy expensive. Most of the good CAD softwares have remained very expensive.
this is free and open source :) also runs directly in your browser / offline. onshore requires an account and internet connection because it streams to your browser
Vibe coded? Nothing works.
Yes, vibe coded. The author has posted several other articles about this whole vibe coding project, like this one: https://campedersen.com/brep-kernel
This guy is a machine! Like Terminator vs. HN and Autodesk :)
probably best that you didn't say what kind of machine :D
<3
Man, I really tried but I can't even get through the article because it sounds so AI written. I feel like I'm scrolling on LinkedIn...
That website has literally caused my window manager (sway/wlroots/wayland) to bug out and consume 90% of a core.
> That website has literally caused my window manager (sway/wlroots/wayland) to bug out and consume 90% of a core.
That is incredibly concerning, but not for the website...
I agree. I wanted to make a note for anyone else seeing odd behavior, but I'm working on figuring out what sort of degenerate behavior this hits.
thanks for the heads up! I'll work on perf this weekend
I just built it last night, what bugs are you running into?
Why is right/middle click both orbit and pan? Why is scroll wheel vertical orbit? This feels like it was vibecoded using a macbook touchpad
I built it for my trackpad. What mouse settings would you prefer? Or configurable?
Nice UI. Pretty cool to see a CAD program in the browser, without even an annoying login to try screen. On the other hands it seems to be pretty choppy and I was visual artifacts about 5 seconds into the tutorial. I got the same artifacts in Zen and Chrome.
Thanks for the feedback, I will test in other browsers!
And now you know why CAD is hard.
That it is. I’ve been doing one for a sideproject for years. And I worked in CAD professionally for over a decade.
Vibecoding expedites the easy parts fantastically.
But the hard parts are hard. Really, damn hard.
>> I’ve been doing one for a sideproject for years. And I worked in CAD professionally for over a decade.
Can we see it?
Sure! Here’s the most recent public alpha build https://github.com/AdaShape/adashape-open-testing/releases/t...
What are the hard parts?
Sorry for the flood below. It's relevant but not very compact.
The compact answer is software complexity, intrinsically complex algorithms and geometric robustness. Data model may be difficult depending what you want to do. Robust import. Robust export domain to domain.
The last two are especially nasty if you are solo since there are no good specs here. There are _specs_ but what happens in practice is that each party has their own implementation that almost works, except in n. corner cases. Then you need to figure out is your software wrong, or is the input data wrong, and not rush to hasty conclusions. This will be time consuming.
Well, clearly not for you :).
Even though Claude's improved considerably in the past few months I'm super impressed what you achieved in a very little time.
You clearly know what you want and how to get there.
The key here is _you design parts_ for _your job_.
You _already_ know what the requirements are to do _your job_.
The HN critique is pointless noise honestly (sorry guys but that's how it usually is, queue 'Dropbox' critique). If you want to develop this further, design your robot with this, then find other people building robots, test can they use this and fix the parts that don't work for others, iterate.
What's your most important talent here? Not the software engineering bit. You are an industrial end user yourself. If you give me a room full of four mediocre software engineers and one person who understands the end user deeply, and a room with 1-2 kick-ass programmers 9/10 times the room with the domain expert wins. Now in this case you are the programmer and the end user. I'd say I would bet very high on good outcomes for this project if you can keep at it and can sustain empathy for end users (not all of them! just the ones you care about).
So rather than explain this as "CAD" explain it as "CAD for doing X" and I would hazard X in this case is robots.
I mean it's startups 101. You develop a tool to solve your own problem. Then you build your mvp and find your next users. You know how to build robots and what the problems are. I guarantee you 100% there are other people building robots, well capitalized, and they have exactly the same problems as you.
That said the problems to you may not be problems to others. Not all solution are universal. That's why understanding _the market_ needs with an mvp after you know how to solve your own problems is critical.
"I will solve your problem" and "this will exist in 10 years" are the two magic words to industrial adoption if you are not bullshitting and find someone to hustle those first magical beached users in.
If history of software business has taught us anything it's this: The _most important talent_ in developing complex software is not be a kick ass software engineer. It's to understand the end user. And in industrial workflows end user pain has an immediate and usually significant financial benefit to it which means if you actually can penetrate the market do plan for making this into a business. But not an open source one. Those end in tears usually. See Ondsel for example https://www.ondsel.com/blog/goodbye/. I don't know _why_ these things fail but I _guess_ there comes a point where you need to be well capitalized to make headway and capital does not seem to like open source. I'm not telling you what to do! I'm just giving a fair warning the Open Source route may be the more difficult one unless you land exactly right.
--
To answer you _technical_ question the 1st difficulty _is_ figuring out to whom the software is and what they do with it.
There is no "universal" CAD. _All_ of the applications are tailored for a more or less specific industrial design workflow. Mech eng is totally different than AEC which is totally different from circuit design.
The second hard part is understanding the software's position in the value chain. What are the inputs. What are the outputs.
Traditionally in CAD the final outputs have been a) drawings b) manufacturing robot control code (GCODE, CAM etc) c) documentation (database, drawings, 3d models... whatever the documentation spec requires)
And in addition to this there are the software that sit "in between" where the input is a design file from previous modeling step or software, and output is another design file.
Why are these hard? Markets are surprisingly opaque unless you participate in them - there is no playbook to copy, you have to mostly discover it yourself.
Now what does this have to do with _the actual part of modeling_?! Well, the user requirements drive the outputs _which drive the requirements_ to your surface model and the enrich data landscape where it lives.
Based on what I'm reading your blog you might be grokking these things intuitively so it may sound I'm spewing trivialities but trust me, in the industrial scale of things - they are not - these are some hard learned facts :)
Ok, now you know for whom the software is and what the inputs and outputs are.
Now we get to the technical bits.
The thing that kills your velocity will be complexity creep unless you take care.
Since you are a software engineer you probably understand what good architecture is, so I don't have to spell it out, but in these types of programs good architecture gets thrown under a bus at some point as the software has basically evolved to an architectural dead end because the team did not anticipate some requirements that manifest only much later in the development plan. Then what happens is rather than refactor the entire codebase (which at this point is usually massive) the team starts to do "clever hacks" to implement the next feature.
Then those "hacks" pile up and you end up with legacy software like no other, like I would guess most of Autodesk's or Trimble's portfolio is composed of.
Why dont't they just fix things? Well, then the user space equivalent of Hyrum's law kicks in.
At this stage you are either default dead or have bunch of industrial projects humming on your software.
And industrial users _don't appreciate change_. They prefer 99/100 times a software whose bugs they understand and know how to circumvent to have the software perform reliably in _their_ design pipeline for the next decade at least (well, figuratively speaking - in any case you need to commit to _support_, _maintenance_ and _not changing critical things_).
One point of view to all software is that they are discovery tools for end user requirements.
The problem with CAD is that the entire stack is so complex that when you get to your mvp:s using the software successfully, it's already so complex you really don't know how to fix it anymore without writing it from scratch or breaking things.
I think the above makes clear why I'm quite bullish for you and hope you keep up with the project.
But the architecture will stab you in the back so many times unless you prefer the "gray goo" model of software architecture. There's no manual for this. Just keep at it. Why can't someone tell you just what the problems are? Because they are emergent. Because you are doing a creative thing and not just copypasting some boring-as-hell SaaS app that's Crud-with-sugar-on-top.
In general I agree with the overall software architectural sentiments you wrote about so looking good so far :).
P.S. Of course 3D modeling, good UX and all that stuff is really hard if you look at industrial baseline on what things are "easy" or "hard" for people, but that's the table stakes stuff which you need to also to cover.
its not really
This... what is this even doing? The camera controls are all fucked up. Why is mousewheel bound to rotate on the X axis? I can't actually select and move things. The container example is... is this supposed to be an object? Why is a cylinder floating above it? Why is shading all fucked up on the "twisted ribbon"? Etcetera etcetera.
Oh, it's vibe coded? And the author seems to have a bad case of Dunning-Kruger?
Yeah, I'll pass.
Damn, even his blog posts sound AI-written: https://campedersen.com/brep-kernel
"I'm not building a weekend project. I'm building a Fusion 360 replacement."
This seems to have the same weakness as OpenSCAD, no relative positioning.
I added this to the kernel but it isn't exposed to the UI yet. What is your use case? id love to support it
Interesting, that would be a big plus once it works.
I don't have a concrete use case, I just know that it's generally easier to "attach this cube to this face", than having to work out the formula to position it correctly, especially once you start working with weird angles, or wanting something to be tangent to a circle. That is how every professional CAD package I've ever used works.