Why Draftlytic asks which AI coding tool you're building with

When Draftlytic asks "which AI tool are you building with?" at the start of a new project, a lot of people click the first option and move on. It feels like a preference setting. Like picking a theme.

It isn't. The target tool you select shapes the implementation plan Draftlytic generates. Not the color scheme or the export filename. The actual content. How features are described. Which tech-stack details get surfaced. Whether the output sounds like file-level guidance for a developer or like visual direction for a visual builder.

If you picked randomly, or left the default, and then wondered why the implementation plan felt a bit off, that's probably why.

What each tool actually needs from a spec

The short version: different tools are looking for different things, and a spec that's useful for one can feel confusing or incomplete in another.

Cursor (and similar developer IDEs like Windsurf) is used by people who write code all day. What helps here is file-level structure. Which components belong in which folder. Where state lives. What the API shape looks like. Which things need to be done first because other things depend on them. A Cursor implementation plan that just says "build a dashboard" is useless. One that says "create DashboardPage.tsx, wire it to the existing useSubscription hook, and add a loading state component" is actually actionable.

Lovable (along with v0, Bolt.new) is a visual AI builder. The person using it probably isn't writing any code at all, or very little. What helps here is visual specificity and product clarity. What the user sees first. What a page looks like. What they can and can't do. The features, in priority order, with each one concrete enough that Lovable doesn't have to invent the rest. A Lovable implementation plan shouldn't have dependency trees. It should describe the thing clearly enough that a prompt-first builder can generate it.

Claude Code is an autonomous agent you direct from the terminal. It reads the codebase, plans, and writes. What it needs are constraints. Scope boundaries. What already exists that it shouldn't touch. What the project is definitively not doing. Without those guardrails, it'll make sensible-sounding decisions that steer the project the wrong direction, and by the time you notice, it's committed a hundred lines of polite surprises.

v0 (Vercel's tool) is strong on frontend and UI components. The useful framing here is component-level thinking. What the component accepts as props. What states it handles. What it looks like in each state. It doesn't need to know much about the backend; it needs to know the shape of the thing it's building.

None of this is new. Which AI coding tool you should use depends on how much code you want to touch. The tool choice tells you everything about the person using it. And the spec for that person should be written with them in mind, not a generic output that works for no one in particular.

The same feature, written three ways

Take a feature you might add to almost any app: user notifications.

Here's what a useful spec entry for that feature looks like in three different tools.

For Cursor:

Notifications feature. Create NotificationBell.tsx in src/components/layout/. Fetches unread count from /api/notifications/unread on mount and on a 30-second polling interval. Clicking the bell opens a NotificationDrawer that loads the last 20 notifications from /api/notifications. Each notification has a read_at timestamp; unread ones render with a blue dot. Mark-as-read on click, mark-all-read button at the top. Add the notifications table with columns: id, user_id, message, read_at, created_at. Wire up the DB query in src/lib/api.ts.

For Lovable:

Notification bell in the top-right corner of the app. Shows a red badge with the count of unread notifications. Clicking opens a slide-out panel on the right. Each notification shows a short message and a timestamp like "2 hours ago." Unread ones have a subtle highlight. There's a "Mark all as read" button at the top of the panel. Design should feel lightweight, not intrusive. No email notifications, no push, just in-app.

For Claude Code:

Add in-app notifications. Scope: new notifications table in the DB, a bell icon in the nav, and a drawer that shows the last 20 for the current user. Do not touch the existing email system. Do not add push notifications. Do not build an admin-side notification tool. Use the existing auth middleware for the API routes. The useSubscription hook should not be modified. Keep the polling interval reasonable (30 seconds) rather than aggressive.

Same feature. Same product. Three completely different documents. The Cursor version is a build spec with components named. The Lovable version describes what the user sees. The Claude Code version is a constraints doc that says as much about what not to build as what to build.

Writing the wrong version for your tool doesn't mean the AI fails. It means it guesses. And guessing is how you end up on prompt twelve undoing something that didn't match what you meant at prompt one.

When to change your target tool mid-project

You can. And sometimes you should.

It's common to start in Lovable, get a working prototype quickly, and then realise you need more control over the code than Lovable comfortably gives you. At that point you might export the code and move to Cursor or Claude Code for the next phase. The app is the same. The tool changed.

When that happens, update your target in Draftlytic and re-generate the implementation plan. The features and structure you've already worked out carry over. What changes is the framing layer around them.

The reverse also happens. A developer builds a backend in Cursor and then wants to hand the frontend off to a designer who's working in v0. The backend spec stays. The frontend spec needs to be written in v0 terms: component descriptions, prop shapes, UI states.

The target tool isn't a permanent identity. It's context about what you're doing right now.

The "Other" option: how to write a target description that actually helps

If you pick "Other" and type a custom target, you're not locked out of anything. But the description you write matters.

A custom target like "Replit Agent" or "Windsurf" works fine if you name the tool specifically. Draftlytic uses it to adjust how the output is framed, even for tools that aren't in the main list.

Where it gets murkier is when people type something like "my own code" or "just AI tools in general." Those descriptions don't give Draftlytic enough signal. The implementation plan falls back to a middle-ground output that doesn't fully optimise for any one approach.

If you're building with a tool that isn't on the main list, the most useful thing to write is a short description of what that tool needs. Something like: "CLI-based agent, needs file-level instructions" (Aider) or "visual builder, component-first, no backend details" (Figma Make). You don't have to name the tool if you don't want to. A description of how it works is enough to point the output in the right direction.

This is the same principle that makes a good Lovable spec different from a vague prompt: the tool doesn't need you to be precise about everything. It needs you to be precise about the things it can't infer.

So why does Draftlytic ask?

The question that probably brought you here is: why does it even matter? You're building the same app either way.

The app, yes. But not the plan. A plan is useful only to the person who has to act on it, and that person is you with a specific tool open in front of you. A plan written for Cursor helps you build faster in Cursor. Pasted into Lovable, half of it is noise.

Draftlytic asks which tool you're using because a spec for Cursor vs Lovable is not the same document, and handing you the generic version of both wastes the time you spent describing the idea in the first place.

If you picked the wrong one, or skipped it, go back and update it. Re-generate the implementation plan. The questions you answered, the features you prioritised, the structure you worked out already. None of that changes. Only the framing does. That's the whole point.