La IA de Vi no escribe código, y es a propósito
Respuesta corta: Vi no construyó un asistente que escriba o revise código, porque los equipos de software ya tienen uno y lo que les falta está en otro lugar: la distancia entre la tarea y el código. El servidor MCP de Vi permite que el asistente que el desarrollador ya usa (Claude Code, Cursor, Codex y otros) lea una tarea, la inicie en el IDE, cree subtareas, comente y pida cerrarla. Todo lo que tiene un efecto duradero, como iniciar o cerrar una tarea, ocurre solo después de que el desarrollador lo aprueba en su IDE. La IA es un par de manos, no un compañero de equipo.
¿Qué está vendiendo el mercado?
Si hoy abres la página principal de casi cualquier herramienta de gestión de proyectos, verás la misma promesa: "Añade un compañero de equipo con IA". Un agente que toma tareas, escribe código, abre pull requests e incluso revisa el trabajo de los demás.
Estas herramientas no son inútiles. Los asistentes de programación realmente han hecho más rápido escribir código, y la revisión automática detecta antes los errores sencillos. Este artículo no dice que sean malos. Dice que una herramienta de gestión de proyectos no tiene motivo para construir uno más.
¿Por qué no construimos otro asistente de programación?
Tuvimos tres razones.
Primero, los desarrolladores ya eligieron su asistente. Quien trabaja con Claude Code no va a cambiar de asistente mañana por culpa de su herramienta de gestión de proyectos. Cada nuevo asistente integrado significa otra ventana, otro modelo y otra factura. Preferimos conectarnos al asistente que ya está abierto en la terminal y en el IDE.
Segundo, escribir código no es el cuello de botella. En la mayoría de los equipos de software el trabajo se atasca en otra parte: una tarea con la descripción a medias, un desarrollador que no sabe bien qué tarea es suya, código ya escrito cuya tarea sigue "en curso" y un cliente que no sabe que su problema está resuelto. Son problemas de cerrar el ciclo, no de teclear.
Tercero, la responsabilidad necesita un dueño. Cuando un agente de IA entra en el equipo y hace commits y cierra tareas con su propia cuenta, una pregunta sencilla se vuelve difícil: si algo sale mal, ¿de quién fue el trabajo? En Vi la respuesta siempre es una persona.
¿Qué hace exactamente el servidor MCP de Vi?
El servidor MCP de Vi está en https://useviapp.com/mcp. El asistente se conecta mediante OAuth con tu propia cuenta y trabaja exactamente con los permisos que tienes en Vi, ni uno más.
Con esa conexión el asistente puede ver proyectos, equipos y miembros, buscar tareas y leer una tarea con sus comentarios y subtareas. Puede crear una tarea o una subtarea y, antes de crearla, busca tareas parecidas para que no se registre trabajo duplicado. Puede comentar en una tarea. Y, sobre todo, puede pedir al desarrollador que inicie, pause o cierre una tarea.
La palabra "pedir" es deliberada. Cuando el asistente dice "voy a iniciar la tarea 12", esa orden llega a la extensión de Vi en el IDE del mismo desarrollador y se abre un diálogo: esta aplicación quiere iniciar la tarea 12, ¿estás de acuerdo? Si el desarrollador lo rechaza, el asistente no empieza el trabajo. Cerrar funciona igual: el asistente lo pide, el desarrollador revisa los archivos y termina el trabajo él mismo con Commit & Close.
¿Cómo es una mañana normal con este enfoque?
El desarrollador abre la terminal y le escribe a su asistente: "Haz la tarea 42".
El asistente envía primero una solicitud de inicio. En el IDE aparece el diálogo de confirmación, el desarrollador acepta y arranca el temporizador de la tarea. Luego el asistente lee la tarea. Si la tarea fue rechazada y devuelta, lo primero que ve es la nota del revisor, y esa nota pasa a ser el objetivo del trabajo. Si la tarea es grande, propone algunas subtareas y no las crea hasta que el desarrollador está de acuerdo.
El código lo escribe en el repositorio el propio asistente, el que eligió el desarrollador. Vi no tiene ningún papel en este paso, ni quiere tenerlo.
Cuando el trabajo termina, el asistente deja un resumen de los cambios como comentario en la tarea y pide cerrarla. El desarrollador ve los archivos en el IDE, aprueba, se hacen el commit y el push, y la tarea pasa al siguiente paso del flujo de trabajo. Si el push falla, la tarea no avanza. Un responsable puede ver qué commit y qué archivos pertenecen a la tarea directamente en la propia tarea, sin pedirle un informe a nadie.
En ninguno de estos pasos ocurrió algo sin que el desarrollador lo supiera.
Compañero o herramienta: ¿qué cambia en la práctica?
La diferencia está en dónde queda registrado el trabajo.
Un compañero de equipo con IA suele tener identidad propia: una cuenta, un puesto y un historial a su nombre. En Vi el asistente no tiene una identidad aparte. La tarea que crea queda registrada a nombre de la persona que aprobó la conexión, no ocupa un puesto extra y cada acción hecha a través del asistente queda en el historial de actividad con una marca de esa conexión. Así siempre está claro de qué mano vino el trabajo y por qué camino.
Hay otra diferencia: en Vi el asistente no puede hacerlo todo, y eso también es deliberado. No puede reasignar una tarea a otra persona, no puede mover una tarea entre pasos del flujo de trabajo, no borra nada y no toca la configuración. Esas decisiones son del equipo. Si las reglas del flujo de trabajo asignan a otra persona una tarea creada por el asistente, el asistente te lo dice claramente para que no pienses que está en tu propia lista.
¿Qué límites tiene este enfoque?
Siendo honestos:
Vi no revisa tu código. Si quieres revisión automática de código, usa una herramienta hecha para eso; no entra en conflicto con Vi en absoluto.
Iniciar, pausar y cerrar tareas a través del asistente solo funciona cuando la extensión de Vi está abierta y conectada en tu IDE. Si el IDE está cerrado, el asistente te avisa de que la solicitud no llegó a nadie. Los IDE que tienen extensión aparecen en la página de gestión de proyectos en el IDE.
El coste de la IA corre de tu cuenta. Vi no vende un modelo; el asistente funciona con el servicio que ya pagas. El servidor MCP está disponible en todos los planes de Vi, incluido el gratuito.
¿Por qué creemos que es la decisión correcta?
Porque las herramientas de programación envejecen rápido y los flujos de trabajo duran. El modelo que hoy escribe el mejor código quizá sea el segundo o el tercero dentro de seis meses. Si Vi tuviera su propio programador, los equipos tendrían que quedarse con él o abandonarlo. Tal como está, cualquier asistente compatible con MCP se conectará también mañana a Vi, y un equipo puede cambiar de asistente sin cambiar de herramienta de gestión de proyectos.
Y porque el ciclo para el que se construyó Vi, de la solicitud del cliente a la tarea, de la tarea al código y del código a avisar al cliente (de la solicitud del cliente al código), necesita una persona responsable en el centro. La IA puede hacer ese ciclo más rápido. Cerrarlo es trabajo de una persona.
Preguntas frecuentes
¿Vi tiene su propio asistente de IA para escribir código? No. Vi se conecta al asistente que ya usas, y ese asistente escribe el código en tu repositorio.
¿Puede el asistente cerrar una tarea sin mi permiso? No. Cerrar es solo una solicitud que aparece en tu IDE como un diálogo de confirmación. No se hace commit ni se cierra nada hasta que revisas los archivos y apruebas.
¿El asistente recibe de Vi órdenes de commit y push? No. La regla del servidor de Vi es que el asistente nunca haga commit ni push por su cuenta a causa de una tarea. Eso ocurre solo si tú lo pides expresamente, o mediante Commit & Close después de tu aprobación.
¿El asistente cuenta como un usuario más del equipo? No. Trabaja con tu cuenta y tus permisos y no ocupa un puesto extra.
¿Qué asistentes pueden conectarse a Vi? Cualquier asistente compatible con MCP remoto. Los pasos de configuración para Claude, Claude Code, Cursor, VS Code y Codex están en la página del servidor MCP para asistentes de IA.
¿Puedo desconectarlo? Sí. En la sección "Acceso de IA" de la configuración de Vi verás la lista de aplicaciones conectadas y podrás desconectar cualquiera. El propietario del espacio de trabajo también puede desactivar el acceso de IA para todo el equipo.