La experiencia en el dominio siempre fue el verdadero foso
(brethorsting.com)- La parte difícil del software no estaba en escribir 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 esa comprensión
- La IA agéntica permite producir software incluso sin entender el dominio y mueve el cuello de botella de “¿se puede construir?” a “¿se puede juzgar si está bien?”
- Los expertos de dominio como despachadores logísticos, codificadores clínicos o actuarios de seguros pueden no saber programar, pero sí determinar si una salida cumple con reglas legales, de facturación u operación
- Un ingeniero generalista puede validar arquitectura y confiabilidad, pero en áreas donde la respuesta correcta depende del conocimiento del dominio, como la codificación clínica, puede pasar por alto errores plausibles
- La capacidad más valiosa es el criterio para validar tanto la solidez del código generado como la veracidad de sus salidas, y para los ingenieros experimentados se vuelve más importante invertir en experiencia de dominio
El cuello de botella del software se mueve de la implementación a la validación
- La parte difícil de escribir software no era teclear código en sí, sino construir primero un modelo de dominio en la cabeza
- Un sistema de nómina incluye embargos, deducciones antes de impuestos y el manejo de periodos de pago que cruzan el momento de un cambio salarial
- Una app de transporte incorpora feeds GTFS, la diferencia entre trip y route, y por qué un autobús “a tiempo” todavía puede estar mal
- El código era el resultado de trasladar esa comprensión, y adquirir esa comprensión era el trabajo real
- La IA agéntica debilita la conexión entre comprensión del dominio y producción de software
- Ahora es posible producir software sin construir directamente ese modelo de dominio
- Se tambalea una premisa de la que dependían todas las profesiones del software
- Como en la perspectiva del año pasado, es cierto que estas herramientas amplifican a los desarrolladores senior con buen criterio, pero esa explicación no basta
- El cambio más concreto es que el cuello de botella pasó de “¿se puede construir?” a “¿se puede juzgar si está bien?”
Quién usa bien las herramientas agénticas
-
Los expertos de dominio pueden determinar la respuesta correcta sin saber programar
- Personas como despachadores logísticos, codificadores clínicos o actuarios de seguros quizá no puedan leer un stack trace ni explicar la diferencia entre un hash map y una list
- Pero si ven un horario hecho por un agente, saben de inmediato qué conductor no puede cubrir legalmente ese turno
- También pueden detectar que cierto conjunto de códigos no será pagado en una reclamación de seguro
- Han pasado 10 años entre entradas y salidas, así que conocen la salida correcta para una entrada dada
- Lo que el agente les aporta es la capacidad de producir código que les faltaba, y lo que ellos aportan al agente es el criterio de verdad (ground truth) que este no tiene
-
Un ingeniero generalista puede no distinguir entre software bien construido y software correcto
- Un buen ingeniero generalista sabe de arquitectura, confiabilidad, pruebas y cómo evitar que el sistema colapse a las 2 de la mañana
- Pero en dominios como la codificación clínica, puede no distinguir entre una respuesta plausible pero incorrecta y una correcta
- El agente puede generar algo que compila y pasa las pruebas que el ingeniero imaginó, pero aun así introducir errores sutiles y costosos en reglas de facturación
- El ingeniero puede validar si el software está bien construido, pero cuando la corrección se define por completo por un dominio que no tiene en la cabeza, es difícil validar la exactitud
-
Antes de los agentes, había una ruta de aprendizaje favorable para los ingenieros
- Los ingenieros podían seguir a los expertos, leer especificaciones y aprender poco a poco el dominio cometiendo errores en entornos operativos
- En muchos campos, ese proceso era una parte central de la escalera profesional
- Los expertos de dominio no tenían una ruta simétrica
- Aprender a construir software confiable toma años, y era un camino que en la práctica les resultaba difícil recorrer
-
Las herramientas agénticas solo derrumbaron una de las dos rutas
- La capacidad, que era ventaja del ingeniero, de traducir un modelo de dominio en código funcional se volvió barata
- La capacidad, que era ventaja del experto de dominio, de saber qué está bien no se volvió barata
- Esa capacidad no se obtiene solo con prompts, y no existe un skill file que contenga el conocimiento tácito de alguien que ya acertó miles de cálculos de nómina
-
La persona más valiosa es la que puede validar en ambos niveles
- Se vuelve más importante quien sabe si el código generado es sólido y también si las respuestas que ese código entrega son verdaderas
- La razón por la que alguien puede escribir una prueba como “un conductor no puede exceder 11 horas” es que conoce la regla
- La razón por la que también puede juzgar si esa prueba tiene sentido es que sabe qué está probando
- El agente hace el trabajo de transcripción, y la persona ejerce criterio tanto sobre el código como sobre el dominio
- La inversión importante para un ingeniero experimentado es adquirir un modelo profundo y validado del dominio real
- El valor de la capacidad mecánica de convertir una idea clara en código limpio cayó de forma importante
- Lo que sigue siendo escaso es la comprensión profunda de industrias reales, herramientas, marcos regulatorios y procesos físicos
- Hay que elegir un dominio y aprenderlo del mismo modo en que antes se aprendía un lenguaje de programación o un framework
- La parte que los agentes no pueden reemplazar, y la que hoy más valor ganó, es la experiencia en el dominio
¿Quieres seguir recibiendo temas de tecnología seleccionados?
Sigue el canal de Telegram. @GeekNewsES
1 comentarios
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