Actualidad
Vibe coding: el x10 no está en el prompt, está en el test
Cuando el equipo trabaja con agentes, lo que antes tardaba semanas sale en días. Gestionar como siempre deja de funcionar. Esto es lo que ha cambiado en mi trabajo, lo que hacen mis agentes y lo que sigo decidiendo yo.
Soy Carolina, Project Manager en Origen. Y antes de que sigas leyendo, aviso: esto no es un artículo sobre «las bondades de la IA». Es sobre cómo he pasado de terminar cada día con demasiadas cosas pendientes a cerrar el portátil con la sensación de haber sacado adelante todo lo importante. Y sobre lo que ocurre cuando el equipo entero empieza a trabajar a otra velocidad.
Spoiler: no es magia. Es tener un segundo par de manos que no se cansa y un equipo humano capaz de aprovecharlas.
Cuando me hablan de estar «agentizada», yo prefiero decir que estoy aumentada. Sigo siendo yo quien decide, habla con el cliente y se pelea con las épicas y las fechas que no cuadran. La diferencia es que ahora tengo detrás distintos agentes, herramientas de IA configuradas para una tarea concreta, con el contexto que necesitan, que me devuelven un resultado listo para revisar. Redactan, resumen, buscan, formatean, auditan. Me liberan de horas de trabajo mecánico pero imprescindible.
Y un equipo aumentado sigue siendo un equipo humano. Los agentes multiplican lo que rinde la gente buena; no la sustituyen.
El agente acelera la ejecución; las personas siguen aportando la experiencia, el conocimiento y el criterio.
Tareas que antes necesitaban semanas ahora pueden estar terminadas en unos pocos días. Suena fantástico, y lo es. Pero cambia por completo la manera de gestionar.
Antes podía preparar un paquete de tareas y tenerlo controlado un par de semanas. Ahora, a mitad de semana, muchas ya han desaparecido del tablero porque están terminadas. Así que trabajar con agentes no reduce la necesidad de gestión. Aumenta su frecuencia.
No se trata de vigilar a nadie ni de caer en el micromanagement. Trabajamos con un tablero Kanban y una reunión diaria, y con eso sé qué está haciendo cada persona, qué está a punto de terminar y quién podría quedarse sin trabajo preparado. El objetivo es ver los bloqueos antes de que frenen al equipo: con ciclos tan cortos, tardar varios días en descubrir que alguien necesita una decisión es tirar a la basura buena parte de la velocidad ganada.
He tenido que reforzar sobre todo dos cosas: coordinar y anticipar. Antes las entregas llegaban cada dos o tres semanas; ahora llegan casi cada pocos días. Y cuanto más rápido va el equipo, más alineados tienen que ir el análisis, el desarrollo, las validaciones y la comunicación con el cliente.
Cuando desarrollar es más rápido, el problema deja de ser la ejecución. El atasco se muda a lo que tiene que estar listo antes de empezar: las decisiones y los análisis funcionales, que el cliente revisa con sus equipos, debate e itera antes de aprobar.
El cliente no valida ahora más despacio que antes. Lo que ha cambiado es nuestra velocidad. Si un desarrollo que antes necesitaba cuatro semanas puede estar terminado en una semana y media, necesito que el siguiente análisis esté aprobado en ese mismo plazo.
Hasta ahora el equipo no se ha quedado parado, aunque alguna vez el colchón de trabajo preparado ha bajado más de lo que me gustaría. Cuando pasa, intensifico el seguimiento con el cliente para cazar las necesidades que estén a punto de concretarse y empezar cuanto antes su análisis, con tiempo para iterarlo y validarlo.
Ya no basta con saber que hoy todo el mundo tiene una tarea. Hay que anticipar qué podrá empezar el equipo dentro de varios días.
Por eso el cliente también forma parte del flujo. Lo que mejor funciona es tener un backlog suficiente de análisis validados, priorizados y listos para implementar. Suficiente, no infinito: si las prioridades cambian, lo acumulado de más se queda viejo. Y si hace falta ampliar el equipo para ir más rápido, solo sirve si ese trabajo previo está hecho. El cliente gana capacidad para incorporar necesidades nuevas, probar antes y reaccionar más rápido; a cambio, tiene que priorizar, validar y reservar sus ventanas de pruebas a ese mismo ritmo.
Antes preparaba semanas de trabajo. Ahora, muchas veces, preparo días. Seguimos teniendo un backlog amplio y una visibilidad de unas 16 o 20 semanas, pero la planificación real se revisa cada semana con el cliente.
Eso no significa cambiar todas las prioridades cada lunes. Significa poder reaccionar cuando aparece algo importante: si el cliente necesita incorporar una nueva compañía o adaptar la plataforma para uno de sus propios clientes, esa petición sube al primer puesto y otros desarrollos esperan. Con este ritmo, un plan cerrado a ocho o doce meses pierde buena parte de su sentido. Se puede mantener una dirección a medio plazo, pero no fingir que el orden de hoy será el mismo dentro de un año.
Tampoco trabajamos por semanas cerradas. El lunes revisamos con el cliente estado y prioridades, y a partir de ahí el proyecto fluye. Cuando una entrega está disponible en UAT, se lo decimos en ese momento, por llamada, correo o Teams, sin esperar al lunes. El viernes no hay cierre especial: el trabajo sigue, y el lunes siguiente volvemos a mirar qué ha avanzado y si algo debe cambiar de orden.
La velocidad trae un «problema», bendito problema: el cliente ve que el desarrollo avanza muchísimo más rápido y puede empezar a pensar que cualquier petición estará lista pasado mañana. Pero todo trabajo sigue necesitando análisis, desarrollo y validación.
Parte de mi función es cuidar esa expectativa. Si una estimación me parece alta o baja, lo digo, pero la respuesta final la da el equipo de desarrollo. Para un usuario, añadir un campo o una columna parece un cambio mínimo. Técnicamente, según dónde esté y a qué afecte, puede ser bastante más.
Nuestro cliente es muy exigente, y sobre todo con los compromisos. Acepta que algo lleve dos, tres o más semanas; lo que necesita es que, en la fecha acordada, la entrega esté disponible para probarla. Detrás de esa fecha hay personas, equipos y ventanas de pruebas que ha tenido que reservar. No podemos terminar una tarea y decirle: «Ya está, pruébala ahora».
Por eso siempre dejamos un pequeño colchón. El mismo equipo que desarrolla también da soporte a la plataforma que ya funciona, y puede caer un servicio o aparecer una casuística que nadie había contemplado. No convertimos toda la velocidad ganada en compromisos más ajustados.
Ir más rápido no rebaja la calidad. Cada funcionalidad tiene que cumplir sus criterios de aceptación, y antes de llegar a UAT cada cambio pasa por sus controles de calidad y seguridad: desde la validación del propio desarrollador hasta las pruebas de un agente de QA. Las prisas se notan enseguida en un entregable flojo, y aunque nada llegue a producción sin validar, lo que el cliente prueba en UAT tiene que estar a la altura.
Y el éxito se mide igual que siempre, con IA o sin ella: un buen resultado en la fecha acordada, que llega a producción con pocas o ninguna incidencia y sin afectaciones críticas.
Parte de esto lo he contado también en vídeo, por si prefieres escucharlo:
Además de gestionar un equipo que va a otra velocidad, uso agentes directamente en mi trabajo.
Me ayudan a entender el código. Hace muchos años que no programo, pero gestiono productos técnicos. Abro el repositorio, les pido que me expliquen cómo funciona una parte concreta y en minutos tengo el contexto para hablar con el cliente con criterio.
Dan forma visual a mis ideas. Si quiero enseñar cómo podría quedar una pantalla o un flujo, les pido un mockup en HTML con varias versiones, sus pros y sus contras. Luego lo iteramos con el cliente en la propia reunión. También me preparan timelines, mapas de funcionalidades y planificaciones, con nuestros colores, tipografías y plantillas.
Llevan la comunicación y las reuniones. Preparan borradores, respuestas y comunicaciones para el equipo, pero soy yo quien revisa y decide qué se envía. Transcriben, resumen y sacan los siguientes pasos.
Ordenan el seguimiento en Jira. Detectan épicas que no cuadran, tareas sin asignar u horas pendientes, y me lo dejan preparado para revisar y decidir.
Las horas de pelea con PowerPoint, de búsqueda o de preparación manual se han quedado en mucho menos.
No basta con tener agentes: la forma de trabajar con ellos marca la diferencia.
Háblale como hablas tú. Los buenos prompts importan, pero no hace falta un manual para cada tarea. Yo soy bastante directa: si me pide que responda diez cosas a la vez, le digo «Pregúntame de una en una, que me estoy volviendo loca». Muchas veces, un «vamos paso a paso y en orden» es todo lo que necesita.
Trabaja en paralelo. Puedo tener varias sesiones abiertas a la vez, cada una con su tarea. Es como tener un equipo entero trabajando conmigo.
Enséñale una vez lo que te importa. Explícale tu tono, tu estética y tu estilo. Lo mantiene mejor que yo un lunes a las nueve.
La IA ejecuta, tú firmas. Nunca sale un correo a un cliente sin que yo lo lea. Nunca se registra nada oficial sin mi confirmación. La frontera la pongo yo, y esto es importantísimo: la IA tiene el poder que tú le des.
Por encima de todo, una empresa que quiera trabajar con agentes necesita personas con criterio profesional. Un agente puede entregar el trabajo de otras manos, pero alguien tiene que revisarlo, cuestionarlo y decidir si está bien. La IA no ofrece una verdad absoluta: su respuesta depende de las instrucciones, del contexto y de muchos otros matices. Hacen falta profesionales capaces de decir «esto no está bien», «este enfoque no es el adecuado» o «esto tiene que cambiar». El criterio no pierde importancia. Se vuelve más necesario que nunca.
Una PM aumentada tiene más capacidad para centrarse en lo que su experiencia hace mejor. Mi trabajo ya no es gestionar una lista de tareas. Es gobernar un flujo que va mucho más rápido: anticipar el siguiente trabajo, coordinar al equipo, mantener la calidad, proteger los compromisos y ayudar al cliente a decidir a tiempo.
Obtener los datos es cada vez más fácil. Lo importante es interpretarlos y decidir qué hacer con ellos. Así puedo dedicar más tiempo a entender y atender al cliente, cuidar al equipo y, por supuesto, tomar las decisiones que ninguna IA debería tomar por mí.
Y, por si te lo estás preguntando: no, este artículo no lo ha escrito la IA. El contenido y las experiencias son míos; ella me ha ayudado a ordenarlos, pulirlos y encontrar mejores formas de explicar algunas ideas, y yo he decidido qué sugerencias aceptar. Ha hecho exactamente lo que cuento aquí: ayudarme a mejorar el resultado sin decidir por mí.
Escrito por
Carolina Gan
Project Manager en Origen
Cuando el equipo trabaja con agentes, lo que antes tardaba semanas sale en días. Gestionar como siempre deja de funcionar. Esto es lo que ha cambiado en mi trabajo, lo que hacen mis agentes y lo que sigo decidiendo yo.
Soy Carolina, Project Manager en Origen. Y antes de que sigas leyendo, aviso: esto no es un artículo sobre «las bondades de la IA». Es sobre cómo he pasado de terminar cada día con demasiadas cosas pendientes a cerrar el portátil con la sensación de haber sacado adelante todo lo importante. Y sobre lo que ocurre cuando el equipo entero empieza a trabajar a otra velocidad.
Spoiler: no es magia. Es tener un segundo par de manos que no se cansa y un equipo humano capaz de aprovecharlas.
Cuando me hablan de estar «agentizada», yo prefiero decir que estoy aumentada. Sigo siendo yo quien decide, habla con el cliente y se pelea con las épicas y las fechas que no cuadran. La diferencia es que ahora tengo detrás distintos agentes, herramientas de IA configuradas para una tarea concreta, con el contexto que necesitan, que me devuelven un resultado listo para revisar. Redactan, resumen, buscan, formatean, auditan. Me liberan de horas de trabajo mecánico pero imprescindible.
Y un equipo aumentado sigue siendo un equipo humano. Los agentes multiplican lo que rinde la gente buena; no la sustituyen.
El agente acelera la ejecución; las personas siguen aportando la experiencia, el conocimiento y el criterio.
Tareas que antes necesitaban semanas ahora pueden estar terminadas en unos pocos días. Suena fantástico, y lo es. Pero cambia por completo la manera de gestionar.
Antes podía preparar un paquete de tareas y tenerlo controlado un par de semanas. Ahora, a mitad de semana, muchas ya han desaparecido del tablero porque están terminadas. Así que trabajar con agentes no reduce la necesidad de gestión. Aumenta su frecuencia.
No se trata de vigilar a nadie ni de caer en el micromanagement. Trabajamos con un tablero Kanban y una reunión diaria, y con eso sé qué está haciendo cada persona, qué está a punto de terminar y quién podría quedarse sin trabajo preparado. El objetivo es ver los bloqueos antes de que frenen al equipo: con ciclos tan cortos, tardar varios días en descubrir que alguien necesita una decisión es tirar a la basura buena parte de la velocidad ganada.
He tenido que reforzar sobre todo dos cosas: coordinar y anticipar. Antes las entregas llegaban cada dos o tres semanas; ahora llegan casi cada pocos días. Y cuanto más rápido va el equipo, más alineados tienen que ir el análisis, el desarrollo, las validaciones y la comunicación con el cliente.
Cuando desarrollar es más rápido, el problema deja de ser la ejecución. El atasco se muda a lo que tiene que estar listo antes de empezar: las decisiones y los análisis funcionales, que el cliente revisa con sus equipos, debate e itera antes de aprobar.
El cliente no valida ahora más despacio que antes. Lo que ha cambiado es nuestra velocidad. Si un desarrollo que antes necesitaba cuatro semanas puede estar terminado en una semana y media, necesito que el siguiente análisis esté aprobado en ese mismo plazo.
Hasta ahora el equipo no se ha quedado parado, aunque alguna vez el colchón de trabajo preparado ha bajado más de lo que me gustaría. Cuando pasa, intensifico el seguimiento con el cliente para cazar las necesidades que estén a punto de concretarse y empezar cuanto antes su análisis, con tiempo para iterarlo y validarlo.
Ya no basta con saber que hoy todo el mundo tiene una tarea. Hay que anticipar qué podrá empezar el equipo dentro de varios días.
Por eso el cliente también forma parte del flujo. Lo que mejor funciona es tener un backlog suficiente de análisis validados, priorizados y listos para implementar. Suficiente, no infinito: si las prioridades cambian, lo acumulado de más se queda viejo. Y si hace falta ampliar el equipo para ir más rápido, solo sirve si ese trabajo previo está hecho. El cliente gana capacidad para incorporar necesidades nuevas, probar antes y reaccionar más rápido; a cambio, tiene que priorizar, validar y reservar sus ventanas de pruebas a ese mismo ritmo.
Antes preparaba semanas de trabajo. Ahora, muchas veces, preparo días. Seguimos teniendo un backlog amplio y una visibilidad de unas 16 o 20 semanas, pero la planificación real se revisa cada semana con el cliente.
Eso no significa cambiar todas las prioridades cada lunes. Significa poder reaccionar cuando aparece algo importante: si el cliente necesita incorporar una nueva compañía o adaptar la plataforma para uno de sus propios clientes, esa petición sube al primer puesto y otros desarrollos esperan. Con este ritmo, un plan cerrado a ocho o doce meses pierde buena parte de su sentido. Se puede mantener una dirección a medio plazo, pero no fingir que el orden de hoy será el mismo dentro de un año.
Tampoco trabajamos por semanas cerradas. El lunes revisamos con el cliente estado y prioridades, y a partir de ahí el proyecto fluye. Cuando una entrega está disponible en UAT, se lo decimos en ese momento, por llamada, correo o Teams, sin esperar al lunes. El viernes no hay cierre especial: el trabajo sigue, y el lunes siguiente volvemos a mirar qué ha avanzado y si algo debe cambiar de orden.
La velocidad trae un «problema», bendito problema: el cliente ve que el desarrollo avanza muchísimo más rápido y puede empezar a pensar que cualquier petición estará lista pasado mañana. Pero todo trabajo sigue necesitando análisis, desarrollo y validación.
Parte de mi función es cuidar esa expectativa. Si una estimación me parece alta o baja, lo digo, pero la respuesta final la da el equipo de desarrollo. Para un usuario, añadir un campo o una columna parece un cambio mínimo. Técnicamente, según dónde esté y a qué afecte, puede ser bastante más.
Nuestro cliente es muy exigente, y sobre todo con los compromisos. Acepta que algo lleve dos, tres o más semanas; lo que necesita es que, en la fecha acordada, la entrega esté disponible para probarla. Detrás de esa fecha hay personas, equipos y ventanas de pruebas que ha tenido que reservar. No podemos terminar una tarea y decirle: «Ya está, pruébala ahora».
Por eso siempre dejamos un pequeño colchón. El mismo equipo que desarrolla también da soporte a la plataforma que ya funciona, y puede caer un servicio o aparecer una casuística que nadie había contemplado. No convertimos toda la velocidad ganada en compromisos más ajustados.
Ir más rápido no rebaja la calidad. Cada funcionalidad tiene que cumplir sus criterios de aceptación, y antes de llegar a UAT cada cambio pasa por sus controles de calidad y seguridad: desde la validación del propio desarrollador hasta las pruebas de un agente de QA. Las prisas se notan enseguida en un entregable flojo, y aunque nada llegue a producción sin validar, lo que el cliente prueba en UAT tiene que estar a la altura.
Y el éxito se mide igual que siempre, con IA o sin ella: un buen resultado en la fecha acordada, que llega a producción con pocas o ninguna incidencia y sin afectaciones críticas.
Parte de esto lo he contado también en vídeo, por si prefieres escucharlo:
Además de gestionar un equipo que va a otra velocidad, uso agentes directamente en mi trabajo.
Me ayudan a entender el código. Hace muchos años que no programo, pero gestiono productos técnicos. Abro el repositorio, les pido que me expliquen cómo funciona una parte concreta y en minutos tengo el contexto para hablar con el cliente con criterio.
Dan forma visual a mis ideas. Si quiero enseñar cómo podría quedar una pantalla o un flujo, les pido un mockup en HTML con varias versiones, sus pros y sus contras. Luego lo iteramos con el cliente en la propia reunión. También me preparan timelines, mapas de funcionalidades y planificaciones, con nuestros colores, tipografías y plantillas.
Llevan la comunicación y las reuniones. Preparan borradores, respuestas y comunicaciones para el equipo, pero soy yo quien revisa y decide qué se envía. Transcriben, resumen y sacan los siguientes pasos.
Ordenan el seguimiento en Jira. Detectan épicas que no cuadran, tareas sin asignar u horas pendientes, y me lo dejan preparado para revisar y decidir.
Las horas de pelea con PowerPoint, de búsqueda o de preparación manual se han quedado en mucho menos.
No basta con tener agentes: la forma de trabajar con ellos marca la diferencia.
Háblale como hablas tú. Los buenos prompts importan, pero no hace falta un manual para cada tarea. Yo soy bastante directa: si me pide que responda diez cosas a la vez, le digo «Pregúntame de una en una, que me estoy volviendo loca». Muchas veces, un «vamos paso a paso y en orden» es todo lo que necesita.
Trabaja en paralelo. Puedo tener varias sesiones abiertas a la vez, cada una con su tarea. Es como tener un equipo entero trabajando conmigo.
Enséñale una vez lo que te importa. Explícale tu tono, tu estética y tu estilo. Lo mantiene mejor que yo un lunes a las nueve.
La IA ejecuta, tú firmas. Nunca sale un correo a un cliente sin que yo lo lea. Nunca se registra nada oficial sin mi confirmación. La frontera la pongo yo, y esto es importantísimo: la IA tiene el poder que tú le des.
Por encima de todo, una empresa que quiera trabajar con agentes necesita personas con criterio profesional. Un agente puede entregar el trabajo de otras manos, pero alguien tiene que revisarlo, cuestionarlo y decidir si está bien. La IA no ofrece una verdad absoluta: su respuesta depende de las instrucciones, del contexto y de muchos otros matices. Hacen falta profesionales capaces de decir «esto no está bien», «este enfoque no es el adecuado» o «esto tiene que cambiar». El criterio no pierde importancia. Se vuelve más necesario que nunca.
Una PM aumentada tiene más capacidad para centrarse en lo que su experiencia hace mejor. Mi trabajo ya no es gestionar una lista de tareas. Es gobernar un flujo que va mucho más rápido: anticipar el siguiente trabajo, coordinar al equipo, mantener la calidad, proteger los compromisos y ayudar al cliente a decidir a tiempo.
Obtener los datos es cada vez más fácil. Lo importante es interpretarlos y decidir qué hacer con ellos. Así puedo dedicar más tiempo a entender y atender al cliente, cuidar al equipo y, por supuesto, tomar las decisiones que ninguna IA debería tomar por mí.
Y, por si te lo estás preguntando: no, este artículo no lo ha escrito la IA. El contenido y las experiencias son míos; ella me ha ayudado a ordenarlos, pulirlos y encontrar mejores formas de explicar algunas ideas, y yo he decidido qué sugerencias aceptar. Ha hecho exactamente lo que cuento aquí: ayudarme a mejorar el resultado sin decidir por mí.
Escrito por
Carolina Gan
Project Manager en Origen
