Un asistente te espera. Un compañero de equipo carga con trabajo que no estás supervisando. Esa única diferencia explica la mayor parte de la confusión en la conversación actual sobre la IA en el trabajo, y determina qué partes de tu proceso tienen que cambiar.
Ambos patrones son útiles, y ninguno es una etapa de la que el otro surja por sí solo. Lo que cambia es dónde vive el trabajo, quién responde por él y cómo se entera el resto de lo que pasó. Esta guía traza la línea entre un asistente de IA y un compañero de equipo de IA, enumera las cinco cosas que realmente cambian en la semana de un equipo y dice con franqueza dónde la metáfora del compañero deja de ser útil. Sharkly existe gracias al segundo patrón, así que los límites que siguen se exponen con claridad en lugar de venderse.
Resumen
Un asistente de IA trabaja dentro de tu sesión: tú das la instrucción, él responde, el valor está en tu contexto y desaparece cuando cierras la ventana. A un compañero de equipo de IA se le asigna una unidad de trabajo con un resultado definido, la ejecuta en algún lugar donde el equipo puede verla y reporta a un registro que sobrevive a la sesión. Pasar de uno a otro no requiere mejores modelos. Requiere una asignación, un rastro de ejecución visible, un estado de revisión y una persona que acepte el resultado.
Las definiciones que conviene conservar
Un asistente de IA está acotado al prompt. Tú estás presente durante todo el proceso. El producto del trabajo es una sugerencia que aceptas o descartas, y la cuestión de la responsabilidad nunca surge porque nunca te fuiste. El autocompletado, el chat y la refactorización en línea viven todos aquí.
Un agente de IA, trabajando como compañero de equipo, está acotado a la tarea. Recibe un objetivo, restricciones y contexto suficiente para avanzar. Investiga, ejecuta, prueba y reporta. Tú no estás presente en el tramo intermedio. Esa ausencia es justamente el punto, y también la fuente de todos los requisitos nuevos que siguen. Nuestro artículo de definición sobre codificación agéntica recorre la misma escala desde otro ángulo.
La pregunta que divide no es la inteligencia. Es esta: si cierras el portátil, ¿el trabajo continúa, y puede un colega saber qué pasó?
Lo que realmente cambia en el trabajo
1. El trabajo se convierte en un elemento, no en un mensaje. Con un asistente, la petición es un turno de chat. Con un compañero de equipo, la petición tiene que sobrevivir a que la lea alguien que no estaba en la sala: un resultado declarado, qué entra y qué no entra en el alcance, archivos relevantes, restricciones y cómo se revisará la finalización. Los equipos que se saltan esto escriben tareas vagas y luego culpan al modelo.
2. La asignación se divide en dos. Una persona sigue siendo responsable del resultado. Un agente ejecuta. Las herramientas que funden ambas cosas en un único campo de asignado producen tableros donde no se le puede preguntar nada a nadie. Sharkly mantiene a los asignados humanos y al asignado de ejecución como campos separados en la misma tarea, de modo que ambos hechos quedan registrados a la vez.
3. La visibilidad deja de ser opcional. El trabajo de un asistente es visible porque lo observaste. El trabajo de un compañero de equipo solo es visible si la plataforma transmite el progreso, los comentarios, los bloqueos y un rastro que remite a un registro compartido. De lo contrario, el estado honesto de la mitad de tu trabajo es «pregúntale a Priya, ella lo empezó».
4. La revisión se convierte en un estado con nombre. No «alguien lo mirará en algún momento», sino una señal explícita de espera de revisión humana que llega a una cola. En Sharkly esa señal aterriza en la bandeja de entrada del agente de la persona responsable, junto con los fallos y las preguntas directas.
5. La capacidad se comparte, o se queda en el plano personal. La destreza de un desarrollador con los prompts es un truco de asistente. Guardada como una configuración de agente con instrucciones, entorno de ejecución, repositorios y habilidades reutilizables, se convierte en algo que la siguiente persona hereda en lugar de redescubrir.
| Dimensión | Asistente de IA | Compañero de equipo de IA |
|---|---|---|
| Unidad de trabajo | Un prompt | Una tarea con criterios de aceptación |
| Tú estás presente | Siempre | Para dar dirección y revisar |
| Dónde aterriza el resultado | Tu editor o tu chat | Un registro compartido con un rastro |
| Responsabilidad | Implícitamente tuya | Una persona con nombre, de forma explícita |
| Modo de fallo | Mala sugerencia, descartada | Trabajo silencioso que nadie revisa |
| Reutilización | Hábito personal | Configuración y habilidades guardadas |
Una semana que se ve distinta
Los cambios aparecen en el calendario antes de aparecer en las métricas.
La reunión diaria deja de ser un anuncio de estado, porque el tablero ya lleva el estado. Lo que merece cinco minutos es la lista de excepciones: qué ejecuciones fallaron, qué resultados están esperando a una persona, qué tarea resultó estar tan mal escrita que el agente tuvo que adivinar. Esa lista es corta y es accionable, lo cual ya es más de lo que consiguen la mayoría de las reuniones diarias.
La planificación también cambia de forma. Cuando una tarea tiene que ser lo bastante específica para que un agente la ejecute, el refinamiento se adelanta y se vuelve más concreto: los criterios de aceptación dejan de ser una formalidad porque uno vago produce una ejecución que tienes que tirar. Los equipos suelen notarlo como escribir más alcance por adelantado y perder menos tiempo a mitad del sprint.
La revisión se convierte en el recurso limitado. Tres agentes pueden producir más cambios en una mañana de los que un revisor despacha en un día, así que la restricción real pasa de la velocidad de escritura a la capacidad de lectura. Planifícalo en lugar de descubrirlo: limita cuánto trabajo de agentes está en curso por revisor, y trata una cola creciente de resultados sin revisar como el mismo problema que una pila creciente de pull requests sin fusionar.
Dónde se rompe la metáfora del compañero de equipo
Toma la metáfora al pie de la letra y empezará a llevar a la gente por mal camino de tres maneras.
Un agente no puede asumir responsabilidad. Se le puede atribuir trabajo; no puede responder por un resultado, ni se le puede pedir que justifique una decisión de compromiso el próximo trimestre, ni puede absorber las consecuencias de una mala decisión. Toda plataforma seria de este espacio lo codifica: Linear mantiene a la persona como asignado principal y al agente como contribuidor, y el propio planteamiento de Sharkly es que los agentes investigan, ejecutan, prueban y reportan, mientras que las personas marcan la dirección, conceden autoridad y aceptan el resultado.
Un agente no tiene memoria continua de tu equipo a menos que se la des. Un colega nuevo absorbe el contexto por el simple hecho de estar cerca. Un agente recibe exactamente lo que escribiste, y por eso el alcance escrito siempre gana al alcance implícito.
Y el estado de un agente no es el estado de un proyecto. Una tarea puede quedarse en «En progreso» mientras el agente trabaja, espera una respuesta, espera una revisión o reporta un error. Leer el estado de una ejecución como estado del proyecto es la forma en que los equipos acaban sorprendidos al final de un sprint. Nuestra guía sobre gestión de proyectos con agentes de IA cubre esa separación en detalle.
Qué añadir antes de que los agentes se comporten como compañeros de equipo
Cuatro cosas, en este orden. Ninguna requiere una migración.
- Una tarea con un resultado revisable. Si no puedes decir cómo comprobarías el trabajo, un agente tampoco puede.
- Un asignado de ejecución separado del propietario. Asigna a la persona y al agente en el mismo elemento.
- Una ejecución visible. Progreso, comentarios y un rastro adjuntos a la tarea, que cualquiera del equipo pueda leer.
- Un paso de aceptación. Una persona con nombre mueve el trabajo a hecho después de leer las pruebas, no después de ver que la ejecución terminó.
Añádelas primero para un tipo de trabajo que se repita: actualizaciones de dependencias, cobertura de pruebas en un módulo estable, andamiaje de migraciones. Amplía cuando una segunda persona haya revisado el resultado del agente de otra sin necesidad de un briefing verbal. Descarga Sharkly si quieres ese circuito preconfigurado, o móntalo en el gestor de tareas que ya usas.
Preguntas frecuentes
¿Un agente de IA es solo un asistente con más permisos? Los permisos importan, pero la verdadera diferencia es la unidad de trabajo. Un asistente maneja un prompt dentro de tu sesión; un agente maneja una tarea que sobrevive a la sesión y reporta a un registro compartido.
¿Deberíamos sustituir los asistentes por agentes? No. Los asistentes siguen siendo mejores para todo lo que quieras guiar pulsación a pulsación. Los agentes son para el trabajo que puedes especificar, delegar y revisar.
¿Quién revisa el trabajo de los agentes a escala? Las mismas personas que revisan los pull requests humanos, y por eso la capacidad de revisión se convierte en el verdadero cuello de botella. Empieza midiendo cuánto tardan los resultados en que una persona los abra.
¿Los agentes necesitan sus propias cuentas y permisos? Necesitan acceso acotado, y debería ser tan estrecho como lo exija el trabajo. En la práctica, eso significa repositorios concretos, máquinas concretas y un modelo de roles que decida quién puede activar qué agente. Nuestra explicación de Sharkly Agents muestra una implementación.
