- I've always thought it was silly my university had an Entrepreneurship major. Starting a company is probably much better achieved by studying something technical or going deep into a problem space and seeing a problem there, not a generic "entrepreneurship" curriculum.
- I think startups starting as side projects was more of an artifact of the early YC days where startups could just be simple software that some engineers built on nights and weekends. Increasingly I feel like the next generation of startups is more capital intensive and requires more time commitment from deeply technical talent. Not in 100% of cases obviously.
"Starting a company is probably much better achieved by studying something technical or going deep into a problem space and seeing a problem there, not a generic "entrepreneurship" curriculum."
I think this is beyond bad.
The #1 thing anyone could ever to do study entrepreneurship is to do 'case studies'.
Liteally just learning/observing how they work - the nature of founding, structure, power relationships, what debt and equity are for.
Learning 'how a VC firm' operates, and indeed how other kinds of investment bankers work is golden.
HBS is almost a glorified 2 years of basic concepts + 'a lot of case studies'.
Learning how IBM, Standard Oil, Apple and a host of companies you've never heard of operate is deeply enlightening.
The 'Naive By Design' approach by the YC people is almost toxic.
There is definitely some insight in it - that 'seasoned executives' are probably worse at starting small companies in many ways, but, understanding why that is is really important. It has a lot to do with risk, the kinds of things CEO's of established companies are good at etc..
It's as absurd as saying 'Don't Learn Nursing By Studying Nursing - Just Do Music and Engineering'.
> Increasingly I feel like the next generation of startups is more capital intensive and requires more time commitment from deeply technical talent.
Would that be more like other engineering fields? An interesting comparison would be aerospace, for example – it took 15 years to build the first A380, and tens of thousands of indispensable technical niches.
I have no idea how you could think a startup is comparable to a project that ended up costing 25 billion dollars to devolop and involved something like 15k engineers. It's began development in 1988 and the first flight wasn't until 2005.
I want to ask you, what do you think a startup is?
I'm a little confused by what you mean with your question? I was trying to ask what features of an engineering discipline OP was pointing towards with his comparison. I wasn't intending to describe what the next generation of startups might look like!
It’s not obvious to me that a “nobody wants this” megaproject by a decades old multinational forced to succeed by government mandate wasting over a decade debating national workshare is a great example of a “startup in aerospace”.
There’s tons of startups making cool fused harnesses and phased arrays and trying to get every permutation of diesel and electric and hydrogen engines certified. Drones and rc aircraft spawn many “built in a dorm room” prototypes for people who don’t value their eyebrows
> It’s not obvious to me that a “nobody wants this” megaproject by a decades old multinational forced to succeed by government mandate wasting over a decade debating national workshare is a great example of a “startup in aerospace”.
It looks like I wrote that in a confusing way! My intention was to ask about what features of the engineering discipline was motivating OP's comparison. Maybe a better series of comparisons would have been...
- the 747 – program conception in '63, delivery in '69;
– the A350 - first sales in '05, delivery in '13;
which I think captures the slow pace, and large dependency chain, of any significant program beyond a revision.
You probably aren't building the next Airbus in a dorm room, but you might build a weird propulsion prototype, simulation tool, control system, manufacturing technique that eventually becomes the reason a company exists
I think side projects still matter, but maybe in a slightly different way now. They don't necessarily have to become the company themselves. They can be how you discover the problem, test an approach, meet the people you eventually build the company with
my prediction is even if open source Chinese models are 90% as good (or even a bit better, which I don’t really believe because of benchmark hacking) enterprises will still pay for Claude / ChatGPT and the harness, integrations, and peace of mind versus using some Chinese cloud.
Enterprise's peace of mind is being able to use the model and not have the US government decide on a whim to block access.
Additionally I may want to run attack simulations which requires the removal of safeguards. My only option is to use an open model I can run on my own hardware.
You think the US can’t, on a whim, decide US companies can’t use Chinese models? They already showed exactly how they would do it - designate it a supply chain risk and say anyone using it can’t be a provider to the government.
For non-US companies, the supply chain risk is probably higher with US models. The US government has already removed access to some models (Fable). IIRC that particular incident also affected US companies.
1. Is your company run by fuckwits? If no: they will not try to trick the US government about whether they are using prohibited models when the government asks. Your CISO will block access. We're done. If yes, continue to #2.
2. Are they the specific brand of fuckwits who would try to trick the US government about whether they are using prohibited models? If no: They will probably still not let you use those models, but maybe they'll be bad at enforcement. If yes: this is probably not the kind of company that it will serve your long term interests to work for, but have fun with the prohibited models.
How is anything enforced on B2G agreements? Contractually & legally, which turns into internal policy, which shuffles the risk on to the rogue dev deciding to use GLM instead of the mandated Grok subscription.
This is literally the playbook they ran for Claude. I know folks who work for government contractors who were immediately going through the evals to get rid of Anthropic because it became a risk for them.
These are open weight models (GLM-5.3 soon too). You can run them on the Together AIs or Firework AIs of this world. Use OpenRouter or HF Inference Providers in between and you can effortlessly switch between models and providers.
I have been using GLM and Kimi models the last few months mixed with the latest Anthropic models and for my daily work there is barely a difference anymore (except for pricing).
On a tech level I’d say that Kimi and GLM 5.3 on Max reasoning are good enough for non-trivial planning and exploration and on High are good enough for various implementation tasks. They can easily replace Opus 5 for me and mostly even Fable (webdev with some ML and DevOps work on the side, as well as local software).
All of that pretty much means nothing for the orgs that just want to do the AI equivalent of picking IBM.
In the real enterprise world companies are running their processes writing Gemini "gems" or using copilot because they were already google/Microsoft customers.
Am I the only one that knows people in industries like insurance, banking, consultancy, materials, etc? Cause none of them gives two damns about what the leading SOTA is, procurement and compliance matter.
what i appreciate most about this post is the level of transparency in how they built and scaled an RL pipeline. my friends at the big labs are so cagey about everything, and Zai is just putting out a great crash course for free.
the wisest lil wayne lyric is "jealousy is love and hate at the same time". often times, a hater is just someone who resents someone's success because they wished they were in that position.
while it's true the model layer is getting commoditized, there is absolutely no way we are migrating any serious enterprise workflows to Kimi work. i think chinese models will continue to have an adoption problem.
