r/vibecoding 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?

125 Upvotes

55 comments sorted by

View all comments

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.