Everything you wanted to ask before you ship.

The agent has access to the whole working copy during a task, the same way a human engineer cloning the repo would. In practice, it pulls only the files relevant to the requested change into its working context. It does not pre-train on your code, and it does not retain repository contents between tasks.

Lightsprint is stack-agnostic. Teams ship changes in TypeScript, JavaScript, Python, Go, Ruby, Rust, Swift, Kotlin, and more. On the frontend side, React, Next.js, Vue, Svelte, Astro, and React Native are well-covered. The agent learns from your repo, so the more idiomatic your project is, the closer the generated code will match your conventions.

Yes. Each cloud workspace runs your install command, lint, typecheck, and test suite as part of the task. If anything fails, the agent iterates until the suite passes (or surfaces the failure with context if it cannot resolve it). You see the green or red signal on the PR before you review.

In the cloud. Each task gets its own isolated, ephemeral sandbox in Lightsprint's infrastructure. You can kick off a task, close the tab, and come back to a live preview. You can also run multiple tasks in parallel on the same repo without them blocking each other.

Through a scoped GitHub App (or equivalent provider integration). You grant access only to the repositories you choose. The app uses short-lived installation tokens, not long-lived personal access tokens, and the scopes are limited to what is needed to clone, push branches, and open pull requests on the repos you select.

No. Lightsprint does not train, fine-tune, or share your source code with model providers for training. Code sent to model providers as part of a task is governed by zero-retention agreements with those providers wherever they offer them.

Inside an isolated, single-tenant sandbox in Lightsprint's cloud. The sandbox is destroyed when the task ends. We retain the resulting pull request artifacts (diff, plan, preview URL, run logs) so you can audit what shipped, but the working copy itself is ephemeral.

Secrets are stored encrypted at rest and injected into the sandbox at runtime as environment variables. They are scoped per repository and never logged, never sent to model providers, and never written into generated code. You can rotate or revoke them at any time.

By default, no one. Access to customer environments is gated by least-privilege controls and only granted on explicit support request from you. All such access is logged. Enterprise customers can require zero-access mode with stricter controls.

Yes, for Enterprise customers. We support private cloud deployments where the agent sandboxes run in your own cloud account so source code never leaves your perimeter. Reach out for an Enterprise conversation.

One credit corresponds to one unit of model token spend. Credits cover the full lifecycle of a change: generating the visual plan, breaking that plan into tasks, and the agent executing the tasks (reading files, writing code, running tests, iterating). The dollar value of a credit roughly tracks frontier-model token pricing, so what you pay reflects what you actually used.

As a rough guide: a small content or styling change is typically a few hundred thousand credits. A medium feature (new component, API endpoint, form flow) usually lands in the low millions. A larger multi-file refactor or new page with tests can reach the high single-digit millions. Most teams comfortably fit inside the Team tier; teams shipping multiple features per day per engineer tend to choose Growth.

Team is $125 / month for up to 5 team members. It includes 40M credits per month (equivalent in token spend), unlimited repositories, parallel cloud agents, preview environments, and PR-based review. Best for small product teams shipping a few changes per week.

Growth is $499 / month and includes 150M credits per month (equivalent in token spend), everything in Team, and Bring Your Own Key (BYOK) for direct model provider routing. Best for product teams shipping multiple changes per day or teams that want to run on their own model contracts.

Tasks pause cleanly. You can top up credits on demand or wait for the monthly reset. Nothing breaks, no work is lost, and any preview environments and open pull requests stay live and reviewable.

Credits reset at the start of each billing cycle and do not roll over. Top-up credits purchased outside the plan allotment are valid for the current cycle.

Yes. Enterprise covers larger teams, SSO/SAML, private cloud deployments, custom credit pools, audit logs, and dedicated support. See our enterprise page or talk to us for a quote.

Plan is the visual planning step. You describe the change in plain English, and Lightsprint generates a structured plan: what files change, what the UI looks like, and a small set of visual options styled to your live app. You pick the option you want before any agent writes code. This is where most of the steering happens, and it is the reason Lightsprint avoids the endless revision loops typical of single-prompt code tools.

Build is where cloud agents execute the approved plan in parallel. Because the plan is already correct, the agent runs one-shot against your repo: writes the code, installs dependencies if needed, runs lint and tests, and iterates until the suite passes. You can have multiple builds running on different changes at the same time without them stepping on each other.

Ship is the review and merge step. Every change produces a real pull request on your normal Git workflow with a live preview URL attached. Engineers review the diff, comment, request changes, and merge through their existing process. Nothing reaches production without engineering approval.

Because the cost of fixing a wrong plan is much lower than the cost of fixing wrong code. Lightsprint front-loads the steering into the Plan phase (cheap, visual, fast) so the Build phase runs against a target that is already correct. Teams typically see fewer revision loops and shorter time-to-merge as a result.

Yes. For tightly scoped changes (copy edits, minor styling, small bug fixes) you can go straight to Build. For anything that touches UI or product behavior, the Plan phase is what makes the visual review possible, so most teams keep it on.

A set of visual options for the change, rendered in components and styles pulled from your live app. Buttons match your buttons, type matches your type, spacing matches your spacing. The PM picks the option closest to the intended outcome (or asks for an adjustment in plain English) before any code gets written.

Lightsprint reads your design system: tokens, component library, recurring layout patterns. The Plan phase composes the proposed change from those primitives so the options on screen are realistic representations of what would actually ship, not generic AI mockups.

Yes. PMs can request adjustments in plain English ("tighter spacing," "primary button instead of secondary," "move the CTA above the fold") and Lightsprint regenerates the option. This iteration loop is cheap because it happens at the plan level, not by re-running a full code build.

The Plan, the live preview URL, and the pull request are all linked. A PM approves the visual option, the agent builds against it, the engineer reviews the resulting PR with the preview in hand. Comments on the PR (from engineers) and notes on the plan (from PMs) stay tied to the same change, so the conversation does not split across tools.

That is the entire point of the Ship phase. PM approval at the Plan phase is approval of intent and visual direction. Engineering approval at the PR phase is approval of the actual code that ships. Engineers can request changes, push their own commits to the branch, or close the PR. The PM-approved plan never bypasses code review.

Yes. Designers typically work alongside PMs in the Plan phase, refining visual options before the build kicks off. Because the options are rendered in your real design system, the handoff between design intent and shipped code is much tighter than a Figma-to-PR workflow.