
Vuelvo a compartir aprendizajes con una verdad incómoda: si en tu equipo todavía destináis a dos o más ingenieros para desarrollar una sola funcionalidad, probablemente os estáis equivocando.
En los últimos cuatro meses, en Punto no ha habido ni una sola funcionalidad en la que hayan trabajado dos ingenieros a la vez. Cada ingeniero es como si fuera un squad. Hemos partido y simplificado muy bien los proyectos y el resultado ha sido radical: un ingeniero, una funcionalidad, valor en producción en días.
¿Cómo es posible? Primero, por el poder de herramientas como Claude Code. La IA ha eliminado las fronteras entre el back y el front; hoy un ingeniero debe ser versátil por definición. Si alguien pide ayuda, es para que le enseñen, no para que le hagan la tarea.
Segundo, esta limitación de un solo ingeniero obliga a una higiene de producto brutal: te obliga a definir mejor y reducir el alcance centrándote exclusivamente en lo que aporta valor real. Si no puedes entregarlo en unos días o máximo una semana, es que no has entendido el problema.
Este modelo nos ha llevado a alcanzar un ritmo de PRs prácticamente diarias por ingeniero, con ciclos de priorización semanal. No es solo una cuestión de capacidad técnica, sino de entendimiento de negocio. Al ser uno solo, el ingeniero se ve obligado a entenderse perfectamente con Producto; la comunicación es directa, sin ruidos de coordinación innecesarios ni tareas que se pierden en el limbo de un equipo sobredimensionado.
Eso sí, no trabajamos aislados. Hemos implementado un sistema de pares entre los desarrolladores para pensar, decidir arquitectura y tener ese ojo externo que revise los principios fundamentales. Pero la ejecución y responsabilidad es individual.
En un mundo donde la IA acelera el desarrollo, el cuello de botella ya no es el código, es la claridad mental para entender y partir el problema e implementar la mejor solución. Piénsalo, ¿por qué necesitas ya tres ingenieros para hacer una funcionalidad?
También puede interesarte

Iterando el prototipo en vivo mientras los usuarios lo prueban
Siempre he hecho tests de usuario para diseñar mejor. Lo que no había vivido antes era poder implementar el feedback en la propia sesión. Lo que antes tardaba semanas, ahora sale en el día.

5 comportamientos que definen a un Product Engineer
La IA hace que programar sea rápido. El reto que queda es entender el problema, plantear una buena arquitectura y fasear con criterio.
