El tester que escribe código todo el día está desapareciendo

Durante años, muchos testers construimos nuestra carrera alrededor de una habilidad específica: escribir código.

Aprendimos Java, JavaScript, Python. Frameworks de automatización. Patrones de diseño. Cómo mantener miles de líneas de tests sin que todo explote.

Y durante mucho tiempo, eso fue exactamente lo que el mercado pedía y vaya que me ha dado alegrías, laburo y plata.

Pero algo está cambiando. Y si no lo estás viendo todavía, probablemente lo estés sintiendo.

El problema de seguir compitiendo por sintaxis

La mayoría de los profesionales de testing siguen invirtiendo su tiempo en aprender nuevas librerías, nuevos frameworks, nuevos detalles de sintaxis.

El problema es que escribir código ya no es el cuello de botella.

Cursor, Claude Code, Codex, Replit — estas herramientas generan en segundos lo que antes nos tomaba horas. No estoy diciendo que el código desaparece. Estoy diciendo que el valor se está moviendo a otro lugar.

La pregunta ya no es "¿podés escribir este script?"

La pregunta es "¿entendés qué problema hay que resolver, y sabés cómo integrar todas las piezas para resolverlo?"

Son preguntas muy distintas.

Del SDET al arquitecto de calidad

Por mucho tiempo la carrera parecía clara: Tester Manual → Automation Engineer → SDET.

La próxima evolución es diferente.

Estamos viendo aparecer perfiles que diseñan estrategias de testing completas, definen arquitecturas de automatización, orquestan herramientas de IA, supervisan agentes que generan código. El foco deja de estar en escribir cada línea y pasa a estar en diseñar el sistema.

Es la misma transición que ocurrió cuando apareció la nube. De un día para el otro, administrar servidores físicos dejó de ser el skill central para aportar valor.

Esto es lo mismo, pero para el código.

Lo que la IA todavía no sabe hacer bien

Acá está el punto que más se pasa por alto.

La IA es excelente generando soluciones. Es muy mala definiendo qué problema resolver.

Todavía necesita contexto. Todavía necesita criterio. Todavía necesita alguien que entienda qué riesgos tiene el negocio, qué experiencia espera el usuario, qué escenarios importan de verdad, qué vale la pena automatizar y qué no.

Y ahí es exactamente donde los testers tenemos una ventaja enorme.

Porque históricamente nuestro trabajo nunca fue escribir scripts. Nuestro trabajo fue entender riesgos. Siempre lo fue.

La ventaja competitiva de los testers

Los mejores testers que conozco tienen algo en común: no destacan únicamente por programar. Destacan porque entienden sistemas. Entienden cómo fallan. Entienden cómo se comportan los usuarios. Entienden qué puede salir mal antes de que salga.

Ese conocimiento vale más, no menos, en un mundo donde el código se genera cada vez más rápido y más barato.

¿Qué aprender ahora entonces?

Si tuviera que apostar por habilidades para los próximos años, pondría el tiempo en: arquitectura de sistemas, cloud y plataformas modernas, observabilidad, diseño de pruebas, prompt engineering, integración entre servicios, y comunicación con negocio y producto.

No dejaría de aprender programación. Pero dejaría de verla como el objetivo final.

La programación pasa a ser una herramienta más dentro de una caja mucho más amplia.

Para cerrar

La automatización no está muriendo, lo que está muriendo es la idea de que nuestro valor profesional depende exclusivamente de escribir código.

Los testers que le vayan bien en los próximos años probablemente no sean los que escriban más líneas. Serán los que entiendan mejor los sistemas, los riesgos, y las oportunidades que la IA está creando.

Para muchos testers, eso es una muy buena noticia.

¿Y vos? ¿Seguís apostando todo a escribir código, o ya empezaste a expandir la caja de herramientas? En la web tenés TODO lo que necesitás para romperla actualmente en el mercado.