Vi's AI doesn't write code, and that's on purpose
Short answer: Vi didn't build a coding or code-review assistant, because software teams already have one and what they lack is somewhere else: the gap between the task and the code. Vi's MCP server lets the assistant a developer already uses (Claude Code, Cursor, Codex and others) read a task, start it in the IDE, create subtasks, comment and request a close. Anything with a lasting effect, such as starting or closing a task, happens only after the developer approves it in their IDE. The AI is a pair of hands, not a teammate.
What is the market selling?
Open the homepage of almost any project management tool today and you'll see the same promise: "Add an AI teammate." An agent that picks up tasks, writes code, opens pull requests and even reviews other people's work.
These tools aren't useless. Coding assistants really have made writing code faster, and automated review catches simple mistakes earlier. This article doesn't argue they are bad. It argues that a project management tool has no reason to build yet another one.
Why didn't we build another coding assistant?
We had three reasons.
First, developers have already picked their assistant. Someone who works in Claude Code is not going to switch assistants tomorrow because of their project management tool. Every new built-in assistant means another window, another model and another bill. We preferred to connect to the assistant that is already open in the terminal and the IDE.
Second, writing code is not the bottleneck. In most software teams, work gets stuck elsewhere: a task with a half-written description, a developer who isn't sure which task is theirs, code that has been written while its task still says "in progress", and a customer who has no idea their problem was fixed. These are problems of closing the loop, not of typing.
Third, responsibility needs an owner. Once an AI agent joins the team and commits and closes tasks under its own account, a simple question gets hard: if something goes wrong, whose work was it? In Vi the answer to that question is always a person.
What exactly does Vi's MCP server do?
Vi's MCP server lives at https://useviapp.com/mcp. The assistant connects through OAuth with your own account and works with exactly the permissions you have in Vi, no more.
With that connection the assistant can see projects, teams and members, search tasks and read a task with its comments and subtasks. It can create a task or a subtask, and before creating one it looks for similar tasks so duplicate work isn't logged. It can comment on a task. Most importantly, it can ask the developer to start, pause or close a task.
The word "ask" is deliberate. When the assistant says "let me start task 12", that command reaches the Vi extension in the same developer's IDE, and a dialog opens: this app wants to start task 12, do you agree? If the developer declines, the assistant doesn't start the work. Closing works the same way: the assistant makes the request, the developer reviews the files and finishes the work themselves with Commit & Close.
What does an ordinary morning look like this way?
A developer opens the terminal and types to their assistant: "Do task 42."
The assistant first sends a start request. A confirmation dialog appears in the IDE, the developer accepts and the task timer starts. Then the assistant reads the task. If the task was rejected and sent back, the first thing it sees is the reviewer's note, and it makes that note the goal of the work. If the task is large, it proposes a few subtasks and doesn't create them until the developer agrees.
The code is written in the repository by the assistant itself, the one the developer chose. Vi plays no part in this step and doesn't want to.
When the work is done, the assistant leaves a summary of the changes as a comment on the task and requests a close. The developer sees the files in the IDE, approves, the commit and push happen, and the task moves to the next step of the workflow. If the push fails, the task doesn't move forward. A manager can see which commit and which files belong to the task right on the task itself, without asking anyone for a report.
At no point in these steps did anything happen without the developer knowing.
Teammate or tool: what's the difference in practice?
The difference is where the work is recorded.
An AI teammate usually has its own identity: an account, a seat and a history under its own name. In Vi the assistant has no separate identity. A task it creates is recorded under the person who approved the connection, it doesn't take an extra seat, and every action made through the assistant is logged in the activity history with a mark for that connection. So it is always clear whose hand the work came from, and by which route.
There's one more difference: in Vi the assistant can't do everything, and that's deliberate too. It can't reassign a task to someone else, it can't move a task between workflow steps, it doesn't delete anything and it doesn't touch settings. Those decisions belong to the team. If the workflow rules give a task the assistant created to another person, the assistant tells you so plainly, so you don't assume it's on your own list.
What are the limits of this approach?
To be honest about it:
Vi doesn't review your code. If you want automated code review, use a tool built for that; it doesn't conflict with Vi in any way.
Starting, pausing and closing tasks through the assistant only works when the Vi extension is open and connected in your IDE. If the IDE is closed, the assistant tells you the request didn't reach anyone. The IDEs that have an extension are listed on the IDE project management page.
The cost of the AI itself is yours. Vi doesn't sell a model; the assistant runs on the service you already pay for. The MCP server is available on every Vi plan, including Free.
Why do we think this is the right choice?
Because coding tools age fast and workflows last. The model that writes the best code today may be second or third in six months. If Vi had its own coder, teams would have to either stay with it or drop it. As it is, any assistant that supports MCP will connect to Vi tomorrow too, and a team can switch assistants without switching its project management tool.
And because the loop Vi was built for, from customer request to task, from task to code, and from code back to telling the customer (from customer request to code), needs a responsible person in the middle. AI can make that loop faster. Closing it is a human's job.
Frequently asked questions
Does Vi have its own AI assistant for writing code? No. Vi connects to the assistant you already use, and that assistant writes the code in your repository.
Can the assistant close a task without my permission? No. Closing is only a request, shown in your IDE as a confirmation dialog. Nothing is committed or closed until you review the files and approve.
Does the assistant take commit and push instructions from Vi? No. Vi's server rule is that the assistant must never commit or push on its own because of a task. Those happen either when you explicitly ask, or through Commit & Close after you approve.
Does the assistant count as a separate user on the team? No. It works under your account with your permissions and doesn't take an extra seat.
Which assistants can connect to Vi? Any assistant that supports remote MCP. Setup steps for Claude, Claude Code, Cursor, VS Code and Codex are on the MCP server for AI assistants page.
Can I disconnect it? Yes. Under "AI access" in Vi's settings you'll see the list of connected apps and can disconnect any of them. The workspace owner can also turn AI access off for the whole team.