Hace meses que le vengo dando vueltas a una pregunta que, con la IA generando código a patadas, me parece la más importante para cualquiera que trabaje en tecnología (y sobre todo para vos, que te ganás la vida escribiendo código): si escribir código se volvió barato, ¿qué es lo que sigue valiendo caro? Y cada vez lo tengo más claro: la respuesta es el conocimiento profundo del dominio. La experiencia en el problema, no en la herramienta.
Y va dirigida a un público bien concreto: a los devs 👨💻. A los que están viendo cómo un agente les genera en minutos lo que antes les llevaba una tarde, y se preguntan —con razón y con algo de vértigo— qué lugar les queda en todo esto.
🪜 La escalera que se dio vuelta
Durante años el camino era uno solo y siempre para arriba. Un ingeniero/a de software podía ir sumando conocimiento del negocio con los años, pero al revés casi no pasaba: un experto en lo suyo —un médico, un contador, un especialista en logística— difícilmente se ponía a programar (hay casos, lo se, pero no son la moneda corriente). La habilidad escasa, la que te abría puertas, era escribir software. Eso te ponía «en la mesa».
Lo que cambió, y cambió rápido en los últimos 6 meses, es que la parte mecánica —agarrar una idea clara y convertirla en código limpio— se abarató de golpe. Para mí ese es el quiebre: la IA no devaluó del todo «saber programar», pero sí devaluó la parte que más usábamos para ser «únicos». Y al sacarla del medio, dejó a la vista lo que de verdad sostiene el valor.
Y hay algo más, que es lo que termina de dar vuelta la escalera: ahora el camino inverso también funciona. El médico, el contador o el especialista en logística que antes no podía programar, hoy con un agente de IA puede armarse una herramienta que funciona. No va a construir un sistema de misión crítica, pero para resolver su problema concreto le alcanza. El que durante años nos necesitó para todo, hoy nos necesita para menos cosas. Esa es la parte que más te tiene que hacer pensar.
🎯 Saber cómo se ve «lo correcto»
Le pedís a un agente una solución completa y te la da: compila, pasa los tests, parece prolija. El tema es que pasar los tests no es lo mismo que estar bien. El que conoce el dominio —el que entiende qué significa de verdad el cálculo de un seguro, una regla de facturación o un protocolo clínico— mira esa salida y en dos segundos sabe si está bien o si está sutil y carísimamente mal 🤓.
Un ejemplo típico: un sistema de facturación que calcula prorrateos. La IA te genera la función perfecta… para meses de 30 días. El que conoce el negocio sabe que el problema real está en los meses de 28 y de 31, en las altas a mitad de mes, en la nota de crédito que llega después. Nada de eso falla en el demo. Todo eso explota en producción, con plata de por medio 💸.
El generalista, sin ese conocimiento, no tiene cómo darse cuenta. Tiene el código, pero no tiene la verdad de campo contra la cual compararlo. Y ese es justo el agujero que la IA no tapa: te da la respuesta, pero no te dice si esa respuesta sirve para tu mundo.
🏗️ El trabajo cambió: de escribir a validar
Y esa validación tiene dos caras. La del negocio —saber si la respuesta sirve para tu mundo, que es de lo que venía hablando— y una segunda, más técnica, que es la que más me cambió el día a día: mi trabajo dejó de ser escribir y pasó a ser validar. Mirar una solución completa y darse cuenta si las piezas están bien elegidas, si va a escalar, si se va a poder mantener, dónde se va a romper en producción.
Ojo: no hablo de revisar el código línea por línea —para eso también está la IA, y lo hace bien—. Hablo de juzgar la arquitectura: las decisiones de fondo, las que después cuesta carísimo cambiar. Ese criterio no viene en ningún modelo; se construye con experiencia. Y acá está la parte linda: es exactamente lo que la IA potencia en lugar de reemplazar.
¿Y cómo se ve eso en la práctica? En las preguntas que le hago a la IA. Ya casi no le pido «escribime tal cosa»: le pido que busque los bugs de un PR rankeados por severidad, que me diga qué edge cases no estoy contemplando, que sea el abogado del diablo de mi propio diseño, que compare mi solución con cómo la resuelven los proyectos serios del ecosistema. El que escribe es el agente; el que duda soy yo. Y dudar bien es un oficio.
👥 Lo que vengo viendo en la comunidad
En el día a día del MUG y de los equipos con los que trabajo, esto se nota cada vez más. Los perfiles que más suman hoy no son los que tipean más rápido, sino los que entienden el problema lo suficiente como para validar lo que la máquina propone. Saben qué preguntar, saben qué oler, saben dónde se esconde el error que ningún test agarra.
Y acá viene una buena noticia para muchos desarrolladores de software que hoy se sienten perdidos (y quizás también para vos, ¿por qué no?): ese conocimiento que tenés —de tu industria, de tu empresa, del problema que venís masticando hace años— de repente vale más, no menos 📈. «No te lo prompteás», leí por ahí y me quedó grabado. No hay atajo: eso se construye metiendo las manos en el problema durante mucho tiempo.
🧩 El combo que no tiene techo
Si me preguntás dónde está hoy el lugar más valioso, te lo digo sin vueltas: en la intersección. El que sabe juzgar la calidad de una arquitectura (no del código) y además entiende el dominio. Esa persona valida en dos capas a la vez —la técnica y la del negocio— y se vuelve casi imposible de reemplazar (al menos por un par de años), porque la IA le potencia las dos en lugar de competirle en alguna.
Pensalo así: cuando un agente te genera una solución completa, hay dos preguntas que la máquina no puede responder por vos. La primera: ¿esto resuelve el problema correcto? (capa de negocio). La segunda: ¿esto se va a sostener en el tiempo? (capa técnica). El que puede responder las dos es el que firma. Y el que firma es el que vale ✍️.
En los equipos lo veo todas las semanas: la persona que a la mañana se sienta con la gente del negocio y a la tarde revisa la arquitectura de una solución es la que termina marcando el rumbo. No porque sea la que más sabe de cada cosa por separado, sino porque es la única que puede traducir entre los dos mundos.
Y acá viene lo interesante: la IA hace que llegar a esa intersección sea más rápido que nunca. Te saca de encima el trabajo mecánico y te libera horas para meterte en el negocio, estudiar arquitectura y hacer las preguntas que antes no tenías tiempo de hacer.
🌱 ¿Y los juniors? La pregunta que más me hacen
Cada vez que hablo de esto, alguien me hace la mejor pregunta de todas: «¿y los juniors? Si lo que vale es la experiencia, y la IA hace el trabajo con el que antes se aprendía… ¿cómo arranca el que arranca hoy?»
Mi respuesta: el camino viejo se rompió, pero se abrió uno distinto. Y a dónde te lleva depende de cómo lo camines.
El junior de antes se pasaba años haciendo trabajo mecánico hasta que lo dejaban tocar un problema de verdad. El de hoy tiene al lado un profesor infinitamente paciente 🤖, que le puede explicar cualquier código, cualquier decisión y cualquier error, las veces que haga falta, sin hacerlo sentir mal por preguntar.
La diferencia está en cómo lo usa. ✅ El que usa la IA para entender —preguntar por qué, pedir que le expliquen las decisiones, meterse en las conversaciones del negocio— crece más rápido que cualquier generación anterior. ❌ El que la usa para evitar entender —copiar, pegar, pasar al siguiente ticket— no acumula nada. Y ese sí está en problemas.
La experiencia ya no se mide en años: se mide en problemas entendidos. Y nunca fue tan barato entender problemas como ahora.
Por eso, cuando un dev me pregunta qué estudiar o para dónde apuntar en esta etapa, mi consejo es el siguiente: aprendé a usar bien las herramientas de IA, obvio. Pero no descuides lo otro: volvete «groso» 💪 en algo concreto, y cuando lo domines, buscá otra parte que no conozcas del negocio de tu empresa.
¿Y cómo se hace eso de «meterse en el negocio»? Sin magia: pedí estar en las reuniones donde se discute el problema, no solo en las que se reparte el trabajo. Preguntá por qué las reglas son como son. Hablá con la gente que usa lo que construís. Cada una de esas conversaciones vale más que un curso.
El moat —ese foso que te protege de la competencia— nunca fue solo saber programar. Siempre fue entender de verdad el problema. La IA no vino a borrar ese foso: vino a hacerlo más ancho.
💡 ¿Qué te puedo decir para cerrar?
Que no te quedes con el miedo. Estamos en uno de esos momentos que pasan pocas veces en una carrera: las reglas cambiaron y todavía nadie tiene el manual escrito. Eso, que de entrada asusta, es también una oportunidad enorme para el que se mueve 🚀.
Mi recomendación es simple: formate. Aprovechá la IA —nunca fue tan barato ni tan rápido aprender algo nuevo—. Aprendé a usar bien las herramientas, claro. Pero sobre todo aprendé del dominio del negocio donde trabajás, o de eso a lo que te dedicás: hablá con la gente, preguntá por qué, metete en el problema de verdad.
El código se volvió barato, es cierto. Pero vos no. Tu criterio, tu experiencia y tu conocimiento del problema valen hoy más que ayer. Lo único que cambió es que ahora tenés el tiempo y las herramientas para hacerlos crecer. Aprovechalo 👊.
