agentic-ship Runs Lovable-Style Builds on Your Agent

agentic-ship is an MIT-licensed open-source toolkit by the GitHub user moasq that helps a coding agent build and ship a full-stack app. It deals with the annoying part of AI app builders: the setup around the model, including rules, backend conventions, service connections, checks, and deployment gates. The useful takeaway is simple: hosted builders are not only selling generation; they are selling a product harness, and agentic-ship tries to make that harness portable. For Cursor, Anysphere's AI code editor, the interesting question is how much of that harness belongs in cursor rules, skills, subagents, and reviewable IDE workflows.

Agentic Ship is a set of project contracts and verification steps that direct an existing coding agent instead of bundling a generated app. As of August 2026, the GitHub repo is small — 5 stars, mainly JavaScript, MIT license, and last pushed on 2026-08-14 — which makes this more early signal than mature platform.

Read it as a harness, not a hosted builder

The README frames agentic-ship against Lovable, Bolt, v0, and Replit. That comparison is spicy, but the real idea is calmer: take the conventions those products hide inside their hosted experience and put them in your own workspace.

The project says it can guide a coding agent through frontend, backend, payments, tests, provider setup, and production deployment. It also says existing files are skipped by default, with flags such as --force, --merge, and --dry-run for more explicit behavior. That matters because agentic tools become much less scary when the first move is inspectable instead of destructive.

The trap is treating this like a magic app factory. A harness can coordinate Convex, Netlify, payment work, tests, and deployment gates, but it still inherits the quality of your prompt, repo state, credentials, and agent review loop. If those are messy, the harness will faithfully automate the mess.

Notice the trick: contracts before prompts

The clever part is not a new model. The clever part is making the agent read durable product contracts before it starts making changes.

In the source project, the agent is expected to read AGENTS.md and follow the rules there. That file becomes the boundary between a vague request and a buildable product: which stack to use, how services are connected, what must be tested, and what counts as done. This is also where the project starts to rhyme with Cursor workflows, because Cursor users already have a native place for repository instructions through cursor rules.

A small example is a repo that allows new serverless functions but forbids direct database writes from React components. Put that in AGENTS.md for the harness, and mirror the local enforcement in a Cursor .mdc rule. The point is not duplication for its own sake; the point is that your coding agent should encounter the same boundary whether it is planning, editing, or reviewing.

The trap is writing rules that sound wise but cannot be checked. Prefer concrete constraints: allowed directories, required commands, service ownership, and test gates. An agent can follow those more reliably than it can follow please keep the architecture clean.

Use Cursor as the review surface

For Cursor users, agentic-ship is most interesting when Cursor remains the place where changes get inspected. Cursor Agent can make multi-file edits, use tools, and work inside the repo; cursor rules can keep it close to local conventions. That makes the IDE a useful review surface for a harness that wants to orchestrate bigger app-building steps.

A practical boundary looks like this: let the harness create or update the app plan, service checklist, and scaffolding, then use Cursor to review each diff before credentials, payments, or deployment enter the picture. If you use cursor custom agents or cursor subagents, give each one a narrow job, such as database schema review, frontend accessibility pass, or deployment checklist review. Keep the permissions boring.

Here is a tiny Cursor rule stub that pairs well with an agentic-ship experiment:

---
description: Guardrails for agentic-ship experiments
alwaysApply: false
---

When working on an agentic-ship generated change:
- Do not overwrite existing application files without showing the diff first.
- Keep provider setup steps in docs/service-connections.md until a human adds credentials.
- Run pnpm test and pnpm lint before calling the build done.
- Do not create payment, deployment, or database resources from the IDE without explicit approval.

The trap is giving one agent the whole story and every tool. The stronger pattern is smaller surfaces: rules for repo boundaries, skills for repeatable workflows, MCP servers for external systems, and subagents for review jobs. If you want the Cursor-specific version of that idea, the related notes on Cursor subagents and skills are the natural next stop.

Try it safely before you trust it

The right first test is not your production app. Use a disposable repo, a fake product brief, and sandbox provider accounts. You are testing whether the harness produces understandable work, not whether it can impress you in one long run.

Copy this checklist into the issue or README for a trial:

## agentic-ship safety checklist

- [ ] Start in a throwaway repo, not the production app.
- [ ] Run the installer with a preview mode first if available, such as --dry-run.
- [ ] Keep existing files protected unless you intentionally choose --force.
- [ ] Put product rules in AGENTS.md before asking for a build.
- [ ] Add a Cursor .mdc rule for local edit boundaries.
- [ ] Use sandbox accounts for Convex, Netlify, Stripe, or any provider connection.
- [ ] Review generated diffs in Cursor before running setup commands.
- [ ] Require lint, tests, and one manual happy-path check before deployment.
- [ ] Write down every secret or service permission the agent asked for.

This is also where MCP becomes relevant. If the agent needs GitHub, a database, or a deployment provider, an MCP server can make that integration explicit and reviewable. The Brave DevTools MCP experiment in brave-devtools-mcp Connects Brave to Agents is a good nearby example of why tool boundaries matter.

The trap is connecting real accounts too early. The moment an agent can create infrastructure, charge a card, or mutate production data, you are no longer testing generation quality. You are testing operational safety.

Know when it is worth the complexity

agentic-ship is a good fit when you want the hosted builder experience but do not want the hosted builder to own the workflow. It is especially interesting for people who already pay for Claude Code by Anthropic, Codex by OpenAI, or Cursor, and would rather invest in reusable project setup than another generation subscription.

It is overkill for a small static site, a one-file prototype, or a codebase that has no tests and no deployment story yet. In those cases, the harness has nothing stable to grab onto. Start with a simple Cursor Agent session, a short rules file, and a clean review checklist.

The honest limitation is that this is an early open-source project. The idea may be more important than this particular implementation today. But early tools are often useful because they show the shape of the missing layer.

Common questions

• Is agentic-ship a Lovable replacement?

  It is trying to replace part of the Lovable-style experience, not become the same kind of hosted product. The repo positions itself as the setup around the AI: contracts, conventions, provider connections, and verification gates that your existing agent can run from your workspace.

• Does agentic-ship work with Cursor?

  The source describes using the toolkit from the project directory and then opening the folder in your agent, which can include Cursor. The README separately mentions plugin installation for Claude Code and Codex, so Cursor users should treat it as a repo harness plus Cursor rules workflow unless the project adds a Cursor-specific plugin later.

• Should I run it inside an existing repo?

  Start with a disposable repo first. The README says existing files are skipped by default and mentions flags like --force, --merge, and --dry-run, but a first run is still a broad agentic operation with service and deployment implications.

• Where do Cursor skills and subagents fit?

  Cursor skills and subagents fit around the harness, not necessarily inside it. Use a cursor skill for a repeatable workflow such as release verification, and use a cursor subagent for a bounded review such as schema safety or payment-flow checks after agentic-ship generates changes.

• What is the main risk?

  The main risk is giving the agent real service permissions before the workflow has earned trust. Keep provider connections in sandbox mode, review diffs in Cursor, and require deterministic checks such as lint, tests, and a manual happy-path run before any production deployment.

Best ways to use this research

• Best for: Developers who like hosted AI builders but want the app, rules, and service setup to live in their own repo.
• Best first artifact: A short AGENTS.md file plus one Cursor .mdc rule that defines what the agent may edit and what must be reviewed.
• Best comparison angle: Compare agentic-ship with hosted builders on ownership of workflow, credentials, review surface, and repeatability — not only on prompt-to-app speed.
• Best Cursor workflow: Let the harness propose and scaffold, then use Cursor Agent, cursor rules, and narrow review subagents to inspect the actual diff before external side effects.

Further reading

• Cursor — Agent
• Cursor — Rules
• agentic-ship — source

Try one small build

Create a throwaway repo, write a plain AGENTS.md, and run agentic-ship only far enough to inspect the first diff. If the diff is understandable and the checks are real, then decide whether the harness deserves a second run.

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.