¿Claude Code te convierte en menos fundador?

Resumen

Dirijo eesel, una empresa de IA, y seré honesto: la mayor parte de nuestro código ahora lo escribe un agente de IA, buena parte de este blog lo redacta uno, y una proporción creciente de nuestros propios tickets de soporte los resuelve uno. Así que cuando los fundadores me preguntan si Claude Code los está convirtiendo silenciosamente en menos fundadores, no lo tomo como una hipótesis. Llevo dos años viviendo con esa pregunta.

Esta es mi respuesta. Claude Code no te convierte en menos fundador. Elimina la parte del fundar que nunca fue el punto, y expone la parte que siempre lo fue. Escribir el código nunca fue el trabajo. Saber qué construir, juzgar si el resultado es bueno y ser dueño del resultado es el trabajo, y la IA hace los tres más valiosos, no menos.

El verdadero riesgo no es para tu identidad. Es para tu criterio, y solo si dejas de revisar lo que la máquina te entrega. Los fundadores que se vacían son los que entregan código que nunca leyeron. Los que se afilan mantienen las manos en el volante y dejan que el agente conduzca.

La ansiedad es real, pero apunta en la dirección equivocada

La preocupación suele salir así: "Si yo no lo escribí, ¿lo construí realmente? Y si sigo sin escribirlo, ¿lo olvidaré?"

Es algo razonable de sentir. Cuando abres Claude Code y lo ves leer toda tu base de código, editar una docena de archivos, ejecutar las pruebas y abrir un pull request mientras tomas café, la vieja medalla de honor, yo escribí cada línea a mano, deja de sentirse tuya. Los números lo hacen vívido. El ingeniero Gergely Orosz, que entrevistó al equipo que construye Claude Code, reportó que el 90 % del propio código de Claude Code lo escribe Claude Code, que los ingenieros allí fusionan alrededor de cinco pull requests al día, y que el rendimiento de pull requests por ingeniero subió un 67 % el año en que todos lo adoptaron.

Pero fíjate en lo que la ansiedad realmente lamenta. Lamenta el tecleo. Y teclear siempre fue lo menos valioso que hacía un fundador. Las partes difíciles de construir una empresa, decidir qué merece existir, sentir dónde el producto está mal, elegir qué recortar, nunca estuvieron en las pulsaciones de tecla. Estaban en tu cabeza. Claude Code no toca eso. Simplemente despeja el trabajo manual del camino para que haya más espacio para ello.

Qué se atrofia en realidad, y qué no

Permíteme ser preciso, porque aquí vive la versión honesta de la respuesta. Algo sí se atrofia. Solo que no lo que imaginarías.

Un desarrollador que usó Claude Code treinta días seguidos escribió uno de los relatos más francos que he leído. Entregó más en un mes que en los seis anteriores, y al mismo tiempo vio cómo una habilidad lo abandonaba en silencio:

"En la segunda semana me di cuenta de algo perturbador: estaba perdiendo la capacidad de escribir código desde cero. ¿Para qué pensar en un algoritmo si Claude Code podía generarlo al instante? Me estaba convirtiendo en un gestor del output de la IA en lugar de un programador."

Prassanna Ganesh Ravishankar, 30 días con Claude Code

Esa última línea lo dice todo, y si es una tragedia depende completamente de la palabra "gestor". Si eres un programador cuyo valor es escribir algoritmos de memoria, convertirte en gestor del output de la IA es una pérdida. Si eres un fundador, convertirte en un gestor más agudo del output es exactamente el ascenso que llevas años intentando darte. La habilidad que se atrofia es la que un fundador debería haber estado delegando de todas formas.

Lo que no se atrofia, a menos que lo descuides activamente, es el criterio. El ingeniero principal Jesse Altman dio en el clavo con el cambio: escribir código, dijo, ya no es la parte difícil, y "la parte más desafiante y que más tiempo consume del proceso es ahora la toma de decisiones y luego la comunicación de esa información". Eso no es una degradación de tu rol. Es una descripción de lo que fundar siempre ha sido.

El encuadre más claro que he visto viene del educador de IA Santiago Valdarrama, que traza la línea entre dos modos:

"Modo 1: la IA escribe el código y el humano copilota. Modo 2: el humano escribe el código y la IA copilota. Estos dos son muy distintos. Uno no reemplaza al otro. Los desarrolladores profesionales usan ambos. El IDE sigue siendo el rey."

Santiago Valdarrama en X

Un fundador vive principalmente en el Modo 1, y eso es correcto. Muchos builders también mantienen abierto un copiloto basado en editor como Cursor para el trabajo del Modo 2, y eso está bien. La trampa no es estar en el Modo 1. La trampa es estar en el Modo 1 con los ojos cerrados.

La línea divisoria: quién se afila, quién se vacía

Esta es la parte que nadie quiere escuchar, así que lo diré sin rodeos. Claude Code hace mejores a los buenos fundadores y peores a los fundadores perezosos, y la diferencia está en si sigues leyendo el output.

El cuento de advertencia está en todas partes cuando lo buscas. Un líder de ingeniería describió cómo entregó un feature 5 veces más rápido, lo vio pasar cada prueba y luego miró el código real para encontrar que la IA había escrito cinco métodos casi idénticos en lugar de una función reutilizable. Su veredicto me quedó grabado:

"La IA optimiza para 'haz que funcione', no para 'haz que sea mantenible'. Lo que hoy ahorra tiempo crea deuda técnica mañana. Lo que funciona: tratar a la IA como un desarrollador junior que necesita revisión."

jkeaney en LinkedIn

Esa frase, un desarrollador junior que necesita revisión, es toda la disciplina en cinco palabras. Nunca dejarías que un junior brillante, rápido y ligeramente arrogante fusionara en main sin revisar. El momento en que empiezas a hacer eso con un agente de IA es el momento en que la herramienta empieza a vaciarte, porque has dejado de ejercitar el único músculo que importa.

Un desarrollador de diez años expresó la misma idea como consejo, y se lo daría a cada fundador que entrega con IA:

"Los ingenieros que ganarán no son los que más usen la IA. Son los que la usen para multiplicar su propio entendimiento. Claude Code no es un atajo. Es un multiplicador, pero solo si traes los fundamentos a la mesa."

@ujjwalscript en X

Léelo como fundador y cambia "ingenieros" por "fundadores". Los fundadores que ganan no son los que más automatizan. Son los que usan la automatización para multiplicar su propio criterio y alcance. Los fundamentos que aportas son criterio, sentido del producto y la disposición a decir "no, eso está mal, hazlo de nuevo".

Cómo se ve esto desde el asiento del builder

No estoy teorizando aquí. En eesel hemos vibe-codeado partes reales del producto, probado internamente un escritor de contenido con IA durante seis meses antes de confiar en él en el blog público, y ejecutamos agentes de IA en nuestra propia cola de soporte. He visto a un agente seguro de sí mismo entregar algo sutilmente incorrecto, que es exactamente por qué ahora simulamos cada cambio contra el historial antes de que salga en vivo en lugar de creer en la demo. El apalancamiento es real y los modos de fallo también, y vivir con ambos fue lo que me enseñó dónde está realmente la línea.

Este es el patrón que veo en literalmente cada cliente que adopta bien la IA, y es el mismo arco que yo mismo recorrí. Nadie cuerdo pasa directamente al piloto automático total. Empiezan con la IA redactando respuestas, mientras un humano aprueba cada output. Luego, a medida que la confianza se construye sobre resultados reales, la dejan manejar la rutina sola y hacen revisiones puntuales. Finalmente el humano deja de hacer el trabajo y empieza a marcar la dirección. No te ganas la cima de esa escalera con nervio. Te la ganas con criterio.

También hay una señal más silenciosa en todo esto. Un cliente que nos dejó una vez me dijo, en el mismo aliento que su cancelación, que a largo plazo "simplemente construiría el suyo, lo cual es tan posible ahora con la IA". Hace cinco años esa frase habría sido una fantasía. Ahora es una reunión de directorio. Herramientas como Lovable y OpenAI Codex ponen un prototipo funcional al alcance de alguien que no puede escribir un bucle for. La barrera para hacer software se ha derrumbado, lo que significa que lo escaso se ha movido. Ya no es quién puede construirlo. Es quién sabe qué vale la pena construir y puede decir si lo que se construyó es realmente bueno. Eso es trabajo de fundador, y de repente hay mucho más de eso disponible.

Vale la pena mantener honestos a los escépticos, sin embargo, porque las ganancias no son gratuitas. El ingeniero Michael Novati señaló bien el punto de calibración: un agente de IA sale ganando si reemplaza aunque sea el 1 % del esfuerzo de un ingeniero, pero convertir eso en apalancamiento real es una habilidad que tienes que aprender, no un interruptor que activas. Esperar milagros y recibir el primer borrador de un junior es como la gente acaba decepcionada. La herramienta es un multiplicador de lo que ya aportas, y un multiplicador de cero sigue siendo cero.

Entonces, ¿te convierte en menos fundador?

Solo si le dejas tomar tus decisiones.

Usado con los ojos abiertos, Claude Code es la herramienta que más amplifica al fundador que he tocado. Toma lo que siempre debiste delegar, la producción manual, y te lo devuelve como un borrador para juzgar. Deja que un equipo de dos entregue como uno de diez. Convierte "tengo una idea pero no tengo tiempo para construirla" en "veámosla esta noche". Nada de eso te convierte en menos fundador. Hace que las habilidades del fundador, criterio, gusto y decisión, sean las únicas cosas que siguen siendo escasas.

Usado con los ojos cerrados, te construirá gustosamente una torre de código plausible, no probado y duplicado que no entiendes y no puedes mantener, y eso te convertirá en menos fundador, porque habrás externalizado no solo el tecleo sino el pensamiento. La herramienta no decide qué fundador te conviertes. Lo decides tú, cada vez que eliges si lees el diff.

Prueba eesel

El mismo cambio que está golpeando al código está golpeando al soporte al cliente, y es por eso que construí eesel. Claude Code es infraestructura para construir software; eesel es el compañero de equipo de IA que contratas para realmente ejecutar un trabajo, en este caso tu cola de soporte. Lo conectas a Zendesk, Freshdesk, Gmail o donde vivan tus tickets, entrena con tus propios tickets pasados y centro de ayuda, y empieza a redactar y resolver desde el primer día, mientras te mantienes exactamente en el bucle de copiloto a autopiloto del que trata todo este post: redacta, tú apruebas, y le das más cuerda a medida que se gana tu confianza simulando cada cambio contra tu historial real primero.

Si tiene sentido para ti delegar tu código sin perder tu criterio, delegar tu soporte de la misma manera también lo tendrá. Puedes probar eesel gratis y tener un agente en marcha en minutos, sin llamada de ventas requerida.