Es frecuente escuchar en equipos técnicos alguna versión de esta frase: “con copilotos ya no se necesita producto”, “ya no se necesita QA”, “ya no hace falta un especialista en esa tecnología”.
La frase suele venir acompañada de una demostración convincente. Alguien le pide al copiloto que escriba una user story, genere casos de prueba, arme una pantalla en una tecnología que no domina o implemente una integración completa. El resultado aparece rápido, prolijo, razonable. A veces incluso mejor que lo que hubiese salido después de varias idas y vueltas entre personas.
Y ahí aparece la tentación: si el copiloto puede producir el artefacto, quizás el rol que antes lo producía perdió sentido. Hay una parte de verdad en esa intuición. Pero también hay un error profundo. El error está en confundir el artefacto con la práctica.
Una user story no es producto. Un test no es calidad. Una pantalla en Swift no es dominio de iOS. Un pull request mergeado no es ingeniería de software. Son expresiones visibles de una práctica más amplia, más lenta de formar y más difícil de automatizar. La IA no elimina esas prácticas. Lo que hace es desestabilizar la forma histórica en que las empaquetamos dentro de roles.
El rol es un envase
Durante las últimas dos décadas, en tecnología fuimos empujando muchas prácticas hacia modelos de especialización. Producto, diseño, QA, backend, frontend, mobile, data, DevOps, seguridad. En algunos casos la especialización llegó a niveles muy finos: Java developer, iOS developer, React developer, especialista en una nube, en una herramienta, en una familia de frameworks.
Esa especialización tuvo sentido. Nos permitió profundizar, profesionalizar prácticas, construir estándares, reducir ambigüedad. Cuando un sistema crece, dividir trabajo no es un capricho burocrático: es una forma de sostener complejidad.
Pero un rol no es una ley natural. Es un envase organizacional. Una manera temporal de agrupar prácticas, responsabilidades, autoridad y conocimiento. Andrew Abbott, en The System of Professions (1988), propuso una idea útil para este momento: las profesiones no son esencias, sino jurisdicciones. No existen porque una tarea les pertenezca por naturaleza, sino porque durante un tiempo logran reclamar autoridad sobre cierto cuerpo de trabajo. Cuando cambian las herramientas, las organizaciones o los mercados, esas jurisdicciones se renegocian. La práctica no necesariamente desaparece. Lo que cambia es quién puede ejercerla, con qué legitimidad y bajo qué nombre.
Producto existía antes de que existiera el rol moderno de product manager. El rol nació en un memo de Neil McElroy en Procter & Gamble en 1931 y tardó más de medio siglo en consolidarse en software: durante los ochenta y los noventa, las decisiones de producto las tomaban fundadores, líderes de ingeniería o el “program manager” de turno. La práctica —cuidar el problema del usuario, priorizarlo, decidir qué construir— ya estaba ahí. Lo que cambió fue quién se dedicaba a sostenerla a tiempo completo. Calidad existía antes de que existiera un equipo de QA. Ingeniería existía antes de que “backend” y “frontend” se separaran como identidades profesionales. Los roles cambian porque las herramientas, las organizaciones y los mercados cambian. Las prácticas profundas cambian más lento.
El copiloto vuelve visible esa diferencia. Si la herramienta permite que una persona produzca más artefactos en menos tiempo, algunas fronteras entre roles empiezan a sentirse artificiales. Tareas que antes necesitaban handoffs ahora pueden ocurrir dentro de una misma conversación entre una persona y su copiloto. Eso no es menor. Es una transformación real del trabajo.
Es el espejo del movimiento que rastreamos al pensar al desarrollador como editor: la función editorial estaba disuelta dentro del acto de escribir código y, cuando los copilotos separaron producción de criterio, se volvió visible como práctica propia. Acá pasa al revés: prácticas que estaban contenidas en roles separados —producto, calidad, especialidad técnica— pueden volver a integrarse en una sola persona acompañada por un copiloto. El movimiento es opuesto, pero la lógica es la misma: los envases organizacionales se acomodan a las prácticas, no al revés.
Integrar no es ahorrar
La discusión más pobre es la del ahorro de headcount. Preguntar “a quién podemos sacar” es una forma chica de mirar una transformación grande.
La pregunta interesante es otra: si el copiloto se vuelve ciudadano de primera clase del equipo de desarrollo, ¿qué prácticas conviene integrar en el flujo persona+copiloto para acelerar el delivery sin perder criterio?
Porque la integración vertical tiene un beneficio enorme de velocidad.
En el modelo tradicional, una idea puede pasar por muchas manos antes de llegar a producción. Alguien detecta una necesidad. Alguien la traduce a requerimiento. Alguien la convierte en historia. Alguien diseña la solución. Alguien implementa. Alguien prueba. Alguien revisa. Alguien despliega. Cada paso agrega valor, pero también agrega latencia. Cada handoff puede perder contexto, introducir interpretación, generar espera.
Con copilotos, parte de esa secuencia puede comprimirse. Una persona con suficiente contexto puede explorar el problema, redactar una primera historia, generar alternativas técnicas, escribir código, producir tests, documentar decisiones y preparar un despliegue. No porque se haya vuelto experta en todo mágicamente, sino porque la herramienta reduce la fricción de producción en cada una de esas capas. Bien usado, acelera mucho.
En equipos chicos, especialmente en América Latina, esta posibilidad es poderosa. No siempre tenemos la estructura ideal, la cantidad de especialistas deseada o el tiempo para procesos extensos. Aprendimos a construir con restricciones. Un copiloto bien integrado puede reducir esperas, acercar decisión y ejecución, y permitir que una persona sostenga un flujo completo con más continuidad.
Negar esa velocidad sería ingenuo. Pero quedarse solo con la velocidad es peligroso.
La práctica no viaja sola
Una práctica no se transfiere a otra persona solo porque el copiloto reduzca la fricción de ejecución. Para mover una práctica, también hay que mover el criterio que la sostiene.
Donald Schön, en The Reflective Practitioner (1983), distinguió dos formas del saber profesional. La racionalidad técnica: la parte explícita, codificable, que se puede escribir en un manual. Y el knowing-in-action: el juicio situado que un profesional ejerce cuando el caso real no encaja en el manual. Schön observaba que casi todo el valor de un profesional vive en la segunda capa, y que la primera —la que es enseñable como procedimiento— es apenas la punta visible. El copiloto absorbe muy bien la racionalidad técnica. No absorbe el knowing-in-action.
Ese es el punto que muchas conversaciones sobre IA pasan por alto. Creemos que si alguien puede producir el artefacto, entonces puede ejercer la práctica. Pero las prácticas importantes no se reducen a sus entregables. Incluyen sensibilidad, lectura de contexto, criterio de riesgo, comprensión de tradeoffs, responsabilidad sobre consecuencias y capacidad de decir que no.
Si una persona que no entiende producto escribe una user story con ayuda del copiloto, puede producir una historia impecable y equivocada. Si una persona que no entiende calidad genera tests con ayuda del copiloto, puede producir una suite prolija que no cubre los riesgos importantes. Si una persona que no entiende ingeniería pone código en producción con ayuda del copiloto, puede entregar rápido y dejar deuda, fragilidad o vulnerabilidades que todavía no se ven. La práctica puede moverse. Pero no debe moverse vacía.
Producto no es escribir stories
Reducir producto a escribir historias es cómodo, pero equivocado. Hacer producto implica entender un problema antes de enamorarse de una solución. Leer señales ambiguas. Distinguir lo que un usuario pide de lo que realmente necesita. Priorizar bajo restricción. Decidir qué no construir. Negociar tradeoffs entre velocidad, experiencia, negocio y riesgo. Convertir incertidumbre en apuestas pequeñas que permitan aprender.
Una story es apenas una forma de cristalizar parte de ese trabajo. El copiloto puede ayudar muchísimo en esa capa. Puede ordenar criterios de aceptación, proponer edge cases, detectar ambigüedades, mejorar redacción, generar variantes. Pero no sabe por sí solo si ese problema importa, si el usuario correcto fue escuchado, si la solución llega demasiado tarde, si la métrica elegida captura valor real o si estamos construyendo algo que se ve razonable pero no cambia nada.
Entonces sí: un ingeniero con buen criterio de producto, acompañado por un copiloto, puede ejecutar muchas tareas que antes dependían de un product manager. Pero la condición no es tener copiloto. La condición es entender la práctica de producto. Si no, solo estamos produciendo documentos con forma de producto.
Calidad no es generar tests
Algo similar sucede con calidad. Durante años confundimos QA con ejecutar casos manuales, reportar bugs o validar una checklist antes del release. Esa reducción hizo que la conversación sobre automatización pareciera obvia: si los tests automáticos cubren lo que antes hacía una persona, entonces el rol desaparece.
Pero calidad nunca fue solo ejecutar tests. Calidad es entender riesgo. Saber qué caminos del usuario son críticos. Imaginar cómo falla un sistema en producción. Distinguir un bug cosmético de una falla que erosiona confianza. Preguntarse qué pasa si el servicio externo cae, si el dato llega duplicado, si el usuario abandona a mitad de flujo, si una migración parcial deja al sistema en un estado imposible.
Los tests son importantes. Pero son el residuo ejecutable de una mirada de riesgo.
El copiloto puede generar tests rápido. Puede cubrir casos repetitivos, sugerir escenarios, completar mocks, automatizar regresiones. Eso es valioso. Pero si nadie tiene criterio para decidir qué merece ser probado, qué falla sería inaceptable y qué riesgo no está expresado en los tests, la práctica de calidad quedó huérfana aunque la suite crezca todos los días.
Cuando desaparece QA como rol separado, alguien tiene que heredar su autoridad. No solo su tarea. Alguien tiene que poder decir: esto no sale.
Esa autoridad es lo que en otro artículo llamamos criterio como infraestructura: no un control burocrático ni un trámite de compliance, sino la condición que define el techo de calidad de lo que el equipo es capaz de producir. Si nadie sostiene esa función, el techo baja sin que nadie lo haya decidido explícitamente.
Ingeniería no es escribir código
El caso más visible es ingeniería. Hoy parece que cualquiera puede hacer código y ponerlo en producción. En cierto sentido, es verdad. La barrera de entrada bajó de manera brutal. Una persona sin experiencia profunda puede construir una app, automatizar un proceso, crear una integración, levantar una API, desplegar algo funcional. Lo que antes requería años de aprendizaje puede aparecer en horas.
Eso es extraordinario. Pero solo si recordamos que desarrollar software siempre fue más que escribir líneas de código.
Ingeniería es entender cómo una decisión local afecta al sistema completo. Es diseñar límites entre componentes. Es elegir dependencias con conciencia de futuro. Es pensar observabilidad, operación, seguridad, performance, mantenibilidad, rollback. Es saber cuándo una solución que funciona hoy se vuelve una trampa mañana. Es leer código no solo para ver si compila, sino para entender qué forma le está dando al sistema.
El copiloto puede escribir código. A veces muy buen código. Pero no responde automáticamente por la arquitectura que está creando, por la complejidad que introduce ni por el costo operativo que deja detrás. Por eso la democratización del desarrollo es real, pero incompleta. Más personas pueden participar en la construcción de software. Eso es bueno. Pero participar no es lo mismo que dominar, y producir no es lo mismo que hacerse cargo.
El riesgo de las prácticas sin dueño
Cuando una práctica estaba contenida en un rol, ese rol no solo producía artefactos. También sostenía memoria, estándares, autoridad y responsabilidad.
El product manager no solo escribía historias: protegía una lectura del usuario y del negocio. QA no solo probaba: sostenía una sensibilidad por el riesgo. El especialista técnico no solo escribía en un lenguaje: conocía las trampas de una plataforma. El arquitecto no solo dibujaba diagramas: cuidaba la coherencia del sistema a largo plazo.
Podemos discutir si esos roles estaban bien diseñados, si generaban demasiados handoffs, si ralentizaban decisiones o si se habían vuelto burocráticos. Muchas veces sí. Pero eliminarlos o diluirlos sin redistribuir explícitamente sus prácticas deja un vacío.
Ese vacío no siempre se ve al principio. Los tickets se cierran. Las PRs se mergean. Los tests pasan. El delivery acelera. Hasta que nadie sabe quién decide que una funcionalidad no debería construirse. Nadie sabe quién tiene autoridad para frenar un release. Nadie sabe quién cuida la consistencia de la experiencia. Nadie sabe quién mira la deuda técnica que todavía no duele. Nadie sabe quién enseña a los demás a ejercer esa práctica con criterio.
El vacío trabaja despacio. Primero aparece como segundas derivadas: un incidente que nadie supo anticipar, un cliente que se va por un detalle que nadie cuidaba, una decisión arquitectónica que se sostiene seis meses y se derrumba en el séptimo. Como nadie tiene el rol explícito, esas consecuencias se atribuyen a otras causas. Y como nadie las defiende en la próxima planificación, la práctica pierde tiempo, atención y presupuesto. La organización no decidió bajar su criterio: lo bajó por omisión, en muchos pasos chicos.
Ese es el peligro real: no que desaparezca un rol, sino que una práctica crítica quede sin dueño porque todos asumieron que el copiloto la absorbía.
Rediseñar alrededor de prácticas
La respuesta no es defender todos los roles como si fueran eternos. Tampoco es disolverlos todos en nombre de la velocidad. La respuesta es rediseñar el equipo alrededor de prácticas. Antes de preguntar qué roles sobran, conviene hacer preguntas más precisas:
- ¿Qué prácticas son críticas para que este equipo construya bien?
- ¿Qué parte de cada práctica es producción de artefactos y qué parte es criterio?
- ¿Qué puede acelerar el copiloto sin pérdida significativa de calidad?
- ¿Qué requiere todavía juicio humano entrenado?
- ¿Quién tiene autoridad explícita para responder por esa práctica cuando el rol ya no existe como especialista separado?
Esa última pregunta importa especialmente. Si un equipo decide que los ingenieros van a asumir más trabajo de producto, entonces necesita formar criterio de producto. No basta con darles una plantilla de stories y acceso a un copiloto. Tienen que aprender a investigar, priorizar, conversar con usuarios, leer métricas, formular hipótesis y decidir qué no construir.
Si un equipo decide que la calidad se integra al flujo de desarrollo, entonces necesita formar criterio de calidad en quienes desarrollan. No basta con generar más tests. Tienen que aprender a pensar en riesgo, regresión, criticidad y operación.
Si una organización permite que perfiles no tradicionales construyan software con copilotos, entonces necesita crear mecanismos para que esa producción tenga revisión, arquitectura, seguridad y aprendizaje. No para frenar la creatividad, sino para que la creatividad no se convierta en fragilidad.
Detrás de cada una de esas preguntas hay una constante: las prácticas críticas no se transfieren por decreto, se forman. Y las disposiciones que las hacen formables son las mismas que ya nombramos al pensar el seniority en la era del copiloto: curiosidad para entender un dominio que no es el propio, pensamiento crítico para distinguir el artefacto del criterio, agencia para hacerse cargo de una práctica que antes pertenecía a otro. Sin esas disposiciones, redistribuir prácticas es solo redistribuir tareas.
En este nuevo modelo, los especialistas no necesariamente desaparecen. Cambia su centro de gravedad.
Algunos dejarán de ser los únicos ejecutores de una práctica y pasarán a ser sus guardianes, formadores y reviewers. Menos cuello de botella, más multiplicadores de criterio. Menos “pasame el ticket y yo lo hago”, más “te ayudo a que puedas hacerlo bien”. Ese movimiento puede ser incómodo para quienes construyeron identidad profesional alrededor de una especialidad cerrada, pero también puede ser una forma más alta de impacto.
La especialidad no desaparece. Se vuelve más estratégica.
Las dos verdades
Hay dos verdades que conviene sostener al mismo tiempo.
La primera: integrar verticalmente prácticas en el binomio persona+copiloto acelera muchísimo el delivery. Menos handoffs, menos espera, menos traducción entre roles, más continuidad entre intención y ejecución. En un mundo donde la velocidad de aprendizaje importa, esa ventaja no es menor.
La segunda: esa integración solo es progreso si conserva el criterio que antes aportaba la especialidad. Si absorbemos la tarea pero no la maestría, ganamos velocidad y perdemos profundidad. Si mantenemos todos los roles intactos por miedo a perder criterio, podemos proteger calidad pero quedar lentos frente a equipos que aprendieron a integrar mejor.
Quedarse solo con la velocidad deja al equipo manco de criterio. Quedarse solo con la defensa de los roles lo deja manco de velocidad. La madurez está en sostener las dos verdades a la vez. No preguntar “¿qué rol podemos eliminar?”, sino “¿qué práctica podemos integrar responsablemente?”. En lugar de “¿quién puede producir este artefacto?”, la pregunta más útil suele ser “¿quién entiende lo suficiente para hacerse cargo de esta decisión?”. Y antes de “¿el copiloto puede hacerlo?”, una pregunta que se sostiene mejor en el tiempo: “¿persona+copiloto pueden hacerlo con la misma o mayor maestría que antes?”.
Porque cuando el rol desaparece, la práctica no desaparece con él. La práctica queda. Y si nadie la toma con criterio, la organización no se volvió más liviana. Solo dejó de ver una parte esencial de su propio trabajo.
¿Qué prácticas de tu equipo están todavía atadas a roles que quizás podrían cambiar? ¿Qué parte de esas prácticas puede acelerar el copiloto, y qué parte requiere formación real? ¿Dónde estás integrando velocidad sin perder criterio, y dónde quizás solo estás produciendo artefactos más rápido?