ARIA IDE documentation

Relationship to ARIA Agent

ARIA IDE is not a second underlying assistant. It is ARIA Agent operating in software-development mode. It uses the same user account and is intended to share the same conversation/project relationship and relevant memory rather than requiring a developer to start over with another AI identity.

Random Target AI gives IDE its own public product page and documentation because the development experience is substantial enough to deserve a clear explanation.

Real-time voice development

ARIA IDE should support a natural sequence such as:

1. The developer describes a bug by voice.
2. ARIA inspects the project context available to it.
3. ARIA explains what it found and proposes a scoped action.
4. The developer asks a question, interrupts, changes direction or authorizes the next step.
5. ARIA performs the permitted action, reports the output and continues the same conversation.

This is more than speech-to-text pasted into a coding assistant. Conversation and execution are meant to stay connected throughout the task.

Project connection

ARIA can only work with a codebase that the IDE workspace is actually allowed to access. Project setup can involve a repository connector, local secure bridge, mounted project, development environment or other approved integration. The customer-facing dashboard does not by itself grant repository access.

A connected project should define what ARIA may read, what it may write, which commands are allowlisted, what actions require human confirmation, and what deployment targets are explicitly off limits.

Reading project context

Before proposing a code change, ARIA IDE should inspect the relevant structure, files, existing conventions and dependency relationships available to the workspace. This reduces the risk of producing generic code that ignores how the real application already works.

Read access can be narrower than the whole repository. Secret files and protected deployment targets should remain outside the model's readable scope when the connector security model requires that boundary.

Requesting changes

Requests can be conversational and outcome-focused:

• “Fix the drawer that is open before a prospect is selected.”
• “Add customer access to Sales, but keep internal RTAI prospects isolated.”
• “Review this login flow and tell me why the session disappears after password change.”
• “Update the public page without changing the realtime voice backend.”

ARIA should translate the request into the smallest appropriate change set, call out dependencies and preserve unrelated work.

Approval and execution

IDE actions should follow the security policy of the connected project. Read-only inspection may be allowed automatically while writes, commands, deployments or destructive operations can require explicit approval.

Approval is not merely a UX prompt. It should be enforced by the connector or execution boundary so the assistant cannot bypass the policy by changing how it phrases a request.

Debugging and fixes

A useful debugging cycle is evidence-driven:

1. Observe the actual error, failing behavior or logs.
2. Trace the relevant code path.
3. Identify the root cause separately from symptoms.
4. Explain the proposed fix and any risk.
5. Apply only the approved change.
6. Re-run the relevant verification.

The developer can remain in voice conversation during this cycle and ask why a file is being changed or redirect the investigation.

Checks and tests

If the connected IDE environment exposes an allowlisted test, lint or verification command, ARIA can run it and use the real output as evidence. A passing check should not be invented when the command cannot be executed.

When the environment cannot run the required tool — for example, a local PHP linter is unavailable — ARIA should report that limitation and move the required verification to an environment where the tool exists, such as server-side staging.

Interruptions and redirection

Voice-driven IDE work must remain interruptible. The developer should be able to say “stop,” “don't touch production,” “that's the wrong file,” “show me the diff,” or “run the check again” without waiting for a long spoken response to finish.

The realtime conversation manager therefore needs the same core capabilities expected from ARIA Voice: speech-onset detection, cancellable model/speech output, authoritative listening/thinking/speaking state, and reliable barge-in.

Reviewing changes

ARIA should be able to describe the exact files changed, show or summarize the diff, explain why the change solves the issue and identify anything left unverified. A dedicated visual diff/terminal experience can improve the workspace, but the underlying requirement is traceable change review rather than a particular panel layout.

Security boundaries

Examples of appropriate IDE boundaries include:

• Repository-root sandboxing and path-escape protection.
• Secret-file refusal and output redaction.
• Structured git actions with destructive operations denied.
• Separate read versus write capabilities.
• Allowlisted commands instead of unrestricted shell access.
• Explicit production/deployment protections.
• Audit records for actions taken through the development bridge.

The exact controls depend on the connector. Do not assume a generic ARIA IDE session has unrestricted access merely because the product supports code execution.

Deployment and rollback

ARIA IDE can help prepare, review and coordinate deployment work, but deployment authority belongs to the connected environment and the user's approved release process. Production deployment must never be inferred from permission to edit local or staging code.

Rollback similarly follows the project's version-control and hosting strategy. A deployment/rollback button in the customer dashboard is not required for the IDE conversation model and is not currently represented as a universal self-service control.

ARIA IDE in the customer dashboard

The console IDE page explains the Agent relationship, product capabilities and configured development workspace/project status. Product access can be Active, Trial, Locked, Setup required or Suspended like other ARIA products.

Current limitations and implementation boundaries

• Not every customer account has a repository/project connector configured.
• Available read/write/command actions vary by connected IDE environment.
• The customer console does not imply unrestricted terminal access.
• Production deployment is not automatically authorized by an IDE session.
• Realtime voice/tool execution depends on the active realtime and development connector stack; dashboard copy alone does not create that backend connection.

See Security & privacy and Troubleshooting for related boundaries.