Capacitación de Ingenieros para AI Sin Convertirlos en Monos de Prompt

Entonces, comencemos con algo muy, muy importante hoy en día y creo que es exactamente eso, cómo deberíamos entrenar a nuestros ingenieros para IA sin convertirlos en verdaderos monos de prompt. Esta charla es básicamente algo que experimenté de primera mano porque necesitaba implementar IA en más de 300 personas en nuestra empresa. Entiendo que generalmente es muy difícil entrenar a las personas para usar IA de manera adecuada, solo porque IA puede hacer que los ingenieros sean realmente capaces, pero tampoco significa que no sean dependientes al final de IA.

Entonces, tanto como sea posible usan IA, dependen de ella, y también es difícil convencer a ellos de que la forma en que están usando IA es incorrecta. Así que preparé para ustedes algunas cosas y técnicas diferentes que uso en mi trabajo básicamente para poder enseñar a mi gente a usar IA de manera adecuada. Y aquí está la agenda de hoy, un poco más de información sobre mí y pasaremos a algunos problemas que encontré cuando intenté implementar IA. También hablaremos sobre algo que creo que es cada vez más importante hoy en día y eso es el principio dry.

Y más adelante, veremos algunas reglas y estándares para implementar IA y entrenar a las personas. Y continuaremos con los puntos clave y, por supuesto, la sesión de preguntas y respuestas, donde pueden preguntar lo que deseen sobre la implementación de IA en sus equipos. Entonces, sobre mí, soy un Docker captain, cursor ambassador, orador, autor de libros y persona con mucha experiencia en tecnología. Y mi rol es principal. Como principal, necesito implementar todo el sistema de IA en nuestra empresa, pero también cómo usamos IA. No son solo herramientas. No es solo que puedas usar cursor, por ejemplo, o código, y eso sea suficiente. Sino también cómo usar la herramienta de manera adecuada.

Y estamos seguros de que si unimos a un nuevo miembro en nuestro equipo, la calidad del código se mantendrá absolutamente buena y también intentaremos enseñarle a usar los mismos estándares. Así que, este es el gran, gran problema. Muchas, muchas empresas hoy en día intentan básicamente enseñar a las personas cómo escribir buenos prompts, pero no cómo pensar y escribir buen código con IA.

Entonces, lo que esperamos hoy en día, solo porque la IA es muy buena y los modelos son realmente fuertes hoy en día, lo que vemos es básicamente una salida rápida. Significa que puedo escribir cualquier cosa en el terminal del editor de código y esta ejecución con alguna IA será realmente rápida. Pero también significa, ¿entiendo todo el código que generó la IA? La IA puede generar una tonelada, un código masivo en segundos. Pero más tarde, muchos desarrolladores son perezosos. No revisan este código. No están interesados en una forma de entender toda la base de código.

Sino que están interesados solo en terminar sus tareas. Lo que lleva a un sistema frágil. Entonces, el código en sí ya está construido, está ahí. Alguien decidió empujarlo y ya está en nuestro sistema de código. Pero no sabemos exactamente qué está haciendo este código. El propio desarrollador, más tarde, intentará usualmente lo que hacen y les encanta hacer, es decir que la IA es el problema. Fue la IA. La propiedad hoy en día es una cosa muy extraña.

Usualmente, mis desarrolladores realmente se quejan de que la IA es una mierda, la IA puede hacer buen código. Pero también, si ocurren algunos problemas de seguridad, no dicen que es mi culpa, intentaré solucionarlo inmediatamente. Están diciendo que la IA no es lo suficientemente buena. Pero creo, creo firmemente que la IA no es un problema. La persona detrás de la IA es el problema.

Lo que necesitamos hacer es básicamente intentar enseñar a nuestros desarrolladores algunos principios y reglas. El primer principio, que creo que es cada vez más importante hoy en día en la era de la IA, es DRY. Así que no te repitas. Lo que está sucediendo es que si le pides a la IA que cree alguna tarea, usualmente comenzará y directamente creará la tarea e implementará funciones similares, utilidades similares, y duplicará prácticamente todo solo porque nunca le dijiste a la IA que escaneara tu base de código o que intentara reutilizar algo que ya tienes.

Así que al final, tenemos muchas duplicaciones en el código. Mi experiencia personal es que reviso un código, como un proyecto, y desafortunadamente encuentro cinco lugares haciendo exactamente lo mismo. Era una utilidad, la utilidad estaba duplicada en cinco lugares, y más tarde, tenemos un problema que necesitamos solucionar exactamente en esta utilidad. Y desafortunadamente, el desarrollador lo solucionó en solo un lugar. Así que los problemas permanecen. Y le estaba preguntando, OK, ¿cuál es la razón por la que estás usando cinco funciones de utilidad para una cosa similar? ¿Por qué no reutilizas una? ¿Por qué no usas el principio DRY?

Le pedí a la IA que hiciera el trabajo, pero al final me di cuenta de que es muy buena repitiendo el código en lugar de reutilizar el código. Y desafortunadamente o no, lo que usualmente los ingenieros necesitan hacer al trabajar con IA es básicamente algunas cosas. Usualmente, muchos desarrolladores hacen esta primera cosa. Pegan algún prompt, obtienen el resultado, lo ponen en el código. Hoy en día, por supuesto, podemos usar editores como cursor o quote, y son muy buenos para entender tu contexto, pero al final, si no validas lo que se genera o no usas un modo, por ejemplo, el resultado en sí será una mierda. Así que primero que nada, necesitas pensar en tu sistema como un todo y ser capaz de entender.

Personalmente, lo que uso es que trato de escanear toda la aplicación con IA. Y si algo no está claro para mí, trato de hacer preguntas como, IA, explícame por qué esto es así. Por qué eso fue implementado de esta manera en particular. Más tarde, veo algunas duplicaciones, trato de optimizarlas. Así que estoy usando utilidades, hooks, y diferentes métodos que me permitirán seguir el principio correcto que te mostré en la diapositiva anterior.

Así que básicamente, la IA es muy buena. Es poderosa. Pero también, si solo le dices ciegamente a tus desarrolladores que la IA les salvará la vida y desarrollarán aplicaciones más rápido y si no les enseñas, al final, el resultado será realmente malo. Así que lo que deberías hacer, deberías establecer algunos estándares y reglas para poder implementar IA. Y también, si estableces este tipo de reglas, deberías seguirlas.

Y también, si estableces este tipo de reglas, deberías seguirlas. Mi consejo para todos aquí es tratar las reglas o la documentación de la IA como documentación real en tu proyecto. Si cambias algo en tu código, actualiza la documentación, actualiza las reglas, actualiza las habilidades. Solo porque más tarde, alguien más se unirá y no podrá trabajar.

Además, tenemos dos tipos diferentes de reglas. Las primeras reglas son reglas globales que significan los aspectos específicos de tu empresa. Significa lo que estás usando como verificaciones de seguridad, lo que estás usando para la edición de código, qué linters estás usando, qué versiones de paquetes estás usando y, por supuesto, qué arquitectura estás usando en toda la aplicación y toda tu empresa, como cuáles son tus proveedores para, digamos, entregar la aplicación en el servidor. Toda esta información, la compartimos como reglas globales. Las reglas globales son algo muy importante y están estableciendo los estándares para toda la empresa.

Pero por otro lado, también tenemos reglas específicas del proyecto. Las reglas específicas del proyecto son muy, muy poderosas porque si una regla global está estableciendo los estándares de la empresa, las reglas específicas del proyecto están estableciendo los estándares para el proyecto en sí. Qué versión de React.js se está usando, qué linters se están usando, si tenemos algunas reglas de Git o cualquier tipo de reglas que deberíamos seguir, cuáles son las reglas de rendimiento que tenemos y que necesitamos seguir y este tipo de cosas son específicas del proyecto.

Entonces, si tienes reglas globales como un estándar para todo, cada desarrollador debería implementar en el proyecto, reglas específicas del proyecto para poder seguir los mejores estándares posibles. Y aquí hay algunas reglas y prácticas que creo que te ayudarán mucho. En primer lugar, crea archivos que la IA entienda. Como en mi empresa, usualmente usamos cursor, pero en los editores de IA más avanzados, digamos es lo mismo. Tenemos archivos AMD donde establecemos estándares y aquellos que implementan alguna lógica detrás. Lo que vi muchas veces cuando trato de hablar con algunos desarrolladores, los problemas que enfrentan es que no tienen reglas similares.

Así que, es un poco extraño, pero usualmente la gente no quiere comprometerse con las reglas hoy en día, solo porque tienen miedo de que las reglas que usan sean expuestas y más tarde la gente entenderá que no son tan buenos haciendo el trabajo. Pero esto está mal. Creo totalmente que lo que necesitamos seguir es una imagen clara de una arquitectura. Necesitamos tener un repositorio separado donde establezcamos estándares, como estándares del proyecto, y luego compartimos estos estándares con el resto del equipo. Deberíamos tratar las reglas del cursor como una parte existente del repositorio.

Lo que está sucediendo hoy en día es que la IA se está volviendo más y más poderosa, lo que significa que pueden hacer muchas tareas simultáneamente, y al final, el resultado puede ser realmente positivo o negativo basado en el contexto que proporciones a la IA. Así que, el contexto es el rey. Intenta proporcionar tanto contexto como sea posible para tu proyecto específico. Y también, intenta crear agentes.

Los agentes son algo muy poderoso si sabes cómo utilizarlos. Puedes tratar a los agentes como una persona real que puede hacer el trabajo antes que tú o validar el trabajo que hiciste más tarde. Mi enfoque personal en eso es que tengo desarrolladores como frontender, backender, tengo un agente de QA, y también tengo agentes de seguridad, agentes de refactorización, y por supuesto agentes de documentación. Eso es porque lo que quiero hacer es que después de hacer algún tipo de cambios en las reglas o en el contexto mismo, quiero documentarlo.

Simplemente porque más tarde, puedo usar esta documentación para alimentar el contexto de la IA. Y entonces, la IA hace un trabajo realmente, realmente bueno. Así que, reglas simples a seguir. En primer lugar, define tu objetivo.

¿Cuál es tu objetivo? ¿Qué quieres lograr? Además, un objetivo simple como, hazme un botón no hará lo que quieres o lo que se necesita hacer. Necesitas proporcionar contexto. Dije que el contexto es el rey y realmente lo creo, simplemente porque si proporcionas contexto, entonces la IA podrá entender y también validar que tu comprensión de la tarea es correcta y más tarde implementarla adecuadamente.

Lo que suele suceder es un tercer paso. El agente ejecuta el código. El código se ve bien, pero estamos omitiendo la revisión. La revisión también es un paso muy importante, simplemente porque lo que creo que deberíamos hacer como desarrolladores y enseñar a nuestra gente es que antes y después de generar el código, deberías pensar en cómo mejorar tus habilidades usando IA. No solo para generar el código, sino también para tratar de mejorarte a ti mismo como desarrollador de código porque hoy en día creo que el trabajo de un desarrollador no es solo escribir código, sino también tratar de navegar realmente entre diferentes sistemas.

Deberías ser el dueño de todo el sistema y también el arquitecto de la IA. Después de la revisión, básicamente es la integración y es tu propia responsabilidad decir que este código es lo suficientemente bueno para ir a producción. Aquí hay algunas muy buenas prácticas que me encanta compartir contigo. Estas son prácticas que ya implementamos en mi empresa. En primer lugar, creamos la biblioteca de prompts. Este es un repositorio Git. Todas nuestras reglas, lo que significa reglas globales, reglas de la empresa, viven allí. Tratamos de actualizarlas constantemente.

Lo que hicimos y encontramos realmente útil es que primero actualizamos estas reglas cuando escribimos un código, pero en segundo lugar, cuando empujamos el código, tenemos un pipeline de CI con un agente que es responsable de actualizar la documentación al instante. Esto es muy útil simplemente porque la gente es realmente cautelosa para actualizar las reglas localmente y más tarde se olvidan de actualizarlas globalmente. Pero si actualizas la documentación, más tarde tendrás un contexto que es lo suficientemente bueno para escribir un buen código. A continuación, tenemos registros de decisiones. Esto significa que cada decisión que realmente cambia el comportamiento de la IA o cómo la IA debería funcionar en tu empresa debe registrarse en algún archivo específico y más tarde debe usarse como un recurso de información. Si no tienes este tipo de historial, al final, lo que encontrarás es que no sabes por qué tu IA está actuando así y quién decidió hacer esta tarea exacta. Es muy importante tener documentación. Préstamo específico de IA. Así que usa la IA no solo para escribir código, usa la IA para validar el código, usa la IA para explicar el código. Simplemente porque la IA está escribiendo buen código, no significa que no esté explicando bien.

Así que la IA debería explicarte por qué hiciste este código de esta manera específica y también cómo cambiarlo más adelante para que sea mejor. Esto es curación de prompts. Esta técnica es muy popular hoy en día y creo que será cada vez más importante simplemente porque si eres bueno escribiendo buenos prompts, más adelante, tu resultado será bueno. Y la ingeniería de contexto. Intenta enseñarte a ti mismo cuando escribes código con IA no solo a ejecutar la tarea sino también a intentar hacerlo de la mejor manera posible y rápida, lo que significa que deberías ser una persona que pueda proporcionar contexto lo más rápido posible y lo mejor posible simplemente porque la IA está haciendo las cosas más rápido, pero tú no. Así que el contexto es el rey, pero también eres la persona que proporciona este contexto.

Trata tus reglas de cursor o todo como habilidades o reglas o agentes o lo que sea como documentación. Muchas personas olvidaron actualizar sus propias habilidades. Más tarde, cambian entre proyectos y encuentran que ejecutan los mismos prompts y obtienen resultados diferentes. Además, si tienes un equipo de junior senior o algunas personas que están tratando de adaptarse a la IA, no intentes medir los resultados por ellos básicamente en qué tan rápido son, sino también en la capacidad de pensar y usar la IA correctamente. Enseñar a los ingenieros de la manera correcta es básicamente un proceso, es algo que deberías adaptar y estimular mucho en nuestras empresas simplemente porque necesitas entender que usualmente si eres bueno en IA, no significa que todos lo sean.

Así que deberías compartir el conocimiento y la mejor manera de compartir el conocimiento es dando la tarea a las personas. Deberías darles premios. Deberías intentar revisar obligatoriamente el código que hicieron y reproducirlo con IA y tratar de darles un muy buen feedback que no sea para juzgarlos. No saben cómo usar la IA, sino más bien para apoyarlos a usar más la IA. Y la pregunta aquí es como líderes técnicos qué necesitamos hacer y creo que la primera y probablemente más importante prioridad es establecer los estándares. Deberías establecer la guía de las personas que te siguen sobre cómo deberían usar la IA.

Además, invierte en personas, invierte en conocimiento, invierte en habilidades, intenta crear canales o cualquier cosa que les ayude a adaptarse al nuevo mundo cambiante solo porque la IA está cambiando mucho. Así que deberías educarte a ti mismo pero también deberías compartir el conocimiento con ellos. Y en segundo lugar, construye un viewport. No solo intentes medir qué tan rápido somos.

Mide qué tan buenas son las personas escribiendo buenos problemas y también qué tan buenas son las personas si dejas a alguien solo en el proyecto, cuál es su primer trabajo, probablemente crear las reglas y habilidades. Pero si no lo hace, no lo culpes, enséñale. Y mide la calidad, no solo la velocidad. Muchas personas hoy en día y CTOs, miden resultados.

Miden qué tan rápido somos, cuánto tiempo dedicamos a la IA, cuántos tokens usamos. Pero no miden qué tan buenos somos con la IA. Es muy difícil medir eso pero también puedes hacerlo por ti mismo.

Puedes escribir un prompt a la IA cada vez que preguntas algo en el terminal para que te dé una puntuación, como de 0 a 10, qué tan bueno fue mi prompt, qué necesito mejorar. Así que la autoeducación es algo en lo que creo firmemente que es importante y deberías invertir en ti mismo primero, luego en el resto.

¿Qué hacemos como errores? Estamos celebrando solo la velocidad de salida en lugar de la calidad. Pretendemos que ya validamos el código y se genera como cinco mil líneas y en dos minutos decimos que el código es bueno solo porque le preguntamos a la IA si el código es bueno y nunca abrimos el archivo para revisarlo.

Lo que también hacemos es empujar a nuestros desarrolladores a usar IA sin establecer ningún tipo de estándares. Usualmente lo que hacemos es que llega un nuevo proyecto y decimos, está bien, usamos cursor, buena suerte. Pero esa no es la manera. Deberíamos proporcionarle lo que tenemos como recursos, lo que tenemos como documentación y dejar que se adapte a nuestro sistema y luego deberíamos esperar los resultados.

También muchos desarrolladores, seniors hoy en día porque es difícil adaptarse a las nuevas cosas en IA, creen que solo es necesario adaptarse y luego no compartir el conocimiento. Porque si lo sé, puedes preguntar y aprender también por qué necesito compartir el conocimiento. Pero esto no es tan cierto para ser honesto. Solo porque si viste algo o quieres algo nuevo, deberías proporcionar la información al resto de las personas.

Entonces tenemos un grupo de personas que realmente están a la vanguardia de la IA y también saben cómo usarla correctamente.

Así que los puntos clave de esta presentación, la IA mejora tus habilidades, no las reemplaza así que úsala sabiamente. En segundo lugar, el principio DRY es muy importante hoy en día. No creas que la IA será lo suficientemente inteligente como para no repetir código. Es muy bueno repetir muchos fragmentos de código y luego es difícil de mantener. Así que deberías seguir el principio DRY.

En segundo lugar, establece estándares, establece reglas globales, establece agentes, algo que permanecerá y también será utilizado por todos. Los agentes desbloquean nueva productividad, úsalos sabiamente, lo que significa crear desarrolladores front-end, crear QA y desarrolladores back-end, cualquier cosa que te ayude a terminar tu trabajo a tiempo y la calidad permanecerá. Capacita a tus ingenieros para la IA, no solo los culpes. Y la calidad, la propiedad y los fundamentos sobre tu código son algo de lo que eres responsable. Muchos desarrolladores culpan a la IA, pero no necesitamos hacer eso. Lo que necesitamos hacer es adaptarnos y pensar que la IA es una herramienta que nos ayuda a escribir buen código, no algo que nos está reemplazando exactamente y necesitamos culparla.

Dicho esto, aquí hay un código promocional para mis libros. Si alguien aquí quiere leer sobre Docker o React.js, puede tomar este código y recibirá un 50% de descuento. Y por supuesto, estaré muy feliz si ustedes se conectan conmigo en LinkedIn, pueden escanear este código QR y directamente iremos a LinkedIn. Sí. Gracias, chicos.

Preguntas de nuestra audiencia. ¿Qué tenemos? La primera. ¿Cómo mitigas la pérdida de contexto? Con más contexto, es probable que LLM descuide cada parte de los requisitos y el contexto. Esa es una muy, muy buena pregunta. Solo porque el contexto lo es todo sobre los LLMs y creo que lo que nos encanta hacer es establecer diferentes agentes como si alcanzamos el límite de agentes, tienes mucho contexto y el agente comienza a simular mucho. Lo que nos encanta hacer es cambiar a una nueva sesión o intentar resumir el contexto que es y más tarde proporcionar el contexto resumido y luego esto funciona. Por cierto, cursor introdujo algo que es modelos de aprendizaje simultáneo como agentes. Esto es muy bueno para manipular y seguir el contexto en sí. Así que te aconsejo encarecidamente que los uses. Una técnica rápida que añadiré sobre eso son los documentos intermedios que capturan tu contexto central para que a medida que tu agente rote el contexto, sigas redirigiéndolo a ese documento intermedio para mantenerlo fresco.

A continuación tenemos, ¿cómo aseguras que las reglas globales permanezcan actuales, relevantes y sincronizadas en todos los repositorios? Básicamente lo que hicimos, este es un problema muy serio que encontré en muchos, muchos proyectos. Lo que hicimos fue implementar la tubería en el proceso CI-CD que está actualizando el contexto del proyecto en sí cuando estás ejecutando la tubería. Así que imagina que tenemos algo como construir, escanear y probar y luego tenemos un documento. Así que esta tubería específica es responsable de actualizar el contexto para cada proyecto cuando agregamos nuevo código a él. Sí. Muy bien. Así que a continuación, ¿cómo estás evaluando la calidad? ¿Cuáles son las métricas para el código, los prompts, etcétera? Esta es una pregunta bastante difícil solo porque no tenemos herramientas adecuadas para evaluar tus habilidades y capacidades. Pero de nuevo, lo que personalmente hago para mí mismo es cuando estoy escribiendo algo a la IA, intento decirle a la IA que necesito tener un sistema de puntuación. Así que basado en la puntuación en sí, veo qué tan bueno soy interactuando con la IA.

Desde el principio, pensaba que era realmente bueno solo porque usaba IA para todo. Pero me doy cuenta de que la IA no funciona de esa manera. Si crees que eres bueno, no significa que lo seas. Esto es solo un sistema de creencias. Así que más tarde, cuando implementé mi propia calificación como de cero a 10, me di cuenta de que obtengo un seis, todo era cinco. Solo porque estaba apresurándome. Intentaba decirle a la IA que hiciera el trabajo rápido en lugar de proporcionar el contexto. Así que sí, intenta implementar algo como la validación del sistema para ti.

Siguiente pregunta. ¿Has notado una reducción en la deuda técnica al implementar estos principios? Sí. Básicamente, lo que encontré es que si tienes buenas habilidades, si tienes buenas herramientas y agentes y las personas son conscientes de ellos y sabes cómo usarlos adecuadamente y actualizarlos, por supuesto, la deuda técnica es menor y también la calidad del código mejora. Pero si dejas a tu gente sin reglas, habilidades y cualquier cosa para escribir el mismo código exacto, recibirán resultados exactamente diferentes, lo cual es molesto. Sabemos que esta IA es muy, muy buena en hacer duplicaciones y también diferentes resultados en el mismo prompt exacto. Así que generalmente, de nuevo, intenta establecer los sistemas para tus desarrolladores. No los empujes ciegamente a usar cursor code o lo que sea que esté permitido en tu empresa. Deberías poder y ser responsable de proporcionarles los conjuntos de habilidades y también los agentes que usarán más adelante para entregar un código de buena calidad.

Muy bien. Hay dos preguntas aquí. No tenemos tiempo para ambas y están bastante superpuestas. Así que solo voy a elegir una. ¿Tienes algún consejo o técnica para lograr que los agentes consulten o ignoren, en su caso, consejos particulares de manera confiable? Sí. Así que lo que hicimos básicamente fue crear el agente, que es un agente de advertencia, y puedes hacer una pregunta y explicará directamente. Pero lo mejor en el contexto de tu proyecto específico. Así que es fácil. Si preguntas a la IA qué está haciendo esta función, explicará la función y también explicará lo que está sucediendo, pero no en el contexto de tu proyecto específico.