The vibe coding workflow.
Describe
Plain English: what should this test do, step by step.
Generate
AI writes the code: Cypress, Playwright, whatever your stack is.
Review
The one step you cannot skip. Does the logic match what you know should happen?
Run and verify
Execute it. Confirm it fails when it should, passes when it should.
That review muscle is exactly what a decade of manual QA instinct already built. Vibe coding just moves where that instinct gets applied: from executing the test yourself to verifying the AI executed it correctly.
Page Object Model: one fix instead of twenty.
Refactoring into a Page Object Model stores each page's selectors and actions in one place, so when a button's selector changes, you fix it once instead of hunting it down in twenty test files. AI tools like Cursor apply this pattern consistently, and it's specific enough that you can verify each change quickly.
Your toolkit: three categories, none require coding first.
| Category | Role |
|---|---|
| AI code partner | Claude and Cursor: generate and explain the actual test code |
| Test execution environment | Where the suite actually runs: Cypress, Playwright |
| Version control home | GitHub: where the portfolio project lives, publicly |
Tests that only run when you remember to run them. Protect no one.
A GitHub Actions workflow that runs the suite automatically on every push. One YAML file, AI writes a solid first draft.
More 2026 job postings ask for Playwright specifically. Once you've built one Cypress suite, porting it with AI's help is an afternoon's work. The logic is already right, only the syntax changes.
Manual vs. automated: what actually changes.
Everything above is the manual path: you steer AI one prompt at a time. The other path is letting AI generate the entire framework from your acceptance criteria. Here's what actually changes between them:
| Hand-prompted (this module) | Generated framework | |
|---|---|---|
| Who writes the code | AI, one prompt per test, you steer each one | AI scans the live app and generates the whole framework |
| Your role | Review every block as it comes back | Review the framework once, as a deliverable |
| Starting point | A blank file and a prompt | Your acceptance criteria |
| What you own | Every line, deeply familiar | Production-ready code, still yours to read and keep |
| Where it fits | Learning the skill, portfolio building | Shipping at work, where speed matters |
The review skill is identical in both columns. The difference is altitude, not responsibility: one test at a time, or the whole framework at once. Either way, you read the code before you trust it.
Build the loop.
Pick one real user flow on any site (product search, a login form, a public demo app). Describe it in plain English, have AI generate the test, review the logic line by line, then run it. Note one thing the review step caught that you'd have missed skipping straight to running it.
The takeaways:
- The mistake to avoid: trusting AI-generated code like a senior engineer's pull request, by default, because of who wrote it
- The right frame: treat it like a junior engineer's first draft on unfamiliar code. Probably fine, definitely needs a real read, and your job is the read, not the typing
- The real skill: reviewing code you didn't write, fast, with QA instincts instead of developer instincts. Not "does it compile" but "does the logic match what the test should actually verify"
- The two paths: hand-prompting builds the skill and the portfolio. A generated framework gets you the same deliverable at work speed. The review stays your job on both
Why it stays your call: AI doesn't know your product the way you do. That judgment is the one thing it cannot make for you.
Check yourself: next time AI generates a test for you, before you run it, read it once and predict what it will do. Then run it. Did it match your prediction? If not, that gap is exactly the skill this module is asking you to build.
This module showed you how to prompt for it.
QA Smith AI just builds it.
Everything in the second column of that table is what QA Smith AI does: a production-ready Cypress or Playwright framework generated directly from your acceptance criteria, grounded in your real app by scanning the live DOM first, ready to commit. No prompting required, no starting from a blank file.
describe('login', () => {
it('logs in', () => {
cy.visit('/login')
cy.get('#email')
.type('user@test.com')
cy.get('.btn').click()
})
})
cypress/ e2e/ login.cy.ts checkout.cy.ts pages/ LoginPage.ts CheckoutPage.ts reports/ selector-report.md cypress.config.ts
The four-step vibe coding workflow
Page Object Model, and the three tools that cover this whole workflow
Why tests belong in CI/CD, not on your machine only
Building a Persistent AI Workflow.
- Why every new AI chat starts from zero, and the fix
- Claude Projects and CLAUDE.md, side by side
- Then: the 15-question certification exam