Una auditoría que hice del front end de mi propio producto encontró cuatro listas editables que seguían las filas por posición sobre arrays que se modificaban en el lugar. Compilaba, y nada en el build se quejaba. Eliminar una fila del medio hacía que el framework reutilizara el nodo del DOM de la fila borrada para el siguiente ítem, así que el estado de input y de foco de cada fila podía quedar asociado a la fila equivocada hasta un re-render completo. Una revisión centrada en el estilo aprobaría ese diff. Corregí las cuatro y agregué un spec que fija ese comportamiento. Detectar ese tipo de bug es ahora una parte más grande del trabajo.
Netguru escribe que el trabajo senior de front end en 2026 se parece menos a escribir componentes y más a dirigir un sistema que los escribe. La primera parte coincide con lo que veo: producir un componente ya no es donde está el valor. El resto lo describiría de otra forma. Dirigir suena a gestión, y el trabajo se siente más como leer, decidir y hacer que lo incorrecto sea difícil de hacer.
Construyo mi propio producto, MailHive, con Angular 21 y un flujo de trabajo asistido por IA, y hasta agosto fui el único desarrollador front-end en un equipo de cinco desarrolladores en BMO. En ambos casos, el componente nunca fue la parte difícil. La IA solo quitó el escudo que antes daba tener que teclearlo.
Lee el Comportamiento, Porque el Estilo Dejó de Ser Evidencia
El código generado se ve limpio. Buenos nombres, estructura ordenada, comentarios en los lugares correctos. Antes eran señales débiles de que el autor lo había pensado bien. Ahora son una evidencia mucho más débil. Tienes que leer qué hace el código cuando cambia el estado.
Que las haya escrito una persona o un modelo no le cambia nada al revisor. La trampa es la misma en los dos frameworks con los que trabajo:
<!-- Angular. Position is not identity when the list mutates. -->
@for (condition of conditions; track $index) { ... }
<!-- Follows the object while its reference is stable. Prefer condition.id if you have one. -->
@for (condition of conditions; track condition) { ... }{/* React. Same trap. */}
{rows.map((row, i) => <Row key={i} {...row} />)}
{/* Follows the item. */}
{rows.map(row => <Row key={row.id} {...row} />)}Un concepto como este se traslada entre Angular y React. Una lista de nombres de herramientas, no.
Hazte Cargo de los Estados Por los Que Nadie Preguntó
Pide una pantalla y obtienes la pantalla. Obtienes el happy path, bien renderizado. El trabajo senior es la lista que el prompt no mencionó: la cuenta vacía, la red lenta, el guardado que falla con la mitad del formulario cambiado, el permiso revocado a mitad de sesión, el lector de pantalla, la etiqueta en francés mucho más larga que la de inglés. Si has trabajado de Figma a producción, sabes que esta lista es la mayor parte del trabajo real.
Mi experiencia en UX ayuda aquí. Esos estados son una decisión de producto antes de ser código. ¿Qué debería ver el usuario cuando esto falla, y puede recuperarse? Un modelo inventará una respuesta sin ningún problema. Alguien tiene que notar que eso era una decisión, y llevársela a la persona responsable de ella.
Convierte Tu Criterio en Restricciones
Revisar el mismo error dos veces es una señal de que el control debería automatizarse. La primera vez que lo ves, pregúntate si una máquina puede detectarlo de ahí en adelante. Esto es parte de lo que vive hoy en el repositorio de MailHive, varios elementos salidos de una auditoría del repositorio y no de un solo bug:
- Reglas de lint que aplican los límites entre módulos, de modo que un nuevo import de una feature a otra falla, con las violaciones existentes en una línea base.
- Reglas de accesibilidad para templates en cada template nuestro, con las violaciones existentes en una línea base para que solo fallen las nuevas.
- Un control de que los cuatro archivos de idioma tengan las mismas claves, para que una clave de traducción faltante haga fallar el pipeline y no al usuario.
- Instrucciones de proyecto que la IA lee, más un registro de bugs pasados que no debe repetir, donde cada entrada tiene que hacer referencia a un incidente real.
- Registros de decisiones que explican por qué se tomó una decisión de arquitectura, para que ni yo ni un modelo la reabramos por accidente.
Cada uno hace que las próximas mil líneas generadas sean un poco más seguras. La investigación DORA de Google llama a la IA un amplificador de las fortalezas y debilidades que una organización ya tiene. A la escala de un repositorio, lo que se amplifica son las restricciones, o la falta de ellas.
Di Que No Temprano, Porque el Código Es Demasiado Fácil de Agregar
Cuando agregar código no cuesta casi nada, la tentación es agregarlo. Cada abstracción, helper y servicio generado igual tiene que ser leído, testeado y migrado por alguien más adelante. Borrar código y negarse a generarlo también cuentan como trabajo. MailHive tiene un job de CI, knip, que falla ante código de front end sin usar, porque el volumen por sí solo terminará enterrando a un producto pequeño.
Con las grandes reescrituras pasa lo mismo. Un modelo planificará y redactará una sin ningún problema, y no estará ahí para explicarle la regresión al cliente. Alguien tiene que sopesar el riesgo contra lo que gana el negocio, y decir en voz alta cuando la respuesta es no.
Conserva la Habilidad Que Te Permite Juzgar
Por eso, para mí, dirigir no describe el trabajo. Solo puedes juzgar un hallazgo como esas cuatro listas porque entiendes cómo un framework reconcilia una lista. Juzgas el código generado con un conocimiento que vino de escribir y depurar código. Si dejas de construir ese conocimiento, tus revisiones se debilitan, despacio, y nada te avisa.
No tengo una respuesta limpia para ese riesgo, sobre todo para quienes están al comienzo de su carrera. El Digital Economy Lab de Stanford encuentra que el empleo de personas de 22 a 25 años en trabajos muy expuestos está alrededor de un 19% por debajo de donde estaría si hubiera seguido el ritmo de sus pares menos expuestos, sin una brecha comparable para trabajadores con experiencia. Los autores lo llaman descriptivo, no causal. Aun así me preocupa, porque los juniors de hoy son de donde salen los próximos seniors. Lo que intento hacer yo: profundizar a propósito en las áreas de las que soy responsable. Escribir yo mismo la parte difícil cuando necesito entenderla. Tratar una explicación de la IA como una hipótesis inicial, y después leer la documentación del framework y el test que falla.
Qué Mostrar en una Entrevista
Un post del blog de Stack Overflow de octubre de 2026 les deja a los empleadores una frase que vale la pena conservar: contrata por criterio, no por una lista de herramientas. El dominio de herramientas importa, pero es la parte más fácil de mostrar, y hoy la mayoría de los candidatos pone Copilot o Claude Code en su lista. Estas son las historias que yo prepararía en su lugar, con un ejemplo real para cada una:
- Una vez que detectaste algo que parecía correcto y estaba mal. ¿Qué lo delató?
- Un guardrail que agregaste después de un error, y lo que ha detectado desde entonces.
- Un estado o flujo que nadie especificó, y cómo lograste que se tomara la decisión.
- Algo que decidiste no construir, y lo que eso ahorró.
- Cómo decides qué resultado de la IA recibe una lectura detallada y cuál una rápida.
Cada una de esas es una historia sobre criterio, y el criterio es lo que el rol pide ahora.
Referencias
- Netguru. Is frontend development dying? https://www.netguru.com/blog/is-frontend-development-dying
- Stack Overflow Blog. Is AI really reshaping the developer market? October 2026. https://stackoverflow.blog/2026/10/22/is-ai-really-reshaping-the-developer-market/
- Brynjolfsson, Chandar, Chen. Canaries in the Coal Mine, Stanford Digital Economy Lab. https://digitaleconomy.stanford.edu/publications/canaries-in-the-coal-mine/
- DORA. 2025 State of AI-assisted Software Development. https://dora.dev/research/2025/dora-report/
- Angular. Track expressions in @for blocks. https://angular.dev/guide/templates/control-flow
- React. Why React needs keys. https://react.dev/learn/rendering-lists
- knip. https://knip.dev/