If your whole AI coding workflow is: open Cursor, describe the ticket, hit generate, open a PR — you are using maybe 5% of what the tool can do.
The other 95% is everything that keeps production calm: requirements that don’t lie, edge cases PM actually signed off on, decisions written down, and proof the change is safe before merge.
Treat the model like a coworker, not a vending machine for diffs.
Try the ship loop: kramlipi.com · Get started · VS Code extension
The vending-machine trap
Most teams adopted AI assistants to go faster. Fair.
But “faster” often collapsed into one step: turn the ticket into code. That skips the work humans still get paid for — and the work review queues drown in when it is skipped.
| Vending-machine AI | Coworker AI |
|---|---|
| Ticket → generate → PR | Spec → gaps → edge cases → doc → generate → understand → verify |
| Review becomes archaeology | Review checks judgment, not basic completeness |
| CI red on Friday | Same verify command green before merge |
| “LGTM” on code nobody read | You can explain every line you ship |
The bottleneck moved. It is not typing. It is proving the change is safe — and understanding what you merged.
Step 1 — Brainstorm the spec (before any code)
Paste the ticket. Then ask the coworker to interview you:
- What is in scope vs explicitly out?
- What did the ticket assume that is not written?
- What breaks if we ship the happy path only?
- What would a skeptical senior ask in review?
Example prompts:
Here is the Jira ticket. List assumptions it makes.
For each assumption, say what question I should ask PM before coding.
Do not write code yet.Turn this into acceptance criteria I can verify with tests.
Mark anything ambiguous as BLOCKED until PM answers.Output you want: a short spec with open questions — not a diff.
This is where AI for requirements pays off. One hour here saves three review cycles later.
Step 2 — Edge cases — verify them with PM
AI is good at being annoying in a useful way: it will list edge cases you would have remembered at 2am in prod.
Workflow:
- Ask for edge cases by category (null, empty, auth, idempotency, rollback, concurrency).
- Turn each into a one-line “what should happen?” question.
- Send that list to PM (or paste in the ticket). Get answers in writing.
- Only then promote items to test ideas.
Example:
Feature: refund partial order when one line item is cancelled.
List 15 edge cases. For each: expected behavior + suggested test name.
Flag any that need PM decision.Do not skip the PM step. Generated tests for the wrong behavior just automate the bug.
Step 3 — Document why this shape (not just what)
Before you hit generate, write (with AI help) a decision note — five bullets is enough:
- Why this approach vs the obvious alternative?
- What are we explicitly not doing?
- What will we regret in six months?
- What file or module owns this behavior?
Put it in the PR description, ADR, or .code-agent/review-guidelines.md if your team uses org standards.
Reviewers stop re-debating solved questions. Future you stops hate-reading git blame.
Prompt:
We will implement [approach]. Draft a 5-bullet "why this way" for the PR.
Include one tradeoff we accept and one we rejected.Step 4 — Now hit generate (Cursor / Claude / Copilot)
Code generation is step four, not step one.
You have:
- A spec with fewer hidden assumptions
- PM-backed edge cases
- A written rationale
Now the assistant produces code that matches intent — not a plausible first draft that looks done.
Tips that still matter:
- Generate in small slices (one file / one behavior) when the change is risky.
- Ask for tests alongside implementation, tied to the edge-case list.
- Prefer “show diff plan first” on touchy modules.
Step 5 — Don’t ship what you don’t understand
If you cannot explain a block, select it and ask.
In Cursor or VS Code: highlight the code → chat → “Explain this like I’m on call tonight.”
Questions worth asking:
- What breaks if this input is null?
- What caller depends on this side effect?
- Is this assignment or comparison? (Yes, still happens in AI PRs.)
- What test would fail if this logic is wrong?
Understanding is part of the job. “The AI wrote it” is not a merge strategy.
If explanation reveals a smell, fix or reject before review — do not offload comprehension to the senior on the queue.
Step 6 — Review and green CI (the coworker loop doesn’t end at commit)
Coworker workflow still needs a floor on the diff and a ceiling on proof:
| Layer | Job |
|---|---|
| You + AI | Spec, edge cases, docs, code you understand |
| First-pass review | High-signal comments on changed lines |
| Verify gate | Your test/build command exits 0 — not model claims |
| Human | Product risk, architecture, merge |
Comment-only bots help step two. They do not make CI green.
That is why teams that only “use AI to write code” still lose Friday to red GitHub Actions — review passed, verify failed.
A practical week (copy this rhythm)
Monday — spec coworker
- 20 min: ticket → assumptions → PM questions
- Block coding until BLOCKED items are answered
Tuesday–Wednesday — build
- Doc note → generate in slices → select-and-explain anything fuzzy
- Run local verify early (
pytest,npm test, …)
Thursday — PR
- First-pass review on the diff
- Fix or respond; do not merge on vibes
Friday — not archaeology
- If CI is red: repair until same command as pipeline is green
- Draft PR for human merge — not silent auto-merge
Who this is for
- ICs using Cursor / Claude / Copilot daily who want fewer review ping-pongs
- Tech leads tired of AI PRs with no spec and no tests
- Teams where code review is the bottleneck because generation outran proof
FAQ
Isn’t this slower than just generating?
Slower for the first hour. Faster for the week — fewer rewrites, fewer review rounds, fewer prod surprises.
Do I need a special tool for steps 1–5?
No. Any chat + IDE works. Step 6 is where a verify-gated agent earns its keep.
What if PM won’t answer edge cases?
Ship less. Explicitly document “accepted unknowns” and add monitoring or feature flags — do not pretend the list was empty.
Does AI replace code review?
No. It front-loads clarity so review can focus on judgment — and so CI can focus on truth.
Where Kramlipi fits (after the coworker steps)
You did the human work: spec, edge cases, docs, code you can explain.
Kramlipi handles the part vending-machine AI leaves broken:
- First-pass AI code review — comments on the diff (magic strings, assignment bugs, missing tests on changed lines). Quiet / chill / assertive profiles like CodeRabbit — customer-hosted, BYO LLM.
- Verify-gated CI repair — when tests or Actions are red, edit until your verify command exits 0. Draft PR. We do not edit GitHub Actions YAML to fake green.
- VS Code panel — Review / Fix tests / Coverage at the bottom; diffs on the right; verify auto-detected.
Same category phrase everywhere: verify-gated CI agent — not a Cursor replacement, not a senior-reviewer SaaS.
Get started (free path):
- kramlipi.com
- Get started guide — binary, Action, env
- VS Code Marketplace — Kramlipi — AI Code Review & CI-Repair
- GitHub Action
Use AI as a coworker through step five. Use Kramlipi when the PR exists and green CI is the only honest definition of done.