CAD has needed a proper code-first workflow for years. The existing options always felt like they were built for the GUI first and scripting was bolted on after.
I disagree. Most CAD is inherently visual. These code-based systems work great for highly parametric and regular objects like fasteners and gears, or for procedural art, but those are really the tiny minority of CAD tasks. Most of the time you need to see what you're doing and click on stuff.
Most CAD is more similar to graphic design, painting, etc. You wouldn't expect a "code first workflow" for Illustrator, and as far as I know nobody has ever successfully done anything like that.
The closest I've seen are things like UI design tools that can generate code. But a) they usually suck, and b) that is a much simpler problem than CAD.
GUI CAD is fine for freeform work. For parts that live in a repo and share dimensions with other parts, code wins because you can diff changes and change one number without replaying a pile of clicks six months later.
Yeah that would be amazing, but sadly nobody has made that work for any CAD of reasonable complexity.
In reality, CAD version control is done just like assets in the artistic world (game design, animation, films, etc): with file locks.
I used to work for Dyson. There's no way you're designing a vacuum cleaner with code-based CAD. We used TeamCenter (which is probably the worst software I've ever used, but for unrelated reasons).
It does but the internal state is not going to be very meaningful in text form. Edge 4826 connects to vertex 7264.
Think about SVG - you can do some simple stuff procedurally but you're never going to create something like the SVG tiger in code, nor would it be remotely useful to read the source SVG for the SVG tiger. Most CAD is like that.
Housing policy fails because everyone is playing a different game. Zoning boards, developers, homeowners and renters all have completely different incentives and nobody is solving for the same outcome.
PLG only worked when the product could sell itself to a team without procurement getting involved. That window is closing fast and everyone pretending otherwise is about to have a bad year.
Why is the window closing though? Because the prices went up? Or companies have to demonstrate belt-tightening? Or the AI mandate has teams building their own saas?
There's several aspects. For one, I don't see teams building their own SaaS even with AI. Companies buy rather than build to avoid significant operational and maintenance burdens as well as transfer risk and liability to a third party. AI does not change that calculus.
What AI instead is enabling a shift from Software as a Service to Service as a Software. In other words: SaaS is dead, long live SaaS. Most vendors in SaaS started because software is high margin and has limited scaling costs. But as they mature, they find clients also want guidance, professional services, and clear outcomes. This is part of the rise of the Forward Deployed Engineer (FDE) as a formal role. So it's not enough to sell the software, you also now to have sell how to use the software and what transformations are possible using the software. Essentially you can sell software to an individual but you sell transformations ("value alignment") to teams, divisions, orgs.
Another is that inference will become more expensive rather than cheaper over time. The capex spend on data centers has to be paid back by someone. This is the standard Silicon Valley playbook. Start cheap, gain marketshare, operate as a cartel, and then massively hike prices (i.e Uber, Airbnb...). So vendors (even if they operate with value-based pricing) still have to protect their inference costs will see more value from going upmarket early with larger contract deal sizes
TL;DR
Companies will still buy SaaS but a new variant -> services and outcomes rather than purely software. This coupled with increasing inference costs means value alignment will more likely require a negotiated conversation than a 1-click purchase
Thank you for taking the time. Your dot-connection ability is well honed.
This is particular apt for me as I switch from employment from product consumer tech to a smaller-scale sales-led company.
What's your take on the forward-deployed engineer setup in the mind's of the startup as a long-term, viable/lucrative model? I've always heard the warning for tech startups to avoid the traps of becoming a consultancy.
That warning is still valid and prudent. Consultancies are highly customized one-time engagements that do not easily scale. Startups prefer to have long-term relationships built on useful software.
The difference of customization vs. implementation which is where the role of the FDE shines. A consultancy builds something specific for a customer whereas a startup builds general purpose software. The FDE can then act as a force multiplier in educating the customer on how to use the product to its full potential.
Essentially as AI is making software more commoditized (i.e, there's a billion notetaking apps for example), the ability to sell a solution and outcome that solves individual customer pain points while still supporting a unified product experience serves as a differentiator moat. If every platform in the market offers the same features, you'll go with the person that offers the best hightouch sales experience. This is why over time as startups scales, opex switches from eng to sales and marketing.
reply