¿Están muriendo los roles tradicionales del desarrollo? Los cinco arquetipos de Boris Cherny

Hace unos días, Boris Cherny —el creador y líder de Claude Code en Anthropic— publicó en Twitter algo que generó bastante conversación: la idea de que los roles típicos de la industria (ingeniería, diseño de producto, diseño web, ciencia de datos) se están fusionando en un nuevo tipo de rol, impulsados por la IA. Y para ilustrarlo, propuso cinco arquetipos que observó dentro de su propio equipo.

Me pareció interesante porque sé que muchos ya tienen esta sensación, sobre todo si son freelancers o están levantando sus propios proyectos y terminan haciendo de todo. Pero lo que vale la pena analizar es que aquí estamos hablando de roles que pertenecen a una empresa, y eso importa: a futuro quizás ustedes estén buscando trabajo y se topen con esta forma de pensar los equipos. Así que vale la pena entender si realmente vale la pena enfocarnos en esto o simplemente dejarlo pasar como una moda de ponerle nombres bonitos a las cosas.

Los cinco arquetipos

La propuesta de Cherny no divide a las personas por frontend o backend, ni por su título de trabajo. Describe lo que realmente se necesita en cada etapa de un proyecto.

1. El Prototyper (prototipador). Es la persona que genera ideas nuevas, muchas, sabiendo que la mayoría no va a llegar a producción. Se me ocurre pensar en quienes participan en un hackathon: crean distintos proyectos muy rápido, no necesariamente usables, pero llevan una idea a algo tangible en el menor tiempo posible. O simplemente: se te ocurrió algo, lo generas en unos minutos, y deja de estar solo en tu cabeza para convertirse en una demo básica. El problema es que ideas tiene todo el mundo, y muchos de esos prototipos no llegan a nada real. Por eso se necesita el siguiente.

2. El Builder (constructor). Toma la idea del prototipo y empieza a añadirle piezas de verdad para convertirlo en algo de grado producción. Aquí pienso en quienes hacen vibe coding sin conocimientos técnicos, usando plataformas tipo Lovable, Bolt, v0 o Replit, pero que en algún punto —por falta de conocimiento o porque quieren ocuparse de otra cosa— dejan de mejorar el proyecto. Y ahí se topan con algo que los desarrolladores conocemos bien: el software no tiene un fin, siempre se sigue mejorando. El builder es quien le añade lo necesario para que el proyecto funcione en una nube, escale en usuarios y llegue a un entorno de producción real.

Pero ojo: llevar algo a producción no significa que ya esté terminado. Puede estar funcionando, tener servicios reales, y aun así faltarle una revisión. Por ejemplo, un proyecto que sube archivos a S3 pero al eliminarlos los deja huérfanos; o una autenticación que funciona pero no tiene OTP; o roles definidos en el backend pero sin verificación de permisos. Cosas que, sinceramente, me he encontrado muchas veces.

3. El Sweeper (el que limpia). Aquí entra quien limpia el proyecto: UIs rotas o que lucen claramente generadas por IA, código que necesita revisión, optimización de rendimiento, unship de cosas innecesarias. No es un rol muy vistoso porque no implementa nada nuevo —de hecho, muchas veces quita código o archivos que el proyecto no necesita. Es como un control de calidad, pero no solo a nivel de UI (eso sería más bien el QA), sino del proyecto en general.

4. El Grower (el que hace crecer). Ya no hablamos de que el proyecto esté limpio o funcione —para eso están las fases anteriores—, sino de alguien más enfocado en el producto y en la interacción con el usuario, iterando para mejorar el product-market fit. El proyecto puede funcionar perfectamente y resolver el problema, pero quizás el usuario no lo entiende o no se sabe cómo entregárselo para que lo use. Y aunque pueda parecer poco técnico, hacer que el usuario entienda tu proyecto es una parte importante que muchos minimizan.

5. El Maintainer (mantenedor). Cuando el proyecto ya está funcionando y maduro, esta es la persona que hace cambios constantes y se encarga de que el sistema sea seguro, confiable, rápido y eficiente a medida que escala.

Lo más interesante: no son roles, son modos de trabajo

Si lo notan, estos cinco parecen más modos de trabajo que roles propiamente dichos. Y el propio Cherny lo reconoce: muchas personas abarcan dos arquetipos a la vez, a veces tres. No están atados a tu función en la empresa —entre los diseñadores de Anthropic, algunos encajan en el arquetipo 1, otros en el 2, otros en el 3; y lo mismo pasa con ingenieros, PMs y científicos de datos.

Lo que define cuál arquetipo necesitas no es tu cargo, sino la etapa del proyecto:

• Un producto que recién empieza necesita una combinación de los tres primeros (Prototyper + Builder + Sweeper).
• Un producto que está creciendo se apoya más en el dos, tres y cuatro, con algo de soporte del mantenedor.
• Un producto maduro, con mercado definido, se enfoca en los últimos (Sweeper, Grower, Maintainer), tomando prestado al Builder cuando hace falta.

La crítica más válida que leí

En las respuestas al tweet apareció una observación que comparto. El riesgo de definir arquetipos es que es fácil que alguien los lea, piense "ah, ese soy yo" y deje de cuestionarse. En la realidad, el rol de una persona debe evolucionar junto con el proyecto: cuando empiezas algo eres prototyper y builder, pero muy pronto te vuelves sweeper cuando los bordes ásperos se convierten en el cuello de botella, y luego grower y maintainer a medida que madura. Si te encasillas en un arquetipo, tendrías que abandonar el proyecto en algún punto del camino.

El consejo que rescato de ahí: mantente flexible, obsesiónate con lo que sea importante para lograr tu objetivo, y preocúpate menos por los límites de roles que van a seguir difuminándose.

El contexto que le falta al tweet

Algo que vale la pena entender es de dónde sale esta idea. En el equipo de Claude Code, según ha contado el propio Cherny, los PRDs (documentos de requerimientos de producto) prácticamente murieron: en lugar de escribir especificaciones, construyen decenas de prototipos funcionales antes de lanzar una feature. Su frase fue clara: no habrían podido lanzar ciertas cosas si hubieran empezado con mockups estáticos en Figma o con un PRD.

¿Por qué? Porque cambió la economía de construir. Antes, el costo de construir era alto, así que tenías que apuntar con cuidado antes de disparar, porque corregir el rumbo después era difícil. Ahora el costo de construir es muy bajo, pero tampoco sabemos hacia dónde apuntar, así que toca probar y ver qué se siente bien. Es un proceso mucho más exploratorio, y de ahí nace la lógica de los arquetipos: están pensados para construir, no para encasillar.

El otro lado: cuando se trata de contratar

Acá viene mi reserva. Estos arquetipos son interesantes, pero no creo que sea tan fácil implementarlos en un trabajo de verdad. Se nota que vienen de ingenieros o de personas que tratan de construir algo, no de recursos humanos. Porque al momento de pagarle a alguien, sí necesitas darle un rol bien definido. No es tan simple como "trabaja en estos tres roles según lo que pida el proyecto".

Y eso se confirma si entran a la página de empleos de Anthropic: ahí están los roles típicos. Necesitan ingenieros de IA en muchas áreas, otros enfocados solo en ciencia de datos, otros solo en marketing y ventas. Y la mayoría de esas posiciones piden seniority —perfiles de 10 años de experiencia o más—, algo normal para una de las empresas más importantes en torno a la IA.

El antecedente: el Forward Deployed Engineer

Esto me recuerda a un rol del que hablé hace aproximadamente un mes: el Forward Deployed Engineer (FDE). Es una persona que trabaja dentro de una empresa de IA —OpenAI, Anthropic, etc.— y se encarga de implementar una solución real en empresas que tienen algún tipo de asociación con ellas.

La idea es esta: un banco quiere implementar algún tipo de análisis con IA usando modelos de OpenAI o Anthropic. Entonces la empresa de IA le envía a sus ingenieros, no para hacer un análisis, sino para crear la solución en el menor tiempo posible y que el cliente pueda empezar a consumir lo que realmente venden estas empresas: los tokens. Es básicamente armarte el producto para que empieces a consumir la API.

Y este rol no es menor. Pasó de ser una contratación táctica a una categoría estratégica: en mayo de 2026, las dos mayores empresas de IA del mundo lanzaron unidades de negocio dedicadas a esto casi al mismo tiempo. OpenAI creó "The Deployment Company", con más de 4 mil millones de dólares en compromisos empresariales anunciados, y Anthropic anunció una empresa conjunta de 1.5 mil millones con Blackstone y Goldman Sachs para incrustar ingenieros de Claude dentro de clientes del sector financiero.

En Anthropic, por cierto, a este rol lo llaman Applied AI Engineer —el mismo trabajo, distinto nombre, que refleja su cultura más orientada a la investigación. Y la compensación da una idea de qué tan en serio se lo toman: se reportan rangos que van de los 350 mil a más de un millón de dólares dependiendo del nivel, benchmarkeados contra los ingenieros de investigación. Las publicaciones de empleo para FDE subieron alrededor de 800% interanual.

Lo interesante es que el FDE va en la misma línea que los arquetipos de Cherny: construir algo y entregar un resultado, en lugar de enfocarse en el rol. Es alguien que prototipa, construye, despliega y transfiere conocimiento, todo en cuestión de semanas.

Entonces, ¿los roles tradicionales están muriendo?

En lo personal, no lo creo —y lo pueden verificar viendo los puestos que se están contratando actualmente. Pero sí es cierto que estos días ya puedes llegar a construir proyectos por ti mismo, y que muchos roles eventualmente se van a combinar.

Mi expectativa concreta: probablemente ya no veamos a futuro roles como puro frontend o puro backend, pero quizás sí ingenieros de software que cubran ambas partes. ¿La razón? Es simple: la IA puede hacer el trabajo muy rápido, pero igual se necesita alguien que lo revise y, sobre todo, que lo diseñe bien. La IA te da muchas rutas posibles, y al final alguien tiene que decidir por cuál ir.

Estos arquetipos me parecen una forma bonita de nombrar las cosas, pero en la práctica pueden ser mucho más complejos de aplicar. Yo los tomaría como una anécdota interesante, no como un manual. Son, en buena medida, formas de trabajo más que roles, y describen el ciclo completo de desarrollo de un proyecto con nombres nuevos.

Si me preguntan, el consejo es el mismo: sigan tranquilos, estudien el área que les da la base para aprender de software. A partir de ahí sí van a existir áreas de especialización, pero al momento de contratar es muy probable que veamos cada vez más roles simplificados en uno solo.

Esa es mi expectativa, y ustedes pueden tener otra. ¿Creen que los roles están muriendo o es simplemente una moda de nombrar cosas y todo va a seguir igual? Los leo en los comentarios.

¿Quieres profundizar en algún tema de IA, desarrollo o infraestructura? En fazt.dev puedes reservar asesorías personalizadas sobre cualquier tema.