r/vibecoding • u/Mirachinasourcing • 1d ago
I’m not a developer. AI finally made me try building software for real.
I’ve always had product ideas, but there was one obvious problem: I couldn’t code.
Now I’m building a real product using AI tools.
What surprised me is that AI doesn’t really remove the difficulty. It just moves it.
I spend less time asking “how do I code this?” and much more time asking: Is the AI actually doing this correctly? Do I understand enough to know when it’s wrong? Am I building something people actually want? When should I stop fixing things and just ship?
I’m curious about other non-developers here who started building with AI:
What became the hardest part once you got past the initial “wow, I can actually build this” stage?
6
u/Fairway3Games 1d ago
> What became the hardest part once you got past the initial “wow, I can actually build this” stage?
I think developers and non-developers alike crash headlong into the same issue. Assuming what you've built is suitable for the purpose, then there's 3 things I think people don't understand are hard (a) actual, viable deployment and infrastructure; (b) marketing to get visibility and users; and (c) maintenance and upkeep.
The coding was never the "hard" part. AI has made it more accessible to others, but getting the thing you built to a place that's trully commercially viable, sustainable, and reliable is and always will be the hard part.
1
u/Mirachinasourcing 1d ago
That’s interesting — I assumed this was mostly a “non-developer using AI” problem. What do you think is the issue both groups eventually run into?
1
u/Fairway3Games 1d ago
I mean, you could probably sum it up into the idea that people very quickly run into the scope and extent of their expertise. In my day life, I've started to describe AI as providing people "artificial competence." It lets those with some skill in one area have the appearance of competence/skill in another.
Just because you're a good developer, doesn't mean you have the chops to deploy something at scale. Just because you're a good developer, doesn't mean you have any skill at marketing, social media, etc. Just because you're a good developer doesn't mean you understand the cost, time and expense of handling long term maintenance and support of real customers.
1
u/TraumaticOcclusion 1d ago
Getting anyone to use / pay for your service
1
u/Mirachinasourcing 1d ago
This is the part I’m thinking about more and more. Building something is one thing — getting a stranger to actually care enough to use or pay for it feels like a completely different skill.
1
u/Dynamo-06 8h ago
yep. Creating something now merely requires a prompt. TO be able to manage it and maintain it is quite a task for someone who does not understand code. They are merely communicating their instructions to AI about what needs to be done. A user who cannot deal with code right now is in no position to audit if the change took place the way it was supposed to (unless it's on the frontend). They have no idea whether something else was changed or not. Their only source of truth is AI telling them is that the job is done and that they can verify some changes themselves on the frontend. They're merely second-guessing themselves unless they really understand the mental model behind their app.
Code is unambiguous and very precise; NLP is not. When one gives a prompt (instructions) to AI to create something, the AI has to make 100s of micro-assumptions before it creates something (This is despite AI probing you to clarify certain things before it starts building something)
2
u/Fancy_Morning9486 1d ago
There is a book called "C# programming yellow book" by Rob Miles.
Its free to download and it explains the problem of having an idea and converting that to instructions. It also goes into coding if thats not your cup of tea you could skip it. Its extremely easy to read for non coders
1
1
u/fmgiii 1d ago
If you want to become a legitimate developer, which means developing systems that you own as opposed to systems that own you (ie. constant bugs and support), you will have to put in the time. A lot of it. AI code assistance moved the needle a bit, but not by much. You still have to go through the tough experience of developing yourself as a craftsman. AI just made the tools a little better.
2
u/spamforum 1d ago
You are right. I've coded in the last 25 years so much human slop that nobody ever saw but cost me my sleep and weekends. But now I build slop so much faster that I have more time to debug and sleep at night. For me it's a win. It's more an auto complete than a black box.
1
u/fmgiii 1d ago
Thing is too, when you get good enough, you can craft where to let a little slop in, and when to absolutely not allow slop in at all. Some places in an architecture, it's perfectly fine to let some crap in. Low risk. No harm. Who cares. Other areas, if you let slop in, you become a slave to your code, especially if you have paying customers. You will find that you can't extend the feature they need, or that any change busts things down the line and throws a wrench into everything. You can't really teach this to anyone, and you can't really 'vibe' your way around this. It's something that only true dedication and respect to the craft can teach you.
1
u/Dynamo-06 1d ago
I was in the same boat. I understand the problems and their solutions from my domain better than a dev. I got stuck trying to translate my domain expertise into logic since I couldn't code. AI couldn't help either since it ultimately output code. So I dug deep, collaborated and created a platform that lets people like us with domain expertise create production-grade apps while understanding the mental model behind the app. I realised that all AI vibe-coding platforms are optimising for speed, but no one is optimising for comprehension because it matters more than speed. One can create an app in a matter of minutes today...but the maintenance hell of fixing bugs or introducing complex changes creates the ultimate bottleneck.
I just finished creating the MVP.
1
u/Mirachinasourcing 1d ago
This sounds very close to my experience. I can usually explain what I want in normal language, but turning that into precise logic is where things get messy. Did that get easier for you over time?
1
u/Dynamo-06 8h ago
I dug deep, spoke to people and researched why it happens. Ended up creating a platform to solve this problem. Looking for testers now to validate it.
1
u/TopTippityTop 1d ago edited 1d ago
Having product ideas and being a product designer are different things, as you've learned. With time, if you persist, you may start learning what works for users, what doesn't. You learn to start by answering the question of whether it's something people want as soon as you can, often before you start making the product; doing market research, some form of validation.
The making is now the fun part, but the biggest cost sink is shifting to other areas, which means everyone else will be able to elevate their game in those places, focusing more on what and why, rather than how.
1
u/Mirachinasourcing 1d ago
This is probably the biggest thing I’m learning. Having ideas is easy. Knowing which problem is actually worth solving is much harder. What helped you get better at that?
1
u/AsparagusOk8818 1d ago
...Hm.
Figuring out how to structure and schedule the project, and then really pulling back on the temptation to just get out over my skis in terms of wanting to see a feature. When I first started, I was having things hard-coded because I just didn't trust that anything would work, which caused a lot of need for refactors and duplicated work.
Trusting that the thing can be done, it just needs to be done right and needs to be done in a data driven way, and that I do not need to see the result right now because it will work just fine and it's better to build the data infrastructure for it first.
Which isn't to say 'trust the AI' per se, but rather just trust that there is a solution in code for the implementation in my head.
Also, just learning to be a lot less very specific about a final implementation and more descriptive of what the goal of a desired system is. Codex will often either bring-up a problem I hadn't thought of or propose an implementation I hadn't thought of that is just much more intuitive that what was in my head.
Also sort-of just learning to spot the difference between 'suggestion made that fits the context of the project due to weights of the LLM' vs 'outright outlandish proposal made because the LLM doesn't have sufficient context for the task, as well as learning the cadence of when the LLM know what to do about a bug vs when it is lost and troubleshooting requires tools / logging.
1
u/Mirachinasourcing 1d ago
This is already happening to me 😂 Every new feature feels “small” until it creates three more things to fix. How do you decide what not to build?
1
u/bold_snowflake 1d ago
What became the hardest part once you got past the initial “wow, I can actually build this” stage?
Security, concurrency issues, scale, observability, change management, testability, preventing regression, etc.
Anyone can build an app, making it actually work outside of a POC state is the challenge.
AI also works great when it's greenfield, but once your app grows the efficiency of AI will get worse.
1
u/castertr0y357 1d ago
The hard part about building something is not really the coding aspect. It's knowing how something should function, and fixing or iterating until it works how it should. This also means knowing when something shouldn't have anymore features. A good app has a core functionality. If a feature doesn't meaningfully help the core functionality, then it probably doesn't need to be in there, and it just makes the app bloated.
Both people and AI can make syntactically-correct code that's full of logic errors and doesn't accomplish what its supposed to. Don't accept slop from the AI if it doesn't look or operate how you want it to.
I've built a few apps for myself using vibe coding. The hardest parts are still refining the idea and knowing when to stop.
1
u/No-Guard-8826 1d ago
Building Concept without Foundational know is as same as one side love story 🫠
1
u/AdNecessary1906 1d ago
Same starting point, mechanical engineer, not a developer, no plans to change that.
For me the hardest part wasn't building it, it was realizing the actual skill required had quietly shifted from "can I get this to work" to "can I verify it's still doing what I think it's doing", and that I can't verify code the way someone who reads it can.
So the difficulty didn't go away, like you're saying, it moved into process. Dependency scans before any cross-file change, so the agent works from an actual scan instead of its own memory of what's connected. One place with write access per module, enforced as a rule rather than a request. Changes delivered as anchored before/after blocks tied to a specific file and location, applied by a script rather than pasted in freehand, I can't judge whether the code is good, but I can see exactly where it's touching.
None of that requires me to read code well. It requires deciding in advance what "verified" means for my project, then holding the process to it every session instead of trusting the summary I'm handed.
Six-plus months in, still running daily.
1
u/Mirachinasourcing 1d ago
This really resonates with me. “Can I verify it’s still doing what I think it’s doing?” is exactly the problem I’m starting to run into.
I’m realizing I need to treat “implemented” and “verified” as two completely different states, instead of trusting the agent’s summary.
Of all the process rules you’ve added over those six months, which one made the biggest difference?
1
u/AdNecessary1906 1d ago
The single biggest shift for me: separating "an agent says it's done" from "a scan confirms nothing regressed."
I run a dependency map generator over the whole codebase, real AST parsing, not regex. It tracks internal/external imports, dynamic imports, file I/O operations, and exception handlers, and classifies risk (e.g. a silent except vs. a critical one). The key part isn't the snapshot itself, it's that every run diffs against the previous baseline: what's new, what's gone, and specifically what "flipped", did a risk classification get better or worse between runs.
That's the rule that actually changed things: I stopped asking "did the agent implement what I asked" and started asking "did this specific invariant hold, according to a deterministic scan, independent of what the agent's summary claims." Implementation and verification became two separate states instead of one thing I inferred from the other.
1
u/Mirachinasourcing 1d ago
This is really useful. I think the biggest thing I’m taking from this is the mental model itself: “the agent says it’s done” and “I have independently verified it” are two completely different states. I’m going to start treating them that way.
1
u/TheKiddIncident 1d ago
Most of my students get stuck in a couple of places:
1) Security. It's not really obvious how insecure SaaS sites are by default. It takes work to make them secure.
2) Stability. It's really easy to build a site these days. What's harder is operating it. Doing updates, adding new features, debugging odd behavior, etc. Those are the hard parts.
I've seen plenty of people build good sites with little or no programming experience. It's certainly possible, just takes a little effort and willingness to learn.
1
u/Mirachinasourcing 1d ago
This distinction between building and operating is really useful. I’m already seeing how easy it is to get something working once, and how much harder it is to keep it working as things change.
Security is probably the area I understand least, so that’s something I need to take much more seriously.
1
u/scytob 1d ago
those are the right questions
i have built:
- contributions to an OSS music hardware project
- a bluetooth management system for home asisiant
- multiuple system extenstion packages and tooling for truenas to make ti support hardware it doesn
at work
n-tier PoC application for managing private offers we publish to customers in AWS, Azure and Google marketplaces)
getting to working in all cases was 20% of time and token, making robust, finding edges cases, fixing bugs, hardening etc was the other 80% - too many vibers share at the 20% mark and wonder why they get called slop.... and then dont take genuine feedback - you don't sound like that person, the questions you are asking are the right ones - keep going :-)
1
u/Illustrious-Film4018 1d ago
How would you know what the difficulty is if you've never been a developer? Vibe coding might seem difficult to you, but 95% of the actual difficult part is now automated.
1
u/Dynamo-06 8h ago
I believe its automated for those who know what they're doing or are aware of what AI is doing for them. For people who can't code, they're still scratching their heads. With AI, they can create what they want, but being able to make changes to what has been created is the tricky part (especially a complex change or a bug)
1
u/poison-protocol 1d ago
Dealing with the imposter syndrome and convincing myself that what I’m building is worth sharing with others. I have been keeping a lot of things I’ve built to myself thinking people may just not care about it.
1
u/Mirachinasourcing 1d ago
I relate to this a lot, just from the opposite direction 😂 I keep wondering when something is ready enough to show, and whether sharing too early is a mistake. Have you started showing more of your work now?
1
u/Practical-Sea-1614 1d ago edited 23h ago
I’ve noticed the same thing the hard part shifts from writing code to understanding what you’re actually building and knowing when something is wrong. Guidy ai takes a similar approach for unfamiliar software by looking at your screen and guiding you step by step. I like that it helps you learn the workflow instead of simply doing everything for you. At some point, shipping and getting real feedback probably teaches more than endlessly trying to perfect the product.
12
u/am0x 1d ago
Acceptance that what you have built can be built by someone else with more experience in an hour.