Cada semana aparece una nueva forma de

llamar a cosas que probablemente ya

hacíamos antes. Primero fue el prompt

engineering, luego fue el context

engineering, luego fue el harness

engineering, luego el loop engineering y

ahora lo que se está cociendo es el

graph engineering. En este vídeo quiero

explicarte a qué se refieren la mayoría

de artículos y menciones a este término.

Y quiero desgranar qué parte parece ser

que es útil, que es novedosa y qué parte

es solamente hype y humo. Y además al

final del vídeo te voy a explicar cómo

yo analizo y estudio estos diferentes

términos que van apareciendo para no

volverme loco y saber diferenciar qué

merece la pena y qué no. El mundo del

desarrollo de software siempre ha tenido

esa parte vertiginosa de las novedades.

Ahora estamos hablando de ingenierías de

inteligencia artificial, pero es algo

que lleva pasando hace tiempo. Todos

recordamos esa etapa en la que cada dos

semanas salía un nuevo framework de

JavaScript o una biblioteca construida

encima de React. Ahora toda esa boráine

se ha cambiado por ingenierías en

inteligencia artificial. Por lo tanto,

nosotros podríamos decir que ya estamos

medianamente acostumbrados a ir

aprendiendo cosas nuevas. No creo que el

aprender cosas nuevas sea lo que

realmente moleste o esté generando tanto

ruido en la comunidad. Para mí lo que

está generando tanta incertidumbre,

tanta incomodidad en la comunidad de

desarrolladores, es que la mayoría de

estos nombres no parecen generar ni

resolver problemas reales o incluso se

le dan nuevos nombres a cosas que ya se

llevan haciendo. Si a esta poca

confianza, los términos le sumamos la

sensación de urgencia, la sensación de

tienes que aprender esto, te vas a

quedar atrás, la sensación de que golpe,

todos los influencers empiezan a hablar

sobre estos conceptos nuevos generando

lo que parecen ser artículos y cursos, y

ya no distingues si es para rascar views

o es para ganar dinero, al final te

genera un ecosistema, como digo, de muy

baja confianza. ya no sabes qué es

realmente humo, qué vale la pena

aprender, si son cosas nuevas, si no lo

son o realmente qué está pasando en todo

este ecosistema. La frustración no viene

de la innovación, viene de que cada

pequeño cambio se presenta como una

disciplina completamente nueva. Para mí

tendría mucho más sentido hacer un

ejercicio. Agarremos todos estos nombres

que han ido apareciendo de engineering y

cambiamos la parte de engineering por

pattern, por patrón. Creo que todos

tendríamos la mente mucho más sana si se

llamaran simplemente patrones de uso de

agentes y estuviéramos hablando del

patrón de bucle o el patrón de grafo.

Pero ponerle el nombre de una disciplina

que parece ser que va a ser el nombre

que vas a tener en tu puesto de trabajo

y que la empresa va a contratar un

equipo de cuatro loop engineers y siete

context engineers y 20 graph engineers,

pues genera esta incomodidad porque

dices, realmente no creo que eso vaya a

pasar. Pero bueno, aparte de todo esta

discusión, quiero dar un poquito de

sentido a lo que realmente se entiende

por graph engineering o qué es lo que se

está comentando en la mayoría de

artículos que han ido apareciendo cuando

este término se ha hecho medianamente

viral. Te quiero dar un resumen de todo

lo que he leído, precisamente para que

no tengas que ponerte a hacerlo. Y es

que en la mayoría de artículos o

bibliografía que he encontrado sobre

graph engineering se menciona que esta

nueva disciplina o esta nueva forma de

hacer las cosas, este patrón, es una

construcción por encima del loop

engineering, sería la evolución. Por lo

tanto, lo que está ocurriendo es que nos

da siempre la sensación de que cada cosa

que aparece se construye sobre la cosa

anterior, generando por ende esa

sensación de urgencia. Ya tengo un vídeo

donde comentaba un poquito los conceptos

que había detrás del loop engineering,

que te voy a dejar por acá abajo en la

descripción. Pero para hacer un pequeño

resumen, loop engineering era

básicamente darle a un agente de

inteligencia artificial la capacidad de

ir hacia un objetivo. Ese objetivo no se

cumplía hasta que se cerraba lo que se

llamaba un ciclo. Por ejemplo, quiero

que estés revisando mis tickets que

tengo en mi herramienta de tickets, por

ejemplo, en linear wengira. Y cuando

veas que aparece un ticket nuevo,

empieces a generar una serie de specs,

de documentos, de código, hasta que

consigas solucionar ese ticket, generes

la PR y entonces tenemos el ciclo

cerrado. Podríamos entender eso como una

especie de orquestación de diferentes

agentes. Pues por si fuera poco, ahora

con el graph engineering lo que se dice

es que ese bucle nosotros lo tenemos que

aumentar y representar como un grafo. En

vez de definir solamente lo que un

agente tiene que hacer y qué objetivo

tiene que cumplir, lo que vamos a hacer

es definir una orquestación de agentes.

Vamos a definir una serie de pasos, una

especie de máquina de estado sobre la

que podemos delegar diferentes etapas de

nuestro trabajo. Aquí lo que haríamos es

que cada nodo de nuestro grafo sería

básicamente un agente de inteligencia

artificial y cada arista sería

comunicación de estado y contexto entre

las diferentes etapas. Esto simula mucho

la forma en la que trabajes en una

organización con diferentes ingenieros o

diferentes equipos de ingeniería. Al

final, tú no trabajas en un bucle tú

solo, sino que transfieres conocimiento

a otras personas o esperas que te den

conocimiento para tú poder continuar.

Incluso tienes diferentes personas

trabajando en paralelo, pues lo mismo

sucede con este concepto que se hace

llamar graph engineering. ¿Por qué digo

que no es algo totalmente nuevo? Porque

realmente las máquinas de estado no son

algo que se haya inventado ahora. Y de

hecho ya había un montón de herramientas

cuando empezó todo el auge de la

inteligencia artificial que utilizaban

agentes dentro de máquinas de estar.

Recordemos Make, recordemos N8N, incluso

herramientas un poquito más avanzadas

como Langraf. Es decir, es por eso que

me da la sensación de que simplemente le

hemos puesto un nombre molón a una cosa

que ya llevamos haciendo desde hace

tiempo. Como ves, el concepto de

ingeniería de grafos puede parecer muy

sencillo, pero también el hecho de

ponerle otro nombre, además un nombre

con el engineering detrás a esta especie

de disciplina o esta especie de patrón,

pues también genera confusión porque le

estamos sumando otro nombre más a un

montón de cosas que no paran de

aparecer. Como digo, hasta cenato

estábamos hablando de Harness

Engineering o de loop engineering. Ahora

le añadimos uno más. Y mucha gente se

puede confundir, pensar que el loop

engineering es antiguo, que el graph

engineering es lo nuevo, que el harness

engineering no sabemos ya exactamente

qué es lo que hace y ahora tenemos que

aprender esta otra parte. Ya no sabes

directamente qué tienes que poner en tu

currículum ni cómo buscar ofertas de

trabajo que incluyan IA. Por eso siempre

digo que lo importante es aprender los

conceptos fundamentales y luego el

nombre que le pongamos es totalmente

indiferente. Uno de los mayores riesgos

que veo en aprender hoy en día es en

dejarnos llevar por el hype y no

aprender lo que realmente importa. cómo

construir sistemas con inteligencia

artificial que sean robustos y

resilientes por suerte, hay algunos

artículos que son conscientes de todo

esto y en la propia explicación de Graph

Engineering ya explican que no es una

técnica 100% nueva, que simplemente le

han puesto una etiqueta que antes no

existía. En el mismo artículo de AI

Builder Club dice lo siguiente: "Lo que

es realmente nuevo en este 2016 no es ni

el patrón ni la tecnología, sino el

nombre común que le damos a esta

práctica. Entonces, ¿por qué ocurre todo

esto? ¿Por qué parece ser que con la

inteligencia artificial no podemos

sentarnos, ponerles nombres con sentido

a las cosas y parece que estemos

corriendo siempre como pollos sin

cabeza? Me atrevería a decir que es por

la viralidad, la gran cantidad de

interés que está moviendo la IA y la

gran cantidad de prisa que tienen muchas

personas por aprender y estar siempre en

lo último, ya sea por miedo a quedarse

sin trabajo, ya sea por miedo a quedarse

atrás o ya sea simplemente por

movimientos de marketing. Como no, el

concepto de graph engineering surgió de

nuevo por un tweet de Peter [música]

Steinberger. Y yo sinceramente a nivel

personal ya no sé diferenciar si estos

tweets acaban siendo meme o son en

serio. Lo que sí sé es que sean meme o

sean en serio, estos tweets generan una

serie de artículos de documentación y de

contenido, ya sea en YouTube, Twitter,

LinkedIn y otras redes sociales que

hacen que estos nombres acaben

disparándose, acaben distribuyéndose por

un montón de gente y acaben

expandiéndose como un incendio.

Básicamente es por esto [música] que a

pesar de que puede haber cierta verdad o

cierto interés o cierta novedad en estas

palabras, en estos nombres que están

apareciendo, para mí se genera un efecto

negativo. Esta sensación de urgencia,

esta sensación de clickbait, esta

sensación de necesitamos atención ahora

mismo, para mí lo único que genera es

toxicidad y problemáticas a la hora de

aprender. Porque como digo, que el

término esté rodeado de hype y rodeado

de ruido no significa intrínsecamente

que sea un mal término o una mala

práctica. De hecho, en la ingeniería de

software siempre le hemos puesto nombres

y etiquetas a diferentes herramientas,

metodologías o patrones, precisamente

para generar un diccionario común que

nos permita comunicarnos entre nosotros.

Esto ha pasado, por ejemplo, un montón

en la programación orientada a objetos.

Todos conocemos los patrones de diseño.

De hecho, hay compendios en libros con

unas recetas y nombres de los 20 y pico

patrones de diseño de los G of War.

patrones, estructuras de clases, métodos

de solucionar ciertos problemas que son

estructuralmente replicables y que por

lo tanto si les pones un nombre puedes

comunicar y puedes informar a la gente

que los estás utilizando. Por ejemplo,

informar de que vas a crear un

singletone y mentalmente todo el mundo

ya entiende lo que quieres hacer o

comunicar que esto se podría arreglar

con el patrón observer y la mayoría de

gente que sepa de programación te va a

escuchar y va a entender a lo que te

refieres. Por lo tanto, las etiquetas no

son malas de por sí. Ahora bien, yo en

ningún momento diría que soy ingeniero

de singletones o ingeniero de observers,

cosa que sí que parece que es la

intención dentro del mundo de la

inteligencia artificial. Para mí, un

término tiene que nacer, tiene que

ocurrir cuando se cumplen estas tres

condiciones. Primero, ofrece un

vocabulario unificado que nos permite

comunicarnos mejor. Segundo, permite

acercar ideas académicas o ideas

complejas a desarrolladores que quizá no

tienen un background tan académico. Y

tres, se entiende de forma unificada,

irreplicable. Podríamos decir, pues

quizás sí, ¿no? Quizá ingeniería de

bucles o ingeniería de grafos nos pueden

ayudar a simplificar ciertas ideas

académicas, aunque tengo mis dudas de

que se expliquen y se entiendan

realmente así, pero bueno, podamos

asumir que sí. Ahora bien, estoy

bastante seguro de que no ayudan a

comunicarnos mejor, porque cuando yo

estoy hablando con alguien y le hablo de

loop engineering, lo que entiende esa

persona, lo que entiendo yo y lo que

entiende un tercero nunca acaba de

encajar. Y me da la sensación de que va

a ocurrir lo mismo con la ingeniería de

grafos. En muchas ocasiones, cuando lees

las explicaciones de o los artículos,

¿no?, de esta serie de disciplinas, son

explicaciones bastante ambiguas. No

acaba de dejar claro exactamente cómo

funcionan, son bastante abstractas y al

final para mí cuando un término

ingenieril tenga sentido y se pueda

utilizar, pues tiene que ser como por

ejemplo un patrón de diseño como el

singleton. Tiene esta estructura, tiene

estas clases, tiene esta forma de

implementarse y soluciona estos

problemas en concreto. En cambio, todos

los términos que aparecen de IA están

generando más problemas que soluciones.

Por un lado, están frustrando un montón

de gente y, por otro, incluyen tantas

cosas que dejan de ser precisos. Para

mí, en el momento en que una decisión

arquitectónica se convierte en una

identidad profesional, que es lo que

está pasando con todos los lo que sea

engineering, en el momento en que un

nombre genera más urgencia que utilidad

real sobre lo que estamos desarrollando,

es cuando tenemos que agarrarlo con

pinzas y al menos sospechar. Es por ello

que doy gracias de haber aprendido a

programar y haber aprendido ingeniería

de software en la era preinteligencia

artificial, porque ahora todo lo que

estamos aprendiendo lo estamos

aprendiendo de forma reactiva. Estamos

respondiendo a marketing, a nombres que

aparecen en redes sociales, a viralidad,

como si fueran verdades ingenieriles.

Saltamos de un término a otro sin dar ni

siquiera tiempo a acabar de masticar,

profundizar y experimentar con el

término anterior. Si no, déjame en los

comentarios cuántos de vosotros habéis

conseguido llegar a ser expertos en loop

engineering y ahora os encontráis que ya

tenéis otro término que tenéis que

aprender desde ya. Esto lo que hace es

que siempre tengas esta sensación de

fomo, esta sensación de nunca dejo de

aprender, esta sensación de dolor de

cabeza y por lo que recibo también un

montón de comentarios de gente que me

dice que directamente quiere dejar este

sector porque no aguanta más y me atrevo

a decir que con razón. Por suerte, lo

que yo intento transmitir es que no

tenemos por qué memorizar todos los

nombres. Como siempre digo, es

importante aprender los fundamentos, si

no nos vamos a volver locos. Es por ello

que te quiero comentar los filtros o los

estudios que yo realizo para detectar si

algo merece la pena ser aprendido o es

directamente high. Y no solamente eso,

saber detectar qué partes son útiles y

qué partes no. Para mí, para ver si algo

merece o no la pena, nos tenemos que

hacer cinco preguntas. Si todas ellas

tienen una respuesta clara, entonces es

algo que merece la pena seguir

investigando en profundidad. Si no es

algo que podemos leer, podemos conocer,

pero tenemos que entender que lo tenemos

que un poquito con pinza. La

primera pregunta es, ¿qué problema

resuelve esto nuevo que acaba de

aparecer? Y con problema me refiero a

algo concreto. Cuando yo estoy

estudiando el patrón Singleton, el

problema que se me presenta para

solucionarlo con este patrón es el hecho

de compartir ciertos recursos, cierta

clase en un entorno de programación en

el que quiero que todos tengan acceso a

ese recurso. Por ejemplo, quiero que

todo el mundo tenga acceso a una

conexión a la base de datos. Es un

problema concreto, factible, trazable

que puedo ver en mi código. Tenemos que

hacer lo mismo con estas palabras que

aparecen en inteligencia artificial.

¿Qué problema resuelve graph

engineering? Si me preguntaran a mí

viendo lo que he leído, pues me

atrevería a decir que resuelve el

problema de trazabilidad entre

diferentes agentes de o entre diferentes

tareas o incluso de especialización. Por

ejemplo, si yo quiero tener diferentes

modelos de inteligencia artificial

especializados en diferentes tareas y

quiero poder ver cómo fluye la

información, quiero tener trazabilidad

de cómo se van delegando información

unos a otros, pues montármelo como un

grafo me puede ayudar a realmente

visualizar eso. La segunda pregunta es,

¿qué cambios técnicos aparecen? Con los

patrones de diseño podríamos entender

que el cambio técnico podría ser que a

partir de que lo aplico, tengo una serie

de capacidades técnicas que antes no

tenía. Si utilizo el patrón observer, a

partir de que lo utilizo, puedo

suscribir o desuscribirme de cambios de

mi arquitectura desacoplando diferentes

parámetros. Entonces, ¿qué capacidades

técnicas me da la ingeniería de grafos?

Bueno, una posible nueva capacidad

técnica, que no sé si es nueva o ya

podríamos decir que lo podéis hacer con

loop engineering, sería la capacidad de

poder definir esta organización de

agentes. Es decir, con graph engineering

la idea es que tú puedas definir

diferentes agentes y decir, "Vale, pues

este agente cuando termine va a mandar

la información a estos dos agentes que

vienen después en el grafo." Al final,

recordemos que es una máquina de

estados. ¿Esta capacidad técnica es algo

que no teníamos antes, seguramente no,

pero como digo, para mí tendría mucho

más sentido llamarlo patrón de gestión

de agentes en grafo, por ejemplo, graph

pattern. Para mí el gran problema es

llamarlo todo engineering, que es lo que

genera más confusión. Pero bueno,

podemos entender que sí que hay una

capacidad técnica nueva que antes pues

quizá no teníamos o no era tan sencilla

de implementar. La tercera pregunta,

¿puedo explicar el concepto sin utilizar

el nombre del concepto? Es decir, puedo

explicarte cómo funciona un singleton

sin utilizar la palabra singleton. Sí,

singleton lo puedes explicar como que

tienes un recurso compartido y accesible

desde cualquier otro recurso. ¿Puedo

explicar graph engineering sin utilizar

la palabra graph engineering? Bueno,

difícilmente lo vas a poder explicar sin

utilizar la palabra grafo o utilizar la

palabra máquina de estados, pero sí que

podrías definirlo a alto nivel como que

organizas diferentes agentes con

relaciones entre ellos y defines cómo se

comunican, en qué orden y qué se mandan.

Por lo tanto, bueno, pues sí que lo

podrías llegar a explicar sin utilizar

la etiqueta. Pregunta cuatro, ¿lo

necesito ahora? Es decir, aunque ahora

mismo es cuando se está haciendo viral

este concepto, realmente necesito

aprenderlo ahora. Y para mí esta es una

de las preguntas más importantes porque

es lo que nos evita aprender [música]

de desarrollo basándonos en el FOMO.

Esto es algo que ya pasaba con los

framos de JavaScript. de golpe parecía

uno, se hacía superviral y parecía que

si no aprendías eso no estabas al día,

cuando la mayoría de código en las

empresas seguía estando en Angular o en

React nativo. Es por ello que para mí

tenemos que tomarnos estos nombres como

lo que son definiciones de patrones, de

herramientas o de soluciones que son

comunes a diferentes problemas, pero que

tengo que aprender cuando realmente sea

necesario aplicarlo. De la misma forma

que muchas veces se decía que aplicar

patrones de diseño era sobre ingeniería,

aplicar graph engineering a todo

también. es sobre ingeniería. Y la

última pregunta, la pregunta cinco,

¿seguiría siendo esta práctica útil si

no existiera el nombre? Como siempre

digo, los fundamentos tienen que ser lo

importante, es lo que tiene que

sobrevivir a largo plazo. Los nombres

van y vienen y más hoy en día. Es por

ello que siempre nos tenemos que

preguntar, "¿Vale, esto que estoy

aprendiendo si se llamara Pepito de los

Palotes también sería interesante de

aprender?" En el caso de la ingeniería

de grafos, me atrevo a decir que sí. Al

final estás aprendiendo a orquestar

[música] diferentes agentes de

inteligencia artificial. De la misma

forma que lo hacías mediante un bucle

lineal, podríamos decir, pues también lo

haces ahora con grafos donde tienes

bifulcaciones y diferentes maneras de

organizarlo. Y como ves, parece ser que

la ingeniería de grafos cumple con todas

las características para merecer tener

un nombre propio o al menos un nombre

para este patrón. Aunque sí que es

cierto que para poder aplicarla

correctamente y de una forma que te dé

soluciones, pues vas a estar quemando un

montón de tokens de inteligencia

artificial. Pero eso podemos pensar que

es otro tema. El concepto puro como tal

de orquestar diferentes pasos en una

máquina de estado y poder ir delegando

las funciones es algo intrínsecamente

con valor, aunque no sea algo nuevo que

aparezca ahora y simplemente se ha hecho

viral por cuatro memes de Twitter. Si

quieres aprender ingeniería de grafos,

mi recomendación es que no busques

artículos de ingeniería de grafos, sino

que busques cómo funcionan las máquinas

de estado. Las [música] máquinas de

estado son herramientas que llevan un

montón de años dentro del desarrollo de

software y es como se han diseñado la

mayoría de UI que son robustas las

interfaces de usuario y un montón de

elementos en el propio cloud. De hecho,

Amazon Web Services, Azure, Google

Cloud, la mayoría de frameworks y

sistemas para construir software tienen

materiales o herramientas para poder

construir máquinas de estado. Y es que

al final una máquina de estado es un

programa, es un software. Por lo tanto,

si tú en cada nodo, en cada línea de

ejecución de esta máquina de estado le

metes IA, estás construyendo un sistema

de software con IA. Si quieres aprender

a desarrollar con inteligencia

artificial, sin dejarte llevar por el

hype, por el fomo, por las prisas, por

la urgencia, te dejo por aquí una lista

de producción que te puedes ver en la

que te hablo de diferentes conceptos,

diferentes términos de ingeniería de

inteligencia artificial. [música]

Todo ello muy bajado a tierra intentando

enseñarte los fundamentos más allá de

las palabras. Y si este vídeo te pareció

interesante, por favor, suscríbete y

déjame un buen like [música] y nos vemos

en el siguiente con más informática.

Hasta otra. M.