Hack The Talk
El podcast de Sopra Steria España donde nuestro talento habla de tecnología, innovación y transformación digital.
Hackea la innovación con nosotros. El futuro… ya está en marcha.
Hack The Talk
Desarrollar con IA sin perder el control: contexto, agentes y nuevas metodologías
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
La inteligencia artificial está transformando la forma en la que desarrollamos software. Cada vez es capaz de generar más código, automatizar más tareas y acelerar procesos que hace apenas unos años requerían horas de trabajo manual.
Pero cuanto más potente es la herramienta, más importante se vuelve el papel de las personas.
En este episodio de Hack the Talk, el podcast de Sopra Steria España, exploramos uno de los grandes desafíos del desarrollo asistido por IA: cómo aprovechar todo su potencial sin renunciar al criterio técnico, la calidad del software y la capacidad de tomar decisiones informadas.
Moderado por Sergio Monroy (HRBP), conversamos con Daniel Hernández, desarrollador backend, experto en Inteligencia Artificial y ganador de la Hackathon de IA 2026 de Sopra Steria España.
A través de ejemplos reales y de su experiencia trabajando con agentes de IA, descubrimos por qué el éxito ya no depende únicamente de escribir código, sino de saber definir el contexto adecuado, estructurar correctamente el trabajo y validar cada paso del proceso.
En este episodio hablamos de:
- Por qué el contexto se ha convertido en el activo más valioso para trabajar con IA.
- Cómo metodologías como Spec Driven Development permiten desarrollar software de forma más controlada, escalable y eficiente.
- El potencial de los agentes de IA para acelerar el desarrollo sin perder calidad.
- Por qué la validación humana sigue siendo imprescindible para evitar errores, alucinaciones y decisiones incorrectas.
- Cómo optimizar costes, tokens y modelos para obtener mejores resultados.
- Qué habilidades marcarán la diferencia en la nueva generación de profesionales tecnológicos.
Porque la pregunta ya no es si la IA va a cambiar la forma de desarrollar software. La verdadera pregunta es quién será capaz de guiarla mejor.
Una conversación sobre tecnología, criterio humano y las nuevas reglas del desarrollo en la era de la Inteligencia Artificial.
🎧 Si este episodio te ha hecho pensar, imagina lo que viene.
Suscríbete a Hack the Talk y acompáñanos en las próximas conversaciones en Sopra Steria España.
Esto es Hack the Talk, el podcast de Soprasteria España donde nuestro talento habla de tecnología, innovación y transformación digital. Hackea la innovación con nosotros. El futuro ya está en
SPEAKER_03marcha.
SPEAKER_00Muy buenas y bienvenidos y bienvenidas a Hack the Talk, el podcast de Sopraster en el que hablamos de tecnología e intentamos compartir nuestro conocimiento y divulgar con aquellas personas que nos escucháis al otro lado. Hoy, un sexto programa en el que vamos a hablar de una iniciativa que hemos llevado a cabo dentro de la compañía hace relativamente poco tiempo, una hackatón, y para ello tenemos aquí a nuestro compañero colaborador Daniel Hernández, desarrollador backend y experto en materia de inteligencia artificial dentro de Sopraster España. Bienvenido, Dani. ¿Cómo estás? ¿Cómo te encuentras? Muchas
SPEAKER_01gracias. Encantado de que me hayas invitado aquí al podcast para hablar un poquito sobre un tema que me gusta, que me apasiona, que es la inteligencia artificial.
SPEAKER_00Inteligencia artificial, pero no solo vamos a hablar de inteligencia artificial, sino también un poco de metodología, de cómo emplear inteligencia artificial con dos dedos de frente sin que creemos monstruos tecnológicos y que poco a poco vayamos pautando y que veamos también un poquito el valor humano dentro de este tipo de procesos y de nuevas metodologías de trabajo Dani sexto programa de Jatetalk queríamos también desde aquí agradecer a la gente que nos está escuchando todas las semanas y el apoyo que os estoy dando a los programas, desde aquí os lo agradecemos encarecidamente y esperemos que os podamos acompañar durante muchas, muchas, muchos meses más y nada ganador de la primera hackathon que realizamos sobre todo en materia de IA agéntica dentro de Superasteria España. Dani, ¿cómo viviste un poco el reto? ¿Qué te llamó para empezar a trabajar en este reto? Luego hablaremos un poco de tu proyecto, pero ¿qué es lo que te llamó de esta iniciativa?
SPEAKER_01Bueno, pues un poco pues a ver, a mí me gusta todo el ámbito de la inteligencia artificial, me estoy formando en ella. De verdad que Soprester me ha dado la oportunidad ahora de poder dar unas formaciones a nivel compañía sobre inteligencia inteligencia artificial. Y cuando vi que se iba a hacer una hackathon enfocada al uso de inteligencia artificial, ya no solo que el propio producto tuviera inteligencia artificial, sino que se tuviera que construir también con inteligencia artificial, me llamó la atención y dije, bueno, pues es una oportunidad de todo lo que estoy aprendiendo poder plasmarlo y Y después también la opción, la oportunidad de poder ver también otros proyectos que se hicieron con inteligencia artificial que al final, aparte del mío, los demás pueden aprender de ellos.
SPEAKER_00O sea, al final compartir
SPEAKER_01conocimiento un poco, ¿no? Claro, compartir y aparte de dar, recibir.
SPEAKER_00Al final todo esto entra dentro de las iniciativas que estamos realizando como empresa tecnológica. Al final estamos capacitando a nuestros equipos a través de formaciones que, por ejemplo, compañero nuestro Dani imparte dentro de la empresa. También un poco poniendo en valor el conocimiento de aquellas personas que ya han visto cosillas por su parte de inteligencia artificial o que han podido disfrutar dentro de las formaciones que realizamos dentro de la empresa, pues darles ese espacio ese contexto para poder mostrar al resto de compañeros y compañeras de la empresa el potencial de este nuevo paradigma de estas nuevas herramientas y sobre todo, creo que es un punto que vamos a centrarnos bastante en ello a lo largo de la charla de hoy a nivel metodológico porque vemos el potencial que tiene este tipo de herramientas todo el tema de agentes, bytecoding etcétera, vemos el potencial que tiene pero no hay que perder de vista sobre todo el tema de metodológico el cómo construir un proyecto de una manera más o menos controlada para que tampoco se nos pueda desvirtuar demasiado cuéntanos un poquito Dani, porque vamos a centrarnos en estas buenas prácticas si quieres de manera vehicular nos puedes contar un poco el tipo de proyecto que realizaste pero cuéntanos un poquito pues oye qué buenas prácticas qué metodologías podemos aplicar en nuestro día a día para conseguir este objetivo que es hacer cosas escalables mantenibles y que la parte humana siga teniendo un un papel predominante en el desarrollo con inteligencia artificial en cuanto a revisión y cerciorarnos y que todo funciona correctamente. Cuéntanos.
SPEAKER_01Lo importante cuando utilizamos inteligencia artificial, sobre todo es, por lo menos hoy en día, es la validación humana. La inteligencia artificial a día de hoy Por ejemplo, hace un año el problema con la inteligencia artificial solía estar en qué código, hablando de desarrollo, en qué código nos daba. Tenemos que validar ese código, que fuera bueno, que fuera malo. Ahora ese problema ha cambiado. Ya el código que nos da la inteligencia artificial ahora es bueno y ahora hay que... Hay que guiar a la inteligencia artificial, ya sea con buenas prácticas, ahora está muy de moda, ¿no? Y que es donde hay que poner el foco, ¿no? Que es en el engineering arnés, ¿vale? En el arnés, en cómo, vale, utilizo la inteligencia artificial. porque es muy potente y nos escribe código y demás, pero claro, hay que saber guiarla. Hay un símil que me parece interesante, es como vamos en un coche y como la inteligencia artificial es el acelerador, podemos ir más rápido, pero si no tenemos un mapa, si no sabemos dónde queremos llegar, vale, vamos muy rápido, pero podemos estar dando vueltas. Entonces, la metodología, todo el arnés, es lo que va a ser el mapa, en el que nos vamos a ver dónde vamos a llegar, la ruta más más corta o más rápida que queramos, pero ¿cómo vamos a ir de un punto A a un punto B? Entonces, todas estas buenas prácticas, todo este arnés, como por ejemplo lo que hablaremos hoy, la metodología SED, el Spectral Event Development, es una más para guiar. Ahora el problema está en que tenemos que saber guiar a la inteligencia artificial y el validar. Al final nos olvidamos muchas veces que tenemos que validar todo lo que nos devuelve la inteligencia artificial. Porque, bueno, o Tenemos tema de alucinaciones, tema de contexto, si tiene mucho, si tiene poco, nos devuelve un poco lo que ella quiere. Si no le damos las cosas, entre comillas, un poco mascadas de lo que queremos, la inteligencia artificial da por hecho cosas. Entonces, ahora lo que hay que centrarse es en eso, en darle un buen contexto, guiarla, decirle a qué queremos que nos devuelva, que no nos devuelva lo que quiera, sino qué queremos que nos devuelva, para así poder sacarle el máximo beneficio. Y sobre todo, validar lo que nos da, ¿vale? La validación es muy
SPEAKER_00importante. O sea, que al final y al cabo, como hemos hablado en otros programas de Hack the Talk, la validación humana y el estar presentes como desarrolladores que controlen el procedimiento y se certinen de que lo que está haciéndose, está haciéndose correctamente, va a ser primordial y prioritario. El rol podría evolucionar y evolucionará. Dejaremos de ser artesanos de generar código a ser más orquestadores de soluciones integrales y un poco arquitectos de cómo se tiene que realizar cosas con este tipo de herramientas pero hay una cosa que me llama mucho la atención porque creo que hay un sentimiento generalizado de que el código que nos devuelve la inteligencia artificial a pesar de conllevar una tarea muy pormenorizada de revisión no suele gozar de la calidad que nos podemos esperar de un estándar de código aplicando clean code o este tipo de cosas actualmente el código está bien estructurado tal cual nos escupe la inteligencia artificial o está o sea es un código de calidad o no es un código de tanta calidad como nos imaginamos
SPEAKER_01sí y no
SPEAKER_00vale
SPEAKER_01Me refiero con esta respuesta de que es de calidad dependiendo, ¿vale? Porque con la inteligencia artificial la clave está en el contexto que le demos. Claro, si yo cojo, yo estoy generando una clase y le digo, oye, genérame esto en Java… Y no le digo nada más, genérame este método o esta clase en Java, la inteligencia artificial va a hacer lo que quiera. Pero si yo, que sé programar, ¿vale? No voy a tocar código, pero yo sé programar y le voy a decir, oye, quiero que me hagas esta clase en Java 17, me utilices programación funcional, quiero que los métodos, que cada método tenga una responsabilidad, ¿no? O sea... le damos contexto, le decimos lo que queremos hacer, ¿vale? Entonces, cuanto más contexto y cómo queremos hacerlo, quiero que pongas una interfaz, quiero que lo que sea, ¿no? Si se lo vamos diciendo todo, él no lo va a hacer. Entonces, al final, la calidad del código, claro, ¿de quién es la culpa de la calidad? ¿De la IA o del desarrollador que se piensa que a lo mejor con una línea la inteligencia artificial
SPEAKER_00va a ser mágica? Sí, que al final es un poco responsabilidad compartida, ¿no? El contexto que le damos y luego también cómo nos certeramos en la revisión y cómo apretamos en la revisión, ¿no?
SPEAKER_01Claro, pero es que muchas veces y mucha gente pone el problema en decir, no, es que yo quiero utilizar los modelos frontera, ¿vale? O sea, los últimos modelos, ¿no? Yo es que para programar bien tengo que utilizar GPT 5.5 o Cloud Opus ahora 4.7 o cualquiera, ¿no? Pero no nos damos cuenta que hoy en día con modelos más pequeños que a priori dices, joder, me va a razonar peor con modelos más pequeños con un buen contexto es que el contexto lo es todo o sea para mí es fundamental con un buen contexto programa muy bien porque el código al final es dependiendo del contexto toda información que no le demos la inteligencia artificial no es que esté en mente pero va a dar por hecho lo que ella considere entonces al final no nos devuelve lo que queremos y de quién es la culpa de la inteligencia artificial o nuestra que no hemos puesto unas buenas instrucciones que no tiene un buen contexto etcétera entonces ahí un poco está la trampa que muchas veces decimos la IA nos devuelve
SPEAKER_00código erróneo porque a lo mejor hemos hecho un prompt o un contexto deficiente que también entiendo que eso impacta directamente ya no solo en la calidad de la respuesta recibida sino también impacta directamente en la cantidad de tokens invertidos entiendo que con un contexto adecuado y utilizando un modelo de inteligencia artificial o de agentes adecuado, sin irnos a las tecnologías frontera, como tú bien decías, también eso tendría una repercusión importante en la cantidad de esfuerzo invertido por la inteligencia artificial a la hora de darnos una respuesta u otra, ¿no?
SPEAKER_01Por ejemplo, es interesante lo de los toques, ¿vale? Porque lo que hablaba, ¿no? Nos obcecamos muchas veces en los modelos frontera. Y al final, cuando Cuanto más contexto metamos, más nos consume, pero es verdad que el contexto es importante. Después se podrá ver que a más contexto tampoco tiene por qué ser bueno, porque puede confundirse y demás. Al final hay que poner el contexto, el necesario, sea poco o sea mucho, pero el necesario, conciso, y que nada de contexto se pise. Pero, por ejemplo, aquí hay que ver que aquí es donde entra uno de los roles para una de las funciones del desarrollador ahora, es hacer un análisis previo de la tarea. Porque si yo sé lo que tengo que hacer Sabré usar si tengo que utilizar un modelo u otro. Me explico. Si vamos a hacer, por ejemplo, una API REST básica, ¿vale? De usuarios o de lo que sea, una API REST básica, no me merece la pena utilizar un modelo frontera. Con un modelo más pequeño, pues, por ejemplo, un GPT 5.2 o 5.3 o un Cloud Sonnet 4.6, con eso me vale. Un buen contexto. Con esto voy a ahorrar muchísimos tokens. Por lo tanto, voy a voy a ahorrar dinero y el resultado es el mismo ¿vale? no por utilizar un modelo más potente el resultado va a ser mejor, el resultado será mejor con el contexto que le ponga ¿vale?
SPEAKER_00entonces muchas veces nos confundimos es como con el vídeo con Solás y los teraflops ¿no? es que tiene no sé cuántos teraflops, es mejor tal bueno, dependerá un poco de la optimización ¿no? que hayamos hecho para ese sistema en concreto o esa petición en concreto en este caso con la inteligencia artificial
SPEAKER_01¿no? claro que muchas veces no por más potencia el resultado es mejor, a lo mejor con menos potencia el resultado es lo mismo y así ahorrado token optimizas ¿vale? entonces al final ahora eso es una de las funciones del desarrollador el saber cuando hay que utilizarlo primero cuando hay que utilizar inteligencia artificial ¿vale? y lo segundo cuando vaya a utilizar inteligencia artificial ¿qué grado de inteligencia artificial tengo que tener? ¿Vale? Porque muchas veces ahora con los agentes y demás, todo tiene que tener agentes, ¿vale? O todo tiene que tenería, pues bueno, habrá casos que
SPEAKER_00sí, casos que no. Habrá casos que sí, casos que a lo mejor no hace falta. Vale, te quería preguntar, porque creo que es un punto interesante, ¿no? O sea, al final vemos que el desarrollador o la desarrolladora es un partícipe y eje central también de todo este proceso, y es muy importante, como tú bien decías, además que tú eres formador dentro de la empresa, la capacitación. Es por eso, por lo que desde la compañía realizamos este tipo de actividades, hackatones, formaciones, workshops, AI Days, AI Weeks, todo ese tipo de acciones para intentar capacitar a los profesionales y las profesionales para que puedan emprender estas acciones, estas nuevas tareas de un modo lo más eficiente posible y con cabeza, que es al final lo más importante. Dentro de la actividad de la hackatón, cuéntanos un poco, Dani, si quieres, un poquito cómo era tu proyecto y qué metodología aplicaste para desarrollar este proyecto y si quieres entramos ya en lo que viene siendo el Spec Driving Development
SPEAKER_01Sí, a ver, el proyecto yo cuando me propuse hacer la hackathon y ver qué proyecto lo quise enfocar un poco en dos aspectos el primero, el proyecto propiamente dicho que utilizar inteligencia artificial dentro del proyecto Y otro, la metodología. El proyecto en sí se llama StoryGate AI y consiste en un analizador de historias de usuario. Tú le pones una historia de usuario y mediante unos agentes la analiza y te dice si esa historia de usuario está lista para desarrollo, está lista para desarrollo, para entrar en el sprint o se tiene que quedar fuera del sprint y hay que darle una vuelta, hay que hacer ciertas preguntas al cliente para aclarar ciertas ambigüedades que tiene esa historia de usuario. Por una parte, ese fue el objetivo. Y el otro objetivo que también quise, porque al final, cuando trabajamos con inteligencia artificial, hay que utilizar una metodología. No vale con, oye, hazme esto, que te lo haga, y dices, vale, pero ¿qué camino ha seguido? ¿Cómo lo ha hecho? Eso se puede convertir en un monstruo, como tú has dicho antes, ¿no? Entonces, utilizar una metodología SDD, Expert Driven Development, que es de hace tiempo, ¿no? Pero ahora con inteligencia artificial se ha puesto de moda porque encaja muy bien, ¿vale? Porque es una metodología que sobre especificaciones... Bueno, no sé si después quieres...
SPEAKER_00Ahora detallamos, ahora detallamos. Sobre todo para aquellas personas que a lo mejor no están tan pegadas a este tipo de mundillo, que entiendan bien cuando escuchan hablar de SDD, pues que sepan realmente qué es SDD. CDD y en qué se basa, ¿no? Y en qué beneficia el proceso del desarrollo de
SPEAKER_01software. Claro. Entonces, un poco, el proyecto estaba en esos dos ámbitos. Uno, el proyecto propiamente dicho, y otro, la metodología que usé, ¿no? Y el proyecto, bueno, como he dicho, es algo sencillo que nos analiza las historias de usuario. Lo interesante era que había cinco agentes por detrás en el proyecto, en el que cada uno iba analizando una cosa, pues las ambigüedades, los riesgos, los criterios de de QA, si estaba lista o no estaba lista con todo lo que habían devuelto los anteriores agentes. Entonces, al final, lo interesante es cómo utilizar agentes dentro de una aplicación, cómo se hacen las llamadas a un LLM, etc.
SPEAKER_00¿Y cómo configuraste? Vamos a entrar un poquito más en lo que es la materia de la propia metodología. ¿Cómo funciona SDD? ¿Qué beneficios nos otorga? ¿Y por qué engrana tan bien con el desarrollo con agentes?
SPEAKER_01Pues al final, SDD, Spec Driving Development, es hacer un desarrollo conducido por una especificación La especificación es un documento que vive en el proyecto en el que explica qué se va a hacer. Una tarea, en ese documento ahí vamos a poner qué se va a hacer. Esta metodología tendría varias fases. El primero sería hacer un documento spec, qué se va a hacer. Con ese documento spec, que sería como la piedra angular de la tarea, a partir de ahí es lo que A partir de este documento vamos a generar lo demás. Después pasaríamos a hacer un plan. Ahí, en este plan, ese documento del plan sería cómo se va a hacer, ¿no? Cómo se va a hacer técnicamente, qué se va a usar, qué partes hay que realizar, etc. Y a partir del spec y del plan haríamos otro documento de task, ¿vale? Donde pondríamos todas las tareas que hay que hacer para solucionar esa especificación, ¿vale? Para solucionar esa tarea. Y después nos pondríamos a hacer tareas una a una. Esto sería lo que es Spectral and Development, hablado así un poco en resumen.
SPEAKER_00Que hay que saber atomizar bien las tareas a las cuales nos enfrentamos para predefinir antes bien el contexto y lo que hay que hacer y los pasos, de tal modo que luego podamos ir guiando poco a poco, paso a paso, a la inteligencia artificial, ¿no? En el proceso de desarrollo.
SPEAKER_01Claro, o sea, en principio SD sería esto, ¿no? O sea, al final vamos a tener unas tareas que están basadas en una especificación. Lo que no esté en esa especificación no se hace. Solo se hace lo que está. Al final la especificación va a ser un contrato vale con el cliente y el desarrollador y esto normalmente pues ahora con las tareas tú te pondrías a desarrollar qué pasa que ahora con inteligencia artificial esto casa muy bien porque es la propia inteligencia artificial que puede ir implementando todas esas tareas porque esas tareas ya están desgranadas vas a tener que tiene que hacer en la tarea y después va a tener contexto la especificación y el plan vale para no salirse de ahí donde en el plan le vas a decir qué tecnologías vas a usar que sí que no que entra que entra dentro del alcance ¿qué queda
SPEAKER_00fuera del alcance? y para aquellas personas que a lo mejor no estén tanto en el día a día del mundo del desarrollo que a lo mejor pertenezcan más a la parte funcional etc. estamos hablando que estos documentos estos archivos que entiendo que se integran directamente en el IDE ¿vale? son archivos que no tienen nada de código realmente es todo texto ¿no? de tal modo que la IA lo entiende entiende el contexto entiende la situación y empieza a tirar las señales del código la propia IA o sea está democratizando, por así decirlo de un modo u otro, lo que es el desarrollo de software.
SPEAKER_01Sí, ahora mismo, lo que hemos hablado siempre, con esta metodología estamos acelerando el desarrollo y como estos documentos no tienes que escribir nada técnico, es más, la especificación es interesante o necesario que no la escriba solo el desarrollador. Que la pueda escribir el desarrollador con gente fundamental. porque al final es el contrato. Entonces, son documentos que cualquier persona puede, se pueden crear con inteligencia artificial esos documentos en base a unas especificaciones que tú le digas, siempre validados por ti, ¿vale? O sea, bueno, no entonces la validación, siempre validados por ti, ¿vale? Porque estos documentos, como he dicho, son los contratos y cualquier persona, aunque sea funcional, también puede seguir este flujo.
SPEAKER_00Y luego estos documentos los introduces en tu IDE, ¿no? ¿Entiendo? ¿O cómo lo consume luego? Sí, no, en el IDE al final,
SPEAKER_01como trabajes, yo por ejemplo trabajo con un CLI, ¿vale? O puede ser con un chat, ¿vale? Da igual, con un agente de codificación, sea Codes, Cloud Code, Login Hack Copilot, y ese, cuando vas a decir quiero que me implementes estas tareas, tú le metes en contexto estos archivos. Por eso son buenos estos archivos. Y hablamos del contexto, de la importancia del contexto. Porque estos archivos encajan muy bien como contexto de la inteligencia artificial. Como ahí detallamos todo y al final es un contrato, eso se lo pasamos a la gente de codificación y ya lo tiene en contexto. Ya sabe, cuando va a realizar las tareas, ya tiene un contexto, sabe qué hay que hacer, cuál es el objetivo de esa tarea, lo que está dentro del alcance, lo que queda afuera, cómo tiene que hacer la prueba, cuáles son los criterios de validación de esa tarea, para que esa tarea esté correcta o no esté correcta, etc. Todo el contexto necesario va a vivir en esa especificación y en ese plan.
SPEAKER_00Y una vez que se hace cada uno de los pasos, al final entra el factor humano de validación y se le indica a la gente o a la guía que continúe con el proceso de desarrollo, que pase al siguiente paso. ¿Cómo sería un flujo? Por ejemplo, imagínate, estamos haciendo un CRUD, un Create, Read, Update and Delete, en un API REST, ¿cómo sería un poco el flujo? Un flujo pequeño, para que podamos un poco vislumbrarlo.
SPEAKER_01Antes de eso, aclarar que cuando hablamos con SDD con tema contexto, es interesante hacer SDD para cada tarea. O si vamos a crear un proyecto desde cero, dividir el proyecto en fases, ¿vale? Por ejemplo, como tú has dicho, una API REST. Pues no aplicar SDD a crear una API REST entera, ¿vale? ¿Por qué? Porque al final va a ser mucho contexto... la inteligencia artificial se puede liar. Y cuanto más concreto lo hagamos, mejor guiamos a la inteligencia artificial. Entonces, en este caso, por ejemplo, si vamos a hacer un API REST, sería interesante dividir toda la creación del API REST en fases y en cada fase hacer SDD en cada fase. ¿Vale? ¿Por qué? Porque al final, si voy a hacer la fase del repositorio, ¿vale? Crear las entities, el repositorio, a lo mejor eso lo puedo hacer en una fase donde tengo una específica función concreta para eso. Y cuando vaya a hacer el controller, ¿vale? Que a lo mejor sea la fase 3, a lo mejor no necesita tener en contexto el repositorio. O sea, ¿cómo se ha creado otro repositorio? A lo mejor en contexto necesita una línea de esa fase. Pues en esta fase se creó el repositorio. ¿Qué estamos haciendo? Ahorrar contexto. ¿Vale? cuando va a hacer la fase, no tiene en contexto todo el proyecto, solo tiene en contexto esa fase y las fases
SPEAKER_00anteriores para tener un poco... Y también eso, obviamente, irá intrínsecamente ligado al tener las diferentes capas separadas, etc. Claro, para eso hay que
SPEAKER_01hacer, como he dicho, un análisis previo de, en este caso, si se va a hacer un proyecto desde cero. Habría que hacer bien qué se va a hacer, cómo se va a hacer, para dividirlo en fases. Una vez que está el proyecto creado, en las tareas en cada tarea se puede hacer por SDD. No tiene por qué ser para crear un proyecto. Yo tengo una tarea de un proyecto que ya está creado, puedo crear, puedo hacer SDD para esa tarea en concreto. Y es más, se debería hacer un SD por cada tarea en concreto. Y al final un poco el SDD, lo interesante, y sobre todo ahora, yo por ejemplo lo apliqué en el proyecto del Hackathon, es que que todo el flujo lo haga la inteligencia artificial, ¿vale? Yo, por ejemplo, no escriba la spec, no escriba el plan, no escriba las tasks, no lo implemente, no lo valide, etc. O sea, no haga la validación, no haga la revisión. Pero, aquí es donde entra, donde está el punto importante. Yo, en cada paso, ¿vale? Validaba. Me explico. Yo cogía y están. Para hacer un SD, los pasos, los principales serían hacer la spec, la especificación, hacer el plan, hacer las tasks, hacer la implementación y después una revisión vale pues yo tenía unos agentes creados para que cada gente me hiciera una fase pero entre fase y fase yo como persona validaba que lo que había devuelto la inteligencia artificial era correcto. Me hacían la especificación en base a unos criterios que yo le había dicho, ¿vale? Lo hacía y antes de pasar al siguiente paso, yo paraba, me leía la especificación bien y decía, vale, esto es lo que quiero que haga. ¿Que no era así? Oye, modificaba yo algo o a la inteligencia artificial, oye, modifícame esto. El momento que estuviera ok, yo decía, ok, venga, seguimos con el siguiente paso, ahora hacemos el plan, ¿vale? Entonces aquí vemos como la validación humana es necesaria para que en cada paso, la persona valide lo que da la inteligencia artificial. Porque un problema en la especificación es como una bola de nieve, ¿no? Sobre todo con inteligencia artificial. Un pequeño problema... se transforma al final en un problema que dices, ¿por qué ha hecho esto? Es que en la especificación estaba esto y tú no lo has revisado. Entonces la importancia de cada fase hacer una revisión humana, ver que lo que ha hecho la inteligencia artificial esté bien.
SPEAKER_00¿Cuáles son, porque también creo que es interesante que lo comentemos, ¿cuáles han sido los principales problemas que te has encontrado a la hora de encarar este nuevo paradigma de desarrollo? O sea, tú como desarrollador backend, cuando has empezado a trabajar de este modo con SDD, con ese tipo de metodologías con ese tipo de herramientas como los agentes, ¿qué tipo de barreras te has encontrado, qué tipo de problemas te has encontrado?
SPEAKER_01El primer problema que yo me he encontrado sobre todo a la hora de trabajar con inteligencia artificial y es lo que explico un poco muchas veces en las charlas es el cambio de mentalidad o sea, en el que porque ahora cuando entra la inteligencia artificial nos pensamos, que lo hablábamos al principio de la charla, nos pensamos que la inteligencia artificial es magia, ¿vale? Y no es magia, ¿vale? O sea, hay que saber, a mí me costó decir, no, es que todo lo que me diga la IA, tengo que validarlo. ¿Vale? Porque me puede dar, si me da una respuesta que es un fallo clamoroso, perfecto. Lo arreglo y ya está. Pero el problema con la inteligencia artificial, que es el chip, es que me puede dar una respuesta que sea clara, que sea concisa, que sea... Las medias verdades, ¿no? Está bien, ¿vale? Pero que después la analizas bien con el contexto que tenía y demás y dices, no, si se lo ha inventado, si es que esto no es así, o ha mezclado cosas y es que esto está mal, ¿no? Ese es el problema. Una respuesta que parezca buena, que no lo sea. Y ese cambio de mentalidad de decir, no, joder, es que todo lo que, o sea, que no todo lo que me diga la guía está bien. Que hay veces que hace cosas que yo no le he pedido. O sea, pues muchas veces cuando empezamos a trabajar con la guía, pues venga, escribimos, oye, hazme esto, hazme lo otro, hazme tal. Y el cambio de decir, no, joder, es que, o sea, antes de empezar con la guía tengo que hacer un trabajo yo antes de tenerlo todo claro, qué es lo que quiero, qué es lo que no quiero. Y esto con el proyecto, pues sobre todo es eso, ¿no? El de Es decir, tengo que estructurar bien lo que voy a hacer, tengo que dividirlo bien en fases, como decía yo antes, para aplicar ese ED en cada una, ver bien qué es lo que quiero, qué es lo que pido y qué es lo que me tiene que devolver. Ese análisis previo que antes se iba haciendo durante el desarrollo, ahora hay que hacerlo antes y hay que perder más tiempo.
SPEAKER_00Sí, que es una inversión al fin y al cabo de tiempo para luego intentar evolucionar la parte de la codificación. Es
SPEAKER_01decir, para Dani antes de empezar a hablar con la IA aclárate qué quieres hacer estructúratelo bien eso por un lado y por otro la gestión de token eso después es fundamental porque al final en el hackathon si teníamos límite de tokens bueno en este caso eran de request porque era con Github Copilot en mayo fue pero había que controlarlo o sea si me quedaba sin ello ya no podía utilizar estaba extendido entonces claro el manejar de pues para hacer por ejemplo las especificaciones los documentos de spec de plan y de task pues si es verdad que utiliza un modelo un poco más potente y para hacer la implementación utiliza un modelo más pequeño ¿por qué? porque la implementación ya lo tenía todo mascado en las tasks con la especificación y con todos estos documentos y no necesitaba un cómputo demasiado
SPEAKER_00grande
SPEAKER_01claro pero para el otro sí
SPEAKER_00además sabemos que además sabemos que el tema de los tokens cambia cada mes cambia y estamos ahora mismo en junio de 2006 en proceso de cambio actualmente.
SPEAKER_01Claro, y hoy los token con CLOD o con GPT te cuestan X, pero mañana mejor cogen y dicen, oye, que donde hace un mes dije X, ahora es X más 10. Y dices, entonces si ya sabemos cómo optimizar, pues eso fue uno de los problemas también con los que me enfrenté, es decir, ¿cómo optimizo token para no quedarme sin ellos, para con estos token poder hacer el proyecto?
SPEAKER_00y tú ya vamos finalizando el programa de hoy pero antes de cerrar me gustaría oye qué recomendaciones sueles dar tú en tus formaciones en tus cursos qué recomendaciones sueles darías a las personas que se están enfrentando un poco ahora a esta transición del paso de un desarrollo clásico a un desarrollo guiado por agentes
SPEAKER_01yo sobre todo lo que digo en mis charlas y es así como lo enfoco es aprender conceptos aprender los conceptos conceptos, aprender los fundamentos, porque el concepto no cambia, ¿vale? Cambiará la herramienta, ¿vale? Cambiará en vez de utilizar Codes, utilizaremos Cloud y o si no tal o evolucionará, pero el concepto del contexto y de la importancia del contexto siempre va a estar ahí. Entonces, aprender los conceptos, que es un contexto, que es RAC, que es las Skills, que son los MCPs, ¿vale? Aprender el concepto y aprender después cómo se usa y demás, pero sobre todo es eso, los fundamentos, es me parece clave, porque eso al final es como la programación. La programación, tú puedes aprender no sé cuántos mensajes, lenguajes, pero los fundamentos de programación son los fundamentos, esos no cambian. ¿Vale? Y eso es lo que hay que tener bien estudiado y bien aprendido. Pues con la inteligencia artificial es lo mismo. Tenemos que aprender los fundamentos, los conceptos, ¿vale? El tema de alucinaciones, el tema de la temperatura, el top cap, todo esto, ¿no? Aprenderlo bien, porque eso al final no va a cambiar. Cambiará después que el modelo sea mejor, sea peor, pero al final el modelo trabaja con un contexto, ¿vale? Y con unos tokens y con un prompt y etcétera. Entonces yo creo que enfocaría las cosas para empezar ahí y después ya de eso ya aprender herramientas, etcétera.
SPEAKER_00Pues Dani, quería agradecerte tu tiempo que te has tomado por estar aquí un ratito con nosotros en How to Talk hablando sobre SPECT, Drive and Development, sobre Inteligencia Artificial Y sobre aquellas cosas tan interesantes que me has contado, que de verdad te lo agradecemos un montonazo y seguro que la gente que nos está escuchando desde sus casas, desde las ondas, también le agradece. Muchísimas gracias, Dani. No sé si quieres añadir alguna cosita más antes de acabar, concluir.
SPEAKER_01No, muchas gracias a ti por invitarme y invito a todo el mundo a que se inicie la inteligencia artificial, a que no tenga miedo y a que interactúe, intere con ella, que al final... Mejora mucho el trabajo y la vida personal y al final también la usamos ahora en todos los ámbitos.
SPEAKER_00En todos los ámbitos de nuestra vida. Y está bien que hagamos conciencia y que sepamos cómo utilizar las cosas porque se nos puede un poco la cabeza muchas veces. Pero está bien estar instruidos, estar al día, estar al tanto de cómo funcionan estas nuevas herramientas y que las utilicemos siempre con cabeza y del modo correcto para obtener las respuestas adecuadas. Dani, muchas gracias. Hasta aquí el programa de hoy. También dar muchas gracias nuevamente a nuestra audiencia que nos está apoyando tantísimo a través de Spotify. Y nada, nos vemos en el próximo programa de Hack the Talk. Muchas gracias.
SPEAKER_03Chau.