Había una grieta invisible en los equipos de software. Existía antes de que llegaran los LLMs, pero nadie podía verla. Dos tipos de desarrolladores trabajaban codo a codo: los que programaban por amor al proceso y los que programaban para que las cosas funcionaran. El resultado era el mismo. El código salía. No había manera de distinguirlos.
Los asistentes de código con IA la hicieron visible de golpe. Y lo que emergió no fue una conversación sobre herramientas: fue una crisis de identidad profesional que pocas startups están sabiendo leer.
¿Por qué dos developers ven la misma herramienta y llegan a conclusiones opuestas?
Hong Minhee, mantenedor de software de código abierto, describió recientemente esta división con precisión quirúrgica. Su análisis parte de una observación de Les Orchard: hasta que llegaron los asistentes LLM, los craft-lovers (desarrolladores que valoran el proceso artesanal) y los make-it-go people (los que priorizan el resultado) eran indistinguibles. El proceso era el mismo para ambos. Las herramientas no crearon la división: solo la revelaron.
IA para el Resto de Nosotros
La nueva versión de mi curso estrella para aprender a usar la IA de forma práctica, simple y útil en tu día a día. Comienza el 24 de marzo.
→ Inscríbete hoy 🚀Nolan Lawson lo describió desde el lado del duelo: “Vamos a extrañar la sensación de sostener el código en las manos y moldearlo como arcilla en la caricia de un escultor maestro.” No es nostalgia por la dificultad. Es la pérdida del acto en sí.
Para quien programaba buscando el resultado, los LLMs son simplemente el siguiente escalón. Para quien encontraba el sentido en el proceso de construir, los LLMs no aceleran el trabajo: lo cortocircuitan. No eliminan la dificultad; eliminan la parte que importaba.
El mercado como mecanismo de alienación, no la herramienta
Hay un análisis que vale la pena hacer explícito, porque la conversación habitual lo evita: el problema no es el asistente de código. Es la estructura que lo rodea.
Minhee lo señala directamente: “Cuando un desarrollador explica que su productividad se está midiendo contra colegas que usan asistentes LLM, y que los está usando porque necesita el trabajo —no porque quiera—, la fuente de la alienación es obvia. No es el asistente LLM. Es la estructura que ata el sustento a una métrica, y esa métrica ahora favorece a quien produce más output más rápido.”
En las startups esto se siente con más intensidad porque la presión por velocidad es estructural. El runway no espera. La demo no espera. El investor update no espera. El resultado es que el mercado está respondiendo a la pregunta “¿qué hacemos con los desarrolladores más lentos que producen más código artesanal?” con la respuesta más dura posible: que usen herramientas o que dejen el equipo.
El estudio DORA 2025 sobre más de 5.000 desarrolladores confirma la presión: el 90% ya usa IA, pero el 30% no confía en ella. La adopción no es voluntaria para todos: es una respuesta a expectativas externas, no a convicción interna.
La identidad profesional bajo presión: lo que los founders no están viendo
Aquí es donde la conversación se vuelve estratégicamente relevante para quienes construyen equipos de software. Hay dos errores opuestos que los founders suelen cometer.
El primero es ignorar la tensión. Implementar herramientas LLM sin procesar el impacto en la cultura del equipo. Asumir que “si produce más código, todos contentos.” Pero los desarrolladores que sienten que la IA mató su pasión no siempre lo dicen en voz alta. Lo acumulan hasta que se van, o se quedan pero desconectados.
El segundo error es romantizar la artesanía hasta la parálisis. Proteger el proceso de escritura manual como un fin en sí mismo, incluso cuando el output sufre. Tratar la preferencia por no usar herramientas como una postura ética, cuando en realidad es una preferencia de experiencia que tiene consecuencias de negocio.
La realidad es más interesante que cualquiera de los dos extremos: hay desarrolladores para quienes los LLMs son liberadores porque les quitan el trabajo repetitivo y les dejan más tiempo para el diseño de sistemas que les importa. Y hay desarrolladores para quienes los LLMs convierten exactamente la parte que amaban en algo que ya no les pertenece.
Baldur Bjarnason añade otra dimensión a este debate: la mayoría de los entornos de desarrollo ya tienen una relación disfuncional con la calidad. Code review que no funciona bien, test-driven development mal entendido, suposiciones supersticiosas sobre el código. En esos contextos, los LLMs automatizan la disfunción, no el craft. Pero eso no hace el problema más pequeño para quien venía tratando de hacer las cosas bien.
Lo que cambia con la adopción masiva de LLMs en startups
La tesis que vale sostener es esta: los LLMs no transforman a todos los desarrolladores por igual, y asumir que sí tiene costos concretos.
El perfil de quien construye software está cambiando: el orquestador que coordina agentes tiene más peso que el coder que escribe línea a línea. Eso no es necesariamente malo. Pero implica que parte del equipo va a experimentar esa transición como una pérdida de identidad, no como una evolución.
Datos concretos refuerzan esta lectura: un experimento controlado de Anthropic con 52 ingenieros mostró que quienes usaron IA para programar mostraron un 17% menos de comprensión del código que escribieron, medida en tests posteriores. No es que la IA sea mala: es que el proceso de escribir código también era proceso de aprendizaje y comprensión. Al saltarlo, algo se pierde.
El movimiento “Anti-AI Crafting” que está emergiendo en algunos sectores creativos —donde productos hechos a mano están alcanzando precios 10x a 50x superiores a alternativas generadas por IA— sugiere que la distinción entre proceso humano y proceso automatizado va a tener valor de mercado. No en todos los contextos, pero sí en algunos.
Por qué importa para los founders
La respuesta práctica no es elegir un bando. Es entender qué tipo de trabajo tiene el equipo, qué tipo de personas lo hace, y cómo las herramientas LLM cambian la ecuación para cada una.
Para los componentes más repetitivos —tests de boilerplate, scaffolding que se ha escrito cien veces, documentación estructural—, la automatización alivia sin alienar. Para las decisiones de arquitectura, el diseño de sistemas, la resolución de problemas complejos, el valor de hacerlo sin intermediarios sigue siendo alto.
El problema emerge cuando se trata igual el código de infraestructura aburrida que el código que define el producto. Cuando la métrica es solo velocidad de output y no calidad de comprensión. Cuando se presiona para usar herramientas sin dar espacio a procesar qué parte del trabajo define la identidad del equipo.
Las startups que naveguen esto mejor no van a ser las que elijan “todo LLM” o “nada de LLM”. Van a ser las que entiendan cuándo la herramienta libera y cuándo reemplaza algo que no debería reemplazarse. Esa distinción es más fina de lo que parece, y hacerla bien empieza por reconocer que la grieta existe.
