Vibe coding, done right
Can you vibe-code and still ship clean? Some people say yes if you are careful. Some say no and go back to writing by hand. Some ship the slop and call it the cost of AI. Here is the loop we landed on while building aislop, which lets us vibe at full speed without shipping the mess.
Vibe coding is letting the agent drive, reviewing changes as they stream in, going with the flow. Anyone shipping with Claude Code, Cursor, Opencode, or Codex is doing it. It is genuinely faster. It is also how you end up with a dozen files of useless JSDoc, three different wrappers around the same fetch, and a catch { return [] } on something that should have thrown.
The question is not whether to vibe-code. The question is how to do it without shipping slop. Here is the loop we landed on while building aislop.
The false dichotomy
Engineering has a reflex that treats "careful" and "fast" as opposites. Slow down to ship quality. Speed up to ship fast. The people who say this are usually doing neither. Careful because they are scared. Fast because they stopped reading.
With the right tooling these are not opposites. You can vibe at full speed as long as the guardrails are automatic. If a rule exists, a human should not be enforcing it. The tool should. Your coding agent should have guardrails.
The rules we use
1. Scan before, scan after
Run aislop scan before you start a session and before every commit. The score is a running number. If it goes up, the work is net positive. If it goes down, the agent added more slop than it cleaned up. That is the whole signal you need.
During 0.5 development, one commit took aislop itself from 78 to 71. We looked at the diff. Thirty lines of narrative JSDoc the agent had left behind. Ran aislop fix. Ended at 83. Three commands. No manual comment-hunting.
2. Let the agent write. Let the tool remove.
Do not hand-edit the agent's output. If there is slop, the rule should catch it. If the rule does not catch it, the rule is the bug. Add one. Do not argue with the agent about comment style. You will lose, and you will waste an hour.
This is the feedback loop that makes vibe-coding sustainable. You upgrade the linter, not the prompt.
3. Own your destructive operations
External tools have opinions that do not match yours. oxlint --fix will happily turn const { foo: bar } = x into a syntax error. knip --fix will delete exports that a framework picks up through conventions it does not know about.
In aislop 0.5 we moved every destructive operation in-house. We use oxlint and knip for detection. The actual mutation runs through our own AST engine because we know our edge cases. Yours will be different. The principle is the same. Do not delegate code mutation to a tool you cannot read the source of.
4. Validate against real code, not fixtures
Fixture tests prove the tool passes. Real projects prove the tool does not corrupt. We ran aislop against 25 projects from the backlog before tagging 0.5. Found four bugs. Every one was a destructure pattern no fixture had covered. The fixtures were written by the same mind that wrote the code. Of course they missed the weird cases.
If you are building anything that touches user source code, keep a directory of weird real projects. Run against all of them on every release. It is the only thing that catches the edge cases that matter.
5. Parse-check before write
Never write a file until you have confirmed it still parses. Revert on failure. Always. aislop's fix pipeline runs the TypeScript parser on every output before committing to disk. A broken mutation is silently discarded.
This single rule would have prevented every one of the four GAP bugs external fixers caused in 0.5. They do not do it. So we do it around them.
6. Short commits, big stories
Small atomic commits. The story of what you built lives in the PR description, not in block comments above functions. The PR description gets read once. The block comment gets scrolled past a thousand times.
If you find yourself writing a paragraph comment to explain why code exists, ask whether it belongs in the git history instead. git blame will find it. Nobody reads stale comments.
What vibe coding is NOT
- − Not skipping tests. Tests are the contract. No vibe gets you out of that.
- − Not ignoring warnings. If the tool says "this looks like slop," it is slop. Fix it now, not later.
- − Not "I'll clean it up later." You will not. You will open another branch, the agent will write more slop, and in three weeks the cleanup commit will be bigger than the feature.
The closing
Build the tool that catches your own slop. Then let the agent rip.
That is the whole loop. The agent produces code ten times faster than you. The tool catches the slop ten times faster than you. The throughput multiplier is the composition. Neither side alone is the story.
Try it on your repo
Run the scan before your next session. Run the fix after. Watch the score move. Star the AI Slop CLI on GitHub if you want the next release in your feed.