Ask HN: Shipping Apps Without Seeing Code

Ask HN: Who build production apps with out seeing code? is a July 2026 Hacker News question about using AI coding agents without opening the code editor. The poster said Cursor, Anysphere's AI code editor, now defaults to an agentic flow where the editor can disappear from view. The question was simple and sharp: are real products being shipped without anyone reading the code? The answer for cursor ai training is also simple: let agents write a lot, but keep review, tests, and security boundaries visible.

Blind agentic shipping is releasing agent-written changes without reading the diff, tests, or security boundary. That is the line the thread kept circling.

Read the Ask HN question as a risk signal

The useful part of the Ask HN thread was not that everyone agreed. They did not. The useful part was the pressure it put on a new default: agents can now feel like the primary interface, not just a helper inside an editor.

The original poster was not anti-AI coding. They said nearly all of their code was written by AI. Their concern was the missing review surface. VS Code-style diff review still helped them see what changed before the app reached users.

Developers pushed on the same fault line. Some said non-technical founders may be more likely to try it. Others said production code still needs systematic tests. The strongest objection was security: even if the business logic works, trusting an agent to secure an app with no human review is not a serious launch posture.

The trap is treating this as a personality debate. It is really an interface debate. When the editor disappears, you need another place where intent, diff, test evidence, and security assumptions become inspectable.

Keep the editor in the loop

Cursor's agent mode is useful because it can plan, edit, run commands, and iterate across a codebase. That does not make the code editor obsolete. It makes the editor a review instrument.

A good Cursor workflow has two modes. In one mode, the agent explores and edits. In the other, the developer reads the patch, checks the tests, and asks what could break. The handoff between those modes should be explicit.

For example, after asking an agent to add password reset throttling, do not stop at a green chat response. Open the diff. Check the route, persistence layer, rate-limit key, tests, and error behavior. Then ask the agent to explain the abuse case it did not cover.

The trap is replaying the chat instead of reviewing the artifact. Chat is useful for intent. The diff is where the product changes.

Give agents boundaries they can quote

Cursor rules are a good place to put durable repo facts. Use them for things that should survive the prompt: architecture constraints, test commands, naming conventions, and unsafe areas. Keep them short enough that an agent can actually use them.

An AGENTS.md boundary can do the same job in plain repo language. Put broad expectations at the root. Put local warnings near risky code, such as auth, billing, migrations, or infrastructure. Local scope beats one giant memory file.

A small example is enough:

# AGENTS.md

## Production safety boundary

Before changing auth, billing, data deletion, or migrations:
- show the files touched
- name the security or data-loss risk
- run the narrow test command
- leave a review note with remaining uncertainty

This does not make the agent safe by itself. It gives you something to compare the agent's behavior against. If the agent skips the boundary, that is a review finding.

The trap is writing rules like wishes. A rule that says be careful is not a boundary. A rule that says run pnpm test -- auth/reset.test.ts after touching password reset code is reviewable.

Use skills to make review repeatable

Cursor skills are best thought of as reusable procedures the agent can invoke when a task matches their description. They are not a substitute for reading code. They are a way to package the checks you would otherwise keep retyping.

This is where cursor skills, cursor subagents language, and cursor custom agents all meet in practice. People want specialized behavior: a security reviewer, a migration helper, a test fixer, a release-note writer. Whether you express that as a skill, a rule, a custom agent note, or an MCP-backed workflow, the point is the same. Give the agent a narrow job and a visible receipt.

The practical cursor ai training move is to teach one repeatable review skill before teaching broad autonomy. Start with a production-change review. Make it ask for the diff, affected surface area, test evidence, and known unknowns.

MCP matters when the review needs outside context. A GitHub MCP server can help inspect issues or pull requests. A database or docs MCP server can add product context. Keep the first connection read-only if the workflow is new.

The trap is making a skill too grand. A skill named ship feature safely will blur everything. A skill named review auth route change has a chance to be useful.

If policy enforcement is the piece you are wrestling with, Kastra Enforces Policies for Cursor Agents is a related research note. For more examples in this lane, see the related training topic.

Copy this Cursor review checklist

Use this when an agent-written change touches production code, user data, payments, auth, permissions, migrations, or infrastructure. It is intentionally small. The next step is to put it in one repo and use it on one real patch.

---
description: Use before accepting agent-written production changes
globs: src/**, app/**, api/**, db/**
alwaysApply: false
---

# Production change review

Before marking an agent task complete:

- Read the diff, not only the chat summary.
- List the user-visible behavior that changed.
- List the files that touch auth, permissions, payments, user data, or migrations.
- Run the narrowest relevant test command.
- Add or update one regression test when behavior changed.
- Check logs, secrets, and error messages for data leakage.
- Ask the agent: what is the most likely failure mode left here?
- Write a final review note with: accepted risk, test evidence, and follow-up.

You can store this as a Cursor rule, keep it in AGENTS.md, or turn it into a Cursor skill. The best home is the one the agent will actually see at the moment it edits risky code.

A tiny review receipt can look like this:

Review receipt

Change: added password reset throttling
Risk area: auth, user enumeration, rate-limit bypass
Tests run: pnpm test auth/password-reset.test.ts
Human review: read route, limiter key, email branch, error text
Remaining uncertainty: distributed rate limit behavior in staging
Next check: verify Redis-backed limiter before release

That receipt is not ceremony. It is the minimum proof that someone looked.

Common questions

• Can people ship production apps without seeing the code?

  Yes, some people probably do, especially in small or non-critical projects. The Ask HN thread did not establish strong public examples of complex, traction-heavy apps shipped this way. The safer reading is that AI can write most of the code, while humans still review diffs, tests, and security-sensitive paths.

• What belongs in cursor ai training after this thread?

  The first skill should be review, not prompting flair. Teach developers to ask Cursor for a plan, inspect the diff, run narrow tests, and record a short review receipt. One reusable artifact, such as a production-change checklist, is more useful than a dozen generic prompt patterns.

• Do Cursor skills replace code review?

  No. Cursor skills make repeatable workflows easier to invoke, but they do not remove the need to inspect the result. A useful skill can gather files, run tests, and summarize risk. The reviewer still owns the final call, especially around auth, payments, data deletion, and permissions.

• Where do cursor rules fit if the agent writes most code?

  Cursor rules fit where the repo has durable constraints the agent must follow. Put test commands, architecture boundaries, naming rules, and risky directories there. Keep task-specific details in the prompt or review receipt, because long global rules become noisy and easier for the agent to ignore.

• Is this a Cursor workshop topic or just a Hacker News debate?

  It is both, but the debate is the useful starting point. A cursor workshop should not promise that agents remove the need to read code. It should show where review moves when agents write more of the patch: rules, skills, diffs, tests, and receipts.

Best ways to use this research

• Best for: Developers already letting Cursor agents write large patches, but who still need a sane review habit before production changes land.
• Best first artifact: A small production-change review rule or skill that asks for touched files, risk areas, test evidence, and remaining uncertainty.
• Best comparison angle: Compare agent chat summaries against actual diffs. The gap between those two views is where missed requirements and security mistakes often hide.
• Best limitation to remember: This research does not prove no one can ship without reading code. It shows why many experienced developers still treat blind shipping as a bad default for serious apps.

Further reading

• Cursor — Agent
• Cursor — Rules
• Cursor — Skills

Try one safe experiment

Pick one agent-written production patch this week and require a review receipt before merging it. If the receipt feels hard to write, the workflow is not ready to be invisible.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.