Developers need different ways to interact with AI for different tasks. Implementing a code change may require an agent working in the terminal, while understanding a module or exploring an architectural question may only require a conversation in the browser.
BatonX’s intended approach connects these experiences through common organisational controls. The interface may change; the user’s access rights and the organisation’s boundaries should not.
CLI: Controlled development work
The CLI experience brings a coding agent into the developer’s terminal workflow. Within its permitted scope, the agent can inspect project files, propose changes, edit files and run test commands.
These actions should be constrained by the session’s workspace and effective policies. Filesystem access, command execution and network connections must be technically enforced in the execution environment rather than left solely to model instructions.
The developer reviews changes and test results before proceeding through the existing code review process.
Web Chat: Understand the project without changing it
Read-only Web Chat is designed for questions and explanations grounded in authorised project context.
A user can explore a module’s responsibilities, understand an application flow or assess the potential impact of a change. Responses may include explanations and suggested code, but those suggestions are not applied to the repository.
The read-only boundary should be explicit:
- No project files are created, modified or deleted.
- No terminal commands or tests are executed.
- No commits, pushes or merge requests are created.
- No changes are made to external systems through integrations.
Conversation history and audit records may still be stored under the applicable retention policy. “Read-only” describes the experience’s authority to act on projects and connected systems.
Read-only access still needs protection
An experience that cannot modify files may still read sensitive information or expose it in a response.
Context selection, repository authorisation, sensitive-information controls and approved model destinations therefore matter for Web Chat as well. Permission to access a project does not automatically permit sending all of its contents to every model.
Where possible, responses should identify their supporting sources and the code version used. The conversation should not imply that it inspected inaccessible files or verified tests it did not run.
A controlled transition from explanation to execution
A developer may first use Web Chat to understand a workflow, then start a CLI session to implement a change.
The CLI session’s permissions and policies must be evaluated separately. A suggestion made during a conversation is not approval to execute a command or modify a file.
BatonX’s design goal is to bring both experiences under shared governance while keeping their action boundaries explicit and enforceable. Available capabilities should be confirmed for the relevant release and deployment.