programa
Fundamentos de agentes de IA
6 h
Analicé cientos de repositorios de GitHub para entender por qué los agentes de codificación con IA suelen desenvolverse mejor en ingeniería de software que en ciencia de datos. Lo que encontré sugiere que no es solo una cuestión de herramientas. Refleja una diferencia más profunda en dónde reside el significado en cada tipo de código.
De qué trata este artículo
Si has usado un agente de IA en una base de código de ingeniería de software, seguramente habrás visto lo eficaz que puede ser. El agente navega por la arquitectura, sigue las abstracciones y hace cambios que encajan sorprendentemente bien con el resto del sistema.
Luego abres un cuaderno de ciencia de datos y la experiencia a menudo cambia.
El agente sigue siendo capaz de escribir código válido. Sigue instrucciones. Pero a menudo no llega a entender del todo lo importante: por qué este conjunto de datos, por qué este filtro, por qué esta ventana temporal, por qué este resultado cambió el rumbo del análisis.
Trata el cuaderno como si fuera un proyecto de software, y eso solo es parte de lo que es.
Quise entender el porqué. Así que analicé cientos de repositorios de GitHub en ciencia de datos e ingeniería de software, midiendo entropía, patrones de referencias y comportamiento de acoplamiento.
Lo que encontré me sorprendió, y creo que tiene implicaciones reales para cualquiera que construya o use agentes de IA en trabajos analíticos.
La inversión de entropía: el código de ciencia de datos no es lo que parece
Qué medí exactamente
Medí la entropía de Shannon en tres niveles de abstracción para cada repositorio: a nivel de caracteres, de tokens y de AST. Cada uno captura una dimensión distinta de variación en el código.
Distribución de entropía de código: diagramas de violín en ciencia de datos vs. ingeniería de software
El patrón que emergió es lo que llamo una inversión de entropía.
La superficie parece compleja; la estructura, a menudo no
A nivel de caracteres, el código de ciencia de datos tiende a tener mayor entropía que el de ingeniería de software. Tiene sentido: el trabajo en ciencia de datos está lleno de nombres de columnas variados, etiquetas de datasets, variables ad hoc e identificadores específicos del dominio que hacen que el código parezca ruidoso e irregular.
A nivel de tokens, los dos dominios están mucho más cerca. Se apoyan en muchos de los mismos bloques sintácticos.
Pero a nivel de AST, donde miramos la diversidad estructural, la imagen se invierte.
El código de ingeniería de software tiende a codificar mucha más variación en la estructura. Crea comportamientos más distintos a través de abstracciones, interfaces, módulos y lógica interna.
El código de ciencia de datos, en cambio, suele reutilizar un conjunto reducido de operaciones en contextos cambiantes: cargar, filtrar, agrupar, agregar, visualizar, inspeccionar, ajustar.
En pocas palabras, el código de ciencia de datos suele parecer más complejo en la superficie, mientras que el de ingeniería de software suele concentrar más complejidad en la estructura.
No es solo una diferencia de estilo. Apunta a una diferencia más profunda en cómo cada tipo de trabajo almacena el significado.
Indexical vs. simbólico: dónde vive el significado
Dos tipos de código distintos
La inversión de entropía se entiende mejor si piensas en lo que realmente hace cada tipo de código.
En ingeniería de software, el significado suele comprimirse en la estructura. Funciones, interfaces, módulos, tipos y límites de clases hacen gran parte del trabajo. Una vez que esas abstracciones se establecen, estabilizan el comportamiento y reducen la incertidumbre futura.
Gran parte del significado está dentro del propio código.
En ciencia de datos, el significado permanece mucho más ligado al contexto externo. Depende del dataset, las columnas, los resultados intermedios, las asunciones detrás de una transformación y la pregunta en evolución que intenta responder la persona analista. El código no solo expresa lógica. Señala una situación analítica concreta.
Esa diferencia es una de las formas más útiles de entender por qué los agentes se comportan tan distinto en ambos dominios.
Se ve en hacia dónde "apunta" el código
También medí densidades de referencias externas e internas por cada 100 líneas de código en ambos grupos.
Densidades de referencias externas e internas con significación estadística
La distinción es clara. El código de ciencia de datos apunta más hacia fuera: a datasets, tablas, columnas, objetos temporales y estados que existen fuera del propio código.
El código de ingeniería de software es más autorreferencial internamente. Construye significado con más frecuencia señalando a funciones, clases, módulos y abstracciones definidas en la propia base de código.
El código de datos apunta hacia fuera. El código de software apunta hacia dentro.
Y eso importa para los agentes. En un caso, gran parte del contexto relevante está en la base de código. En el otro, gran parte está en el estado analítico que lo rodea.
Por qué esto hace que la abstracción se comporte de forma distinta
El problema del acoplamiento en los cuadernos
Uno de los hallazgos más interesantes fue el acoplamiento. Los flujos de trabajo basados en cuadernos mostraron un acoplamiento mucho más estrecho por cada 100 líneas de código que las bases de código de ingeniería de software.
Eso no es necesariamente mal diseño. Refleja algo fundamental del análisis exploratorio: la propia pregunta suele estar aún en movimiento. Estás poniendo a prueba asunciones, siguiendo resultados extraños, comprobando casos límite y cambiando de rumbo a medida que aprendes.
En ese contexto, la abstracción no compensa igual que en ingeniería de software. Estructurar demasiado pronto puede reducir tus opciones antes de entender qué importa. Un mayor acoplamiento es a menudo consecuencia de la exploración, no simplemente de una mala ingeniería.
El papel de los comentarios y el estado
También hay una diferencia importante en cómo se explican ambos dominios.
En ingeniería de software, el código suele explicarse por su estructura. Tipos, interfaces y abstracciones cargan con gran parte del significado, y los comentarios suelen ser secundarios.
En ciencia de datos, los comentarios, los resultados y el estado a menudo cargan parte del significado. Una nota como «se eliminaron los valores atípicos por encima del percentil 99; confirmado que no afecta a la cohorte principal» no es solo documentación adicional.
Recoge una decisión analítica que quizá no se pueda reconstruir solo a partir del código. Una tabla o un gráfico a mitad del cuaderno puede explicar por qué existe la siguiente parte del análisis.
Esto importa para los agentes. Un agente que ignora comentarios, resultados en línea y el estado cambiante de un cuaderno se pierde parte del análisis. En una base de código de ingeniería de software, esa información suele ser complementaria. En ciencia de datos, a menudo no lo es.
Qué significa esto para los agentes de IA
Los agentes encajan bien por defecto en un dominio
La implicación práctica es esta: los agentes funcionan mejor cuando sus herramientas están alineadas con dónde vive el significado.
En ingeniería de software, un agente eficaz navega por la arquitectura. Sigue el grafo de llamadas, respeta las interfaces y mantiene los cambios coherentes en toda la base de código. Funciona porque gran parte del significado está codificado en la estructura.
En ciencia de datos, un agente eficaz necesita hacer algo más que navegar por el código. Debe entender qué contienen realmente los datos, hacer seguimiento del estado a lo largo de los pasos, seguir la procedencia de las variables y razonar por qué se aplicó una transformación o un filtro varios pasos antes.
Un agente creado para ingeniería de software no se trasladará automáticamente bien al trabajo en ciencia de datos. No es solo un tema de sintaxis. La estructura de la información subyacente es distinta.
Por qué persisten los flujos de trabajo con cuadernos
Esto también ayuda a explicar algo que a menudo desconcierta a ingenieros: por qué los cuadernos siguen siendo tan centrales pese a sus limitaciones evidentes.
La respuesta es que los cuadernos mantienen el significado cerca de los datos mientras la pregunta analítica aún está evolucionando. Un cuaderno no es solo un módulo de Python mal estructurado. Es un artefacto distinto, diseñado para una fase distinta del trabajo. Mantiene código, resultados y decisiones muy cerca mientras el análisis toma forma.
Por eso un cuaderno puede resultar intuitivo para quien ha vivido dentro de ese contexto, y torpe para un agente que solo ve el código.
Refactorizar un cuaderno en código limpio y modular antes de que la pregunta analítica esté cerrada a menudo no es una mejora. Puede separar la lógica del contexto que le daba sentido en primer lugar.
La oportunidad: cerrar la brecha hacia producción
La oportunidad real para los agentes de IA en ciencia de datos no es simplemente copiar lo que ya funciona en ingeniería de software. Es ayudar a cerrar la brecha hacia producción: la distancia entre un insight hallado en la exploración y un flujo de trabajo reproducible y desplegable.
Esa brecha existe porque los cuadernos preservan el contexto analítico a costa de la limpieza estructural. Un agente capaz de entender tanto el contexto analítico como los requisitos estructurales de los sistemas en producción podría tender ese puente sin obligar a la persona analista a salir demasiado pronto del modo exploratorio.
Es un problema más difícil que navegar por una base de código. Pero también es el más importante.
Ideas clave
En resumen, esto es lo que sugiere el análisis de los repositorios estudiados:
- El código de ciencia de datos suele tener mayor entropía a nivel superficial, mientras que el de ingeniería de software suele tener mayor entropía estructural.
- El código de ciencia de datos hace más referencias a estado externo como datasets, columnas, tablas y resultados intermedios, mientras que el código de ingeniería de software es más autorreferencial internamente.
- Los flujos de trabajo tipo cuaderno tienden a mostrar un acoplamiento más estrecho, que a menudo es consecuencia de la exploración más que de malas prácticas.
- Los comentarios, los resultados y el estado cambiante forman parte del contenido semántico del trabajo en ciencia de datos, no son un detalle periférico.
- Los agentes optimizados para contextos de ingeniería de software a menudo rendirán por debajo en ciencia de datos si no están diseñados para razonar sobre datos, resultados y contexto además de la estructura del código.
Conclusión
Cuando empecé este análisis, esperaba encontrar que el código de ciencia de datos estaba simplemente peor estructurado que el de ingeniería de software. En cambio, encontré que está estructurado de forma diferente por buenas razones, con el significado residiendo a menudo en otro lugar.
Eso tiene consecuencias prácticas para quien construya o evalúe agentes de IA para trabajos analíticos. La pregunta real no es si un agente puede escribir Python correcto. Es si entiende qué son los datos, por qué el análisis toma la forma que toma y qué decisiones se han tomado por el camino que no son visibles solo en el código.
El código de ciencia de datos no es una versión inmadura de la ingeniería de software. Es una optimización distinta: más dependiente del estado externo, menos apoyada en estructuras internas duraderas durante la exploración y tan moldeada por el contexto como por el código.
Una vez lo ves así, los cuadernos dejan de parecer proyectos de software fallidos y se parecen más a lo que realmente son: superficies de trabajo para razonar sobre datos cambiantes.
Voy a continuar este análisis con un conjunto de datos más grande, de 1.000 o más repositorios, y métricas adicionales. Si quieres profundizar en cómo se están construyendo agentes de IA para trabajar con datos en contexto (incluidas arquitecturas de ejecución persistente que mantienen el estado de los datos entre sesiones), el itinerario de aprendizaje AI agent fundamentals de DataCamp es un buen punto de partida.
