> If the core or that app is more than a few thousand lines of code, something is seriously wrong.
That's the thing about vibe-coding: it is not the core, it is the entire app. We no longer make MVPs and release those, with AI we can make directly the app including all bells and whistles, entire progression, not just one level, all the systems around it.
Why? Because if something needs changing, it's just one prompt away. I do think code is fluid now, any choice of architecture can be instantly changed at basically no cost.
Maybe my mind is just finding ways to cope, thinking that I "wasted" thousands of solving coding challenges and fixing bugs, but I do think, for better or worse, that manually coding is gone. Same as we no longer code in assembly anymore. We no longer write C. We no longer write JavaScript. We no longer write TypeScript. Maybe not today, people don't like change, but manually writing or even viewing code will only be done in a few educational and high-performance/risk cases.
1. If what you say is working, you have a working software factory that should be capable of matching the output of dozens of engineers.
What very impressive externally verifiable results have you had with this?
2. If you are working in software with plenty of customers, my strong suspicion is that there are people on your team who are looking at the code who furiously trying to reign in your output.
I make my own software, so no team to look over the code or be bothered by it. I don't even know how "vibe-coding" works in a team environment, because for me now it feels like it's "ideas to app" directly, so dumping by brain/ideas directly into a functional product.
I think this one is really cool[0], will be a free piano learning app. I do have other projects, but they are all at around 80% too, because some systems are shared amongst the projects and have to be finalized too (i.e. now I'm implementing my own transactional/marketing email service on top of Amazon SES, I need it before releasing ultimidi so people can register and receive email confirmations).
> What very impressive externally verifiable results have you had with this?
I notice this weird hostility whenever the topic of AI coding comes up and it's never made much sense to me. If someone told me about their new method for practicing guitar I'd feel like a real tool if I demanded they prove it for me then and there.
People don't owe you their "very impressive externally verifiable results" - /u/XCSme already posted their app in another comment, it looked fine to me.
You've made your ideological position very clear here, you don't need to keep heaping it on.
Sort of, it's more of a heurisric of bugs found so far. There are very rarely any bugs, most of the changes I request are for tweaks/logic changes, not bug fixes. Usually things just work.
Also, I barely tested and kept changing things simply because of this: whatever I ask for, seems to work as expected.
If your average per request in the application layer is say 20ms. Your p50 is probably 10-15ms and your p99 is probably something like 80ms. p99.9 is probably a good bit higher than that.
If your site is highly interactive, everyone using it is going to regularly run into actions that take long enough that they notice them, and it won’t feel snappy.
Let’s say you went all out and wrote the application layer in C with purely static allocation. You could easily see a p50 around 1-2ms and a p99 of 3-5ms. (This is obviously dependent on the app).
Even with an average time spent waiting in the database of 80ms, you’ve already made a noticeable difference.
That’s not even mentioning the biggest impact, which is that you can likely get by with far fewer application servers.
Now does it make even more sense to optimize your queries? Yes. Definitely. But with faster application stack you can start moving more things into the application layer and out of the database which is generally harder to scale.
And if you have or can build endpoints that don’t hit your database at all, those will actually be 10x faster than before every time.
That's because the process to have any chance in the competition to become a doctor is arduous and there's no consolation prize.
If you aspire to work at FAANG and fail you can be a software developer somewhere else. If you aspire to be a doctor and aren't admitted to med school, those years of education, volunteering, shadowing, test prep, etc. are fairly useless.
And even if you succeed, the hours are as bad as can be and the pay isn't much better than FAANG. It's not a logical choice unless you really want it, while software dev is (was?) a great career choice even if you don't care about software.
For all these reasons, a lot of people are filtered out long before applying to med school.
You’re making my argument for me. The percentage of people who are actively trying to get into FAANG but don’t is higher than the percentage of people actively trying to become doctors.
It’s more selective. So comparing FAANG salaries to the average doctor salary isn’t useful. To find something equally selective, you’d need to pick a higher paid subset of doctors.
Here's why that's a silly comparison: the percentage of people on the general election ballot for US President who don't make it is lower than the percentage of people who are actively trying to get into FAANG but don’t make it. Does that mean US President is less selective? Obviously not, because that's the last of many filters for President and there are essentially no filters before "I'll send a resume to FAANG".
In the same way, there are many filters before filling out a med school application.
Anyway I can't see any way anyone could believe the "median software developer" writing CRUD web pages or in-house apps is comparable to the average physician.
It’s called physicians assistants and nurse practitioners. They are essentially exactly what’s you’re talking about. They make less and they have less training.
In most countries that do this training is longer which that total training time is only 1-2 years shorter.
So you’re doing a few things.
1. Moving more training from cheaper colleges to more expensive medical schools.
2. Moving the filter from undergrad to medical school
3. There is no national curriculum in US high schools, so essentially the first 2 years is getting everyone on the same footing. Removing this without changing high school, puts students at poor high schools at an even greater disadvantage.
Many of the programs you listed don’t cut any time off. They’re just a special pipeline program that can help you get into med school.
Of the ones that do save time, most cut 1 year off not 2. And they do it by having students take more than a full time load during undergrad.
It’s essentially the same thing as taking an extra class or 2 every semester so you can finish undergrad in 3 years instead of 4.
I randomly sample 15 of the programs listed there and 14 were 8 year programs. Only 1 had an optional 7 year program (if you were willing to take more than full time load or go to school in summmer). And there were no 6 year programs.
> why I would review 100k's of lines of code.
If the core or that app is more than a few thousand lines of code, something is seriously wrong.
I don’t want to shit on your app. It’s cool. I’m glad you built it. I’ve vibe coded all kinds of toy apps for myself and my kids.
But it’s not strong evidence that code is irrelevant.
reply