The model only
- Code appears in chat. Review is paste into another window.
Coding agents need a project, not just a chat window
The agent can write code. It cannot invent your repo, your secrets and your pipeline. MCP, CLI, workspace, CI — that is the groundwork, without which the thread only edits files on a laptop disk.
- MCP, ap CLI, VS Code plugin: the agent sees the same project you do
- Longer runs in the workspace, merge through the same GitLab CI
Thread or groundwork
Agent in the project
- It works in the workspace. The merge sees the same tests as yours.
A coding agent without a project boundary writes into the void. It becomes useful when that void is a workspace with a pipeline — otherwise you produce diffs nobody is allowed to ship.
Coding agents with and without a platform
This lays out the tasks that surround coding agents and how much of each the Application Platform covers.
| Criterion |
With the Application Platform
|
Without a platform
|
|---|---|---|
| Access to project context | Fully covered: An MCP server connects agents to the project, repositories and environments | Partly covered: The agent only sees the local folder it was started in |
| Editor integration | Fully covered: VS Code plugin with project overview, repositories and run commands | Partly covered: Editor configuration is maintained per machine by hand |
| Terminal integration | Fully covered: ap CLI for project commands and running applications locally | Partly covered: Homegrown scripts that drift apart between projects |
| Automation through an API | Fully covered: Personal API keys for your own workflows and tools | Not offered: Individual service credentials, scattered and hard to revoke |
| Runtime for longer tasks | Fully covered: Cloud workspaces keep working while your machine is off | Not offered: Runs locally and stops when the notebook sleeps |
| A dependable starting point | Fully covered: Templates and a defined project structure with conventions | Not offered: Empty repository, conventions emerge along the way |
| Checking the output | Fully covered: GitLab CI tests and builds every change before it ships | Partly covered: A pipeline has to be built first, otherwise nothing checks |
| Errors after release | Fully covered: Sentry once you connect your account under Connections – errors arrive with stack trace and release | Partly covered: A separate setup per project, or none at all |
| Traceability | Fully covered: Audit log plus deployment configuration in the Git history | Not offered: Environment changes stay hidden in server state |
| Permissions and access | Fully covered: Roles, organisations and centrally managed credentials | Partly covered: Agents inherit the permissions of whoever started them |
Green means covered, amber partly, grey not available. The right column describes no competitor but the usual situation without an end-to-end platform.
As of 9 September 2026. This comparison describes typical workflows and can differ from project to project. Logos are trademarks of their owners and are used only to identify the product.
What we do not claim
- Not a smarter model The platform does not make the agent smarter. It gives it a place, permissions and a check.
Pricing model
Agent licences stay with their vendors. The platform supplies runtime and review.
acme / customer-app
-
customer-appFlutter app for iOS, Android, and web
-
backendAPI and server logic with Docker setup
-
homepageMarketing site and public content
-
e2e-testsEnd-to-end tests against dev and staging
-
gitops-configurationDeployment configuration for dev and prod
-
local-configurationWorkspace, IDE, and agent configuration
-
gitlab-profileProject documentation and README
Connecting coding agents to a project
Four steps from signing up to a first checked result.
-
Create a project from a template
Repository, project structure, pipeline and environments come out of the wizard, giving the agent a defined baseline.
-
Connect your tools
Set up the MCP server for your agent, install the VS Code plugin or use the ap CLI inside the project folder.
-
Choose where work happens
Work locally with the Setup app, or start a cloud workspace when a run outlasts your attention span.
-
Let the pipeline check it
Changes arrive as commits and travel through the pipeline. Whatever fails there does not ship, no matter who wrote it.
Frequently asked questions
Does the platform improve what AI agents produce?
No. Output quality depends on the model and on how you frame the task. The platform only shapes the setting: every change runs through the same tests and build steps as hand-written code. Judging whether a suggestion is correct remains your job.
Which tools can be connected?
Through open paths, not tool-specific integrations. Agents that speak MCP use the platform's MCP server, editors based on VS Code use the plugin, anything else connects through the ap CLI or API keys. That covers Claude Code, Cursor, Codex and Copilot.
Why use a cloud workspace if the agent runs locally?
Because longer runs need a machine that stays awake, and an agent stops when your notebook sleeps. A cloud workspace continues independently of your device, reachable through VS Code, JetBrains, RDP or VNC, and it is identical for everyone on the team.
How do I review what an agent changed?
With the same means you apply to human contributions: changes arrive as commits and travel through the pipeline. Roles and permissions decide what is reachable at all, personal API keys can be revoked individually, and the audit log records the rest.
How do credentials work when an agent is involved?
Credentials live centrally in the project, not in source code, and the project conventions rule out committing secrets. What an agent can reach depends on the API key or account it operates under; for sensitive environments, use reduced permissions.
Point your agent at a real project
Register for free, create a project and connect your tool through the MCP server, the CLI or the plugin.