La especialización de dominio siempre fue el verdadero foso
(brethorsting.com)- La dificultad del software no estaba en teclear código, sino en entender reglas del mundo real como nómina o transporte para construir un modelo de dominio; el código era el resultado de ese entendimiento
- La IA agéntica hace posible producir software incluso sin comprender el dominio, y mueve el cuello de botella de “¿se puede construir?” a “¿se puede juzgar si está bien?”
- Expertos de dominio como despachadores logísticos, codificadores clínicos o actuarios pueden no saber código, pero sí determinar si un resultado cumple con reglas legales, de facturación u operativas
- Un ingeniero generalista puede validar arquitectura y confiabilidad, pero en áreas donde la respuesta correcta está atada al conocimiento de dominio, como la codificación clínica, puede pasar por alto errores plausibles
- La capacidad más valiosa pasa a ser el criterio para validar tanto la solidez del código generado como la veracidad de su salida, y para los ingenieros experimentados se vuelve más importante invertir en especialización de dominio
La esencia no era escribir código, sino entender el dominio
- En el desarrollo de software, la parte difícil no era escribir código, sino construir primero en la cabeza un modelo de cómo funciona el dominio
- El código era una transcripción de ese entendimiento, y el verdadero trabajo era el proceso mismo de adquirirlo
-
Ejemplos concretos
- Antes de lanzar un sistema de nómina, había que entender deducciones por embargo (garnishment), deducciones antes de impuestos, y cómo manejar periodos de pago que cruzan cambios en la tarifa salarial
- Antes de lanzar una app de transporte público, había que aprender qué es un feed GTFS, por qué un trip y una route no son lo mismo, y cómo un autobús “puntual” aún puede estar equivocado
El eslabón que rompió la IA agéntica
- La IA agéntica rompió el vínculo entre construir el modelo y producir software, permitiendo crear software incluso sin ese modelo
- Eso derrumba la premisa sobre la que estaba organizada toda la profesión
- La perspectiva del año pasado era que esta herramienta amplifica a los desarrolladores senior con criterio, y eso es cierto, pero incompleto
- El cambio realmente observado es que la restricción central se movió de “¿se puede construir?” a “¿se puede determinar si está bien?”
Comparación entre dos tipos de perfiles
-
Experto de dominio (sin experiencia en software)
- Despachadores logísticos, codificadores clínicos, actuarios de seguros y otros, que no pueden leer un stack trace ni explicar la diferencia entre un hashmap y una lista
- Pero al ver un horario generado por un agente, detectan al instante que ningún conductor puede hacer ese turno legalmente, o que la facturación de ese código jamás será pagada
- Como llevan 10 años viviendo entre entradas y salidas, conocen la salida correcta para una entrada dada, y el agente complementa exactamente la capacidad de producir código que les faltaba
- Lo que aportan es la verdad de base (ground truth) que el agente no puede dar
-
Ingeniero generalista fuerte, sin experiencia de dominio
- Puede diseñar cualquier cosa y sabe de confiabilidad, pruebas y cómo evitar que el sistema colapse a las 2 a. m.
- Pero si lo pones a hacer codificación clínica, no puede distinguir entre una respuesta incorrecta que parece correcta y una realmente correcta
- El agente genera una regla de facturación (billing rule) sutilmente incorrecta y costosa, que compila y pasa las pruebas que él mismo escribió
- El ingeniero no tiene un oráculo (oracle): puede verificar que el software esté bien construido, pero no que sea correcto, porque esa corrección está definida por un dominio que no tiene en la cabeza
Una asimetría donde solo colapsó un camino
- Antes de los agentes, el ingeniero tenía un camino que el despachador no tenía: podía seguir a expertos, leer especificaciones y cometer errores en producción mientras adquiría lentamente el modelo de dominio
- En muchos campos, ese camino era la propia escalera profesional (career ladder), mientras que el experto de dominio no tenía un camino equivalente de años para aprender a construir software confiable
- Las herramientas agénticas colapsan solo uno de esos dos caminos
- La fortaleza del ingeniero de traducir el modelo de dominio a código ahora es barata (cheap)
- La fortaleza del experto de dominio de saber qué está bien no lo es, y no se puede alcanzar solo con prompts
- No existe un archivo de habilidades que encapsule el conocimiento tácito (tacit knowledge) de alguien que ha procesado miles de nóminas
Talento capaz de validar ambas capas
- En este nuevo mundo, la persona más valiosa es la que posee ambas capacidades y puede validar en las dos capas
- Sabe que el código generado es sólido y, al mismo tiempo, sabe que las respuestas que produce son verdaderas
- Como conoce las reglas, puede escribir una prueba que codifique “un conductor no puede exceder 11 horas”, y como sabe qué está probando, puede juzgar si esa prueba tiene sentido
- El agente se encarga de la transcripción, y la persona se encarga de juzgar dos veces
La apuesta para ingenieros con experiencia
- Para el ingeniero experimentado que se pregunta en qué invertir los próximos años, esta es la dirección de la apuesta
- La habilidad mecánica de convertir una idea clara en código limpio cae dramáticamente en valor
- Lo que sigue siendo escaso es un modelo profundo y validado de algún dominio real, y eso es lo que hay que conseguir
- Elige una industria, un producto financiero, un marco regulatorio o un proceso físico, y aprende ese dominio como antes aprendías un lenguaje de programación o un framework
- Esa es la parte que el agente no puede hacer por ti, y ahora es la que más valor tiene
7 comentarios
Pero también siento que esto menosprecia demasiado al código.
El desarrollo de software en sí mismo también es un dominio, y hacerlo bien también es una habilidad especializada.
Así como el software que crea la IA puede resolverlo a nivel funcional, pero no puede terminarlo por completo, se necesita a alguien que llene ese vacío.
Tengo una opinión algo distinta de la de xguru.
Pongamos Excel como ejemplo. En general, cuando trabajas en una empresa, hay un nivel que necesitas para hacer tu trabajo, y una vez que lo superas, la mayoría ya no intenta aprender más. Hay personas que manejan Excel de forma casi obsesivamente buena sí, pero de verdad son casos excepcionales.
Con el código también —aunque ahora no sea así— pensé que quizá podría dividirse en dos ramas. Unos pocos que crean productos realmente complejos, y la gran mayoría que lo usa como quien anda en bicicleta.
¿Eh? No es que se menosprecie a la gente que maneja bien Excel.
Pero decir que bajó el valor de programar en sí da la sensación de que sí se está menospreciando.
Creo que así como usar algo como quien anda en bicicleta, no deberíamos decirle a quien crea productos complejos que su valor no es gran cosa.
Estoy de acuerdo con lo que mencionas,
se decía que se reducirá la tecnología y el código que podrían llamarse software complejo, si aumentan las cosas que se pueden programar fácilmente con IA.
Tomando prestada la expresión del resumen de GeekNews: parece que cada día habrá menos código que los agentes no puedan sustituir.
Es igual a este comentario que apareció en las opiniones de Hacker News:
.
Esa parte está en un estado en el que el conocimiento tácito casi ha desaparecido y, como expertos de primer nivel en el dominio están diseñando agentes e integrándolos en el modelo, aunque ahora se enfatiza la importancia del conocimiento de dominio, no sé si dentro de un año se seguirá haciendo la misma afirmación. Al final, el conocimiento tácito está pasando poco a poco a los prompts, y los modelos seleccionarán el conocimiento tácito que los usuarios agreguen a los prompts y lo volverán a inyectar en el modelo. Los modelos de agentes con conocimiento tácito incorporado tendrán valor, pero creo que incluso esto se comerciará en el mercado. Agentes con un conocimiento de dominio mucho más rico en ese campo.
Creo que dentro de un año, más allá de la orquestación, el criterio de evaluación podría pasar a ser la gestión de agentes (como si fueran una empresa).
Opiniones en Hacker News
No sé cuántas peroratas más hacen falta para admitir que nadie sabe cómo usar la IA a nivel individual
Al principio decían que bastaba con ser un buen desarrollador y aprender a usar IA; luego que lo importante era la capacidad de diseñar arquitectura; después que el gusto lo definía todo; y ahora dicen que solo importan los expertos de dominio
Hasta que la mejora o el estancamiento de la IA llegue a un estado estable y predecible, este tipo de interpretaciones va a seguir siendo inútil y probablemente, en su mayoría, equivocada
Se vuelve más difícil porque elevan muchísimo el estándar de lo que es posible. Un desarrollador individual ahora puede asumir proyectos mucho más complejos, y al final la limitación siempre fue el tiempo; la IA ayuda a hacer más dentro del tiempo disponible
Pero eso mismo hace que lo que puede lograrse en ese tiempo sea mucho más difícil. Hay que entender muchísimas más cosas y salir mucho más lejos de la zona segura y familiar previa a la IA
Antes se aceptaba pasar varios días refactorizando una base de código o preparando el lanzamiento de una función pequeña porque era un área del sistema poco conocida o había que aprender una librería nueva
Gracias a los agentes de programación, esa curva de aprendizaje puede subirse mucho más rápido, pero igual hay que subirla uno mismo. Y además, la cantidad de información que entra es muchísimo mayor
Si te preocupa que un vibe coder no técnico te quite el trabajo, la respuesta correcta es hacer software muchísimo mejor que ellos. Para eso hacen falta más habilidad, más ambición y más experiencia, y no es fácil
La analogía que más adecuada me ha parecido hasta ahora es compararlos con un atornillador-taladro eléctrico moderno frente a herramientas antiguas como un destornillador o un taladro manual
En muy poco tiempo pueden dar resultados sorprendentes en comparación con las herramientas antiguas
Por ejemplo, hacen posible anécdotas impresionantes como: “terminé en una hora fijar un piso que me habría tomado todo el día, y hasta me dio tiempo de salir a fumar varias veces”. Si hubiera usado una clavadora, quizá lo habría terminado en la mitad del tiempo, pero después habría sido difícil levantar ese piso y el costo podría haber sido el doble
También uso varios LLM on-premise y tengo acceso a otros modelos, así que supongo que algún día esta analogía se va a extender incluso a diferencias entre marcas
Pero no creo que eso vaya a ponerse a buscar un trabajo nuevo. Un atornillador-taladro no es un carpintero ni un obrero, y sin una persona no sirve de nada
Dentro de 20 años creo que vamos a estar limpiando basura coescrita con Claude
https://mastodon.gamedev.place/@JeremiahFieldhaven/116654345...
En 2018 vi a alguien sin absolutamente nada de experiencia programando crear, en un mes de código, una herramienta que generaba bastante buen dinero solo porque conocía un nicho de mercado específico
Me mostró parte del código y era tan desastroso como mi primer programa, pero estaba resolviendo un problema real
Por ejemplo, dicen: “para ser bueno en un deporte hace falta una simetría perfecta, y eso se correlaciona fuertemente con la estabilidad del desarrollo fetal. Cuanta más simetría, más perfecto el desarrollo”
Luego, años después, sale que Bruce Lee tenía una pierna bastante más corta que la otra, y que Usain Bolt también tenía un desarrollo asimétrico parecido
Entonces dan marcha atrás y dicen que son casos excepcionales que no afectan la regla general
Basta con hacer algo interesante, y puede que funcione
Hace poco revisé una app hecha casi por completo con vibe coding. El dueño decía que ya estaba casi lista para salir y que solo necesitaba una revisión rápida
Al verla, el diseño de la base de datos era un desastre. Algunas funciones andaban y otras no. Le expliqué lo que faltaba y por qué se rompía. Igual que en el post original, esa persona era experta en el dominio
Solo el mes pasado gastó miles de millones de tokens, y las herramientas están mejorando rápido. Pero darle IA a un experto de dominio no significa que ya no haga falta un ingeniero de software
Un experto de dominio puede crear software con IA, y un ingeniero de software puede aprender el dominio con IA. Los dos aportan especialidades distintas
Termina siendo construir guardrails, validaciones, bibliotecas de prompts, agentes y revisión manual para proteger de forma segura a los expertos de dominio cuando empiecen a usar agentes de programación
Se parece un poco al soporte interno T2/T3 o a los ingenieros de soporte. Más que resolver personalmente el 100% de los problemas cotidianos, el rol consiste en detectar puntos peligrosos, casos límite extraños y verificar que toda la configuración esté correcta
Claro, también termina tocando muchos temas transversales
Eso sí, como herramienta para probar ideas nuevas rápido y profundizar, son excelentes. Si tienes curiosidad, incluso pueden ser un gran acelerador de aprendizaje
Uso Claude Code todo el día (Opus 4.6, con la configuración de esfuerzo máximo) y aun así no entiendo cómo eso sería posible. También me pregunto si ese nivel de uso realmente le está dando resultados
Puede ser que yo no sepa lo suficiente, pero de verdad no entiendo cómo se llega a eso
Hay un ejemplo muy bueno que viví hace poco
Estaba en un viaje de pesca y le pregunté al capitán si quería echarle un vistazo a la app gratuita en la que trabajo (https://oceanconnect.ca) para ver si podía ayudarle en su trabajo
Yo no sé mucho sobre cómo usa la gente los datos oceánicos en el mar. No sé bien qué quieren saber ni por qué. Empezaron a salir un montón de preguntas e información sobre cómo usa la gente los datos y qué podríamos hacer nosotros con esos datos, y yo no estaba nada preparado; conseguir esa perspectiva fue realmente genial e interesante
Me recordó otra vez que un modelo no es lo mismo que el sistema que abstrae, y que el conocimiento para desarrollar ese modelo casi no tiene relación con el conocimiento para usarlo
Esta persona tenía un conocimiento enorme sobre cómo se usan los datos meteorológicos en el agua. En cierto sentido, conocía los datos mejor que yo y, aunque quizá no se diera cuenta de ello o no entendiera su representación digital, sentí que si supiera programar podría hacer una app mucho mejor y más útil para gente como él
Pensé que si personas así pudieran poner sus ideas en la pantalla con un LLM enfrente, podrían crear cosas realmente increíbles. Si algún día tengo fondos, me gustaría entrevistar a personas que salen al mar todos los días para pulir el producto. Ese conocimiento de dominio es muy específico, y la gente que ha vivido durante décadas en dominios complejos sabe cosas que uno jamás esperaría
El generalista de software descrito en este texto también tiene especialización de dominio. Ese dominio es el software
Si hoy eres un excelente ingeniero de software generalista, no vas a lanzarte a cualquier dominio al azar para evitar la IA. El software es tu dominio, y vas a seguir dentro de él mientras ese dominio se expande y se transforma
Quizá la buena noticia es que incluso el mejor contador artesano de hojas de cálculo del oeste va a necesitar al final cierto nivel de experiencia en programación para poder validar
Puedes preguntarle a un LLM: “¿Qué hace este código y se cumple siempre X cuando pasa Y?”, pero eso solo anida el problema de validación dentro de otro problema de validación
El punto central nunca fue el código
Después de pasar los últimos 5 años creando software para venture capital y private equity, este texto me pegó mucho. Escribir código es por mucho la parte más fácil de mi trabajo; lo difícil es la ingeniería financiera y el contexto sutil necesarios para entender lo que de verdad necesitan los clientes de la empresa
Solemos bromear con que, si pudiéramos, contrataríamos a un contador senior de fondos y le enseñaríamos a programar. El problema es que casi no existe gente así. También es difícil lograr que un ingeniero entienda los detalles de la contabilidad de fondos lo suficiente como para convertirlos en software
De hecho, como la mitad de mi carrera ha consistido en arreglar cosas hechas por gente que “tenía suficiente conocimiento del dominio como para cerrar tickets o épicas, pero al final dejó muchísima deuda técnica”
Por ejemplo, aunque tengas conocimiento del dominio, la gente se equivoca, no conoce métodos mejores, no incorpora retroalimentación o, peor aún, ni siquiera vuelve a revisar lo que escribió un agente de código, así que había que revisar los PR con muchísimo cuidado
También me tocó muchas veces refactorizar cosas que “técnicamente eran correctas, pero estaban tan mal hechas que causaban timeouts o hacían que el manager o el DBA pusieran el grito en el cielo”
Un ingeniero de software realmente bueno tiene la capacidad y la disposición para aprender el dominio, pero tiene que existir una forma de aprenderlo. He estado en empresas, equipos y con colegas que hacían eso posible, y también en lugares donde decían que era importante, pero al final uno tenía que deducirlo solo a partir de JIRA y de comentarios sueltos de gente no técnica en reuniones
Creo que el gran cambio de paradigma de los últimos 5 años es que la mayoría de las empresas espera que la gente trabaje al límite, y eso termina siendo contraproducente porque impide tener las conversaciones importantes
La cultura es una variable enorme. Al menos he estado en lugares donde podías tener una charla breve al lado o agendar una reunión con facilidad, y en otros donde para pedir tiempo para discutir bien algo parecía que había que lanzar una petición en change.org
Aun así, la idea central es correcta. Al final, los requisitos importan más que el código. He estado en lugares donde se cumplieron todos los requisitos y el equipo aprobó las decisiones de diseño, pero luego volvió alguien que había estado ausente durante toda la implementación y la funcionalidad se retrasó solo porque no le gustó la forma en que se había escrito
Y entonces, de repente, descubres que el “proceso por lotes” está haciendo %numberOfRecord%*10 inserciones, además de consultas extra por un modelo de datos mal diseñado, y está haciendo un upsert SQL de la peor manera posible. O sea, primero consulta en la base de datos y luego agrega los registros que insertará si no existen. Y mientras tanto siguen haciendo cosas cada vez más sospechosas en nombre de la “mejora de rendimiento”, en vez de replantear el patrón de consultas de la capa de datos. Lo he visto más de una vez en mi carrera
Cada vez que leo un texto muy general que parece consejo para responder a la IA, recuerdo que la industria del software se parece a la industria de la construcción
Nunca está realmente ordenada, nunca está totalmente optimizada y siempre termina siendo personalizada. Porque tiene que adaptarse a una realidad donde los gustos, el contexto y la localidad son extremadamente distintos
A veces sí pueden aparecer buenas herramientas o materias primas
Solía pensar que el verdadero foso del software estaba en no requerir, en la práctica, un conocimiento o experiencia amplios tanto del sistema como del dominio
Es mucho más difícil replicar el gusto y los efectos de red. De hecho, incluso antes del vibe coding, era raro que startups financiadas por venture capital con mucho talento y recursos lograran consolidarse en el mercado
Por eso alguien de 20 y tantos podía competir con expertos de muchos campos. Creo que la reacción negativa actual se debe al surgimiento de personas con “X años de experiencia en la industria”, algo muy común en otras industrias maduras
Trabajo como analista, y en nuestro grupo alrededor del 20% de los analistas tiene una base técnica fuerte, es decir, capacidad de ingeniería de software, mientras que el resto son analistas tradicionales o expertos de dominio
Durante el último año he visto cómo los analistas no técnicos usan modelos de IA para la parte de desarrollo y eso ha aumentado la productividad al crear herramientas internas
Antes, casi todo se desarrollaba en Tableau. Era la forma más accesible para que alguien que no era desarrollador pudiera crear una herramienta funcional
Hace apenas unos días, un analista de nuestro grupo presentó una herramienta en la que estaba trabajando, y básicamente era un reporte de Tableau portado a una app más flexible
Creo que estas empresas de BI van a meterse en serios problemas. Especialmente compañías como Tableau, que hacen que sea casi imposible incluso dibujar algo tan simple como un histograma
Mi amigo es ingeniero eléctrico y hace poco superó los 2000 de rating FIDE en ajedrez. Lleva 30 años jugando ajedrez y hasta fundó un club de ajedrez en la preparatoria. En la universidad trabajó con microcontroladores y apenas aprendió algo de programación
Yo me parezco más a un todólogo de infraestructura/administración con título en ciencias de la computación, y llevo 30 años programando como hobby. Mi rating en Lichess es 1000 incluso en un buen día
Hicimos una competencia de bots de ajedrez. Era open book y se valía programar con IA, usar opening books, tablas de finales o lo que fuera; era un enfrentamiento totalmente libre. Lo aplasté por completo, pero en ajedrez sobre tablero real solo le he ganado dos veces en 20 años
Él le ganaría al 99% de los jugadores aleatorios en la vida real, y yo probablemente solo al 20%
No sé exactamente qué quiero decir, pero siento que ahora el conocimiento de dominio quizá ya no lo es todo. O tal vez el dominio mismo haya cambiado
Lo que hiciste fue retarlo a una competencia de programación, y tú, que eres un programador con mucha más experiencia, ganaste. Aunque se pudiera usar IA, yo diría que aquí tu conocimiento de dominio fue el factor decisivo