A veces me cuesta separar mi historia personal de la historia de nuestra profesión, porque en tecnología muchos llegamos aprendiendo como se podía: leyendo documentación, copiando ejemplos, rompiendo cosas, preguntando en foros, mirando código ajeno y volviendo a intentar cuando algo no funcionaba. Algunos pasaron por la universidad, otros por cursos, otros por trabajos que los obligaron a aprender a los golpes. Pero casi nadie pudo vivir de lo que aprendió una sola vez. En software, tarde o temprano, todos tenemos que volver a aprender sin pedir demasiado permiso.
A mediados de mayo, esa idea me volvió a aparecer por un camino inesperado: un paper sobre médicos haciendo vibe coding. No desarrolladores profesionales, no equipos de producto, no startups buscando levantar inversión, sino clínicos intentando construir pequeñas herramientas para resolver problemas concretos de su día a día. Y ahí se me mezclaron varias conversaciones que venimos teniendo en este blog: la IA como acelerador, el peligro de confundir velocidad con criterio, y ese lugar incómodo donde la credencial visible no siempre coincide con el oficio real.
Cuando alguien que conoce el problema empieza a construir#
A fines de abril se publicó en arXiv un trabajo llamado “Vibe coding for clinicians: democratising bespoke software development for digital health innovation”. La idea central es simple y potente: muchas personas que trabajan en salud se encuentran todos los días con problemas demasiado específicos, demasiado pequeños o demasiado poco atractivos comercialmente como para que una empresa de software los resuelva. Son dolores reales, pero no siempre tienen mercado. Entonces quedan ahí, sostenidos por planillas, procesos manuales, atajos, notas, formularios mal adaptados y paciencia humana.
El paper plantea que el vibe coding puede abrir una puerta interesante para ese tipo de casos. Un médico o una médica que entiende muy bien el problema, pero no sabe programar en profundidad, puede usar lenguaje natural para prototipar una herramienta sencilla, validar una idea o darle forma inicial a algo que antes dependía por completo de conseguir tiempo técnico. No lo presentan como reemplazo de desarrolladores profesionales. Al contrario, el texto habla de habilidades de base, desafíos, límites y guardrails para llevar algo a despliegue. Esa aclaración es importante, porque cambia por completo el tono de la conversación.
La novedad no es que ahora cualquiera pueda construir cualquier sistema serio sin saber nada. Esa fantasía ya la discutimos varias veces y, cuanto más la miramos, menos se sostiene. La parte interesante es otra: personas que antes estaban condenadas a explicar un problema una y otra vez, esperando que alguien con capacidad técnica tuviera tiempo para escucharlas, ahora pueden producir una primera forma. Imperfecta, limitada, probablemente insegura si se la empuja donde no corresponde, pero suficiente para mostrar una intención con más fuerza que una reunión o un documento.
Esto conecta con algo que en desarrollo conocemos muy bien. A veces la persona que más entiende el problema no es la que sabe escribir el código más elegante. Y a veces la persona que sabe escribir el código más elegante no entiende todavía qué parte del problema duele de verdad. Cuando esas dos cosas se encuentran, aparece buen software. Cuando se separan demasiado, aparecen sistemas correctos en los papeles y torpes en la realidad.
Por eso el ejemplo de los clínicos me resulta más interesante que otro anuncio de herramienta para developers. Nos obliga a mirar la programación no solo como escritura de código, sino como una forma de convertir comprensión del mundo en algo ejecutable. Y si lo pensamos así, el autodidacta entra naturalmente en escena. No como el héroe solitario que sabe más que todos, sino como alguien que no espera a que el camino esté completamente autorizado para empezar a entender.
La profesión siempre tuvo algo de autodidacta#
El tema del autodidacta en tecnología es delicado porque se puede caer muy rápido en dos caricaturas. De un lado está la romantización: el genio que aprende solo, desprecia todo título, no necesita a nadie y descubre verdades que los demás no ven. Del otro lado está la desconfianza automática: si no pasó por el camino formal, entonces su conocimiento es sospechoso, incompleto o amateur. Las dos miradas son pobres.
La realidad de nuestra profesión suele ser más mezclada. Hay gente formada en universidades excelentes que además se sigue formando sola toda la vida. Hay gente sin título que construyó una profundidad técnica enorme a fuerza de curiosidad, trabajo y errores. Hay gente con credenciales fuertes que dejó de aprender hace años. Y hay autodidactas que confunden independencia con soberbia, que también los hay. Ningún camino garantiza criterio por sí solo.
Lo difícil de negar es que el software, como oficio, premia la capacidad de aprender por cuenta propia. No porque el aprendizaje formal no sirva, sino porque la velocidad del campo lo vuelve insuficiente si se queda quieto. Stack Overflow, en su encuesta de 2024, decía que los recursos online eran la principal forma de aprender a programar para el 82% de las respuestas, y que la documentación técnica seguía siendo una fuente central de aprendizaje. Un año después, la encuesta de 2025 mostraba que más de un tercio de quienes respondieron habían aprendido a usar herramientas de IA para su trabajo o carrera en el último año. No hace falta leer esos datos como una celebración de “la educación formal murió”; alcanza con leerlos como una señal de algo que vivimos todos los días: programar es estudiar en movimiento.
Y estudiar en movimiento no es cómodo. No tiene el orden de un programa cerrado ni la tranquilidad de que alguien ya filtró todo por nosotros. Muchas veces aprendemos porque un error nos dejó sin salida, porque una librería cambió, porque una arquitectura ya no alcanza, porque un proveedor modificó sus reglas, porque una herramienta nueva aparece y no podemos ignorarla. El autodidacta, en ese sentido, no es necesariamente alguien que aprende solo en una habitación. Es alguien que aprendió a no quedarse esperando a que el permiso, el curso perfecto o la certificación ideal lleguen antes que la necesidad.
A mí esa actitud me interesa. No como rebeldía adolescente contra las instituciones, sino como una forma adulta de responsabilidad. Cuando un problema cae sobre la mesa, alguien tiene que leer, probar, preguntar, equivocarse, volver a leer y construir una opinión propia. En equipos técnicos reales, esa capacidad vale muchísimo. Y en una época de IA, probablemente valga más, no menos.
Juzgar por los ojos, tocar con las manos#
En el capítulo XVIII de El Príncipe, Maquiavelo escribe que los hombres juzgan más por los ojos que por las manos, porque todos pueden ver pero pocos pueden tocar. La frase aparece en un contexto político, hablando de apariencia, reputación y poder. Pero llevada con cuidado a nuestro mundo, sirve para pensar la diferencia entre lo visible y lo vivido.
En tecnología también juzgamos mucho por los ojos. Vemos títulos, cargos, nombres de empresas, certificaciones, repositorios con muchas estrellas, dashboards, métricas, presentaciones prolijas, demos que funcionan. Todo eso puede aportar información, claro. No hay que despreciarlo. Un título puede representar años de esfuerzo; una certificación puede ordenar conocimiento; una trayectoria en una empresa exigente puede decir algo sobre la experiencia de una persona. El problema aparece cuando confundimos esas señales con la totalidad del oficio.
Tocar con las manos es otra cosa. Es haber tenido que sostener un sistema cuando el caso feliz se terminó. Es haber hecho una migración que parecía simple y no lo era. Es haber leído documentación hasta entender por qué una API se comporta distinto de lo que prometía. Es haber aceptado una dependencia y después pagar el costo. Es haber arreglado un incidente sin tener todo el contexto, o haber dicho que no a una solución que brillaba en la demo pero no cerraba con la realidad del equipo.
Ese conocimiento no siempre queda bien empaquetado en una credencial. A veces tampoco queda bien explicado en un CV. Pero se nota cuando la conversación se pone concreta. Se nota en las preguntas que alguien hace, en los riesgos que anticipa, en la humildad con la que valida, en la capacidad de decir “esto no lo sé” sin quedarse paralizado. Ahí aparece el oficio.
Por eso el autodidacta valioso no es el que rechaza la mirada de los demás, sino el que aprendió a tocar el problema con las manos. No se queda solamente con lo que parece correcto. Lo prueba, lo contrasta, lo rompe si hace falta, y recién después empieza a confiar.
La IA baja la barrera, pero también baja algunas defensas#
Acá entra la parte nueva de esta época. Durante años, aprender por cuenta propia exigía atravesar cierta fricción. Había que leer documentación, instalar cosas, pelear con errores tontos, entender un mensaje de compilación, buscar en foros, comparar respuestas, preguntar de una manera que otros pudieran responder. Esa fricción era molesta, pero también enseñaba. Obligaba a construir paciencia, vocabulario y criterio mínimo para saber qué estaba pasando.
La IA cambió parte de ese recorrido. Hoy alguien puede describir una idea y obtener una primera versión funcional sin atravesar todo ese camino previo. Eso es impresionante. También es peligroso si se confunde con aprendizaje completo.
En el post anterior, cuando hablamos de lo que la IA no puede diseñar, la idea de fondo era que producir no es lo mismo que entender. Lalit Maganti pudo construir en tres meses algo que llevaba ocho años postergando, pero también tuvo que tirar un mes entero de trabajo porque el código funcionaba sin que él lo entendiera lo suficiente. Ese caso era de un ingeniero experimentado. Ahora imaginemos ese mismo fenómeno en manos de alguien que recién está entrando a un dominio técnico, o que conoce muy bien el problema de negocio pero todavía no sabe distinguir un prototipo de una base mantenible.
Ahí aparece una tensión que me parece central: la IA puede volver más autodidacta a mucha gente, pero también puede permitirle saltear aprendizajes que antes eran incómodos y necesarios. Puede ayudar a explorar más rápido, pero también puede tapar la ignorancia con una respuesta que suena segura. Puede acercar al médico, al analista, al operador o al fundador de una pyme a la construcción de una herramienta útil, pero si no hay una práctica de validación, también puede dejarlo con una pieza que parece software y se comporta como una deuda esperando su momento.
GitHub, en su Octoverse 2025, mostró una señal interesante: más de 36 millones de desarrolladores se sumaron a la plataforma en un año, y casi el 80% de los nuevos desarrolladores usó Copilot durante su primera semana. La IA ya no está entrando al final del recorrido, como una herramienta avanzada para gente con años de oficio. Para mucha gente, está en el inicio. Eso cambia la forma en que se aprende, y todavía estamos entendiendo qué se gana y qué se pierde en ese cambio.
Mi intuición es que se gana velocidad, acceso y confianza para empezar. Y eso no es poco. Pero se puede perder algo si no somos cuidadosos: la relación directa con el error. Esa relación áspera, incómoda y a veces frustrante que te obliga a entender por qué algo no funciona. Si la IA nos resuelve siempre la próxima línea antes de que hayamos masticado el problema, corremos el riesgo de avanzar con menos cicatrices, pero también con menos profundidad.
Autodidacta no es aprender sin otros#
Hay una confusión habitual que conviene sacar del medio: ser autodidacta no significa aprender aislado. De hecho, casi nadie aprende así. Aprendemos leyendo a otros, copiando patrones, haciendo preguntas, mirando cómo una comunidad resuelve problemas, recibiendo correcciones, discutiendo con gente que sabe más, y también enseñando lo poco que vamos entendiendo. Lo autodidacta no está en la ausencia de otros; está en la iniciativa propia para ordenar ese aprendizaje.
Esto importa porque la IA puede empujar una versión demasiado solitaria del aprendizaje. Una conversación con un modelo puede ser muy útil, pero si se convierte en el único espejo, nos puede dejar encerrados en una burbuja muy prolija. El modelo responde siempre, no se cansa, no se ríe de la pregunta, no nos expone frente a nadie. Eso ayuda a animarse, especialmente al principio. Pero también puede quitar una parte valiosa del aprendizaje técnico: la fricción con otras miradas.
En un equipo, una mala idea no solo se corrige con un test. A veces se corrige porque alguien pregunta “¿por qué lo hiciste así?”. O porque otro recuerda que esa integración ya falló antes. O porque una persona de producto explica un caso que no habíamos considerado. O porque alguien con más experiencia reconoce un patrón de deuda que todavía no se ve en la superficie. Esa conversación no es un trámite; es parte del aprendizaje.
El autodidacta que más me interesa no es el que se encierra en su propio criterio, sino el que se vuelve dueño de su proceso de aprendizaje sin volverse dueño absoluto de la verdad. Sabe buscar solo, pero también sabe pedir revisión. Sabe avanzar sin permiso, pero no sin responsabilidad. Sabe construir una hipótesis, pero la pone a prueba. Sabe que una respuesta de la IA puede destrabar una idea, pero no la convierte automáticamente en conocimiento propio.
En este punto la credencial y el autodidactismo dejan de ser enemigos. Una buena formación formal puede dar bases, lenguaje, disciplina y mapa. Una buena actitud autodidacta permite seguir caminando cuando el mapa se queda viejo. Lo que necesitamos en tecnología no es elegir una contra la otra, sino combinar lo mejor de ambas: fundamentos y curiosidad, método y hambre, comunidad y autonomía.
La objeción honesta#
La objeción a esta defensa del autodidacta es necesaria: aprender por cuenta propia también puede salir mal. No todo cuestionamiento es profundidad. No toda independencia es criterio. A veces el autodidacta se enamora de su propio camino y empieza a despreciar cualquier advertencia externa. Confunde no haber pedido permiso con no necesitar revisión. Y ahí deja de ser una fortaleza para convertirse en un riesgo.
Esto se vuelve todavía más sensible con IA, porque la herramienta puede reforzar esa ilusión. Si uno le pregunta con suficiente insistencia, casi siempre obtiene una explicación que acompaña su dirección. Puede pedir una arquitectura, después pedir argumentos para defenderla, después pedir respuestas a las objeciones, y terminar rodeado de texto convincente sin haber pasado por una validación real. Antes el autodidacta tenía que pelearse más con la realidad; ahora puede pelearse durante horas con una simulación de realidad que le contesta muy bien.
Por eso no me gusta romantizar. Hay autodidactas brillantes y autodidactas peligrosos, del mismo modo que hay profesionales formados excelentes y profesionales formados que se esconden detrás del diploma. La diferencia no está en el origen del aprendizaje, sino en la relación con la verdad, con el error y con los demás.
Un autodidacta sano no se define por aprender solo, sino por hacerse cargo de lo que todavía no sabe. Esa es la parte menos vistosa y más importante. No alcanza con decir “yo aprendo por mi cuenta” si después no verificamos, no leemos documentación, no dejamos que otros revisen, no entendemos los límites de lo que construimos y no aceptamos cuando una decisión propia estaba mal. La autonomía sin humildad se parece demasiado a la improvisación.
También conviene reconocer algo incómodo: las instituciones cumplen una función. No todo sello es decorado. En medicina, en ingeniería civil, en seguridad, en sistemas críticos, las credenciales, los procesos y las revisiones existen porque el costo del error puede ser enorme. El problema no es que existan filtros; el problema es creer que el filtro reemplaza al criterio, o que quien no pasó por ese filtro no puede construir comprensión genuina en ningún terreno.
Lo que conviene cuidar en esta nueva etapa#
Si el vibe coding para clínicos nos dice algo, no es que los médicos vayan a reemplazar a los equipos de software ni que los desarrolladores profesionales nos volvimos accesorios. Nos dice que la frontera de quién puede empezar a construir se está moviendo. Personas con conocimiento profundo de un dominio van a poder prototipar más. Equipos chicos van a poder probar más ideas. Gente que antes quedaba afuera del primer paso técnico va a poder acercarse. Eso es bueno.
Pero cuanto más se abre la puerta de entrada, más importante se vuelve enseñar qué hay después de la puerta. No alcanza con celebrar que alguien hizo una app en una tarde. La pregunta importante es qué aprendió mientras la hacía, qué entiende de lo que quedó funcionando, qué riesgos sabe detectar, qué partes no debería tocar sin ayuda, qué datos está manejando, qué pasa si falla y quién se hace cargo cuando deja de ser experimento.
Para los equipos técnicos, esto puede ser una oportunidad enorme si no la leemos desde el miedo. En lugar de pelear contra usuarios internos que empiezan a prototipar, quizás convenga ayudarlos a hacerlo mejor. Darles marcos simples, espacios seguros, reglas de datos, criterios para distinguir demo de producto, caminos para pedir revisión y formas de traer esas ideas al equipo sin que se conviertan en sistemas paralelos imposibles de mantener.
Ese puede ser un rol nuevo del área técnica: no solo construir todo, sino elevar la capacidad de construcción responsable alrededor suyo. Algo parecido a lo que pasó con las planillas durante décadas. Nadie en tecnología pudo impedir que negocio usara Excel para resolver problemas reales. La pregunta siempre fue si mirábamos para otro lado hasta que la planilla se volvía crítica, o si ayudábamos a ordenar, integrar y profesionalizar lo que había nacido como solución de emergencia.
Con la IA puede pasar algo parecido, pero más rápido y con más alcance. Van a aparecer prototipos, automatizaciones, scripts, flujos y pequeñas herramientas creadas por personas que conocen el problema mejor que el stack. Algunas serán descartables. Otras van a mostrar necesidades reales que el roadmap no estaba viendo. Y otras, si nadie las mira, se pueden transformar en riesgo operativo.
El desafío no es cerrar la puerta. Es poner un umbral claro entre aprender, prototipar y operar.
Aprender sin pedir permiso, pero no sin hacerse cargo#
Creo que por eso el tema autodidacta vuelve con tanta fuerza en este momento. La IA nos está devolviendo una pregunta antigua con una forma nueva. Antes preguntábamos si hacía falta un título para programar. Ahora quizás la pregunta sea si hace falta entender para construir. Y esa pregunta, aunque parezca exagerada, empieza a aparecer cada vez que alguien arma algo funcional sin haber pasado por el camino técnico tradicional.
Mi respuesta, por ahora, es incómoda pero bastante simple: para empezar a construir, cada vez hace falta menos. Para hacerse cargo de lo construido, hace falta igual o más que antes.
Ese es el punto donde se juntan el oficio autodidacta, Maquiavelo y la IA. Juzgar por los ojos es ver la herramienta funcionando, la demo respondiendo, el formulario guardando datos, el agente explicando su propio código. Tocar con las manos es entender qué pasa cuando cambia una regla, cuando aparece un dato raro, cuando hay que auditar un acceso, cuando otra persona hereda el proyecto, cuando el error deja de ser una molestia y se vuelve consecuencia.
Aprender por cuenta propia sigue siendo una de las capacidades más valiosas de nuestra profesión. No porque nos haga más libres de toda autoridad, sino porque nos obliga a construir una autoridad interior que no depende únicamente de que alguien nos diga qué estudiar después. Pero esa libertad tiene precio: exige método, paciencia, humildad y una relación honesta con el error.
Tal vez el autodidacta que necesitamos en tiempos de IA no sea el que aprende más rápido ni el que produce más con menos instrucciones. Tal vez sea el que sabe cuándo la herramienta lo está ayudando a entender y cuándo solo lo está ayudando a avanzar sin entender. Esa diferencia va a importar cada vez más.
Y quizás la pregunta que conviene llevarnos a nuestros equipos no sea quién tiene más credenciales ni quién usa más IA, sino otra más difícil de medir: cuando algo parece funcionar, ¿tenemos gente capaz de tocarlo con las manos, entenderlo de verdad y hacerse cargo de lo que pasa después?
Fuentes consultadas#
- Ariel Yuhan Ong, Iain Livingstone, Caroline Kilduff, Mertcan Sevgi, David A. Merle, Eden Ruffell, Pearse A. Keane y Fares Antaki, “Vibe coding for clinicians: democratising bespoke software development for digital health innovation”, arXiv, enviado el 24 de abril de 2026, revisado el 27 de abril de 2026.
- Stack Overflow, “2024 Developer Survey”, 2024.
- Stack Overflow, “2025 Developer Survey”, 2025.
- GitHub, “Octoverse: A new developer joins GitHub every second as AI leads TypeScript to #1”, 28 de octubre de 2025, actualizado el 28 de febrero de 2026.
- Nicolás Maquiavelo, El Príncipe, capítulo XVIII, 1513.