menu
Developmet Rant

Developmet Rant

Backer ●3 ●15 ●49
calendar_today • schedule1 min read

As a lot of you know, I am not a developer, nor will i ever claim to be one, but I have been Vibe coding a lot lately and the one thing i now understand is how when you go to do one chage it sprials to a whole other subset of problems that you spend a week on trying to fix before you can even implement the change you wanted to in the first place.

Now i have created 4 subagents and after code change and update they all audirt different pieces, pipeline, design, security, and secrets, and maybe this is just me being over zealous and wanting thisgs to be good (not perfect) becuase as an engineer i see the upstream and downstream of this form my lens and need to make sure i dont break anthing in either direction so audits are needed.

But why cant what you think is a simple change take you two weeks and still be at the same spot you started at but with a lot more work.

Is it becuase I dont know what i am doing or something else?

12 Comments

•

A) When you vibe-code, you don't have the mental model of the codebase. If you don't have a mental model of the codebase, you have zero way of assessing the complexity of any change.

B) There is a famous software engineering rule - First write the code to accommodate the request you have now, then refactor it so it can be easily extended with the tomorrow requirement. Your agent doesn't know what the next requirement is going to be. Therefore, even if it was capable of meaningful autonomous refactors, it would not be able to do the correct refactors. And these boil down to recognizing the patterns for application of correct design patterns.

C) Even when you can nail the points A and B, there often come requirements that are simple by themselves, but go against how the project was architected so far and therefore require drastic changes.

2 votes
•

@[Jakub Neruda] this a is correct. I have put a lot of things in place to let it know the wants the design lock, the backend and stack and sub agent instruction so I think I have a chunk of what you mentioned but not all. And you are correct not knowing the code base does limit that. It is also why I did a full audit and had it give me a full report of everything that would be affected by the change and its estimated complexity level. It said this change was extreme difficulty so I decided to choose pain rather than ease.

0
•

Visualizing the system structure (what goes where and how data flows) is an absolute game-changer for me during refactoring. It helps break down big, intimidating goals into rational, step-by-step tasks instead of getting lost in the cascade.

But honestly, no matter how deeply you know your own codebase, any architectural change naturally ripples through the system. And yes... it hurts even more when you realize that this cascade of refactoring was caused by your own past decisions! 😄

The fact that you set up audit sub-agents and ran a full impact analysis shows a high level of responsibility, whether one calls themselves a developer or a vibe-coder. Audits and some level of friction are just part of the engineering process when you care about the output!

2 votes
•

@[kate8382] well I'm glad I'm not the only one. As for the auditors, I had to build something because I need something able to look at everything. I do this well in my job but development and systems engineering are 2 different beasts all together.

I always try to start at 30000 ft then start to widdlsectiins down. The one saving grace is being able to ask if I do x will it break anything, dry runs have saved me more times than not.

1
•

@[kkierii] Does it actually save you though? 😂 Because no matter how systematically or thoughtfully I plan things, something ALWAYS finds a way to break!

My package.json is practically 50% --dry-run scripts at this point (from test runs to case normalization), and yet the codebase still manages to throw plot twists at me. I guess dry runs don't prevent the chaos, they just give us a polite heads-up before the explosion!

1
•

@[kate8382] they definately don't prevent chaos and then throws you down a path for a week on something unrelated. I still haven't been able to implement a simple change becuase of the cascading issues. I'd rather take the time now and deal with it before it's fully live than to deal with it when it get busy and I can't fix on the fly. It also helps too that I host it in my server stack at home so I am not burning cloud costs.

1
•

@[kkierii] Smart move with the home server setup — saving cloud credits while fighting refactoring dragons is definitely the way to go! 😅 And fixing it now before production is 100% the right call. Good luck with taming that cascade!

0
•

By the way, that cover image hits the bullseye! The only thing missing is a brick wall with a bloody forehead mark from hitting it repeatedly during the debugging process. Perfectly captures the refactoring mood! 😄

1 vote
•

@[kate8382] how did you see what my office looks like 🤣

1
•

@[kkierii] I didn't need to see your office — I just looked at my own room! We all share the same invisible wall with the exact same forehead prints on it. It’s the universal engineering decor! 🤣

2
•

It is not just you. The cascade you are describing happens because the agent does not hold a coherent model of your standards. It fixes one thing in a way that violates an implicit requirement you never stated, which creates the next problem, which creates the next. Your four audit subagents are a smart workaround for catching downstream breakage, but they operate after the fact. The upstream fix is making sure your agent actually knows what you care about before it touches anything. This is the core idea behind the impression management process in Opportunity Skill, where your agent distils your working preferences and quality standards from your daily interactions into structured signal. The same principle applies to code collaboration. An agent that has observed you reject sloppy typing fifty times will stop generating it, and the cascade gets shorter.

2 votes
•

@[QuestMeet] this is great advise. I did create several md files as well. I have a design lock file a want file and a few others I can't think off hand that help with the goal of the project but I guarentee it needs to be better defined. I was also advised to also just have it implement all of the features first then refactor and audit so it audits all the changes rather than one at a time. As an engineer I don't like building things out then auditing since in my experience it becomes a lot larger of a project.

I will use some of your suggestions becuase they are some things I didn't even think of. This was some great info.

0
🔥 Join developers growing publicly
Share your knowledge, build in public, and grow your developer presence with a global community.
Join CoderLegion

More Posts

Cyera: Non-Human Identities Grew 480% in Six Months. Most Companies Have No Idea What They're Doing.

Tom Smithverified - Aug 3

From Prompts to Goals: The Rise of Outcome-Driven Development

Tom Smithverified - Apr 11

Gemini 4 Argon for Builders: What to Check Before You Put It in Your Agent Stack

alessandro_pignati - Oct 19

Picking an AI Gateway Without Regretting It Later

alessandro_pignati - Oct 12

Your Backup Data Knows More Than You Think. HYCU aiR Is Finally Asking It the Right Questions.

Tom Smithverified - May 14
chevron_left
Kerry Kierverified
3.5k Points • 67 Badges
California, USA • blog.vertexops.org
16Posts
27Comments
73Connections
Systems engineer working in public safety, focused on infrastructure that has to stay up when it mat... Show more

More From kkieriiverified

The site is live: The Known Good

Stop Saying Vibe Coding is Easy

Been MIA for a Bit

Related Jobs

View all jobs →

Commenters (This Week)

4 comments
1 comment
1 comment

Contribute meaningful comments to climb the leaderboard and earn badges!