Ask HN: Is it worth it to build projects from scratch or should I just use AI?
I am a third year Software Engineering Student, is it still worth it to build projects from scratch or should I just use AI (claude, chatGPT, lovable, etc.) to build them for me? I have built plenty of Projects from scratch, trying to learn the ins and outs of languages and frameworks, but it seems like everyone and their mother uses AI to just build stuff for them. So is it still worth it to learn or should I just become a prompt engineer?
9 comments
Why are you building projects? Why are you studying Software Engineering?
If you want a career in software development, it's better to learn, which means writing code. And maybe study AI tools as well because they will probably be part of the job.
If you want a career as a prompt engineer, study that. I'm not convinced this will be a viable path anytime soon, as in the next five years. But what do I know? I'm an idiot on the internet and am surprised as you are by this world.
If you want to build solutions for end users or customers, use whatever tools work for you. The only thing that matters is the functioning software and the technical debt to keep it functioning.
If you want a career in software development, it's better to learn, which means writing code. And maybe study AI tools as well because they will probably be part of the job.
If you want a career as a prompt engineer, study that. I'm not convinced this will be a viable path anytime soon, as in the next five years. But what do I know? I'm an idiot on the internet and am surprised as you are by this world.
If you want to build solutions for end users or customers, use whatever tools work for you. The only thing that matters is the functioning software and the technical debt to keep it functioning.
THink of this way. AI shouldn't detect WHAT/WHY to do, you should. AI should just do the HOW.
One example. Lets say you want to add caching to your application. You shouldn't let AI decide everything on the architecture. Instead, you should dictate to the AI what it should look like. Then lets AI just write the equivalent code.
An example prompt that I would do "Let's add caching functionality. Use Redis as a caching store and lets start with storing these 3 API results in cache".
This ensures that AI only does what you need it to do and not making too many decision on its own. If you let it be too loose, you are giving too much control to AI and will then slowly lose what you are building.
One example. Lets say you want to add caching to your application. You shouldn't let AI decide everything on the architecture. Instead, you should dictate to the AI what it should look like. Then lets AI just write the equivalent code.
An example prompt that I would do "Let's add caching functionality. Use Redis as a caching store and lets start with storing these 3 API results in cache".
This ensures that AI only does what you need it to do and not making too many decision on its own. If you let it be too loose, you are giving too much control to AI and will then slowly lose what you are building.
If you’re gonna do stuff just for the sake of doing stuff..
You should learn software architecture design patterns so you don’t get rekt by having AI “build stuff” because then you’ll end up with “shit” not “stuff”.
Usually you learn that over a period of time when you do actual professional work but now you might have to dive into it immediately.
Start with basics. Use distinct layers. A service layer for business logic that calls a repository layer that deals with only data. Use single responsibility principle so your methods do one thing only. AI will happily jam a bunch of shit into one method.
Once you have some ground game, then you can have AI go crazy because you’ll be able to define some documentation for it to follow. You’ll end up with a sane, testable, and manageable codebase. If you’re smart about it you’ll probably learn a ton too and become far more effective.
You should learn software architecture design patterns so you don’t get rekt by having AI “build stuff” because then you’ll end up with “shit” not “stuff”.
Usually you learn that over a period of time when you do actual professional work but now you might have to dive into it immediately.
Start with basics. Use distinct layers. A service layer for business logic that calls a repository layer that deals with only data. Use single responsibility principle so your methods do one thing only. AI will happily jam a bunch of shit into one method.
Once you have some ground game, then you can have AI go crazy because you’ll be able to define some documentation for it to follow. You’ll end up with a sane, testable, and manageable codebase. If you’re smart about it you’ll probably learn a ton too and become far more effective.
When moving from idea to execution, you can use existing free tools like NextBunny.co a visual UI builder that helps you quickly create Next.js websites. This approach lets you set up a solid base fast, so you can focus on developing the core features of your project. If your goal is to monetize the product, this method saves significant development time.
However, if your goal is to learn and deepen your understanding of frameworks and system design, it’s better to build everything from scratch. This approach gives you a stronger grasp of the fundamentals, valuable especially during interviews, where you’ll often be tested on your coding proficiency and technical depth.
Hope this helps!! All the best!!
However, if your goal is to learn and deepen your understanding of frameworks and system design, it’s better to build everything from scratch. This approach gives you a stronger grasp of the fundamentals, valuable especially during interviews, where you’ll often be tested on your coding proficiency and technical depth.
Hope this helps!! All the best!!
I think that's a question you can only answer for yourself, but if you're talking about skills relative to employment, you probably have no choice but to learn to use AI. I don't think "software engineering" as a skill will even exist in ten years, and not knowing how to use AI will be like not knowing how to use email or the internet, it will just be one of those constants in technological society you have to understand.
That shouldn't stop you from learning or writing your own stuff, though, if only for personal enjoyment and education. Just understand those skills might not be worth what you expect to the marketplace.
That shouldn't stop you from learning or writing your own stuff, though, if only for personal enjoyment and education. Just understand those skills might not be worth what you expect to the marketplace.
Both. You need to know when your AI is bullshitting or hallucinating or just plain producing unmaintainable code.
Build hands-on when the goal is to learn. Let AI build for you —- using tooling you’ve already learned —- when the goal is to use the thing.
Build hands-on when the goal is to learn. Let AI build for you —- using tooling you’ve already learned —- when the goal is to use the thing.
I think the answer, like almost everything in software engineering, is, "It depends."
How well defined are your requirements? Do you need/want a prototype to play around with to get a better perspective on your needs? What scale of project are you building? How novel is what you're trying to build - is it a technical play or is it more a marketing/sales play that just needs some software behind it?
Building prototypes with AI is very empowering. Rewriting large, technical codebases is a recipe for frustration. Shipping lots of "micro-SaaS" products using AI seems reasonable as long as you get value quickly and move onto the next one rather than going deep for years. They might also work well for smaller games.
A lot of people will say that you don't internalize what you've built when using AI. This has the potential to be true, but it doesn't necessarily need to be true. I was surprisingly pleased by how much deeper I thought about functional requirements after working with AI to create a functional spec., then a technical spec. from the functional, then an implementation plan from the technical. AI asked me numerous times for clarification in areas that, on first pass, I thought were clear, but had more issues than I realized. I do not think I would have gotten to as good of results had I just had the AI write code without planning, but there's nobody to stop me from attempting that.
Similarly, being able to build a working prototype in hours, not days, let me realize a lot of other issues much more quickly. There was functionality that sounded good on paper, but, once I got to actually play with it, was no good. This could've been achieved with a no-code solution, but building it with AI got me to effectively the same result without having to learn another tool and then translate designs from that tool into code.
All that said, it is practically guaranteed you will reach a point where, despite best efforts, using AI will result in some excess code complexity that might need to be triaged with a learned mind. The bar for when this occurs is certainly being raised as the tooling and methodologies improve, but it's still there. The more strategies you can employ to stave that off the better.
How well defined are your requirements? Do you need/want a prototype to play around with to get a better perspective on your needs? What scale of project are you building? How novel is what you're trying to build - is it a technical play or is it more a marketing/sales play that just needs some software behind it?
Building prototypes with AI is very empowering. Rewriting large, technical codebases is a recipe for frustration. Shipping lots of "micro-SaaS" products using AI seems reasonable as long as you get value quickly and move onto the next one rather than going deep for years. They might also work well for smaller games.
A lot of people will say that you don't internalize what you've built when using AI. This has the potential to be true, but it doesn't necessarily need to be true. I was surprisingly pleased by how much deeper I thought about functional requirements after working with AI to create a functional spec., then a technical spec. from the functional, then an implementation plan from the technical. AI asked me numerous times for clarification in areas that, on first pass, I thought were clear, but had more issues than I realized. I do not think I would have gotten to as good of results had I just had the AI write code without planning, but there's nobody to stop me from attempting that.
Similarly, being able to build a working prototype in hours, not days, let me realize a lot of other issues much more quickly. There was functionality that sounded good on paper, but, once I got to actually play with it, was no good. This could've been achieved with a no-code solution, but building it with AI got me to effectively the same result without having to learn another tool and then translate designs from that tool into code.
All that said, it is practically guaranteed you will reach a point where, despite best efforts, using AI will result in some excess code complexity that might need to be triaged with a learned mind. The bar for when this occurs is certainly being raised as the tooling and methodologies improve, but it's still there. The more strategies you can employ to stave that off the better.
Build it from scratch so that you can learn the ins and outs of the languages and frameworks, then use AI to help speed things up once you're more familiar with the code. You'll be able to find the places where AI is hallucinating much better once you become a better developer.
I've been building things from scratch for decades and am still building things for production myself (full stack).
I can't really get anything usable out of vibe coding. And when I can even get vibe-coded stuff to run, the security and data schemas are always so laughably bad that I could never release anything.
Now I'm trying to define inputs/outputs (OpenAPI spec, wireframes, etc.) and database schemas myself and have the model fill in the middle using the strictest language I can (usually TypeScript) so that some bugs will come out at compile time.
Regardless, every approach I've taken has required me to be an expert coder, and that's not going to change with LLMs.
I can't really get anything usable out of vibe coding. And when I can even get vibe-coded stuff to run, the security and data schemas are always so laughably bad that I could never release anything.
Now I'm trying to define inputs/outputs (OpenAPI spec, wireframes, etc.) and database schemas myself and have the model fill in the middle using the strictest language I can (usually TypeScript) so that some bugs will come out at compile time.
Regardless, every approach I've taken has required me to be an expert coder, and that's not going to change with LLMs.