This take confuses the value of a project at inception with its value at maturity. Vibe-coded projects are at the beginning of their life. When Slack was at a comparably stage, it similarly didn't have hundreds of engineers running it. So the question facing vibe coding is not whether it can substitute for a mature tech product. The question is if vibe coding can substitute for genuine engineering expertise at the very beginning of a budding, immature project.
In the long run there is no alternative to really reading your codebase and understanding what is going on. You can leave the nitty gritty details to the LLM but you have to be in the drivers seat and know how the parts of your codebase works together. You have to be the architect and can leave the plumbing to the LLM, but dont try to make a plumber an architect.
How many projects get to the point where they're at 50 or 100 people online at the same time but fail due to technical issues before they reach 50k? I would say very few. 99% of the time the problem is that they never reach that simultaneous 100 people due to other, non-technical issues like not being a product that people really want. If you've got 50k people wanting to use your product it's a success even if you've got technical problems and it's crashing all the time.
Are these chat apps built with one giant monolithic architecture? Seems like you could spin up isolated copies per organization and your scaling needs would be a lot lower and simpler. Then run everything in k8s with over subscription to deal with the compute overhead waste.
15 comments
https://x.com/paoloanzn/status/2032388364025118757 (https://xcancel.com/paoloanzn/status/2032388364025118757)
just my 2 ct
Are these chat apps built with one giant monolithic architecture? Seems like you could spin up isolated copies per organization and your scaling needs would be a lot lower and simpler. Then run everything in k8s with over subscription to deal with the compute overhead waste.