Dev&Ops es el espacio donde hablamos de cultura tech, compartimos anécdotas reales y damos consejos prácticos para todo entusiasta del mundo del desarrollo y la tecnología. Acompáñanos a descubrir las últimas tendencias, aprender de nuestras experiencias y recibir tips que te ayudarán a destacar en este entorno digital en constante evolución.
Juan (00:00)
Revisa y evalúa todo lo que genera la IA.
no se trata de aprender o reaprender más cosas, sino más bien es de cómo podemos incluir a la IA en estos procesos que ya teníamos y tratar de entender que la Inteligencia Artificial no es magia.
no es un botón mágico que nos hace todo, sino que tenemos que especificar muchas cosas, tenemos que preparar nuestro proyecto, Si lo hacemos de esa manera, si seguimos estas reglas y nos obligamos a entender el negocio, entender las tareas que estamos haciendo, pues va a ser mucho más fácil trabajar con estas nuevas herramientas que vienen cada vez más poderosas.
Bienvenidos sean todos y todas a una nueva edición de Dev & Ops, el podcast donde tratamos de compartir nuestras experiencias a lo largo de nuestra carrera en este mundo de tecnología, de este mundo tan bonito que tiene mucha innovación, mucho crecimiento pero también muchas frustraciones cuando no sabemos cómo hacer algunas cosas. Mi nombre es Juan y el día de hoy por motivos de fuerza mayor mi compañero Douglas no va a poder acompañarnos.
Así que el día de hoy recae en mi poder llevar la plática de esta ocasión.
Estamos en 2026 así que mucho de lo que se habla hoy en día es inteligencia artificial y hemos visto ¿no? como hay muchos avances, muchos estudios, muchos ejemplos que vemos por ahí. Sin embargo algo que al menos a mí no me sale mucho en YouTube y en las demás redes sociales son testimonios de cómo realmente lo están utilizando en su día a día las personas en su trabajo. Así que eso lo que quiero hacer el día de hoy quiero compartirte
cómo yo estoy utilizando la Inteligencia Artificial en mi trabajo y en mi día a día.
Y bueno para que te des una idea yo tengo ya alrededor de 10 años de experiencia en la industria como programador profesional y he trabajado en diferentes industrias, diferentes empresas con diferentes requerimientos cada una de ellas ¿no? Desde hace un tiempo he venido utilizando la inteligencia artificial de más a mayor, mayor medida
Y bueno, creo que muchos recordarán cuando GitHub Copilot empezaba, cuando teníamos estos super autocompletadores de código, lo cual era increíble. Para mí me volaba la mente, ¿no? Poder ver que escribía una parte de una función y automáticamente me autocompletaba todo el resto. Para lo que podemos hacer hoy en día, eso ya lo vemos como algo casi arcaico, podríamos decir. Pero lo menciono porque quiero mencionar que...
Yo he venido siguiendo el crecimiento de estas herramientas desde hace mucho tiempo. De hecho, recuerdo allá por el 2017, 2018, ver un poco de lo que se empezaba a hablar en ciertos grupos, empezaban a sonar lo que eran las redes neuronales. En su momento no quise involucrarme, ahora me arrepiento, ¿no? Quien para saber. Pero, de nuevo.
menciono estas cosas para que los que sean nuevos en este vídeo entiendan un poco de dónde viene mi conocimiento sobre estas herramientas, al menos como herramientas y como util, y bien como usuario a tiempo completo de lo que es la inteligencia artificial y en modo agéntico y todo esto, ya tengo alrededor de, yo diría como un año de ser tiempo completo
hace mucho tiempo que no me dedico a escribir código línea por línea lo cual al inicio me asustaba, al inicio me sentí incómodo por ese motivo por no poder tener el control total de lo que escribo el código pero con el tiempo he podido ir afinando mis flujos de trabajo he podido ir afinando las instrucciones que se le va dando la Inteligencia Artificial y he ido acostumbrándome también un poco al flujo
Y ojo, tampoco quiero que tengas la idea de que no toco código para absolutamente nada. Realmente hay ciertas ocasiones donde lo mejor es ir directamente, escribir el código que necesitamos y listo, ¿no? Arreglar lo que se tenga que arreglar o agregar lo que se tenga que agregar. Todo depende de la cantidad. En lo personal, yo te diría que donde yo le veo el mayor beneficio a este tipo de trabajo es cuando tenemos que hacer cambios...
o fixes o cambios en general al código que requieran tocar demasiadas partes del código. Si yo necesito solamente modificar una función, no le veo el gran beneficio a utilizar una inteligencia artificial cuando lo puedo hacer yo directamente. Tal vez podría utilizar la guía para preguntar y razonar algunas cosas, pero para escribir el código lo puedo hacer. Ahora, cuando ese código
involucra cambiar diferentes partes de nuestro sistema total ya sean múltiples archivos, múltiples directorios, múltiples incluso microservicios con migraciones de datos, migraciones de tablas y todo esto pues ahí sí creo que es un gran beneficio poder tener una herramienta que hace todo el código automáticamente así que bien para ya estar entrando en materia lo que te traigo hoy son algunos consejos
que creo que te pueden ayudar a mejorar tu flujo de trabajo. No son reglas escritas en piedra, no son reglas que aplican a todos los casos. Algunos que otros te voy a ir mencionando en qué casos sí y en qué casos no. Pero en general son mis consejos, los consejos que yo he tratado de ir afinando con el tiempo y que hoy en día me funcionan mucho. Me funcionan tanto para proyectos que ya tienen mucho tiempo. De hecho, estoy trabajando en un proyecto que tiene alrededor de 15 años y lo estoy...
ahora introduciendo código con inteligencia artificial y puedo trabajar en ello de la mejor manera. También funciona para proyectos totalmente nuevos. Bueno, tenemos una idea en mente y queremos realizar una aplicación, queremos crear el backend, el frontend, la aplicación móvil y todo utilizando EAP, queremos vibecodiar. Entonces, para todo esto creo que te van a servir estos consejos. Así que bien, empecemos y vayamos al gran.
El primer consejo que te tengo va a ser y bueno, antes de entrar muchos de estos, cabe aclarar que no son grandes descubrimientos, de hecho se podría decir que son regresar a nuestras raíces si lo quieres ver de alguna forma, no? Porque el primero, el primer, perdón, el primer consejo que te traigo es tener un patrón de diseño claro y bien definido. ¿A qué me refiero con patrón de diseño? Bueno, un ejemplo claro.
ejemplo muy muy práctico es el famoso Domain Driven Design o Clean Architecture o Arquitectura Hexagonal o todas estas diferentes arquitecturas generalmente se le llama pues un patrón de diseño Design System, Design Pattern bueno algunos tienen diferentes nombres o o con el tiempo se han ido resignificando las palabras pero a lo que quiero llegar es tener un patrón donde sea fácil entender
por qué una carpeta va en un lado, por qué un archivo va aquí, por qué está por allá, por qué le pasamos parámetros de esta manera y no de otra. Todo eso es necesario tenerlo ya muy bien entendido y, si es posible, especificado en alguna parte de nuestro proyecto para que la Inteligencia Artificial pueda saber qué es lo que tiene que hacer y, más importante aún, que no vaya a mezclar cosas. Algo que a mí me gusta mucho y si me has seguido en el otro canal
de Gopher Engineer has notado que yo utilizo mucho lo que es Clean Architecture. Eso es algo que me gusta mucho. Y bueno, algo muy simple es que tenemos el sistema definido en diferentes capas. Y algo que me ha pasado mucho con la Inteligencia Artificial es que si bien el código funciona y hace la tarea, incluso puede arreglar bugs, a veces empieza a mezclar partes del código que no debería... deberían ir en una capa y la ponen otra. Entonces eso...
Si bien como dije funciona, para nosotros que ya sabemos como se tiene que hacer un sistema y un software bien hecho, pues no es lo mejor. Así que ese sería mi primer consejo. Dediquenle el tiempo a entender esos patrones. Dediquenle el tiempo a saber cual deberían utilizar o cual es el que realmente les apetece mejor. Y bueno, implementarlo y apegarse a eso. Porque si nosotros nos apegamos, la Inteligencia Artificial se va a pegar a ella también.
El segundo ejemplo va muy ligado con esto y es algo que vamos a ver en todos lados, no importa si utilizas inteligencia artificial o no, es definir lo que son los estándares. Estándares de naming conventions, cómo debemos separar, como decía antes, las carpetas, los archivos, cómo debemos crear las estructuras de datos, por ejemplo las estructuras de datos en el lenguaje de programación o las estructuras de datos en las bases de datos, puede ser una base de datos no SQL,
o SQL y definir todas estas cosas. Este es un consejo que puede pasar desapercibido porque parece obvio, pero realmente ayuda mucho. Algo que me pasaba mucho al inicio, a pesar de que en nuestro grupo de trabajo teníamos estos estándares ya definidos entre nosotros, no estaban tan bien enmarcados para la IA. Así que a veces creaba
paquetes utilizando ciertos estándares que están por ahí en internet que son válidos pero no eran los estándares que nosotros teníamos en la empresa y eso creaba conflicto porque luego teníamos que regresar reescribir o a veces a alguien se le pasaba por alto no voy a decir quién pero comitía va el código hacía un PR y luego alguien más revisaba ok esto no está bien por esto estoy esto y pues tocaba revir
En fin, es una pérdida de tiempo para uno y para los demás, así que tener todo muy bien enmarcado desde el inicio realmente te va ayudar a mejorar el flujo de trabajo en general. Para mejorar esto, para evitar este tipo de cosas, esto me lleva al siguiente consejo. El siguiente consejo para mí creo que fue uno de los cambios más grandes que tuve al momento de trabajar con la IA, de trabajar de una manera muy a gusto.
podría decir antes como dije me cambiaba cosa y tenía que estar muy pendiente de los cambios que se alaía si bien me ahorraba el tiempo de escribir muchos muchos archivos a la vez si tenía que estar pendiente y bueno el segundo o perdón el tercer consejo que traigo es el de escribir y evitar descargar los skills los famosos skills de la ia hoy en día es muy fácil encontrar los skills
para Python, para Golang, para C++, trabajar con diferentes librerías en diferentes lenguajes. Si estamos trabajando con Java, tenemos un skill para Spring Boot específicamente. Si estamos trabajando con Go, un skill específicamente para Gene, para Echo, para muchas otras cosas, Y si bien puede ayudar a descargar los skills porque ya tienen todo hecho, consejo es evitarlo.
por dos motivos. El primero es la seguridad. Ya se han visto vulnerabilidades al momento de simplemente atraer el... descargar el código de internet porque pues trae ciertas inyecciones de prompt, prompt injection, donde pues la IA empieza a hacer otras cosas que no esperábamos porque no se ve. Cuando lo leemos en el navegador, lo leemos en otra parte. Si quieres descargar uno, yo pues tal vez te podría dar un consejo extra, es...
leerlo literalmente todo y leerlo con un editor de texto que no te muestra ningún carácter especial porque si lo leemos en el navegador, pues el navegador tiene una manera de renderizar así que puedes leerlo con un text editor como lo que es Vim o el blog de notas, etc. Pero bueno, la ventaja más grande y el motivo por el que yo evito descargarlo, el segundo motivo
es porque podemos tener skills a la medida. Skills, bueno, para los que no están muy al tanto de qué son los skills. Los skills son nada más que archivos Markdown dentro de nuestro proyecto que la IA puede cargar. Estos archivos lo que tienen son indicaciones de cómo trabajar con diferentes pedazos de código dentro de nuestro proyecto. Un skill, por ejemplo, podría ser cómo crear las tablas dentro de nuestra base de datos.
y este skill pues le va a indicar cómo hacer el naming convention, qué cosas debería hacer, cuándo incluir un índice, etcétera, etcétera. O podríamos tener otro skill que se refiera a cómo escribir la parte del código de nuestro lenguaje de programación cuando tenga que ir a hacer un query, ¿no? Evitar hacer queries en texto plano, traer los queries de manera externa, etcétera, ¿no? Hay muchas formas de hacerlo. Los skills lo que van a hacer es que vamos a tener
estas indicaciones hechas a la medida para nuestro proyecto. Entonces por eso mi recomendación, consejo es escribir los skills. También podemos escribirlos apoyándonos en la IA. No tienen que ser tampoco todo hecho desde cero y escribirlo a pie como decimos por aquí. Puede ser hecho con la IA pero siempre somos nosotros quienes le estamos dando las indicaciones y estamos haciendo un skill específicamente para el que es.
para lo que necesitamos. Y rapidito doy un ejemplo muy, muy simple. Uno de los patrones que utilizamos en mi equipo de trabajo. Y bueno, esto es debatible para cualquiera que maneje Go, puede tener sus motivos. Pero bueno, así es como se definió en este equipo de trabajo. Y es que normalmente en Go se acostumbra que los packages, el nombre de los paquetes o los folders, como lo quieran ver.
se escribe todo junto, en minúscula todo junto, sin embargo en este equipo como menciono se decidió que se va a escribir en camel case no perdón, case con un guión bajo, la separación con guión bajo muy simple digamos que no está conforme al estándar más generalizado de go pero eso no indica que esté malo simplemente ese es el estándar así que en nuestros skills está esa regla específico
para que se acople a lo que tenemos. que por eso, escribí los skills, escribílos todos desde cero, te va ayudar a entender qué es lo que querés realmente y te va ayudar a entender todas esas partes más específicas de tu proyecto. Así mismo, como menciono escribir los skills, yo me hice, este cual sería el cuarto consejo que te puedo dar, es dedicar mucho tiempo al famoso agents.md.
Hoy en día casi todas las herramientas agénticas tienen un comando, un shortcut o algo que te indique cómo generar el agents.md o actualizarlo. Muchas veces tenemos el comando pleca init o pleca no recuerdo cómo es en otras. Con este va a generar un agents si no existe o lo va a modificar si ya existe. Y esto funciona como primer paso.
lo siguiente que deberías hacer es dedicarle mucho tiempo y más cuando son proyectos desde cero no, perdón, al contrario cuando son proyectos que ya existen en esos casos tenemos que dedicarle más tiempo a escribirlos todas las reglas que tenemos y todas las pues patrones de diseño que queremos que siga la IA para que se acople a lo que realmente tenemos y como dije no empiece a escribir e inventar diferentes formas
de hacer la tarea.
El AGENTS.md con el tiempo ha perdido, bueno no se si lo ha perdido pero ya no se habla tanto de ello y como dije ahora tenemos estos comandos que lo hacen automaticamente entonces cada vez pareciera que tiene menos importancia o relevancia es tanto así que pues sabemos que está ahí y listo no le prestamos tanta atención pero al menos a 2026 que es cuando estoy grabando esto aún es importante así que como es importante démosle la importancia
y dediquemosle mucho tiempo. Bueno, cuando digo mucho tiempo es uno o dos días, pero literalmente es dándole la importancia necesaria. El siguiente consejo que quiero dar, este es un consejo muy curioso. Yo no lo aplicaba tanto, con el tiempo empecé a hacerlo y me ha ayudado. La verdad es que sí he notado que hay una mejoría en cuanto a...
cómo la IA se apega a lo que yo quiero que realmente haga. Y es el de crear, cuando se pueda o cuando aplique, un PRD. Un PRD significa un Product Requirements Document. Un documento de requerimiento del producto. Entonces, esta es una práctica que, como dije, no estoy inventando el agua hervida, esto ya se hacía en la industria.
Sin embargo con la salida de la IA y con la popularidad pareciera que nos dan la falsa sensación que no lo necesitamos, que solo le decimos a la IA, hace una página que se vea bonita y listo. No, aún sigue siendo, yo diría que incluso más importante hoy en día, porque el PRD puede servir como pauta para que la Inteligencia Artificial haga lo que tenga que hacer. Un movimiento que se está empezando a tener más auge hoy en día, ya existía pero sigue como tomando más fuerza.
al menos entre los influencers de tecnología en internet es el spec driven development, algo así creo que se dice o el context driven development. Básicamente es trabajar con IA y dándole mucho contexto, dándole todas las especificaciones que queremos y todos los requerimientos. Y aún me falta, tal vez, testearlo un poco más esa nueva filosofía, bueno, nueva entre comillas.
pero creo que esto se asemeja mucho a esto, tener un PRD donde tenemos todas las especificaciones que nosotros queremos que siga la Inteligencia Artificial y con este PRD poder pues dirigir a la IA básicamente es dirigirla que vaya hacia donde nosotros queremos y que no empiece a alucinar así que bueno puede ser un poco
tal vez si es un feature o una tarea muy pequeña tal vez no la necesites, obviamente a veces solamente necesitamos decirle a la IA tengo un error en la línea tal, revisa en qué partes tienen que ser modificado y pues la IA va a modificar todos los archivos que sea necesario y eso funciona muy bien y la verdad es que nos libera en cuanto al tiempo, ¿no? pero cuando son tareas más grandes eso suele pasar
un PRD puede ser una gran ayuda. que eso me lleva al... ¿Qué número de consejos sería? Vamos a ver... Sexto consejo. Tengo diez consejos. Vamos por el sexto.
El sexto consejo que tengo es el de reducir el scope del feature o de la tarea como lo queremos ver. Y este puede ser contraproducente al inicio, pareciera que... Bueno, hay muchos ejemplos ¿no? en internet donde vemos que alguien le dice a la inteligencia artificial, necesito una página web para una tienda de ropa y quiero que la hagas así, así, así, que tenga estas secciones y que tenga esto. Y lo hace todo. Y la IA pues hace todo.
Algo que nunca muestran del todo es cómo genera el código, cómo está el código realmente estructurado, cuáles fueron los patrones de diseño, cuáles fueron los naming conventions, eso no lo suelen mencionar mucho, tal vez por encima y por eso es que no me parece que sea un gran ejemplo de cómo funciona la IA. Realmente lo más importante, bueno, no es lo más importante, dependiendo de la perspectiva, para el cliente, para el dueño del negocio, para el...
el CEO, lo más importante va a ser el producto y es claro. Pero para nosotros que estamos a cargo de la parte tecnológica, lo más importante es que sea un producto, tenga una base de código que sea mantenible, escalable y fácil de entender. Por eso es importante ponerle límites a la IA. Desde mi punto de vista es mejor una IA un tanto limitada que dejar que la IA pues haga lo que quiera, cuando quiera y como quiera.
Reducir el scope es simplemente decidir qué tareas vamos a utilizar y doy un ejemplo muy particular, algo que estoy trabajando y creo que ya lo he mencionado en otros episodios pero bueno si sos nuevo en este canal no importa te lo menciono. He estado migrando diferentes servicios que estaban escritos en Python a Golan y bueno, cada quien tendrá sus...
argumentos de decir bueno porque estás haciendo eso, etcétera. Pero bueno, esa es la tarea. tarea. Tengo que migrarlos. Y cada servicio hecho en Python, al momento de traducirlo a Go, un solo servicio se va a traducir en múltiples microservicios en Go. Así que si yo hago todo de un solo, de una sola pasada, voy a terminar con un PR o múltiples PR en diferentes proyectos y es incluso complicado de llevar el hilo.
por eso aquí es muy importante reducir el scope y analizar si yo cambio esta sección este grupo de endpoints, este grupo de funcionalidades ¿a dónde va a ir? ok, va a ir al microservicio de cuentas, de pagos, etc. entonces dedicarme a eso dedicarme a un feature, a un dominio si lo vemos como Domain Driven Design y dedicarme solamente a eso ¿por qué es necesario hacerlo de esa manera?
Yo diría que tiene varios puntos a favor. El primero es que es fácil para nosotros hacer un modelo mental de qué es lo que estamos haciendo en vez de seguir el paso de todos los cambios que están pasando a la vez. Nosotros no tenemos la inteligencia o el alcance de una IA. El segundo motivo que yo veo muy importante de por qué limitarlo es porque estamos trabajando, menos en la mayoría de las veces, estamos trabajando con más personas, con nuestros compañeros de trabajo.
Y si tenemos la cultura que lo aconsejo encarecidamente, la cultura de los code reviews, cuando le presentemos nuestro PR a otra persona y tenga que leer el código, va a ser muy complicado que entienda todo el concepto, todo el contexto que nosotros ya tenemos. Y van a tener que ir y revisar todas las partes. Es muy complicado, les quitamos tiempo, se lo hacemos más difícil. Así que si tenemos un scope reducido,
y le decimos bueno estos son los cambios que tienen que ver con los perfiles de la empresa y pues ok ya tienen el contexto perfiles y vemos que los cambios son cuatro archivos y pueden leerlo fácilmente entonces trabajamos de una manera más fácil todo fluye se aprueba más fácil el PR se publica más fácil el PR todo es más fácil entonces
parece contraproducente o parece contraintuitivo porque la IA puede hacer todo al mismo tiempo pero no, realmente mi consejo al menos 20-26 es reducir mucho el contexto para que no tengamos que lidiar con todo esto y como dije creo que también aplica cuando no estamos trabajando con IA cuando estamos trabajando nosotros mismos pues nos dedicamos a una tarea en específico porque es más fácil es lo mismo, sigue siendo igual
Eso me lleva al séptimo consejo y este es un consejo que para ser honesto lo he estado aplicando recientemente. Recientemente. Y es imaginar que le estoy pidiendo todas estas requerimientos y tareas que le voy a pedir a la IA, imaginar que se las estoy pidiendo a otra persona que lo realice. Y mi razonamiento con esto es el siguiente. Cuando, bueno, la IA no tiene memoria.
si bien pareciera que tiene el contexto de todo, la verdad es que no. Lo que hacen los modelos agénticos y lo que hacen las herramientas agénticas es que tratan de leer los archivos necesarios y se los pasan como contexto a la IA. La IA me da una respuesta, si le pido algo más, todo lo que había generado se lo devuelven a la IA y me vuelve a generar. Entonces no tienen una memoria como tal. Por lo que cuando le estamos pidiendo a la IA
que haga algo es como si se lo estamos pidiendo a por primera vez y no sepan nada de nosotros. En ese contexto ¿cómo lo harías? Lo más probable es que antes de pedirle algo, le empezarías a explicar todo, cómo funciona o al menos las partes que son necesarias para realizar la tarea, para corregir el bug, para cambiar algo ¿no? Le explicarías bueno, esta es una aplicación que viene así, así, así.
Y muchas de estas cosas ya van a estar solucionadas con el AGENTS.md y con el Skills Pero lo que es más específico de la tarea como tal es necesario especificarlo bien y especificarlo muy detalladamente en la medida de lo posible A veces un prompt para mi tarda 10-15 minutos escribir el prompt No porque no encuentre qué poner sino porque empiezo a recolectar la información que necesito
y empiezo a editarlo y escribir todos los casos que necesito. Si es posible agregar ejemplos, eso siempre ayuda porque de esa manera la IA va a poder tener el contexto necesario y va a poder tomar la decisión. Enlazado con eso, el siguiente consejo que tengo escrito por aquí es el de utilizar apoyo visual. De nuevo, si le estamos pidiendo a alguien por primera vez, si le estamos dando el contexto,
ayudaría mucho agregar fotos, imágenes, sean imágenes de un mockup, de cómo queremos que se vea o screenshots de qué creemos que está pasando y que debería corregirlo. No es lo mismo decirle a la IA el botón de salvar no funciona, no está bien colocado, a decirle analiza la imagen y el botón de salvar está un poco más abajo y empezamos a darle más detalles, con la imagen va a poder analizarla la IA.
y va a poder planificar mejor un fix y cómo arreglarlo. Así que, de nuevo, este es un consejo que yo personalmente lo estoy siguiendo desde hace relativamente poco y tampoco es que sea algo super metafísico y que estamos hablando con alguien. No, simplemente es si tuviese que pedirle esto a alguien por primera vez, qué información yo le daría.
y tratar de hacerlo de esa manera. Hay tareas que son muy fáciles, hay tareas que son más simples y no es necesario tener que especificar tanto, pero a veces ⁓ sí. Y por eso lo hago de esa manera. Bien, el noveno consejo que traigo por aquí, y aquí ya nos estamos acercando al momento de ya interactuar mucho más con la inteligencia artificial, aunque bueno, todo el
el proceso hemos interactuado de una u otra manera. Pero el siguiente es planificar junto con la inteligencia artificial. ¿Y a qué me refiero? Hoy en día es muy común que las herramientas agénticas, si las voy a llamar, tienen un modo, una forma de tipo planning, de tipo plan. Lo que hace es que este, empiezas a...
a platicar con la guía, le das contexto, puede leer archivos de tu proyecto, pero no hace ningún cambio. Simplemente está revisando y no va a hacer ningún cambio. Y eso, en mi opinión, es muy poderoso. Es una manera de trabajar que nos ahorra mucho tiempo, nos ahorra cambios innecesarios y nos permite poder iterar de manera muy fácil. Así que algo que yo siempre hago es todo lo que ya dije anteriormente.
más en el momento en que estoy especificando todo lo que necesito que haga le digo ok dame un plan de implementación me va a generar todo el plan y mucha hoy en día ya las IAS y las herramientas que utilizan la IA utilizan o están hechas de tal manera que nos pueden hacer preguntas entonces cuando nos están presentando con diferentes maneras de cómo hacerlo me van a preguntar
qué forma o qué metodología quiero que implemente. Y esto es muy interesante. Por ejemplo, cuando estamos trabajando con la parte del frontend, me va a preguntar si quiero que utilice React, Vue o Svelte. Muy simple, Pero luego empieza a preguntarme otras cosas. Necesitas que sea un estilo minimalista, un estilo más moderno, un estilo aquí o un estilo allá, y me da los pros y contras. Eso...
es muy interesante porque incluso me ayuda a poder verificar o poder tomar decisiones que tal vez no tenía antes o incluso cambiar de opinión porque a veces me presenta me ha pasado donde le pido que haga algo de cierta manera pero luego la IA me dice ok veo que me pediste esto pero esta otra opción podría funcionar mejor por X o Y motivo lo analizo
y si veo que tiene sentido entonces le digo está bien cambiarlo y hacerlo de esa otra forma lo cual no ocurriría si entramos de un solo al modo de escritura donde puede hacer cambios porque no va a preguntar, va directamente a escribir y dependiendo del modelo del lenguaje que estemos utilizando el modelo de la IA también
algo que he notado es que dependiendo del modelo que estemos utilizando nos va a dar más o menos resultado. Hace poco estuve probando lo que es GEMMA 4 y bueno el modelo más grande de GEMMA 4 porque tiene diferentes versiones y la verdad es que funciona
pero no siempre, no me funcionaba para ciertas cosas que estaba utilizando que eran un poquito mas complejas pero no tan complejas entonces si tenes la opción de poder probar diferentes modelos algo que yo mencionaba creo que en un episodio anterior era que yo estoy utilizando Ola MacLeod y me gusta eso de poder probar diferentes modelos porque dependiendo del modelo vamos a tener diferentes resultados
Y bueno, si estás utilizando los más grandes, pues también, ¿no? Vas a notar que ChatGPT te puede funcionar para una cosa. Yo he visto que algunas personas utilizan ChatGPT para planificar, utilizan Cloud para escribir el código y luego utilizan Gemini para generación de mockups y cuestiones que tengan que ver con algo visual. ⁓
son flujos de trabajo de cada quien pero bueno, importa mucho el sin embargo, cada vez como yo mencionaba antes en otro episodio yo siento que los modelos de lenguaje a menos que sean modelos no tan de frontera sean un poco más pequeños pero realmente con los modelos de frontera no hay tanta diferencia entre utilizar codecs y utilizar chatgpt o cloud con cloud
algo que si vamos a notar es que todo el mundo dice que es el mejor y que es el más inteligente y si obviamente encuentra bugs de Zero Day en diferentes proyectos open source y cosas muy interesantes pero realmente para lo que estamos utilizando no necesitamos algo como eso no necesitamos que tal vez analice por tres días seguidos la guía y que esté sin parar
esa es mi opinión personal, realmente no le veo yo la gran diferencia entre utilizar los otros modelos que existen hoy en día pero bueno, regresando al tema de planificar junto con la IA eso es muy interesante porque te permite o te obliga mejor dicho a entender la tarea o el feature que estamos realizando me obliga a listar todos los pasos que deberían ser llevados a cabo para que cree el código o la IA
y me ayuda también como una manera, una sesión de rubber ducking. Robert ducking es pues agarrar un muñequito y hablar con él como si fuera otra persona, pero ahora lo podemos hacer con la IA. Entonces eso es muy, muy interesante porque al final de la sesión de planificación donde me presenta opciones de la implementación, le pido cambios, me muestra diferentes caminos que podemos tomar y empiezo a hacer todo esto.
Al final, ya tengo un plan muy detallado que ya lo revisé y estoy seguro que cuando ya le doy el modo de escritura y le digo ok, empezá con la implementación los cambios que voy a recibir son muy muy... no se van a salir de los rieles que ya le había puesto, de las limitantes que le había puesto. Así que eso me lleva al último consejo que te doy y este es un consejo que siempre se ha dado
y no cambia y lo sigo Revisa y evalúa todo lo que genera la IA. Suena mucho, suena que bueno entonces ¿para qué? Si ya le dije a la IA que lo hiciera y ahora tengo que revisar entonces ¿cuál es el ahorro de tiempo? Pero yo creo que si empezamos a realizar estos otros consejos que te estaba dando, donde tenemos los skills o los agents, limitamos el scope, definimos los estándares,
hacemos todo eso y luego tenemos un plan de implementación que está muy bien ejecutado pues lo que vamos a revisar es más que todo que funcione y que no introduzca cosas raras me ha pasado donde hay cambios que son muy grandes o sea que tienen un impacto muy grande en la aplicación pero las líneas de código que tengo que revisar no son tantas porque ya supo la idea que cosas tenía que cambiar dónde las tenía que cambiar y cómo hacerlo
ya solo me dedico a hacer integration test, voy a revisar que no se rompió nada de lo anterior y de esa manera pues creo que si nos va a ahorrar mucho tiempo y también vamos a poder entregar un producto mucho más completo y seguro y escalable y todas estas cosas que queremos que sea así.
Pero bien, esos son mis consejos. La verdad es que, como mencionaba, creo que la IA ha ido evolucionando bastante y a mí me pasa a veces que siento que no nos estamos, nos empezamos a quedar atrás. Pero la verdad es que no. Cuando notas, muchos de estos consejos realmente son consejos que si ya los seguías antes de los tiempos de la IA,
me refiero a un PRD, setear estándares y todo esto, pues no cambia, eso ya lo probablemente ya lo tenías en tu proyecto. Así que no se trata de aprender o reaprender más cosas, sino más bien es de cómo podemos incluir a la IA en estos procesos que ya teníamos y tratar de entender que la Inteligencia Artificial no es magia.
no es un botón mágico que nos hace todo, sino que tenemos que especificar muchas cosas, tenemos que preparar nuestro proyecto, básicamente es eso, un proceso de preparación para que la IA pueda trabajar con ello. Si lo hacemos de esa manera, si seguimos estas reglas y nos obligamos a entender el negocio, entender las tareas que estamos haciendo, pues va a ser mucho más fácil trabajar con estas nuevas herramientas que vienen cada vez más poderosas.
Así que bien, por ahora no tengo más que agregar, este hoy quería que fuese un video más corto, no quería cansarte con todos estos puntos, sin embargo creo que te pueden ser de mucha utilidad y te pueden ser muy fáciles de implementar. Así que bien, sin más que agregar, nos vemos a la próxima, muchas gracias a todos los que siguieron hasta aquí. Bye.