this post was submitted on 01 May 2026
99 points (98.1% liked)
Technology
84858 readers
4154 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related news or articles.
- Be excellent to each other!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I never understood vibe coding (or ✨Agentic Coding✨) tbh.
May be I am too stupid, but I think as I code and code as I think. I do not usually formulate a plan before I start coding. I am categorizing architecture as code btw because, for me, architecture involves pseudo-code to some degree .
Even in college, I could never just understand lectures. I needed to write down the formulas and work out the derivations myself to grasp them. I know there are people who understand things right away, but I am not one of them.
So, now, when I see senior developers (which I am not) vibe code green field projects, I am just astounded as to how they manage the architecture + understanding + optimization + maintenance context.
Oh noooo
Ha ha, may be that came out a bit wrong. What I meant is I don't have a complete understanding of the architecture and the structure before I start coding. It is only when I write the first test and the first function that I start noticing the structure and the limitations. I can't think of all the branches where the code might fail unless I start writing and realizing the
elses.This is the mark of a good engineer, don't let anyone neg you for engaging with problems with your whole brain.
To an extent, you can do this with "the vibe" as well, you just have to stay engaged, do lots of reviews (by which I mean, have the LLM review for you and explain what it finds) and when you decide the architecture needs to be revised, do it - in writing. Your requirements and architecture should be "living documents" developed at least a little bit ahead of the code implementation, and if the current implementation is too far removed from your current vision of how things should fit, throw it out and re-implement from the requirements and revised architecture documents. That's one huge benefit of a tool that writes code so quickly, it's much less costly to throw it all out and start over.