Cuando la IA vuelve gratis el prototipo, ¿quién lleva a producción?

La IA volvió el prototipado casi gratis. Eso no dejó obsoletos a los equipos de software — movió el trabajo escaso y valioso hacia adelante, hacia quien puede tomar un prototipo y hacerlo sobrevivir a producción. Boris Cherny, creador de Claude Code, le puso nombre al cambio: a medida que ingeniería, producto y diseño se funden, los equipos se organizan menos por cargo y más por cinco roles — Prototyper, Builder, Sweeper, Grower y Maintainer. El rol que acaba de abaratarse es el Prototyper. Los que se volvieron más valiosos son todos los demás.

Los cinco roles de un equipo de producto en la era de la IA

En su framework, Cherny sostiene que estos roles no están atados a una función. Un diseñador puede ser Builder; un ingeniero puede ser Maintainer. Lo que importa es el trabajo que hace la persona, no el título en su perfil:

• Prototyper — genera ideas nuevas y produce muchas, la mayoría de las cuales nunca llega a producción.
• Builder — convierte un prototipo prometedor en un sistema real, de producción.
• Sweeper — simplifica y endurece el código, la UI y los sistemas alrededor.
• Grower — itera sobre un producto lanzado para mejorar el product-market fit.
• Maintainer — lo mantiene seguro, confiable y eficiente a medida que escala.

La idea de fondo: un equipo sano necesita una mezcla distinta de estos roles según el momento del producto. Un producto temprano necesita generación de ideas y construcción. Uno maduro necesita refinamiento, crecimiento y cuidado.

Qué cambió realmente la IA

La IA es el sueño de un Prototyper. Cualquiera pasa de una idea a un demo funcional en una tarde — sin equipo, sin sprint, sin pedir permiso. El rol que era trabajo sénior escaso ahora es abundante.

La abundancia mata el apalancamiento. Cuando todos pueden prototipar, prototipar deja de ser el cuello de botella. La restricción se mueve hacia adelante, a los roles que convierten un demo en algo de lo que un negocio puede depender: Builder, Sweeper, Maintainer. Ese es el trabajo que la IA volvió más valioso, no menos — porque ahora hay mucho más output en bruto exigiendo volverse correcto, seguro y durable.

Un prototipo no es un producto

Un demo que funciona en la laptop del founder y un sistema que aguanta usuarios reales, datos reales y carga real son artefactos distintos, separados por una última milla larga y sin glamour. Autenticación que sobrevive al contacto con atacantes. Un modelo de datos que no se corrompe bajo concurrencia. Arquitectura que aguanta el próximo 10x. Costos que no se disparan.

Esa última milla es justo donde se estanca la mayoría del software hecho con IA. El Prototyper te llevó al 80% en un fin de semana; el 20% restante — el tramo de Builder a Maintainer — es ahora la parte cara, y la que decide si el producto se lanza o muere en silencio en staging. Es el trabajo que hacemos en SV Dev: llevar software hecho con IA y en etapa inicial el resto del camino hasta producción.

Cómo armar el equipo según la etapa del producto

El framework es más útil como lente de contratación. Ajusta la mezcla de roles a donde el producto realmente está:

El fallo común es un equipo atascado en modo Prototyper: un cementerio de demos impresionantes y nada en producción. La IA facilita caer en ese fallo, porque vuelve los prototipos demasiado baratos de producir.

Los roles son capacidades, no headcount

El punto más agudo de Cherny es que esto son capacidades, no cargos — y una persona puede asumir varios. Es justo lo que la IA destraba: un equipo pequeño cubre más del espectro ahora, porque el modelo se encarga de buena parte del trabajo de Prototyper y Builder. Pero ningún modelo cubre todavía el criterio de un Maintainer sobre qué se va a romper a las 3 de la mañana, ni el gusto de un Sweeper sobre qué borrar.

Por eso pensamos los equipos como los pensamos — construimos productos construyendo personas. No contratas Maintainers terminados; desarrollas personas en los roles que el producto va a necesitar a medida que madura. Los títulos se están disolviendo. Las capacidades son lo que de verdad contratas.

Puntos clave

• La IA volvió abundante el rol de Prototyper, así que el valor escaso se movió a Builder, Sweeper y Maintainer — los roles que entregan y sostienen software en producción.
• "Prototipo" y "producto" son artefactos distintos. La última milla entre ambos es donde se estanca la mayoría del software hecho con IA.
• Arma el equipo según la etapa del producto: prototipar y construir al inicio, crecer y limpiar en el medio, mantener a escala.
• Los roles son capacidades, no cargos — desarrolla personas en los que tu producto necesita después.

Preguntas frecuentes

¿Cuáles son los cinco roles de producto en la era de la IA?

Según Boris Cherny, creador de Claude Code: Prototyper (ideas nuevas), Builder (prototipo a producción), Sweeper (simplificar y endurecer), Grower (iterar hacia el product-market fit) y Maintainer (seguridad, confiabilidad y eficiencia a escala).

¿La IA dejó obsoletos a los ingenieros de software?

No. La IA volvió abundante y barata la parte de prototipado. Aumentó el valor de los roles siguientes — convertir prototipos en sistemas seguros, confiables y de producción — porque ahora hay mucho más output en bruto que necesita volverse confiable.

¿Qué rol es el más difícil de automatizar?

El Maintainer. Mantener un sistema seguro, confiable y eficiente a escala depende de criterio sobre modos de falla, trade-offs y contexto que los modelos todavía no sostienen con consistencia.

¿Cómo lo usa una startup en etapa temprana?

Refuerza el equipo en Prototyper y Builder para poner un producto real en manos de usuarios, pero no te saltes el trabajo de Builder a Maintainer antes del lanzamiento — esa última milla es lo que convierte un demo en un negocio.