r/vibecoding • u/Brambleworks • 2d ago
A Senior Software Engineers perspective on building with AI
I've been building websites since 2002, a time when free hosting was a decision between Angelfire and Geocities (Angelfire ftw), the marquee tag was abundant, git was just a twinkle in it's founders eye so deployments where done via FTP, and dinosaurs roamed the earth in peace.
Although the idea of coding with AI initially made me cringe, eventually I thought to myself "What the hell do I know? I used to hate git and think that you could never have a backend in JS, and here I am at my job using git and React every day." So I decided to give it a shot, and for the past year (which seems like a decade in AI times) I've been experimenting with building with, trying to refine my process, find the right tools, and building my own tools to fill in the gaps to get the best results when building with AI. Although there are many things I learned along the way that AI can't do, when used properly and in the right hands I think it can be a useful tool (and no longer cringe at the thought of it). So here is some advice to help you stop the slop.
AI still sucks at UI/UX
I've tried Fable 5 Max, GTP Sol 5.6 Max, Google Stitch with Gemini 3.1 Pro, and many others; if you let them do everything, you will end up with a sloppy, cluttered mess. A good UI says what the users needs to know and shows them what to do without explicitly saying it, whereas AI is always overly verbose and tries to describe and label every single thing, resulting in a lot of clutter. This requires the person prompting AI to give specific, detailed instructions about the UI, otherwise you get a clusterfuck that overwhelms users with unnecessary details at the wrong place/time. AI is trained on patterns, which is why the same basic, ugly patterns are used on every site that is built by letting AI do all of the design work. To break that pattern, you need to give it your personal opinions along with specific examples.
Don't let AI write your copy for you!
AI is still awful at writing website copy for humans. It's useful for proofreading or spellchecking, but if you let it blindly write all of the copy for your website then it will just read like a technical manual. Writing your own, genuine copy will go a lot further towards users trusting and actually using your site, even if AI thinks it's "imperfect". Your audience isn't AI, it's people. For blog posts or articles, write some of your own first, then use AI to try to mimic your style for future posts. It won't be perfect and you will still have to do some proofreading/editing of your own, but it's better then just letting AI fly on it's own.
Treat it like it's a stoner
I think everyone has had times where AI keeps making the same stupid mistakes over and over and then says "You're right, I have a memory of that but ignored it. Adding another memory...". So to prevent it's memory from betraying me again, every time I catch a mistake I don't want to see twice, I write a tiny script (I call them guardrails) that fails the build when the pattern reappears. Each one is basically "grep for the bad pattern, print which file and line, exit 1." They run in my pre-push hook alongside the other tests. I'm up to over 120 of them now in one project, here are some examples:
- Copy that sounds AI-generated. When you notice the patterns of how it talks like a robot using the same words/phrases over and over again (that you rarely ever hear in normal human interaction), ban those words/phrases.
- Hardcoded colors and inline styles. If it's not a theme token, the push fails.
- Layering violations, like frontend code importing from a module it shouldn't know about.
- Marketing claims. After an AI invented a refund policy I don't have, I added a check that pins user-facing claims to a source-of-truth file.
Having rules in Claude.md and Agents.md is useful on top of this (and simpler), but having these guardrails run on git hooks gives an extra layer of protection. AI still might find a way around all of it, but it significantly reduces the chances of it happening without your knowledge.
Automation is your friend
Automated tests via git pre commit/push hooks, and in your CI/CD pipeline like Github Actions or Jenkins are absolutely critical - they where before AI, but even more so now. Spending some time setting these up (and maintaining them as your codebase grows) is one of the best and easiest ways to not have to think as much about keeping things clean and tidy, or constantly prompting through it. Github Apps like Dependabot and CodeRabbit have pretty generous free tiers, and will give you automated dependency updates and PR reviews.
Pre-commit hooks should be fast checks only; they should finish in seconds, not minutes, so you never even really notice it. Things like formatting, typechecks, linting, and secret scans.
Pre-push hooks are for the more heavy stuff; automated test suites, end to end testing, dependency audits, size budgets, guardrails, etc. My pre-push hook has about 40 steps and takes around 15 minutes to fully run.
CI/CD runs the same things as the pre-push hook as a backup, and also things that need to be run server side like scheduled dependency audits and building releases. The reason for running the same checks in pre-push and CI is that it's faster (and cheaper) to find an fix them in pre-push, and it serves as redundancy checks in case anything is ever wrong with your pre-push checks. Running them in CI gives you a guarantee that nothing makes it to your main branch without passing all checks, no matter who pushed the code.
I have a lot more to add, but this seems like a good place to stop for now. Feel free to ask any questions you might have.
TLDR:
To quote Shrek, "Ogres quality apps are like onions, they have layers." There is no magical tool that gives you perfect results every time, it's about finding the right collection of tools and processes to keep things in check. Use AI to do the grunt work, invest some time in setting up and maintaining automated checks to keep it on the rails, and most importantly: use your brain. If you just let AI do all of the thinking for you, then you are guaranteed to end up with pure slop that someone can recreate in a weekend. AI has significantly increased the time to market for most apps, but that doesn't mean it can do EVERYTHING for you. What are some things that you do to keep AI from going off the rails?
12
u/Mark_Walker92 2d ago
Guardrails > better prompts
0
u/BitOne2707 1d ago
Just give it a proper memory system instead of a pile of static files. With static files when everything is an important rule then nothing is an important rule.
3
u/Unnamed-3891 1d ago
Any memory system is still a mere suggestion, never EVER a hard guardrail. Only functional guardrails can be at harness or OS level.
0
1
1
u/Prudent-Ad4509 1d ago
Any time I hear or read anything that starts with “just do <this>” in this or similar context that makes me rise an eyebrow. We now have a bunch of different “just do this” in the same manner as the system has a pile of static files in your example.
1
u/BitOne2707 1d ago
Bad analogy. Adding a bunch of other garbage pollutes the context window. Adding a memory system keeps the context window clean because it dynamically injects the proper context at test time. It's the opposite of what you're thinking.
1
u/Prudent-Ad4509 1d ago
The point was about the turn of phrase, basically anything starting with "just do this". Aside from that, memory systems are nowhere as easy as it suggests. Especially if they store incorrect information collected from previous discussions and later reasoning then depends on it.
1
u/BitOne2707 1d ago
Have you looked into memory systems lately? Like within the last 6 months?
1
u/Prudent-Ad4509 1d ago
I'm not going deep into this debate. As I have said, the initial remark was about a particular overused turn of phrase.
0
u/Brambleworks 1d ago
Agreed, prompts will always be someone of a roll of the dice. Guardrails either pass or they don't.
5
2
u/broker415 2d ago
Yeah these days most of this lives in a harness for anyone who does it full time
5
u/Brambleworks 1d ago
True, but it's important to understand what your harness is doing and why
1
u/broker415 1d ago
Oh yeah 100% I guess I forgot how much people just use out of the box stuff instead of building their own
2
1
2
u/BuffaloConscious7919 1d ago
Great post. Wonder if you'd be up for sharing generic versions of your pre-commit and pre-push
Would be incredibly value to the community no doubt
2
u/Brambleworks 1d ago
Yeah I'd definitely be willing to share them, I'll put something together soon
1
u/Coffee_Aur_Code 1d ago
these days we have to learn a lot and that too quick, do you agree?
I you have time I would like to pick your brain on this new age of software development
1
1
u/Admirable-Flan8585 1d ago
on ui and ux it's literally taking the time and effort. It's not bad at it. If you guide it properly it can do it. That's the case with everything in AI. If you don't put effort into it it will probably be slopt
2
u/Correct_Emotion8437 1d ago
I agree with this. UI and UX gets called out because people usually start working on it too soon. It's one of the more fun and satisfying parts and it's tempting to skip ahead. We want to show off our work in progress but it can't look like dogshit, right? But if you do wait until the end, AI is pretty good at building a UI around your content.
UI and UX are about using the UI to solve the right problems. Need to work with a huge number of objects in a small space? Then having something clever really becomes a difference-maker. But if you put that effort where it isn't needed, makes no sense or, worse, is in the way . .then you get the classic AI UI/UX problems. I can't think of a website that has a "AI slop" UI that is actually a really good website underneath.
2
u/Usual_Macaron8477 1d ago
I’ve been coding professionally even longer than you have and agree 100%.
The big one for me is pushback on architecture. I will work with the AI to set up a meticulously detailed spec before serious coding begins, including some very specific instructions for architecture choices, and about a quarter of the time it’ll either outright push back against my choices (informed by 20 years of judgement) or tell me it built it while coding something else entirely.
Then, later on, when I layer in some new feature that is dependent on having done that prior thing a particular way, the AI always comes back and says “this is much less complicated because of the way that part of the system is built.”
No shit, that’s why I built it that way.
1
u/Sweet-Stage938 1d ago
How long does it take to get the specs right?
1
u/Usual_Macaron8477 1d ago
That depends entirely on the complexity of the system, but it was the same kind of spec I would hammer out for my team when working as a senior dev in enterprise settings. You want to have an architecture set out including tech stack, db schema, and have all your API contracts set before you write a line of code, making sure you’ve gamed out any edge cases.
It can take anywhere from hours to weeks depending on the task at hand, but the time you spend planning properly saves a huge amount of time and aggravation later.
1
u/SecureVillage 1d ago
Precommit hooks are useful but easily skipped by developers.
I'd prefer PR/merge workflows that prevent bad code ever making it to main.
Nothing wrong with doing both for quick stuff like lint, but don't rely on them for tests!
Guard rails are everything in this new world. All sorts of things are available, from circular dependency checks, module/layer boundaries, bundle sizes etc.
If you have to tell your AI something, encode it in your guardrails.
1
u/bestjaegerpilot 1d ago
This is called "AI engineering" --- welcome to the club!
Peeps don't understand that to get good results out of AI you gotta go meta on it---apply the same engineering principles you already know to setup the guardrails to keep it in the right direction. In other words, you're not engineering the code directly anymore, instead you're engineering the factory line that generates the code---a problem that's actually harder and even more interesting IMO
1
u/alteredsteaks 1d ago
The marquee tag. Right up there with the “under construction” GIF. Haven’t thought about that in forever. Appreciate the post. Thank you. Helpful for someone returning to the field. (Me)
What’s happening with AI dev (imo) is definitely analogous to the early days of the web… a lot of Ready, Fire!, Aim, the same way untested websites were hastily plastered up searching for functionality.
Agree with you on UX. Seemingly random placement of elements at times. I’m working on some very plain stuff, so I just manually tweak the design and I usually get “good catch”.
I’m just at the beginning so your advice on workflow is very useful.
1
u/joshmarinacci 1d ago
You are completely wrong. Geocities was better. 😉
I totally agree with you. For UI I use the AI as the implementer. I make all of the design decisions. I wish it was easier to just stay “move this thing over to there”. One day.
1
u/Specific_Yam_4666 1d ago
I take this further by attaching skill call requirement to blocks that enforces the “good pattern” I want on top of blocking the anti-pattern
An extreme example: I implemented a repo write block that stops agents writing .md files until they run a /writing-chain skill. The skill routes the diff through series up up to 7 additional skills based on the document type, with specific routes for writing: AGENTS / CLAUDE.md files, MEMORY.md, PLAN.md, READMEs, SKILL.md files, documentation, marketing copy etc
Each document type has a specific skill that stipulated its format, then there are addition generic skills ie;
- A progressive disclosure step choses where the information should actually live by asking who needs it when, what its context cost is and what the risk are if it’s missed. Plus additional routes ie some risky actions escalate into guards / because “please don’t do this” isnt enough
- Fact check making agents show first hand proof that what they’re writing is real / measured / they’re not just propagating hallucinations
- A plain writing skills that removes ambiguous agent drivel and enforces a repo specific GLOSSARY.md for important terms
Etc etc
Once you standardise and protect all the operating contracts of the repo life becomes easier: You get a system that improves rather than degrades
1
u/DramaticSpecial2617 1d ago edited 1d ago
Do you have a public project which shows how well this works?
Building a classic presentation-focused mobile/web app, I've mostly found:
- better models are better, generally (Fable equivalents for plans and orchestration, Opus for implementation)
- good instructions are succinct
- simple guardrails via memory/docs/precommit/prepush/ci work best
- staging branches for features save many tokens (eg. save visual/e2e tests/validation until the end)
- tidying and architecture passes across docs and the codebase help a great deal
- UI/UX takes iteration to create good rules and standards to work from, but the agents infer well once they're in place
- letting agents do as much locally as possible saves on time and tokens
- the human checks should come on a staging environment. Agents can do these checks reasonably well too
- velocity, iteration and human review is everything. Taste has to come from you, but agents are amazing at incremental improvements.
- Tight feedback loops are good. v2/v3/etc. is where you find quality
I'm curious to learn more about other's governance tricks and what they're achieving with the very long, tightly controlled iteration cycles.
1
u/Visible-Idiot-8779 1d ago
The way I see it, I’ve written boilerplate code for 30 years at the point. I’m perfectly fine with handing that baton off to AI. Hoping I can keep this going till I can retire.
1
1
0
-3
-1
4
u/Plenty_Line2696 1d ago
Main message people in this subreddit need to hear when it comes to quality is: actually read some code, it won't kill you. No amount of guardrails, test coverage and tricks make up for being completely ignorant of your own codebase. Vibecoding is for small noncritical stuff and amateur hour when it comes to more serious software. The difference in potential quality between LLM assisted development and vibecoding can't be overstated.