201–210 of 330 posts
[flagged]
Earlier quoted context omitted.
The issue is that before AI, 1% of the population was capable of creating 1 side project per year. After AI, 10% of the population is capable of creating 10 side projects per year. The competition grew by 100x. The pessimist in me thinks that the window of opportunity to create something successful is shrinking.
If the competition just grew by 100x, where's all the great, high-quality, AI-vibe coded side products? Something just isn't adding up here. Could it be that vibe coding on its own just isn't all that useful, and most of those 10% are wasting their time?
If you give an AI a very general prompt to make an app that does X, it could build that in any imaginable way. Someone who doesn't know how these things are done wouldn't understand what way was chosen and the trade-offs involved. If they don't even look at the code, they have no idea how it works at all. This is dangerous because they are entirely dependant on the AI to make good decisions and to make any changes in the future.
Someone who practices engineering by researching, considering their options, planning and designing, and creating a specification, leaves nothing up to chance. When the prompt is detailed, the outcome is constrained to the engineer's intent. If they then review the work by seeing that it wrote what they had in mind, they know that it worked and they know that the system design matches their own design. They know how it works because they designed it and they can modify that design. They can and have read the code so they can modify it without the help of the AI.
If you know what code you want generated, reviewing it is easy - just look and see if it's what you expected. If you didn't think ahead about what the code would look like, reviewing is hard because you have to start by figuring out what the codebase even does.
This goes the same for working in small iterations rather than prompting am entire application into existence. We all know how difficult it is to review large changes and why we prefer small changes. Those same rules apply for iterations regardless of whether it was written by a person or an AI.
AI code generation can be helpful if the engineer continues acting as an engineer. It's only when someone who isn't an engineer or when an engineer abdicates their responsibilities to the AI that we end up with an unmaintainable mess. It's no different than amateurs writing scripts and spreadsheets without a full understanding of the implications of their implementation. Good software comes from good engineering, not just generating code; the code is merely the language by which we express our ideas.
[flagged]
I have my own side project that I vibe coded. I probably did what would take one team 6 montns and produced it myself in one month. I'm not afraid of breaking stuff because it is only a small set of users. However for my own code for my professional job no way I would go that fast because I would impact millions of users. It is insane that companies think they can replace teams wholesale while maintaining quality.
Earlier quoted context omitted.
> Why? Because the bottleneck was never typing code. It was always understanding the problem, making architectural decisions, debugging edge cases, and most importantly - knowing what NOT to build. For me, this is a bit different. Writing code has always been the bottleneck. I get most of my joy out of solving edge cases and finding optimizations. My favorite projects are when I’m given an existing codebase with the…
Fascinating- I've always loved the big picture, architecture, and I've also loved stable software but have one hell of a time fixing bugs. AI helped me a ton with that. Well if you're ever in need for a complementary mind in side projects- huh, how does one connect over HackerNews?
[flagged]
> Why? Because the bottleneck was never typing code. It was always understanding the problem, making architectural decisions, debugging edge cases, and most importantly - knowing what NOT to build. For me, this is a bit different. Writing code has always been the bottleneck. I get most of my joy out of solving edge cases and finding optimizations. My favorite projects are when I’m given an existing codebase with the…
Is this still true?
Earlier quoted context omitted.
Software is not becoming worthless. The value of computers since its inception was that it's capable of transforming data very, very fast and autonomously. But someone has to input that data from the real world or capture it using some device, and someone has to write the rules. What happened is that we created a whole world of information and the rules has become very complex. Now we have multiple layers stacked ver…
Software is just means to an end. Data and data transformation is what people want. Software has sellable dollar value only because creating the software to do the data transformation has had real associated cost. I.e anyone who wanted a particular data transformation had to pay to get the software that does it. When you drive down that cost you drive down the potential value of the software products. Remember that w…
I do agree with you on that point.
> If anyone can create "photoshop" with minimal cost and there are thousands of said "photoshop" apps what will be the retail sell value of those apps. Close to zero.
This is the point that I cannot agree with. Not anyone can create photoshop because of the amount of knowledge you need about the data and transformations that needs to be applied to get a specific result. And then make a coherent system around it. You can create isolated function just fine, just like a lot of people knows how to build a shed with planks and nails. But even when given all the materials and tools, only a few can build a skyscraper or a mansion.
That knowledge of how to create a coherent systems that does something well is the real cost of software. Producing code isn't it.