Saltar al contenido principal

La muerte del frontend tradicional y el ascenso del Product Engineer

  • #Product Engineer
  • #Frontend
  • #Arquitectura
  • #Tooling
Ilustración del artículo: La muerte del frontend tradicional y el ascenso del Product Engineer
Ilustración del artículo: La muerte del frontend tradicional y el ascenso del Product Engineer

Maquetar componentes en React y pelearse con márgenes de CSS nunca fue una disciplina técnica aislada. Hoy cualquier agente te saca un diseño de Figma a código y te escribe los tests en dos minutos. Quien limitaba su día a picar etiquetas y enlazar un par de botones compite ahora con herramientas que hacen eso al instante y gratis. Picar sintaxis nunca fue la parte difícil. Lo valioso siempre ha sido entender el producto end-to-end: saber qué datos necesita la pantalla, entender cómo fluye el estado y resolver problemas reales sin delegar el criterio en terceros.

El fin de la frontera artificial

Durante años se normalizó una cadena de traspasos absurda:

  • Diseño preparaba pantallas en Figma sin contrastar la viabilidad del modelo.
  • Frontend abría un ticket en Jira reclamando los endpoints.
  • Backend tardaba dos semanas en devolver un JSON con nombres de campo inconsistentes.
  • Nadie se responsabilizaba de si la consulta dejaba la base de datos temblando.

Montar una “muralla burocrática” entre la interfaz y los datos nunca tuvo sentido; hoy es insostenible. Con buen criterio técnico y herramientas modernas, definir el contrato con TypeScript, gestionar el estado en cliente, conectar el endpoint y dejar la interfaz lista con feedback instantáneo se hace en la misma tarde. Quitar intermediarios permite que quien diseña la experiencia de usuario entregue la funcionalidad completa, sin quedarse de brazos cruzados esperando a que otro departamento le desbloquee un ticket.

Construcción de software end-to-end

Las cinco áreas donde de verdad se juega la partida cuando dejas de ser un mero maquetador.

  1. Arquitectura de estado y contratos de datos

    Tipado estricto de extremo a extremo, contratos de API compartidos y estado predecible sin sorpresas.

  2. Rendimiento web y carga sin grasa

    Carga inmediata, componentes sin re-renders fantasma y cero kilobytes de JavaScript si un HTML basta.

  3. Sistemas de diseño vivos y accesibles

    Tokens sincronizados, componentes accesibles por defecto y consistencia visual sin reinventar la rueda.

  4. Sistemas agénticos y herramientas con contexto

    Agentes que ejecutan cambios de UI guiados por tests y contratos, no por ocurrencias al vuelo.

  5. Validación defensiva y control de cambios

    Tests de integración de flujos críticos, linters implacables y filtros de CI que evitan sustos en producción.

La resaca del “vibe coding”

Lanzar a un agente a escupir trescientas líneas sin supervisión queda muy aparente en redes. La resaca llega en producción, cuando el componente entra en bucles infinitos de renderizado y el navegador no da hecho con las peticiones a la API.

Escribir sintaxis siempre fue la parte fácil. Lo complicado es diseñar una interfaz que no se desmorone a los dos meses. Hace falta entender el ciclo de vida del estado, esquivar renderizados innecesarios y mantener la accesibilidad al día. Blindar la interfaz con tests y construir arneses para que los agentes no puedan hacer otra cosa que resolverlo bien es lo que permite entregar en una tarde lo que antes atascaba al equipo durante semanas.