Use AI on an existing project
Bring your current folder, repository and tools into Lyre, ask an agent for a bounded change and verify it with the project’s own checks.
On this page
Can I use Lyre with a project I already have?
Yes. Open a real project folder or clone its repository on your Lyre host, then use a configured coding agent on the approved sources. Keep the project’s framework, package manager, editor and build tools. Agent work does not require an app preview: scripts, backends, documents and native source can use their own tools and checks. A phone connection does not make every project runnable as a phone app.
Keep the existing project intact
- Lyre on the host holding the project. Follow installation and check supported downloads and clients rather than assuming a particular phone-store build exists.
- A real checkout or folder you are authorized to use, with its README, lockfile and existing instructions. Keep a recoverable checkpoint and record existing changes before adding agent edits.
- A configured coding provider and an appropriate model. Follow provider setup or local-model setup. Provider charges and account permissions remain separate from Lyre.
- The project’s required runtimes and development services on the host. Use test data; keep credentials with the backend or provider that needs them.
For another device, pair with Owner access or explicit Developer access to this approved project. App-only access cannot open its source, conversations or terminals. Keep the host awake and reachable for remote work. A denied request needs the host owner's scope review, not a different folder name.
Open the correct source directory
-
Add the existing source
From Library, choose Add project and use the folder or repository-clone flow appropriate to your host. If the repository is already checked out, open that folder. Library owns these entry points.
-
Choose the working directory
Use the directory containing the files the task needs. For a frontend/backend repository, that may be their common project root. Check the computer, project and workspace before sending a request; commands run from that workspace directory. See existing-project setup.
-
Inspect before changing
Open Files and Changes to inspect the current sources and edits. Start a conversation with your chosen provider and model. Ask it to read the README and project instructions, identify the affected code and propose the smallest relevant check.
Example: fix a bug without migrating the stack
Use your actual failing behavior in place of this example. The request is an investigation first, not permission to rewrite a project.
Inspect the existing CSV import and its tests.
Explain why an empty date is rejected and identify the current rule.
Read the project instructions, preserve unrelated changes and keep
the current framework and dependencies. Do not edit files yet.After checking the diagnosis, ask for one agreed change:
Implement the agreed empty-date handling only.
Add or update the relevant behavior check using our existing tools.
Do not migrate the stack, change deployment settings or touch other
work. Report the diff, commands, actual results and remaining risks.Use the provider's approval flow for file and command operations. Task modes, provider connections and project context remain available through their existing controls.
Choose verification that fits the project
| Project work | Useful verification |
|---|---|
| Web frontend or supported web target | Use the existing checks and an interactive app preview. Configure the web server and test its real actions. |
| API, backend or script | Use its tests, terminal output and representative requests or inputs. A backend alone does not provide a phone interface. |
| Documentation or generated files | Review the source and rendered output using the project’s own build or document tools. |
| Native mobile or desktop source | Use its SDK, compiler, simulator or device workflow on a suitable host. Source access does not prove the target runs on a client phone. |
For web interfaces, follow startup configuration and framework recipes. Previewing a supported frontend is optional; you can also use a preview without starting an agent. For tools that need a host desktop, follow remote control of your computer with its separate platform and access requirements. Viewing or controlling a desktop does not give an agent automatic screenshot or tool access.
Check what changed before committing
-
Review the scoped diff
Read Changes for the actual workspace. Confirm that pre-existing edits remain intact and only the agreed behavior changed. Use file and Git review; save or resolve any editor conflict before overwriting host content.
-
Read actual results
Inspect the relevant test or command output, including failures. For the CSV example, try both an empty date and a valid date with development data. A successful command does not establish a working app or correct data by itself.
-
Keep the next decision explicit
Commit or request a review through your existing workflow when the change is ready. Keep release, deployment and data migrations as separate decisions. For independent tasks, use separate Git worktrees rather than letting several agents overwrite the same checkout.
The reviewed diff preserves unrelated work, the original failure is addressed, adjacent behavior still works and the relevant checks have recorded results in this project’s actual environment.
Resolve setup and access failures in their owner
- The agent cannot read the intended project
- Check which host and project are selected and ask the owner to review its grant. Do not copy private sources to an unapproved location to bypass a denial. Access and security describes the boundary.
- Commands fail in a new checkout
- Install the project’s existing runtimes and dependencies, and prepare its ignored environment files and development database. Read host preparation; adding a folder does not install its toolchain.
- The agent or provider is unavailable
- Check installation, account, quota and model readiness through provider recovery. Keep your selected provider’s supported controls rather than substituting a new integration.
- A working app fails only on the phone
- Check the selected web target, start command, host connectivity and backend routing. A phone’s localhost is not the host backend. Use API routing and preview recovery.
- An edit conflicts with newer work
- Preserve both versions and use the existing Reload/Overwrite conflict flow. Inspect the diff before retrying the request.
Keep tools, permissions and data scope clear
Lyre does not supply every language toolchain, make an incompatible agent understand every format, or convert every native project into a web preview. The connected provider must support the task and its tools. Commands execute under the host account and existing provider permissions; an approved project is not a process sandbox.
Your project stays on its host, but cloud models, agents and integrations can send context to external services. Review the privacy policy and selected provider before sending private source. Revoke a remote device through device management when access ends; disconnecting it is not revocation. Stop agents and app processes separately when needed.