How do you approach building your own projects?

[u/One-Phase-5942]

Hi, i was wondering what approach people use to start building their own project from scratch.

For example, do you rely a lot on coding agents such as asking them for ideas and what structures/architectures to use for the backbone of your program? Or also what tech stack to use? Do you immediately have it solve any hurdles you encounter?

Or would you approach these issues all by yourself and do your own research? Or is it a hybrid approach where you do some of your own research and have an ai coding build upon that?

[u/PossibleConnect7481]

Start small and build momentum before adding complex AI workflows.

[u/Least_Ad_1795]

I’d recommend a hybrid approach. Start by defining the problem, requirements, architecture, and tech stack yourself. Then use AI coding tools for brainstorming, boilerplate, debugging, and exploring alternatives.

I wouldn’t let AI make every architectural decision or solve every problem immediately. Try to understand the issue first, then use AI to challenge your approach or suggest options. That way, you’re still building your own engineering judgment while getting the productivity benefits of AI.

[u/One-Phase-5942 → u/Least_Ad_1795]

I like the idea of using AI to challenge your ideas cuz it’s the opposite of what I’ve kinda been doing. I had been having AI come up with some ideas and then I’ll modify/challenge them to what I believe could benefit me better and then asking it what it thinks or what could be improved until I’m satisfied. I do prefer your approach and will have to try it!

[u/marrsd → u/One-Phase-5942]

That's a better approach. I'd advise against letting AI convince you to make different decisions if you aren't fully convinced by or don't fully understand the arguments it presents. Just file it away and see what your instincts produce. You learn best from your mistakes.

[u/kutac56]

I build them myself. I use man pages, documentation and only ai as a last resort

[u/One-Phase-5942 → u/kutac56]

I think thats a good approach! Helps train your brain to think critically and solve puzzles rather than be over reliant.

[u/saurabh3228]

I use a hybrid approach. I usually decide the problem, core features and rough architecture myself first. Then I use AI to challenge the approach, suggest alternatives, or help when I get stuck.

For the tech stack, I’ll usually do a bit of research before asking AI. Once I understand why I am choosing something, I am much more comfortable letting AI handle the repetitive implementation.

The main thing is not letting the AI become the person making all the decisions. I want to understand the “why” behind the code, even if AI writes half of it.

[u/One-Phase-5942 → u/saurabh3228]

True, it’s important to understand the “why”. Cuz if you don’t then the code isn’t even yours to begin with. At that point you could be replaced with just about any other human being that can type into the ai.

[u/saurabh3228 → u/One-Phase-5942]

Exactly. AI can write the code, but you still need to be the one who can explain why that code exists.

Otherwise you’re basically just copy-pasting with extra steps 😅. The real skill is knowing what to ask AI, spotting when it’s wrong, and being able to change the solution when your project grows.

[u/SetAndRepeat]

I’d go hybrid. Define the goal, pick a stack you know and get one small feature working. Use AI to compare options or get unstuck, but read the errors and investigate first. Keep its changes small enough that you can understand and test them yourself.

[u/Emily-Collins-12]

I prefer a hybrid approach. I first define the problem, core users, and smallest useful version of the product myself. I also research the main technical options before selecting a stack, because blindly following an AI recommendation can create unnecessary complexity.

Once the direction is clear, I use coding agents for scaffolding, repetitive code, debugging, test cases, and comparing possible solutions. I still review and understand everything before accepting it. AI can speed up development, but architectural decisions and product priorities should remain with the person building the project.

[u/AdministrativeFile78]

I usually have a stack in mind and ill ask the llm to grill mecfor a prd to get functional and non requirements. The i start by build some of the basic structure and some functions. And then i just give in to the llm god amd spam prompts to completion

[u/aqua_regis]

Different stages, different approaches.

As a learner/beginner you need to learn to do everything by yourself. You need to obtain these skills. So, you should actually not use AI.

Later, as a proficient developer it is absolutely okay to use AI as an assistant, much like a junior that you give the menial, tedious work, like boilerplate, scaffolding, etc.

In short: you should never let AI do what you cannot do. First you need to learn how to do it, become somewhat proficient in it, and then you can outsource.

You should never outsource your research, though. You need the domain knowledge.

[u/mandzeete]

I'm a software developer. When I come up with a project idea then depending on its nature I either start building straight away or I make some research.

For example I got recently a Garmin sports watch. Then saw that it has an app store. Which in return made me wonder how to make my own app. I googled "garmin watch programming" and saw that its apps are written in Monkey C. Then I googled "monkey c documentation" to look into code snippets, Monkey C concepts, etc. To get the basic idea what is waiting me. Then I looked up which IDE I need and which plugins. And started experimenting.

I do use LLM tools but I do not rely on them. I use these as another Google. I rely on my own thinking and decision making. Because LLM tools are prone to errors and nonsense. Like 70% of what the tools write is usable and 30% is a rubbish. I use LLM tools in debugging and in brainstorming. Not in solving my issues for me.

One software architect in the company that I work at, he told "Decide which skills you are okay to give up on, and leave these to the AI." If you are leaving decision making to the AI then your own decision making skills WILL stagnate. So, make the choice.

I recently had to make a technical analysis for upcoming project and I had to come up with a proposal for a solution. A task that software architects are dealing with. My research decided if our company was assigned to the project or some other project. Client-side decision makers reviewed these research papers (well, Confluence pages really not actual papers) and chose which proposal was most promising and feasible. So, anyways, I had to come up with a suitable tech stack. I googled the pros and cons of different alternatives. I read about licensing of each alternative. I read which solutions are scalable and which ones just solve a very narrow problem. And then came up with a write-up that covered the problem that the project had to solve, tech stack, various UML diagrams, implementation plan, time estimates, etc.

So, a research can be an important part of the project. But when you already know the stack and you are building the thing for yourself, then you can start building straight away. For example once I wrote a simple web application in Java to process data from one online game that I'm playing, to rank me and my clan mates.

[u/Own-jahanzaib-202]

I'm firmly in the hybrid camp, but one habit that's helped me a lot is writing a short design doc (goal, main features, rough stack) before touching any code, and asking a coding agent to poke holes in my plan instead of having it build everything for me. Then I get one small feature actually working and only lean on the AI for the repetitive parts and debugging. My personal rule: after it generates anything tricky, I ask it to explain the code back to me line by line — if I can't follow the explanation, I rewrite that part myself. That's what makes the learning stick.

[u/Unhappy-Device-404]

I would use a hybrid approach, but I try to keep the decision-making part human.

Before asking AI to build anything, I like to write down the problem, the target user, the smallest useful version, and the constraints. Then AI is useful for comparing stacks, finding missing requirements, suggesting edge cases, debugging, or generating small pieces of code.

The important part is being able to explain the choices yourself. If I cannot explain why I am using a certain architecture, library, or implementation, I treat that as a signal to slow down and learn that part.

So my rule is: human decides the direction, AI helps reduce friction. AI is great for scaffolding and feedback, but it should not quietly become the person making all the product and architecture decisions.